Mekanisme Konsensus Solana: Proof of History, Tower BFT, Proof of Stake

Catatan akurasi: Kinerja jaringan, jumlah validator, biaya, fitur protokol, dukungan wallet, dan integrasi pihak ketiga berubah seiring waktu. Perlakukan angka yang bertanggal sebagai snapshot historis dan verifikasi dokumentasi sumber primer saat ini.

Mekanisme konsensus Solana menggabungkan Proof of History untuk pengurutan waktu, Tower BFT untuk pemungutan suara yang ditimbang berdasarkan stake, dan Proof of Stake untuk partisipasi validator dan insentif.

TL;DR: Solana menggunakan Proof of History untuk pengurutan waktu, Tower BFT untuk pemungutan suara yang ditimbang berdasarkan stake dan pemilihan fork, dan Proof of Stake untuk partisipasi validator dan insentif. Throughput dan konfirmasi bergantung pada runtime penuh, kondisi jaringan, campuran transaksi, dan tingkat komitmen yang diukur.

Isi

1. Apa Itu Mekanisme Konsensus Solana?
2. Masalah yang Dibangun untuk Dipecahkan oleh Solana
3. Proof of History: Jam Kriptografis Solana Dijelaskan
4. Tower BFT: Cara Validator Mencapai Kesepakatan
5. Bagaimana Proof of History, Tower BFT, dan Proof of Stake Bekerja Sama
6. Bagaimana Transaksi Solana Mencapai Finalitas: Langkah demi Langkah
7. Kinerja Solana: Kecepatan, Throughput, dan Finalitas
8. Konsensus Solana vs. Ethereum, Avalanche, Cardano, dan Polkadot
9. Kekuatan dan Keterbatasan Model Konsensus Solana
10. Cara Berpartisipasi: Staking dan Validasi di Solana
11. Pertanyaan yang Sering Diajukan
12. Poin Penting

Solana dirancang untuk eksekusi throughput tinggi, latensi rendah, sementara riwayat gangguan dan persyaratan validatornya menciptakan pertanyaan penting tentang keandalan dan desentralisasi. Kompromi tersebut merupakan inti dari pemahaman mekanisme konsensus.

Solana meluncurkan Beta Mainnet pada Maret 2020 dan dengan cepat menarik perhatian karena memproses ribuan transaksi per detik dengan biaya sepersekian sen per transaksi. Protokol DeFi dan pasar NFT yang dibangun di atas Solana bergantung pada throughput tersebut; inilah yang membuat perdagangan waktu nyata, mint NFT massal, dan pembayaran biaya mikro praktis on-chain. Namun, kecepatan tanpa keandalan bukanlah fondasi yang seharusnya dibangun oleh siapa pun, dan beberapa peristiwa gangguan besar antara tahun 2021 dan 2023 menimbulkan pertanyaan yang sah tentang apakah arsitektur protokol tersebut kokoh.

Artikel ini menjelaskan mekanismenya secara jujur: cara kerjanya, mengapa cepat, mengapa jaringan berhenti, dan apa arti kompromi tersebut bagi siapa pun yang mengevaluasi Solana sebagai investor, pengembang, atau peserta.

Apa Itu Mekanisme Konsensus Solana?

Solana menggunakan sistem konsensus hibrida yang menggabungkan tiga komponen: Proof of History, Tower BFT, dan Proof of Stake. Proof of History bertindak sebagai jam kriptografis yang memberi stempel waktu transaksi sebelum validator berkomunikasi. Tower BFT adalah algoritma persetujuan Byzantine Fault Tolerant yang mencapai konsensus menggunakan PoH sebagai jam bersama. Proof of Stake menentukan validator mana yang berpartisipasi dan menimbang suara mereka berdasarkan SOL yang dipertaruhkan.

Ketiga komponen ini bukanlah nama yang dapat dipertukarkan untuk hal yang sama. Masing-masing memainkan peran yang berbeda dalam cara Solana menghasilkan dan mengonfirmasi blok pada blockchain-nya, buku besar terdistribusi yang mencatat semua transaksi di jaringan.

Berikut adalah cara kerja sistem pada tingkat tinggi:

1. Proof of History menghasilkan catatan waktu yang berkelanjutan dan dapat diverifikasi yang dibagikan oleh semua validator di jaringan.
2. Validator (peserta jaringan yang menghasilkan dan memverifikasi blok) ditugaskan pada slot waktu tertentu berdasarkan jumlah SOL yang mereka pertaruhkan.
3. Validator pemimpin yang ditugaskan untuk setiap slot menggunakan linimasa PoH untuk memberi stempel waktu dan merakit transaksi menjadi sebuah blok.
4. Semua validator lain memverifikasi blok dan memberikan suara Tower BFT yang ditimbang berdasarkan stake; ketika lebih dari dua pertiga stake SOL mengonfirmasi blok, blok tersebut mencapai finalitas.

Kesalahpahaman umum: Solana bukanlah blockchain Proof of Work (tidak ada pemecahan teka-teki komputasi atau komputasi yang boros energi). Menyebut Solana hanya sebagai "blockchain Proof of Stake" secara teknis akurat tetapi tidak lengkap. Ini menghilangkan Proof of History dan Tower BFT, yang sama-sama sentral bagi cara Solana mencapai konsensus. Deskripsi lengkap dan akuratnya adalah: Solana menggunakan sistem hibrida yang menggabungkan PoH, Tower BFT, dan PoS.

Masalah yang Dibangun untuk Dipecahkan oleh Solana

Setiap mekanisme konsensus blockchain menghadapi tantangan mendasar yang sama: bagaimana ribuan komputer yang terdistribusi secara geografis dapat menyetujui urutan transaksi tanpa saling mempercayai?

Trilemma skalabilitas blockchain, sebuah kerangka kerja yang dipopulerkan oleh salah satu pendiri Ethereum, Vitalik Buterin, menjelaskan mengapa ini sulit. Trilemma menyatakan bahwa blockchain paling banyak dapat mencapai dua dari tiga properti secara bersamaan: desentralisasi, keamanan, dan skalabilitas. Bitcoin, blockchain orisinal, memprioritaskan desentralisasi dan keamanan. Hasilnya adalah jaringan yang mencapai sekitar 7 transaksi per detik dengan waktu blok 10 menit, properti yang aman dan terdistribusi secara luas tetapi membuat Bitcoin tidak praktis untuk aplikasi frekuensi tinggi. Ethereum awal menghadapi kendala serupa sebelum jalur peningkatannya sendiri.

Hambatan spesifik yang membuat penskalaan sulit adalah latensi jaringan. Dalam konsensus blockchain tradisional, validator harus mengirim pesan berstempel waktu satu sama lain untuk menyetujui urutan transaksi. Overhead komunikasi antar-node ini menciptakan batas atas seberapa cepat jaringan apa pun dapat mencapai kesepakatan. Tidak peduli seberapa cepat komputer individu memproses data, mereka masih harus menunggu pesan untuk melakukan perjalanan melintasi dunia dan semua peserta untuk mengonfirmasi apa yang mereka terima.

Anatoly Yakovenko, mantan insinyur Qualcomm yang menghabiskan karirnya bekerja pada sistem terdistribusi dan sinkronisasi jam di tingkat perangkat keras, mengidentifikasi masalah komunikasi stempel waktu ini sebagai hambatan mendasar. Wawasan kuncinya: jika validator dapat berbagi satu jam tunggal yang dapat diverifikasi secara kriptografis yang mereka percayai tanpa perlu saling mengomunikasikan stempel waktu, proses konsensus bisa menjadi jauh lebih cepat. Pada November 2017, Yakovenko menerbitkan Solana: Arsitektur baru untuk blockchain berkinerja tinggi,) yang menguraikan apa yang akan menjadi Proof of History. Dia mendirikan Solana Labs (perusahaan pengembangan yang berorientasi pada keuntungan di balik protokol Solana) bersama Greg Fitzgerald dan Raj Gokal, dan ketiganya meluncurkan Beta Mainnet pada Maret 2020.

Tesis desain Solana adalah bahwa trilemma skalabilitas dapat dikurangi secara signifikan, tidak dihilangkan tetapi dikurangi, dengan menggabungkan pendekatan kriptografis baru (PoH) dengan kemampuan perangkat keras modern untuk mendorong ketiga metrik tersebut lebih tinggi secara bersamaan. Apakah pengurangan tersebut datang dengan mengorbankan desentralisasi adalah pertanyaan yang dijawab langsung oleh bukti dalam artikel ini.

Proof of History: Jam Kriptografis Solana Dijelaskan

Proof of History (PoH) adalah mekanisme pencatatan waktu kriptografi yang membuat catatan yang dapat diverifikasi dan tahan gangguan tentang kapan setiap peristiwa di jaringan Solana terjadi. Dengan memberikan jam bersama kepada semua validator yang dapat mereka percayai tanpa bertukar pesan, PoH memungkinkan algoritma konsensus Solana yang sebenarnya, Tower BFT, beroperasi dengan putaran komunikasi yang jauh lebih sedikit daripada sistem konsensus Blockchain standar mana pun.

PoH bukan merupakan Mekanisme Konsensus. Ini adalah jam yang memungkinkan Mekanisme Konsensus Solana terwujud.

Masalah Apa yang Diselesaikan oleh Proof of History?

Dalam jaringan terdistribusi tanpa otoritas pusat, validator tidak bisa begitu saja setuju untuk menggunakan jam dinding. Setiap Node berjalan pada perangkat keras yang berbeda di zona waktu yang berbeda, dan jam mengalami pergeseran. Yang lebih penting, validator jahat dapat memalsukan stempel waktu untuk memanipulasi urutan transaksi. Jaringan Blockchain tradisional memecahkan masalah ini dengan mewajibkan validator saling mengirim pesan berstempel waktu dan mencapai kesepakatan melalui beberapa putaran komunikasi. Setiap putaran komunikasi tambahan menambah latensi.

PoH menghilangkan latensi tersebut dengan membuat linimasa bersama yang dapat diverifikasi oleh semua validator secara independen, tanpa memerlukan komunikasi antar-Node untuk menetapkan kapan sesuatu terjadi.

Cara Kerja Proof of History: Hash Chain

Bayangkan PoH seperti stopwatch kriptografi yang berjalan terus menerus di jaringan. Setiap detik stopwatch menghasilkan output unik yang dapat diverifikasi. Karena setiap output dihasilkan dari output sebelumnya, siapa pun dapat memverifikasi seluruh urutan dan mengonfirmasi bahwa sejumlah waktu tertentu telah berlalu di antara dua titik mana pun, tanpa perlu memercayai pemilik jam tersebut.

Mekanisme teknisnya bekerja sebagai berikut:

1. Generator PoH Solana dimulai dengan nilai hash awal.
2. Ia menjalankan fungsi hash kriptografi SHA-256 pada nilai tersebut, menghasilkan output 256-bit baru.
3. Ia segera memasukkan kembali output tersebut sebagai Input untuk operasi SHA-256 berikutnya.
4. Setiap hash dalam rantai dicatat bersama dengan penghitung, membuat urutan yang dapat diverifikasi yang membuktikan waktu komputasi nyata telah berlalu.
5. Transaksi dimasukkan ke dalam hash chain pada posisi tertentu, secara permanen memberikan stempel waktu terhadap urutan yang dapat diverifikasi sebelum validator mana pun perlu berkomunikasi dengan yang lain.

Hasilnya adalah catatan publik tentang kapan tepatnya setiap transaksi masuk ke dalam antrean. Siapa pun dapat memverifikasi bahwa rantainya utuh. Tidak ada yang bisa memalsukan waktu yang dibutuhkan untuk memproduksinya.

Bahasa Sederhana: PoH seperti stopwatch kriptografi yang memberi stempel waktu pada setiap peristiwa bahkan sebelum validator perlu berkomunikasi. Ini adalah catatan publik tentang kapan tepatnya setiap transaksi masuk ke antrean, dapat diverifikasi oleh siapa saja, tidak dapat dimanipulasi oleh siapa pun.

Pendalaman Teknis: SHA-256 adalah fungsi hash kriptografi satu arah: cepat dihitung dalam satu arah, tetapi secara komputasi tidak mungkin untuk direkayasa balik. Perantaian berurutan dari output SHA-256 memberikan PoH properti "verifiable delay"-nya: rantai tersebut membutuhkan waktu nyata untuk diproduksi (komputasi berurutan tidak dapat diparalelkan), tetapi dapat diverifikasi secara paralel dengan sangat cepat oleh pengamat mana pun yang memeriksa setiap hash terhadap hash sebelumnya. Ini secara fungsional mirip dengan Verifiable Delay Function (VDF), sebuah konstruksi kriptografi yang membutuhkan jumlah minimum komputasi berurutan untuk diproduksi tetapi dapat diverifikasi dengan cepat. Peran SHA-256 dalam PoH sepenuhnya berbeda dari perannya dalam Bitcoin, di mana ia digunakan sebagai teka-teki kompetitif (menemukan hash di bawah target). Dalam PoH, SHA-256 digunakan untuk pencatatan waktu berurutan, bukan untuk komputasi kompetitif.

Apa Itu Proof of History dan Apa yang Bukan

Proof of History bukan merupakan Mekanisme Konsensus Solana. Mekanisme Konsensus adalah proses di mana validator mencapai kesepakatan tentang transaksi mana yang valid dan dalam urutan apa. PoH tidak melakukan itu. PoH mencatat urutan dan waktu peristiwa; Tower BFT adalah algoritma yang mencapai konsensus tentang apakah peristiwa tersebut valid.

PoH juga bukan Proof of Stake. Proof of Stake menentukan siapa yang secara ekonomi memenuhi syarat untuk berpartisipasi dalam konsensus dan seberapa besar bobot suara mereka. PoH tidak menentukan kelayakan atau bobot suara; ia menyediakan jam bersama yang membuat proses pemungutan suara lebih cepat.

Kesalahpahaman bahwa "Solana menggunakan Proof of History" sebagai Mekanisme Konsensus lengkapnya adalah salah satu kesalahan paling umum dalam tulisan publik tentang Solana. Hal ini tidak akurat, dan ini penting: tanpa Tower BFT dan Proof of Stake, PoH saja tidak akan memberikan jaminan keamanan.

Tower BFT: Cara Validator Mencapai Kesepakatan

Tower BFT adalah algoritma konsensus Solana, sebuah adaptasi dari Practical Byzantine Fault Tolerance (PBFT) yang dibangun untuk menggunakan PoH sebagai jam bersama. Ini memungkinkan validator untuk mencapai kesepakatan pada status buku besar menggunakan suara dengan bobot stake. Karena validator berbagi Proof of History sebagai jam tepercaya, Tower BFT memerlukan jauh lebih sedikit putaran komunikasi daripada implementasi BFT standar, dan memfinalisasi blok dalam waktu sekitar 400 hingga 800 milidetik dalam kondisi jaringan normal.

Apa Itu Byzantine Fault Tolerance?

Nama ini berasal dari Masalah Jenderal Bizantium (Byzantine Generals Problem), sebuah eksperimen pemikiran sistem terdistribusi klasik yang diresmikan oleh Leslie Lamport pada tahun 1982. Masalahnya menanyakan: bagaimana sekelompok jenderal dapat mengoordinasikan serangan ketika beberapa dari mereka mungkin adalah pengkhianat yang mengirimkan informasi palsu? Sebuah sistem memiliki sifat Byzantine Fault Tolerant jika ia dapat mencapai konsensus yang benar bahkan ketika beberapa peserta bertindak jahat, mengirim pesan palsu, atau gagal secara sewenang-wenang.

Sistem BFT tradisional, termasuk algoritma dasar PBFT yang diterbitkan oleh Miguel Castro dan Barbara Liskov pada tahun 1999, mensyaratkan bahwa kurang dari sepertiga dari seluruh peserta rusak atau jahat. Untuk jaringan dengan 100 validator, hingga 33 dapat dikompromikan dan 67 sisanya masih dapat mencapai konsensus yang benar. Properti ini dapat dibuktikan secara matematis, yang membuat sistem berbasis BFT menarik untuk aplikasi yang mementingkan keamanan.

Tower BFT Solana mewarisi properti ini. Penyerang perlu mengendalikan lebih dari sepertiga dari semua SOL yang di-stake untuk menghentikan jaringan, dan lebih dari dua pertiga untuk mengesampingkan konsensus. Tidak seperti jaringan Proof of Work di mana penyerang membutuhkan 51% daya komputasi, Tower BFT Solana mengharuskan pengendalian lebih dari 33% dari semua SOL yang di-stake untuk menghentikan jaringan. Ambang batas tersebut umumnya dianggap lebih sulit dicapai dalam praktiknya karena memerlukan akumulasi modal, bukan hanya sumber daya komputasi.

Pendalaman Teknis: PBFT standar memerlukan kompleksitas pesan O(n²), dengan n adalah jumlah validator. Setiap validator harus berkomunikasi dengan setiap validator lainnya untuk mengonfirmasi kesepakatan. Untuk jaringan dengan ribuan validator, hal ini menciptakan overhead komunikasi yang sangat besar. Tower BFT mengurangi overhead ini dengan menggunakan PoH sebagai jam bersama: karena semua validator setuju pada waktu dari urutan PoH tanpa saling berkirim pesan tentangnya, Tower BFT hanya mengharuskan validator untuk memilih validitas blok, bukan pada urutan stempel waktu. Mekanisme penguncian (lockout) menambah efisiensi lain: ketika validator memilih suatu blok, ia terkunci pada pilihan tersebut untuk periode waktu tunggu yang meningkat secara eksponensial. Mengganti pilihan mengharuskan menunggu waktu penguncian habis, menciptakan disinsentif ekonomi untuk reorganisasi (Fork) dan mengurangi jumlah putaran pemungutan suara yang diperlukan untuk mencapai finalitas.

Bagaimana Tower BFT Menggunakan Proof of History

Tanpa jam bersama, validator dalam sistem BFT standar harus saling mengirim pesan berstempel waktu untuk menetapkan urutan peristiwa, sehingga menambah overhead komunikasi di setiap langkah. Dengan PoH, urutan sudah ditetapkan dan dapat diverifikasi oleh setiap validator secara independen.

Validator memberikan suara berbobot stake pada blok, dan Tower BFT menggunakan penguncian (lockout) dan pemungutan suara mayoritas super dalam pemilihan Fork. Konfirmasi optimistik, konfirmasi berakar, dan finalitas ekonomi tingkat aplikasi adalah ambang batas yang berbeda. Pengaturan waktunya bervariasi sesuai kondisi klaster dan harus diperiksa dalam dokumentasi saat ini daripada direduksi menjadi angka milidetik tetap.

Jadwal Pemimpin: Bagaimana Solana Memilih Validator

Pada awal setiap epoch, Solana menghitung penugasan deterministik mengenai validator mana yang akan bertugas sebagai leader untuk setiap slot mendatang. Penugasan tersebut sebanding dengan bobot stake masing-masing validator: validator yang mengendalikan 5% dari seluruh SOL yang di-stake akan ditugaskan sebagai leader untuk sekitar 5% dari seluruh slot dalam epoch tersebut.

Sebuah slot adalah unit waktu dasar Solana, yang menargetkan sekitar 400 milidetik per slot (verifikasi angka terbaru dari docs.solana.com saat penulisan). Sebuah epoch mencakup sekitar 432.000 slot, yang berarti kurang lebih dua hingga tiga hari (verifikasi dari docs.solana.com saat penulisan).

Jadwal leader diketahui secara publik sebelumnya. Validator dapat menggunakannya untuk meneruskan transaksi ke arah leader mendatang sebelum slot tersebut dimulai. Hal ini mengurangi ketergantungan pada Mempool global konvensional, tetapi tidak menghilangkan kemacetan, persaingan biaya prioritas, kegagalan transaksi, atau risiko MEV.

Implikasi desentralisasi dari kepemimpinan berbobot stake sangatlah langsung: validator dengan lebih banyak SOL yang di-stake menerima slot leader yang lebih banyak secara proporsional, yang berarti mereka menghasilkan blok yang lebih banyak secara proporsional. Struktur ini memberi para staker besar pengaruh lebih besar atas transaksi mana yang dimasukkan dan dalam urutan apa. Konsekuensi konkret dari konsentrasi tersebut, termasuk koefisien Nakamoto Solana dan hambatan partisipasi perangkat keras, diperiksa di bagian kekuatan dan batasan di bawah ini.

Cara Kerja Proof of History, Tower BFT, dan Proof of Stake Bersama-sama

Proof of History, Tower BFT, dan Proof of Stake bukanlah tiga mekanisme konsensus terpisah yang berjalan secara paralel. Semuanya adalah tiga lapisan yang saling bergantung dari satu sistem terintegrasi tunggal, yang masing-masing menyelesaikan bagian berbeda dari masalah konsensus terdistribusi.

Proof of Stake adalah fondasi ekonomi. Validator harus melakukan stake (mengunci) SOL untuk berpartisipasi dalam konsensus. Stake ini menciptakan keterlibatan finansial (skin in the game): validator yang memberikan suara secara tidak benar atau mencoba memanipulasi buku besar berisiko kehilangan SOL yang mereka stake melalui pemotongan/slashing (verifikasi detail implementasi pemotongan saat ini dari docs.solana.com, karena hal ini berkembang seiring dengan pembaruan protokol). Delegator, yang berarti pemegang SOL mana pun yang tidak ingin menjalankan validator, dapat melakukan stake SOL mereka ke validator dan mendapatkan bagian dari imbalan validator tersebut yang sebanding dengan delegasi mereka.

Setelah Proof of Stake menetapkan siapa yang berpartisipasi dan dengan bobot berapa, Proof of History menyediakan garis waktu yang digunakan oleh para peserta tersebut. Jam PoH berjalan terus-menerus, menghasilkan urutan hash yang dapat diverifikasi yang memberi stempel waktu pada setiap transaksi. Tidak diperlukan komunikasi antar-Node untuk menetapkan urutan karena semua validator dapat memverifikasi urutan PoH secara independen.

Tower BFT adalah algoritma yang digunakan oleh para validator yang memenuhi syarat dan tersinkronisasi waktu tersebut untuk memberikan suara. Kombinasi antara jam bersama (PoH) dan sistem pemungutan suara yang diamankan secara ekonomi (Tower BFT berbobot PoS) menghasilkan konsensus yang cepat sekaligus tahan terhadap manipulasi.

Validator mencapai konsensus pada status blok, yang mencakup hasil dari Kontrak Pintar, yang disebut program dalam ekosistem Solana. Runtime Kontrak Pintar paralel Solana (Sealevel) memungkinkan beberapa program yang tidak saling bertentangan untuk dieksekusi secara bersamaan, yang berkontribusi lebih jauh pada throughput jaringan.

Bagaimana Transaksi Solana Mencapai Finalitas: Langkah demi Langkah

Transaksi Solana dapat diarahkan ke leader yang dijadwalkan tanpa menunggu di Mempool global konvensional. Siklus hidupnya mengikuti tahapan di bawah ini, tetapi konfirmasi dan Waktu Penyelesaian bervariasi tergantung pada tingkat komitmen dan kondisi klaster; target durasi slot bukanlah jaminan finalitas penuh.

1. Pengiriman Transaksi. Pengguna menandatangani dan menyiarkan transaksi ke jaringan Solana. Transaksi yang ditandatangani berisi semua informasi yang dibutuhkan validator untuk memverifikasi keasliannya: Kunci Publik pengirim, operasi yang dimaksudkan, dan tanda tangan kriptografi yang membuktikan pengirim telah mengizinkannya. Penandatanganan terjadi secara lokal; transaksi kemudian menyebar ke jaringan.

2. Penerusan Sadar-Leader. Solana meneruskan transaksi ke leader mendatang yang diidentifikasi dari jadwal publik. Tidak seperti Mempool global konvensional, desain ini dapat menyiapkan pekerjaan sebelum slot leader dimulai, sementara kemacetan, kehilangan paket, Kedaluwarsa transaksi, biaya prioritas, dan insentif pengurutan tetap memengaruhi hasilnya.

3. Stempel Waktu PoH Leader. Validator leader memasukkan transaksi ke dalam Posisi saat ini dalam rantai hash PoH, yang secara permanen mencatat Posisi transaksi dalam garis waktu yang dapat diverifikasi. Stempel waktu ini terikat secara kriptografi pada urutan semua hash PoH sebelumnya; ia tidak dapat diubah secara retroaktif tanpa membatalkan setiap hash berikutnya, sehingga catatannya terbukti tahan sabotase.

4. Produksi Blok. Dalam jendela slot sekitar 400 milidetik, leader menyusun semua transaksi yang telah diberi stempel waktu ke dalam sebuah blok. Karena transaksi tiba dengan urutan yang telah ditentukan oleh urutan PoH, leader tidak perlu merundingkan pengurutan dengan validator lain. Leader cukup membangun blok sesuai dengan garis waktu yang telah ditetapkan.

5. Propagasi Turbine. Protokol propagasi blok Turbine Solana memecah blok yang sudah jadi menjadi paket data yang lebih kecil yang disebut shred dan mendistribusikannya ke seluruh validator lain menggunakan struktur propagasi pohon yang terinspirasi oleh BitTorrent. Alih-alih menyiarkan blok penuh ke setiap validator secara bersamaan (yang akan membutuhkan bandwidth besar pada volume tinggi), Turbine meneruskan shred melalui pohon validator yang terstruktur, dengan masing-masing validator bertanggung jawab untuk meneruskan ke sejumlah kecil rekan (peer). Hal ini mengurangi beban bandwidth pada satu validator tunggal sekaligus memastikan blok penuh mencapai semua peserta dengan cepat.

6. Pemungutan Suara Tower BFT. Setelah menerima shred blok dan merekonstruksi blok penuh, validator lain memverifikasi bahwa urutan PoH valid dan transaksi dibentuk dengan benar. Setiap validator memberikan suara Tower BFT berbobot stake pada validitas blok tersebut. Validator dengan lebih banyak SOL yang di-stake membawa bobot yang lebih besar secara proporsional dalam pemungutan suara ini. Suara-suara tersebut merambat melalui jaringan saat validator memberikan sinyal konfirmasi mereka.

7. Finalitas. Ketika validator yang secara kolektif mewakili lebih dari dua pertiga dari seluruh SOL yang di-stake telah mengonfirmasi blok tersebut, blok tersebut mencapai finalitas Tower BFT dan dicatat secara permanen di buku besar. Ambang batas mayoritas super ini adalah persyaratan 2/3+ yang sama yang mendasari teori Byzantine Fault Tolerance: ini menjamin bahwa konsensus tetap berlaku bahkan jika hingga sepertiga peserta berbobot stake mengalami kegagalan atau bertindak jahat.

Terminologi finalitas: Target waktu slot tidak sama dengan konfirmasi optimistik, rooting, atau finalitas ekonomi. Aplikasi harus memilih tingkat komitmen berdasarkan persyaratan risiko mereka dan memverifikasi perilaku klaster saat ini.

Performa Solana: Kecepatan, Throughput, dan Finalitas

Kecepatan Solana bukanlah hasil dari satu pilihan desain tunggal. Ini adalah efek kumulatif dari empat keputusan arsitektur yang bekerja dalam koordinasi: Proof of History, Tower BFT, protokol Gulf Stream Solana, dan protokol propagasi blok Turbine Solana.

Mengapa Solana Cepat? Empat Alasannya

1. Proof of History menyediakan referensi urutan yang dapat diverifikasi yang dapat mengurangi beberapa overhead koordinasi waktu; validator tetap bertukar suara dan data jaringan.
2. Tower BFT membutuhkan lebih sedikit putaran pemungutan suara dibandingkan implementasi BFT standar karena semua validator berbagi jam PoH yang sama dan tidak perlu merundingkan waktu.
3. Leader-aware forwarding mengirimkan transaksi ke pemimpin (leader) mendatang sebelum slot mereka dimulai, yang dapat mengurangi antrean mempool konvensional tanpa menghilangkan semua latensi atau persaingan biaya.
4. Protokol propagasi blok Turbine Solana mendistribusikan blok dalam potongan-potongan kecil (shreds) melalui struktur pohon daripada menyiarkan blok penuh ke setiap validator secara bersamaan, sehingga mengurangi persyaratan bandwidth di seluruh jaringan besar.

Throughput maksimum teoritis Solana adalah angka teoritis historis sekitar 65.000 transaksi per detik dalam kondisi jaringan ideal. Angka tersebut adalah tolok ukur, bukan deskripsi kinerja umum. Throughput Mainnet di dunia nyata secara historis rata-rata sekitar 2.000 hingga 4.000 TPS, dengan lonjakan selama periode permintaan tinggi. Kesenjangan antara maksimum teoritis dan rata-rata dunia nyata mencerminkan penundaan propagasi jaringan, distribusi geografis validator, dan overhead perangkat lunak yang tidak tertangkap oleh tolok ukur kondisi ideal. Verifikasi angka terbaru dari Solscan (solscan.io) pada saat penulisan.

Dokumentasi Solana secara historis menggambarkan target waktu slot mendekati 400 milidetik, tetapi slot aktual dan tahapan konfirmasi bervariasi. Konfirmasi optimis, rooting, dan finalitas ekonomi tingkat aplikasi adalah ambang batas yang berbeda dan harus diukur menggunakan dokumentasi terbaru dan kondisi klaster langsung.

Sebagai perbandingan: Ethereum, yang beralih dari Proof of Work ke Proof of Stake pada September 2022, sekarang mencapai sekitar 15 hingga 30 TPS pada Lapisan 1 dengan finalitas ekonomi penuh memakan waktu sekitar 12 hingga 15 menit melalui epoch checkpoint Casper FFG (verifikasi dari ethereum.org). Mekanisme Konsensus Nakamoto Bitcoin mencapai sekitar 7 TPS dengan finalitas probabilistik memakan waktu sekitar 60 menit melalui 6 konfirmasi blok.

Kesenjangan finalitas antara Solana dan Lapisan 1 Ethereum sangat besar. Apakah kesenjangan itu penting bagi kasus penggunaan tertentu bergantung pada aplikasinya. Jaringan Lapisan 2 Ethereum (Arbitrum, Optimism, dan lainnya) menawarkan finalitas yang lebih cepat daripada L1 Ethereum, meskipun mereka beroperasi melalui mekanisme yang berbeda dari konsensus Solana.

Konsensus Solana vs. Ethereum, Avalanche, Cardano, dan Polkadot

Solana bukan satu-satunya blockchain berkinerja tinggi, dan Mekanisme Konsensus-nya bukan satu-satunya pendekatan untuk finalitas transaksi yang cepat dan skalabel. Berikut adalah perbandingan sistem PoH + Tower BFT + PoS Solana secara arsitektural dan berdasarkan metrik kinerja terhadap alternatif paling terkemuka.

Ethereum (pasca-Merge, September 2022) sekarang menggunakan Gasper, sistem konsensus yang menggabungkan LMD-GHOST (aturan Fork choice yang memilih rantai dengan akumulasi atestasi validator terbanyak) dan Casper FFG (perangkat finalitas yang secara berkala melakukan checkpoint pada rantai). Ethereum beralih dari Proof of Work ke Proof of Stake pada 15 September 2022. Kontras arsitektural dengan Solana sangat signifikan: Gasper Ethereum mencapai keamanan dan desentralisasi melalui set validator yang sangat besar (sekitar 900.000 atau lebih validator, verifikasi dari beaconcha.in pada saat penulisan) dengan mengorbankan throughput. Solana mencapai throughput melalui mekanisme jam PoH dan efisiensi Tower BFT, tetapi dengan set validator yang jauh lebih kecil.

Avalanche (C-Chain) menggunakan konsensus Snowman, varian rantai linier dari protokol konsensus Avalanche. Snowman bersifat probabilistik dan berbasis pengambilan sampel, bukan BFT deterministik: validator berulang kali mengambil sampel subset acak dari validator lain untuk mengukur kesepakatan. Angka throughput dan finalitas yang dipublikasikan bervariasi menurut tanggal, beban kerja, dan metode pengukuran, sehingga sumber primer saat ini harus digunakan untuk perbandingan. Kontras arsitekturalnya adalah Avalanche menggunakan pengambilan sampel ulang berulang (repeated subsampling), sementara Solana menggunakan pemungutan suara berbobot taruhan (stake-weighted voting) yang dibangun di sekitar referensi urutan PoH.

Cardano menggunakan Ouroboros Praos, versi mainnet saat ini dari keluarga konsensus PoS Ouroboros. Ouroboros adalah protokol PoS pertama yang terbukti aman, diterbitkan di tempat-tempat akademik yang ditinjau sejawat (peer-reviewed) dengan bukti keamanan matematis formal. Desain Cardano secara eksplisit memprioritaskan kebenaran formal dan bukti keamanan di atas throughput mentah. TPS dunia nyata di mainnet Cardano adalah sekitar 250 (verifikasi pada saat penulisan). Kontras filosofi desain dengan Solana sangat nyata: Solana memprioritaskan throughput melalui inovasi arsitektural; Cardano memprioritaskan keterbuktian formal dari properti keamanan melalui ketelitian akademik.

Polkadot (relay chain) menggunakan BABE (Blind Assignment for Blockchain Extension) untuk produksi blok dan GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) untuk finalitas, mencapai sekitar 1.000 TPS pada relay chain dengan finalitas berkisar antara 12 hingga 60 detik. Arsitektur relay chain plus parachain Polkadot secara mendasar berbeda dari desain rantai monolitik Solana, membuat perbandingan kinerja langsung lebih kompleks daripada yang disarankan oleh angka-angka tabel saja.

Semua angka adalah perkiraan terarah. Metrik kinerja bervariasi menurut kondisi jaringan; maksimum teoritis mewakili kapasitas kondisi ideal. Verifikasi angka terbaru dari dokumentasi resmi (docs.solana.com, ethereum.org, Solana Beach, beaconcha.in) sebelum membuat keputusan apa pun. Jumlah validator sering berubah.

Kekuatan dan Keterbatasan Model Konsensus Solana

Arsitektur konsensus Solana memberikan keunggulan kecepatan dan throughput yang terukur dibandingkan setiap blockchain Lapisan 1 utama, tetapi keunggulan tersebut datang dengan pengorbanan nyata dalam desentralisasi dan catatan keandalan historis yang harus ditangani secara jujur oleh evaluasi serius mana pun.

Kekuatan:

• Target konfirmasi latensi rendah. Solana dapat memberikan konfirmasi optimis yang cepat, tetapi tingkat komitmen dan finalitas ekonomi harus dibedakan.
• Desain throughput tinggi. Tolok ukur historis mengilustrasikan kapasitas arsitektural, sementara throughput langsung bergantung pada beban kerja, akuntansi suara, validator, kemacetan, dan versi perangkat lunak.
• Biaya transaksi rendah. Kapasitas throughput yang tinggi berarti persaingan biaya antar transaksi lebih rendah, menjaga biaya tetap pada pecahan sen untuk sebagian besar operasi.
• Penerusan transaksi tanpa Mempool. Protokol Gulf Stream Solana menghilangkan masalah ruang tunggu (waiting room), mengurangi latensi konfirmasi dengan melakukan pra-perutean transaksi ke pemimpin (leader) mendatang yang sudah diketahui.
• Efisiensi energi. Proof of Stake tidak memerlukan komputasi intensif energi, menempatkan jejak energi Solana dalam kategori yang secara mendasar berbeda dari Proof of Work Bitcoin.

Keterbatasan:

• Pemadaman jaringan historis. Solana mengalami beberapa kali penghentian jaringan total antara tahun 2021 dan 2023, menciptakan kekhawatiran keandalan nyata yang harus ditimbang oleh investor atau pengembang mana pun.
• Lebih sedikit validator dibandingkan Ethereum. Set validator yang relatif kecil menciptakan profil desentralisasi yang berbeda dari jaringan dengan ratusan ribu validator.
• Persyaratan perangkat keras yang tinggi menciptakan hambatan partisipasi. Menjalankan validator Solana menuntut perangkat keras kelas server yang tidak mampu dibeli atau dioperasikan oleh kebanyakan individu, sehingga membatasi siapa yang dapat berpartisipasi dalam konsensus secara langsung.
• Ketergantungan pada klien validator tunggal (pra-Firedancer). Hingga baru-baru ini, hampir semua validator Solana menjalankan klien perangkat lunak yang sama, menciptakan titik kegagalan tunggal jika klien tersebut memiliki bug.
• Konsentrasi Stake di antara validator teratas. Sebagian besar dari total SOL yang di-stake terkonsentrasi di antara sejumlah kecil validator, yang memengaruhi koefisien Nakamoto.

Mengapa Jaringan Solana Pernah Down?

Pemadaman historis Solana tidak disebabkan oleh kegagalan dalam algoritme Mekanisme Konsensus Proof of History atau Tower BFT. Desain konsensus itu sendiri tidak rusak. Akar penyebab yang didokumentasikan dari pemadaman besar adalah kehabisan sumber daya perangkat lunak dan bug implementasi: spam transaksi yang membebani kapasitas memori validator, bug perangkat lunak pada klien validator yang menyebabkan crash, dan kehabisan sumber daya yang dipicu oleh peristiwa permintaan tinggi termasuk lonjakan Mint NFT dan lonjakan aktivitas DeFi.

Peristiwa spesifik mengilustrasikan polanya. Pada September 2021, Solana mengalami pemadaman selama 17 jam yang disebabkan oleh banjir transaksi dari peristiwa IDO yang menjenuhkan memori validator dan memicu Fork jaringan yang memerlukan restart terkoordinasi. Pada Januari 2022, pemadaman signifikan kedua bermula dari kehabisan sumber daya selama kondisi throughput tinggi. Beberapa peristiwa degradasi parsial tambahan terjadi sepanjang tahun 2022 (verifikasi tanggal dan durasi spesifik dari laporan post-mortem Solana Foundation pada saat penulisan, karena daftar insiden yang didokumentasikan telah bertambah). Perbedaan antara peristiwa ini dan kegagalan algoritme konsensus penting untuk mengevaluasi kelangsungan jangka panjang Solana: algoritme konsensus yang rusak akan memerlukan desain ulang protokol, sementara kehabisan sumber daya perangkat lunak adalah masalah teknik yang dapat diperbaiki.

Peningkatan yang diimplementasikan sejak periode puncak pemadaman termasuk adopsi QUIC sebagai protokol jaringan (menggantikan pendekatan berbasis UDP yang lebih rentan terhadap spam), sistem quality-of-service tertimbang stake yang memprioritaskan transaksi dari validator yang melakukan staking daripada spam anonim, dan peningkatan perangkat lunak klien validator yang berkelanjutan. Klien Firedancer, implementasi validator performa tinggi independen yang dikembangkan oleh Jump Kripto, bertujuan untuk menyediakan keragaman klien yang akan mencegah bug perangkat lunak tunggal memengaruhi seluruh jaringan. Verifikasi Status pengembangan Firedancer saat ini dari sumber resmi pada saat penulisan.

Frekuensi dan tingkat keparahan pemadaman mewakili kekhawatiran keandalan yang nyata, bukan sekadar ketidaknyamanan kecil. Jaringan yang memproses transaksi keuangan tidak boleh mengalami penghentian yang tidak terencana. Peningkatan yang dilakukan sejak periode pemadaman terburuk bersifat substantif, tetapi rekam jejak tersebut adalah bagian dari evaluasi yang harus dilakukan oleh siapa pun yang membangun di atas Solana atau memegang SOL dengan mata terbuka.

Desentralisasi dan konsentrasi validator: Solana memiliki sekitar 1.500 atau lebih validator aktif pada saat penulisan (verifikasi jumlah saat ini dari analitik validator Solana Beach). Ethereum memiliki sekitar 900.000 atau lebih validator (verifikasi dari beaconcha.in). Perbedaannya sangat besar dan mencerminkan hambatan perangkat keras untuk validasi Solana: menjalankan validator Solana membutuhkan RAM sekitar 128GB atau lebih, penyimpanan NVMe SSD performa tinggi sebesar 2TB atau lebih, dan koneksi jaringan setidaknya 1Gbps (verifikasi spesifikasi saat ini dari docs.solana.com/running-validator pada saat penulisan). Sebaliknya, validator Ethereum dapat berjalan pada perangkat keras kelas konsumen bersama dengan 32 ETH.

Koefisien Nakamoto Solana (jumlah minimum entitas yang perlu berkolusi untuk mengompromikan konsensus) secara historis berkisar antara sekitar 19 dan 31 validator, meskipun angka ini berubah seiring perubahan distribusi stake. Verifikasi koefisien saat ini dari laporan desentralisasi Solana Foundation atau Nakaflow pada saat penulisan. 20 validator teratas secara historis telah mengendalikan bagian signifikan dari total SOL yang di-stake (verifikasi persentase konsentrasi saat ini dari Solana Beach). Solana Foundation mengoperasikan program delegasi yang dirancang khusus untuk mendistribusikan stake ke validator yang lebih kecil dan meningkatkan koefisien ini, memberikan tindakan pencegahan struktural terhadap konsentrasi. Ambang batas keamanan Tower BFT berarti penyerang perlu mengendalikan lebih dari sepertiga dari semua SOL yang di-stake untuk menghentikan jaringan, dan lebih dari dua pertiga untuk mengesampingkan konsensus, sebuah persyaratan modal tinggi yang berskala dengan seberapa terkonsentrasi stake tersebut dalam praktiknya.

Cara Berpartisipasi: Staking dan Validasi di Solana

Pemegang SOL dapat berpartisipasi dalam Mekanisme Konsensus Solana dengan dua cara: dengan mengoperasikan Node validator secara langsung, atau dengan mendelegasikan SOL ke validator yang sudah ada. Jalur pertama membutuhkan investasi perangkat keras yang signifikan dan keahlian teknis. Jalur kedua dapat diakses oleh setiap pemegang SOL dengan wallet yang kompatibel.

Penafian: Artikel ini hanya untuk tujuan informasi dan pendidikan. Ini bukan merupakan nasihat keuangan, nasihat investasi, atau rekomendasi untuk membeli, menjual, atau memegang mata uang kripto apa pun. Investasi mata uang kripto membawa risiko signifikan, termasuk potensi kehilangan modal. Selalu lakukan riset Anda sendiri dan konsultasikan dengan penasihat keuangan yang berkualifikasi sebelum membuat keputusan investasi.

Persyaratan untuk Menjalankan Validator Solana

Mengoperasikan validator Solana menjadikan operator sebagai pemimpin untuk slot yang ditentukan dan pemilih untuk semua slot lainnya. Persyaratan perangkat keras sangat besar dan telah meningkat seiring pertumbuhan jaringan. Selalu verifikasi spesifikasi saat ini dari dokumentasi resmi validator Solana) sebelum berkomitmen pada perangkat keras:

• CPU: Performa single-thread tinggi; rekomendasi model spesifik diperbarui dalam dokumentasi resmi.
• RAM: Minimum 128GB direkomendasikan; 256GB atau lebih untuk performa terbaik.
• Penyimpanan: NVMe SSD performa tinggi; 2TB atau lebih direkomendasikan.
• Jaringan: Koneksi minimum 1Gbps; 10Gbps direkomendasikan untuk performa kompetitif.
• Stake SOL: Stake yang didelegasikan sendiri secara memadai atau stake yang didelegasikan dari komunitas untuk membuat operasional layak secara ekonomi. Tidak ada minimum stake yang diwajibkan protokol untuk menjalankan validator, tetapi validator dengan stake yang sangat kecil mendapatkan imbalan yang sangat kecil.

Persyaratan perangkat keras meningkat seiring setiap pemutakhiran jaringan utama. Siapa pun yang berencana mengoperasikan validator harus menganggarkan untuk pemutakhiran perangkat keras berkelanjutan dan mengonfirmasi semua spesifikasi dari dokumentasi resmi sebelum membeli peralatan.

Cara Stake SOL: Opsi Staking Native dan Liquid

Mendelegasikan SOL ke validator yang sudah ada adalah jalur yang dapat diakses oleh sebagian besar peserta. Mekanismenya bekerja sebagai berikut.

Native staking: Menggunakan wallet yang kompatibel seperti Phantom atau Solflare, setiap pemegang SOL dapat mendelegasikan token mereka ke validator pilihan mereka. Delegasi tersebut mendapatkan bagian dari imbalan inflasi validator tersebut, proporsional dengan jumlah yang didelegasikan. APY staking saat ini bervariasi berdasarkan parameter inflasi jaringan dan total SOL yang di-stake (verifikasi dari Solana Beach pada saat penulisan sebelum membuat keputusan staking apa pun). Ada periode cooldown pembatalan delegasi sekitar dua epoch, yang berarti sekitar empat hingga lima hari, sebelum SOL yang didelegasikan menjadi liquid kembali (verifikasi dari docs.solana.com pada saat penulisan).

Liquid staking: Protokol termasuk Marinade Finance (yang menerbitkan token mSOL) dan Jito (yang menerbitkan token jitoSOL) memungkinkan pengguna untuk melakukan Staking SOL sambil menjaga Likuiditas. Daripada mengunci SOL secara langsung dengan validator dan menunggu masa cooldown untuk mengaksesnya, pengguna liquid staking menerima token likuid yang mewakili SOL yang mereka pertaruhkan plus hadiah yang diperoleh, yang dapat diperdagangkan kapan saja. Token liquid staking ini adalah bagian dari protokol DeFi yang beroperasi di Solana dan membawa risiko Kontrak Pintar mereka sendiri di luar ekonomi Staking yang mendasarinya.

Saat memilih validator untuk pendelegasian, kriteria yang relevan mencakup catatan waktu aktif historis validator, tingkat komisi (persentase hadiah yang diambil validator sebelum meneruskan sisanya ke delegator), dan konsentrasi stake. Mendelegasikan ke validator yang lebih kecil meningkatkan desentralisasi jaringan dan mungkin memenuhi syarat untuk manfaat program pendelegasian Solana Foundation.

Pertanyaan Umum Tentang Mekanisme Konsensus Solana

Mekanisme konsensus apa yang digunakan Solana?

Solana menggunakan sistem konsensus hibrida yang menggabungkan tiga komponen: Proof of History (PoH), Tower BFT, dan Proof of Stake (PoS). PoH bertindak sebagai jam kriptografi yang menetapkan urutan transaksi. Tower BFT adalah algoritma persetujuan yang digunakan validator untuk mengonfirmasi blok. PoS menentukan validator mana yang berpartisipasi dan membobot suara mereka berdasarkan SOL yang di-Staking.

Apakah Solana merupakan Blockchain Proof of Stake?

Solana memang menggunakan Proof of Stake sebagai lapisan keamanan ekonominya, jadi menyebutnya sebagai Blockchain PoS secara teknis akurat. Namun, itu belum lengkap. Proof of Stake saja tidak menjelaskan bagaimana Solana mencapai konsensus. Mekanisme lengkapnya memerlukan Proof of History (jam kriptografi yang menetapkan pengurutan tanpa komunikasi antar-validator) dan Tower BFT (algoritma pemungutan suara yang mencapai finalitas). Deskripsi yang akurat: Solana menggunakan sistem konsensus hibrida PoH + Tower BFT + PoS.

Seberapa cepat Solana dibandingkan dengan Ethereum?

Tolok ukur historis melaporkan throughput yang sangat berbeda untuk Solana dan Ethereum Lapisan 1, tetapi definisi transaksi, lalu lintas suara, eksekusi Lapisan 2, ketersediaan data, dan model finalitas berbeda. Gunakan pengukuran saat ini yang sebanding dan bedakan konfirmasi optimistik dari Penyelesaian yang difinalisasi atau yang secara ekonomi tidak dapat diubah.

Pemadaman jaringan historis Solana disebabkan oleh kehabisan sumber daya perangkat lunak dan bug implementasi, bukan oleh kegagalan dalam algoritma konsensus Proof of History atau Tower BFT. Penyebab yang terdokumentasi termasuk spam transaksi yang membebani kapasitas memori validator, bug perangkat lunak pada klien validator, dan kehabisan sumber daya selama peristiwa permintaan tinggi seperti pencetakan NFT dan lonjakan aktivitas DeFi. Pemadaman September 2021 berlangsung sekitar 17 jam dan disebabkan oleh banjir dari peristiwa IDO. Peningkatan sejak periode puncak pemadaman 2021 hingga 2022 mencakup jaringan QUIC, prioritas transaksi berbobot stake, dan peningkatan berkelanjutan pada klien validator. Verifikasi Status keandalan jaringan saat ini dari blog Solana Foundation pada saat penulisan.

Apa itu Proof of History?

Proof of History (PoH) adalah mekanisme pencatatan waktu kriptografi yang ditemukan oleh Anatoly Yakovenko dan diperkenalkan dalam Whitepaper November 2017-nya, "Solana: Arsitektur baru untuk blockchain berkinerja tinggi." PoH membuat catatan yang berkelanjutan dan dapat diverifikasi tentang kapan peristiwa terjadi dengan merantai output hash SHA-256 secara berurutan. Ini bukan merupakan Mekanisme Konsensus. Ini adalah jam kriptografi yang memungkinkan algoritma konsensus Solana yang sebenarnya, Tower BFT, beroperasi dengan putaran komunikasi yang jauh lebih sedikit. Untuk detail lengkap, lihat bagian Proof of History di atas.

Anatoly Yakovenko, mantan insinyur Qualcomm, memperkenalkan Proof of History dalam Whitepaper dasar Solana pada tahun 2017. Yakovenko mendirikan Solana Labs bersama Greg Fitzgerald dan Raj Gokal, yang berkontribusi pada implementasi protokol yang lebih luas. PoH menyediakan referensi pengurutan yang dapat diverifikasi yang dapat mengurangi beberapa beban koordinasi waktu, tetapi tidak menghilangkan komunikasi konsensus.

Solana memiliki sekitar 1.500 atau lebih validator aktif pada saat penulisan; verifikasi angka terbaru dari analitik validator Solana Beach untuk data saat ini. Sebagai perbandingan, Ethereum memiliki sekitar 900.000 atau lebih validator (verifikasi dari beaconcha.in). Perbedaan dalam jumlah validator mencerminkan perbedaan dalam persyaratan perangkat keras: validator Solana memerlukan peralatan kelas server dengan RAM 128GB atau lebih, sementara validator Ethereum dapat berjalan pada perangkat keras kelas konsumen bersama dengan 32 ETH.

Tower BFT adalah algoritma konsensus Solana, dibangun sebagai adaptasi PBFT yang menggunakan Proof of History sebagai jam bersama. Validator memberikan suara berbobot stake pada blok; sebuah blok mencapai finalitas ketika validator yang mewakili lebih dari dua pertiga dari semua SOL yang di-Staking mengonfirmasinya. Ambang batas supermayoritas 2/3+ ini berarti jaringan menoleransi hingga sepertiga peserta berbobot stake yang bertindak jahat tanpa kehilangan integritas konsensus.

Staking Solana secara teknis mirip dengan Delegated Proof of Stake (DPoS) karena pemegang SOL dapat mendelegasikan ke validator tanpa menjalankan Node mereka sendiri. Namun, ini berbeda dari sistem DPoS tradisional dalam satu hal utama: tidak ada set validator delegasi yang terpilih dan tetap. Validator mana pun dapat menarik delegasi dari pasar terbuka. Lebih akuratnya, Solana menggunakan sistem PoS berbobot stake dengan delegasi terbuka, yang beroperasi sebagai lapisan keamanan ekonomi di atas PoH dan Tower BFT, daripada arsitektur DPoS tradisional dengan kumpulan delegasi tetap.

Tidak ada jaringan yang secara objektif lebih baik. Masing-masing membuat pengorbanan arsitektural berbeda yang cocok untuk kasus penggunaan yang berbeda. Pengukuran historis umumnya menunjukkan throughput lapisan dasar yang lebih tinggi dan biaya yang lebih rendah di Solana, sementara waktu konfirmasi bergantung pada tingkat komitmen dan kondisi jaringan. Ethereum memiliki komunitas pengembang yang lebih besar dan ekosistem Lapisan 2 yang luas. Jumlah validator saja tidak mengukur desentralisasi; distribusi stake, keragaman klien, konsentrasi operator, dan persyaratan perangkat keras juga penting. Pilihan yang tepat bergantung pada aplikasi dan model risiko.

Jelajahi SOL di Bybit

Pembaca dapat meninjau informasi pasar SOL saat ini) atau membandingkan produk SOL Earn.) yang tersedia. Bybit Earn adalah produk Terpusat dan tidak boleh digambarkan sebagai Staking validator Solana asli; ketentuan, kustodi, ketersediaan, dan risiko berbeda.

• Mekanisme konsensus Solana adalah sistem hibrida: Proof of History (jam kriptografi) + Tower BFT (algoritma persetujuan) + Proof of Stake (lapisan keamanan ekonomi). Tidak ada satu komponen pun yang berdiri sendiri sebagai mekanisme tersebut.

• Proof of History bukan merupakan Mekanisme Konsensus. Ini adalah alat pencatatan waktu kriptografi yang menetapkan pengurutan transaksi sebelum validator berkomunikasi, memungkinkan Tower BFT mencapai konsensus dengan putaran pemungutan suara yang jauh lebih sedikit daripada implementasi BFT standar.

• Pemadaman jaringan Solana disebabkan oleh kehabisan sumber daya perangkat lunak, bukan oleh kegagalan pada PoH atau Tower BFT. Desain konsensus tidak rusak. Peningkatan termasuk jaringan QUIC, prioritas biaya berbobot stake, dan klien Firedancer bertujuan untuk mengurangi risiko penghentian di masa mendatang.

• Konsensus Solana lebih cepat daripada Ethereum Lapisan 1 dan Bitcoin, mencapai finalitas dalam waktu kurang dari 1,3 detik dibandingkan dengan 12 hingga 15 menit untuk Ethereum Lapisan 1 dan sekitar 60 menit untuk Bitcoin, tetapi kecepatan ini datang dengan pengorbanan: validator yang lebih sedikit, persyaratan perangkat keras yang lebih tinggi, dan kekhawatiran konsentrasi stake.

• Setiap pemegang SOL dapat berpartisipasi dalam konsensus Solana dengan mendelegasikan SOL ke validator melalui Staking asli atau protokol liquid staking. Menjalankan validator secara langsung memerlukan investasi perangkat keras yang signifikan dan keahlian teknis.

• Angka performa dan jumlah validator berubah seiring dengan pembaruan jaringan. Setiap evaluasi mengenai desentralisasi, throughput, atau hasil Staking Solana harus menggunakan data terbaru dari Solana Beach, Solscan, dan dokumentasi resmi Solana pada saat keputusan dibuat.

Untuk berpartisipasi dalam Mekanisme Konsensus Solana, lihat bagian Staking dan validasi di atas atau kunjungi dokumentasi resmi Solana di docs.solana.com.

Bacaan lebih lanjut:

• Solana: Arsitektur baru untuk blockchain performa tinggi:) Whitepaper November 2017 karya Anatoly Yakovenko
• Dokumentasi resmi Solana: spesifikasi protokol, persyaratan perangkat keras, panduan Staking
• Analitik validator Solana Beach: jumlah validator saat ini, distribusi Stake, dan statistik jaringan

Bacaan Terkait

• Solana Proof of History
• Arsitektur Solana
• Kecepatan Solana