Konsensus di Solana

Wawasan yang Dapat Ditindaklanjuti

• Peran Proof-of-History (PoH) dalam sinkronisasi: PoH bukan algoritma konsensus, melainkan alat yang digunakan oleh mekanisme konsensus Solana untuk sinkronisasi. Demikian pula, Proof-of-Stake (PoS) bukan konsensus, tetapi mekanisme resistansi Sybil.
• Transaksi vote diperlukan untuk konsensus: Vote di dalam blok bukan transaksi tambahan untuk menaikkan metrik TPS secara artifisial. Jika vote hanya disebarkan melalui gossip (komunikasi informal peer-to-peer), hal ini dapat menyebabkan perbedaan dalam cara validator memandang status Tower (vote).
• Solana memiliki dua aturan konfirmasi utama: satu untuk pemilihan fork jangka pendek (konfirmasi optimistis) dan satu lagi untuk konsensus PoS penuh demi finalitas (finalized/rooted). Klien dan pengguna dapat mengikuti aturan konfirmasi ini untuk memperoleh properti keamanan yang diinginkan dan pilihan UX yang disesuaikan. Hal ini tercermin melalui dua tingkat komitmen: “confirmed” dan “finalized”.
• Memahami risiko penyensoran: Validator dan pengembang harus menyadari potensi serangan penyensoran, yaitu ketika validator mencoba mengganggu urutan produksi blok. Mereka perlu memahami mekanisme serangan tersebut serta peran daya komputasi dan stake dalam menjalankannya.
• Peningkatan protokol mendatang: Validator dan pengembang harus aktif mempersiapkan perubahan yang akan datang pada mekanisme konsensus Solana, seperti eksekusi asinkron dan slashing terprogram.

Pendahuluan

Seiring meningkatnya aktivitas di Solana, berbagai lapisan stack-nya diuji pada tingkat yang belum pernah terjadi sebelumnya. Banyak tulisan dan diskusi membahas topik “hangat”, seperti pasar biaya lokal, tetapi konsensus di Solana telah lama terabaikan. Namun, peningkatan aktivitas dan minat menuntut komunitas untuk memahami konsensus secara menyeluruh karena insentif untuk melakukan serangan berbahaya dan keuntungan dari potensi eksploitasi terus meningkat.

Konsensus adalah salah satu aspek terpenting Solana yang perlu dipahami komunitas luas karena menentukan cara ribuan validator menyepakati urutan transaksi kanonis.

Konsensus telah dipelajari dalam sistem terdistribusi selama bertahun-tahun. Masalah Jenderal Bizantium, yang ditulis oleh Lamport, Shostak, dan Pease, diterbitkan pada awal 1980-an. Algoritma konsensus seperti RAFT telah lama digunakan di web2. Dalam kripto, sebagian besar algoritma konsensus merupakan implementasi berbeda dari konsensus BFT, termasuk Gasper (Ethereum), Tendermint (Cosmos), MonadBFT (Monad), HotShot (Espresso), dan Narwhal/Tusk (Sui). 

Artikel ini tidak berupaya membuktikan mekanisme konsensus Solana (TowerBFT) secara formal. Artikel ini bertujuan menjelaskan cara kerja konsensus di Solana kepada pengembang dan komunitas yang lebih luas, karena sejauh ini topik tersebut sebagian besar hanya dipahami oleh kontributor Solana Labs dan Firedancer. Artikel ini juga membahas beberapa pertimbangan mengenai kompromi dan keterbatasannya.

Pengantar Singkat tentang Konsensus

Tujuan protokol konsensus adalah menghasilkan kesepakatan mengenai transaksi dan urutan relatifnya di dalam sebuah blok. Ada dua jenis utama protokol konsensus yang digunakan validator dalam jaringan untuk menyepakati urutan transaksi kanonis:

• Protokol rantai terpanjang: protokol ini (seperti konsensus Nakamoto milik Bitcoin) menetapkan rantai yang membutuhkan upaya komputasi terbesar untuk dibangun sebagai rantai kanonis. Walaupun hal ini sering berkorelasi dengan rantai yang memiliki jumlah blok terbanyak, deskripsi yang lebih akurat adalah rantai yang mewakili jumlah kerja kumulatif atau daya komputasi terbesar.
• Protokol jenis BFT: sebagian besar protokol PoS menerapkan suatu versi algoritma konsensus BFT. Protokol ini (seperti pBFT) mengandalkan ambang batas untuk liveness dan keamanan. Konsistensi dan ketersediaan merupakan dua jaminan dalam teorema CAP, yang menyatakan bahwa penyimpanan data terdistribusi hanya dapat menawarkan dua dari tiga jaminan berikut: konsistensi, ketersediaan, dan toleransi partisi.

Protokol konsensus rantai terpanjang dan jenis BFT sama-sama memperoleh keamanan dari aturan konfirmasinya masing-masing. Keamanan, yang mencakup safety dan liveness, berasal dari aturan konfirmasi tertentu dan bukan merupakan properti suatu rantai. Sebagaimana didefinisikan oleh Ethereum Foundation, aturan konfirmasi adalah “algoritma yang dijalankan oleh node dan menghasilkan keputusan apakah blok tertentu telah dikonfirmasi. Jika demikian, blok tersebut dijamin tidak akan pernah mengalami reorg berdasarkan asumsi tertentu, terutama mengenai sinkronisasi jaringan dan persentase stake yang jujur.”

Pada akhirnya, semuanya bergantung pada konsensus sosial, yang ditentukan oleh orang-orang yang menulis kode klien untuk mengungkapkan definisi keamanan melalui aturan konfirmasi tertentu.

Proof-of-Stake menambahkan lapisan pada model BFT dengan mewajibkan peserta mempertaruhkan stake mereka sendiri. Peserta diberi imbalan karena mematuhi serangkaian aturan, tetapi dapat terkena slashing jika terbukti melakukan pelanggaran (misalnya, penandatanganan ganda). Hal ini disebut accountable safety dan memungkinkan protokol mengidentifikasi serta menghukum node berbahaya tanpa menimbulkan eksternalitas bagi node jujur. Mekanisme ini tidak menggantikan mekanisme keamanan dasar protokol konsensus BFT: jaringan tetap memerlukan kurang dari sepertiga node yang tidak jujur agar tidak berhenti dan kurang dari dua pertiga untuk mencegah validasi transaksi palsu. Sistem berbasis stake memberikan konsekuensi bagi tindakan yang dapat mengganggu atau menurunkan efisiensi jaringan.

Ada dua ambang batas penting dalam jaringan BFT semacam ini:

1. 1/3: Jika node tidak jujur berjumlah sepertiga atau lebih dari total node, jaringan dapat “berhenti”. Dalam skenario ini, node tersebut dapat memilih untuk tidak berpartisipasi sehingga node lainnya tidak mampu mencapai supermayoritas dua pertiga yang dibutuhkan untuk konsensus. Akibatnya, jaringan tidak menghasilkan transaksi yang salah. Sebaliknya, jaringan berhenti menghasilkan transaksi sama sekali. Salah satu metrik yang populer (meski sederhana) adalah Koefisien Nakamoto, yang menunjukkan jumlah minimum node yang diperlukan untuk menyebabkan kegagalan liveness (menghentikan produksi blok).
2. 2/3: Jika node tidak jujur berjumlah dua pertiga atau lebih dari total node, mereka dapat berkolusi untuk memvalidasi transaksi apa pun yang mereka pilih. Ini merupakan skenario terburuk, ketika jaringan tidak lagi berfungsi dengan benar dan justru memproses transaksi sesuai arahan supermayoritas yang tidak jujur. Dalam skenario ketika pihak lawan menguasai lebih dari 67% stake, mereka berpotensi mengisolasi node jujur, seperti node milik bursa besar (misalnya Binance). Isolasi ini dapat dilakukan melalui kolusi dengan pusat data untuk membatasi lalu lintas jaringan node tersebut. Entitas berbahaya kemudian dapat membuat node yang terisolasi memfinalisasi blok buatannya, sekaligus mendistribusikan blok yang bertentangan ke jaringan lainnya. Serangan semacam ini mengeksploitasi sudut pandang terbatas node yang terisolasi dan berpotensi menyebabkan pembelanjaan ganda karena jaringan lainnya dan node tersebut memiliki pandangan berbeda tentang status on-chain.

Serangan serupa tetap dapat dilakukan dengan stake yang lebih rendah, yaitu di atas 33%, tetapi hal ini memerlukan pembuatan partisi jaringan, bukan sekadar isolasi. Dalam situasi tersebut, pemegang stake Bizantium dapat mengeksploitasi partisi jaringan untuk memanipulasi berbagai segmen jaringan dengan informasi yang saling bertentangan, sehingga kembali menimbulkan risiko pembelanjaan ganda dan kegagalan safety lainnya.

Biasanya, jumlah node yang lebih besar meningkatkan kesulitan bagi pihak mana pun yang mencoba merusak sebagian besar node untuk mencapai ambang batas tersebut (dengan asumsi adanya pemisahan geografis). Namun, keinginan untuk memiliki jaringan yang lebih besar sering bertentangan dengan efisiensi. Jumlah node yang lebih tinggi dapat memperlambat konsensus karena meningkatnya kebutuhan transmisi data (waktu yang lebih lama untuk penyebaran vote), dan beberapa protokol menetapkan batas maksimum node secara tegas.

Proof-of-History (PoH)

Walaupun Proof-of-Stake (PoS) memastikan konsensus dalam jaringan, Solana mengintegrasikan Proof of History (PoH) ke dalam mekanisme konsensus PoS untuk memungkinkan sinkronisasi bagi produksi blok berkelanjutan. Solana melakukannya dengan melewati slot yang memiliki pemimpin slot lambat atau tidak responsif tanpa menunggu putaran konsensus tersinkronisasi. PoH tidak bertujuan membuktikan waktu pasti terjadinya suatu peristiwa, tetapi membuktikan urutan dan berlalunya waktu di antara berbagai peristiwa.

Berlawanan dengan anggapan umum, Proof-of-History (PoH) sendiri bukan mekanisme atau algoritma konsensus. Walaupun implementasi saat ini menggunakan aspek-aspek PoH dalam konsensus, secara teori PoH dapat dihapus dan beberapa perubahan implementasi kecil dapat dilakukan agar konsensus di Solana tetap beroperasi.

Inti PoH adalah algoritma hashing sederhana yang serupa dengan Verifiable Delay Function (VDF), tetapi secara teknis bukan VDF. Solana menerapkannya menggunakan fungsi hash sekuensial tahan pre-image (SHA-256) yang berjalan terus-menerus, dengan output satu iterasi sebagai input iterasi berikutnya. Komputasi ini berjalan pada satu core di setiap validator.

Walaupun pembuatan urutannya bersifat sekuensial dan single-threaded, output dapat diverifikasi secara paralel sehingga verifikasi pada sistem multi-core dapat dilakukan secara efisien. Kecepatan hashing memiliki batas atas, tetapi peningkatan perangkat keras berpotensi memberikan manfaat performa tambahan.

Pertimbangkan contoh yang melibatkan empat validator di jaringan Solana: Validator A, B, C, dan D. Dalam contoh ini, jadwal pemimpin dapat menentukan urutan produksi blok sebagai A - B - C - D. Validator A memulai dengan membuat blok sesuai gilirannya. Untuk melakukannya, Validator A menggunakan mekanisme PoH, yang menjalankan fungsi hash SHA-256 secara berulang untuk membentuk skala waktu berupa “tick”. Proses hashing ini menghasilkan catatan unik dan dapat diverifikasi mengenai waktu yang telah berlalu, sehingga memastikan blok Validator A mencerminkan berlalunya waktu secara akurat. Setelah Validator A menyelesaikan bloknya, giliran Validator B untuk menghasilkan blok berikutnya, lalu Validator C.

Misalkan Validator C mencoba mengganggu urutan dengan mengirimkan blok di luar gilirannya agar dapat langsung mengikuti Validator A dan melewati Validator B. Agar dapat menggantikan Validator B secara meyakinkan, Validator C perlu mereplikasi urutan hash PoH yang seharusnya dihasilkan Validator B. Artinya, C harus membuat urutan hash yang merepresentasikan waktu yang dibutuhkan Validator B untuk menghasilkan blok. Performa hashing single-core memiliki batas maksimum fisik. Dengan demikian, kita mengetahui bahwa sejumlah waktu tertentu telah berlalu karena komputer hanya dapat menghasilkan jumlah hash maksimum tertentu dalam interval waktu tertentu.

Validator C dapat mencoba menyensor Validator B dalam jadwal pemimpin dengan membuat rantai blok kosong yang dimulai dari akhir blok sah sebelumnya (blok Validator A), tanpa menyertakan transaksi apa pun. Agar berhasil menyensor B, C harus memenuhi dua syarat. Pertama, C memerlukan daya komputasi untuk menjalankan rantai PoH kosong tersebut. Kedua, C harus menyebarkan bloknya dengan cepat kepada cukup banyak node yang memiliki stake untuk memastikan blok tersebut diterima selama slot miliknya, sehingga secara efektif menyensor B. Proses ini lebih cepat bagi validator dengan stake-weight tinggi berkat Turbine, yang memprioritaskan aliran informasi berdasarkan stake-weight validator.

Skenario serangan ini dapat dilakukan, tetapi jangka waktu untuk berhasil melakukan penyensoran terbatas. Node penyerang harus memiliki sumber daya komputasi besar (untuk hashing SHA-256) dan stake yang signifikan karena jumlah blok yang dapat dihasilkannya sebanding dengan stake-nya.

Selain harus menjangkau jaringan lebih cepat daripada node A, C juga harus menghasilkan hash dengan kecepatan tinggi. Serangan ini terutama menargetkan skenario ketika validator yang ditunjuk sebagai pemimpin pada slot n ingin menyensor validator dengan slot pemimpin sebelumnya (sebelum n). Tingkat penyensoran yang dapat dilakukan validator ini bergantung pada stake-nya karena kemampuan untuk membuat slot pemimpin berkaitan langsung dengan jumlah stake yang dimilikinya.

Mekanisme PoH juga memastikan blok dihasilkan dengan laju yang konsisten. Karena urutan PoH dapat diverifikasi secara independen oleh setiap validator, sinkronisasi waktu eksternal tidak diperlukan. Sebagai contoh, Ethereum menggunakan Network Time Protocol (NTP) di setiap blok untuk konsensus. Di Solana, setiap validator secara independen memverifikasi secara endogen bahwa setiap blok dibuat dalam slot waktu yang tepat, tanpa menggunakan protokol eksternal.

Tower BFT (Mekanisme Konsensus Solana)

Tower BFT, mekanisme konsensus Solana, beroperasi setelah shred (bagian blok) disebarkan kepada validator lain:

Seperti disebutkan sebelumnya, Solana menjalankan Tower BFT bersama Proof-of-History. Tower BFT adalah algoritma konsensus serupa pBFT yang dirancang untuk memanfaatkan komputasi jam tersinkronisasi dari Proof-of-History. Hal ini membentuk jam universal di seluruh jaringan sehingga jaringan dapat melewati slot yang ditetapkan kepada pemimpin lambat atau tidak responsif secara efisien. Proses ini menghilangkan kebutuhan jaringan untuk menjalani putaran konsensus sinkron pada setiap slot dan memungkinkan produksi blok berkelanjutan karena validator tidak perlu menunggu blok sebelumnya tiba sebelum membangun blok berikutnya.

Kesalahpahaman lainnya adalah bahwa mekanisme konsensus Solana saat ini menerapkan slashing terprogram. Walaupun slashing tercantum dalam roadmap, jaringan saat ini berhenti setelah terjadi pelanggaran safety dan mengandalkan konsensus sosial untuk menerapkan slashing jika diperlukan.

Mekanisme konsensus Solana memberikan tingkat pengaruh yang berbeda kepada setiap node. Vote dalam jaringan tidak setara, tetapi dibobotkan sesuai stake setiap node dengan prinsip yang sama seperti QoS berbobot stake dan Turbine. Jika faktor lainnya sama, node dengan stake lebih besar memiliki pengaruh lebih besar dalam menentukan konsensus kanonis dibandingkan node dengan stake lebih kecil.

Sebagai contoh, dalam jaringan dengan empat node yang secara keseluruhan memiliki 100 unit stake, distribusi dan pengaruhnya dapat terlihat sebagai berikut:

• Node A memiliki 10 unit stake.
• Node B memiliki 20 unit stake.
• Node C memiliki 30 unit stake.
• Node D memiliki 40 unit stake.

Dalam konfigurasi ini, kemampuan setiap kelompok node tidak jujur berbeda-beda. Satu node seperti Node D dapat menghentikan jaringan meskipun hanya mewakili 25% dari jumlah total node karena stake-nya yang besar. Demikian pula, kombinasi Node C dan D dapat menyetujui transaksi yang salah meskipun hanya mewakili 50% node karena keduanya memiliki cukup stake untuk memengaruhi hasil.

Ambang batas sepertiga untuk menghentikan jaringan dapat dicapai melalui node yang tidak jujur, disusupi, atau diblokir. Namun, ambang batas dua pertiga untuk memvalidasi transaksi yang salah memerlukan kolusi aktif dan tidak dapat dicapai hanya dengan memblokir node jujur. Karena itu, mencapai ambang batas kedua jauh lebih sulit. Prosesnya mengharuskan penyerang merusak atau menyusupi node agar aktif berpartisipasi dalam skema tidak jujur, bukan hanya memblokir node jujur.

Konteks dalam Slot

Di Solana, pemimpin slot diberi empat slot berturut-turut dengan durasi total sekitar 1,6 detik (4 blok x 400 md per blok). Pemimpin dipilih pada awal setiap epoch (432.000 slot atau ~2-3 hari). Jadwal pemimpin dipilih secara acak berdasarkan stake-weight validator.

Pemimpin bertugas membangun dan mengusulkan blok baru untuk setiap slot yang ditetapkan kepadanya (tidak ada pemisahan proposer-builder seperti di ekosistem Ethereum). Validator lain mengesahkan validitas blok melalui transaksi vote dengan menerapkan aturan pemilihan fork pada pandangan lokal mereka sendiri terhadap head jaringan Solana.

Pemimpin harus menerbitkan blok dalam rentang tick PoH tertentu agar blok tersebut valid; blok yang tidak diterbitkan dalam rentang ini dianggap dilewati.

Perhatikan contoh jadwal pemimpin berikut dengan empat peserta (A, B, C, D), ketika D mencoba mengganggu urutan. Jika D mencoba ikut campur saat giliran C, D harus membuat urutan tick PoH yang secara efektif melewati blok C sehingga menghasilkan rantai seperti berikut:

A - B - [C tidak ada] - D.

Dalam situasi ketika blok C tidak ada, D yang jujur harus menghasilkan urutan PoH yang mencakup seluruh durasi slot C sebelum memulai slotnya sendiri. Hal ini akan membuat blok D tampak valid karena mengikuti blok B setelah waktu yang dialokasikan untuk slot C berakhir.

Ketika D menghasilkan urutan PoH untuk slot C, biasanya C akan melakukan streaming bloknya yang terhubung ke blok B dengan urutan PoH yang sesuai. Hal ini menghasilkan dua kemungkinan:

• Jika komputasi PoH D tidak lebih cepat daripada C: Saat C menyelesaikan bloknya hampir bersamaan dengan D mulai menyiarkan bloknya sendiri, jaringan yang telah melihat blok C akan menolak blok D.
• Jika D menghitung PoH lebih cepat daripada C: D mulai menyiarkan bloknya sebelum C menyelesaikan bloknya sendiri. Meski demikian, D harus jauh lebih cepat daripada C agar dapat memengaruhi urutan secara signifikan. Hal ini kecil kemungkinannya karena CPU yang digunakan validator untuk komputasi SHA-256 memiliki kecepatan tinggi dan batas kemampuan atas yang (relatif) serupa.

Dalam kedua situasi tersebut, peluang D untuk berhasil menggantikan C sangat kecil. Selain itu, jika upaya D untuk menggantikan C gagal, D kehilangan kesempatan untuk mengirimkan blok di slotnya sendiri. Mengirimkan blok tepat setelah B, lalu mencoba mengirimkan blok lain setelah C, merupakan pelanggaran (membuat dua blok untuk slot D) yang dapat dikenai slashing. Setiap upaya yang gagal membuat D kehilangan kesempatan menghasilkan bloknya sendiri, sehingga strategi ini kemungkinan besar tidak akan dipilih D. 

Dari perspektif jaringan, niat D tidak dapat dipastikan. Sulit, atau bahkan mustahil, untuk membedakan antara D yang sekadar tidak melihat blok C (tanpa berniat menyensor C) dan D yang berniat menyensor B. Akibatnya, tindakan ini tidak mudah dideteksi dan tidak dapat dihukum oleh jaringan.

Transaksi Vote

Mekanisme konsensus Solana mengandalkan transaksi vote untuk mencapai konsensus. Transaksi vote berada di dalam blok, tetapi diprioritaskan agar tidak tersisih oleh transaksi biasa. Saat ini, sebagian besar transaksi dalam suatu blok adalah transaksi vote:

Namun, hal ini mungkin tidak selalu terjadi karena persentase transaksi vote dalam suatu blok mencerminkan rasio antara aktivitas dan jumlah validator yang berpartisipasi dalam konsensus. Di masa mendatang, transaksi vote mungkin menjadi minoritas dalam suatu blok.

Transaksi vote merupakan persyaratan penting bagi konsensus—transaksi tersebut bukan transaksi tambahan untuk menaikkan metrik TPS secara artifisial. Jika vote hanya disebarkan melalui gossip (komunikasi informal peer-to-peer), hal ini dapat menyebabkan perbedaan dalam cara validator memandang status Tower (vote). Perbedaan tersebut dapat membuat validator memiliki pandangan berbeda mengenai fork yang lebih mungkin benar dan berpotensi menyebabkan divergensi ketika validator membuat pilihan oportunistis berdasarkan informasi yang tidak lengkap atau tidak konsisten. Produksi blok berkelanjutan membutuhkan vote terus-menerus, terutama saat blok sebelumnya masih dikonfirmasi. Hal ini membutuhkan pandangan yang andal dan konsisten terhadap status Tower.

Seperti transaksi biasa yang dimulai oleh pengguna, transaksi vote juga harus membayar biaya dasar (0,000005 SOL). Biaya ini dibayar oleh identitas validator, yang harus berada dalam hot wallet agar dapat terus menandatangani, sedangkan akun vote digunakan untuk pencarian akun dan delegasi.

Setiap vote yang ditandatangani validator menyertakan public key validator dan hash blok yang dipilihnya.

Ketika validator menerima beberapa blok untuk slot yang sama, validator melacak semua kemungkinan fork hingga dapat menentukan fork “terbaik”. Validator menjalankan fungsi transisi status yang relevan secara lokal (hal ini akan berubah dalam eksekusi asinkron), lalu memberikan vote pada blok baru setelah replay. Validator menyatakan pilihannya untuk fork tertentu melalui transaksi vote on-chain.

Dalam setiap transaksi vote, validator menerbitkan vote dengan periode lockout.  Lockout ini berfungsi sebagai mekanisme komitmen yang mengikat validator pada fork pilihannya dan membebankan biaya peluang atas keputusan tersebut. Saat ini, lockout tidak diberlakukan oleh runtime, tetapi melalui konsensus sosial—pelanggaran lockout vote secara konsisten kemungkinan besar akan dikenai slashing secara manual. Slashing terprogram untuk pelanggaran periode lockout kemungkinan akan ditambahkan dalam waktu dekat karena tidak menerima kredit vote belum memberikan disinsentif yang memadai.

Validator juga menandatangani hash blok untuk setiap blok leluhur di antara vote sebelumnya dan blok rooted/finalized. Hal ini diperlukan untuk mendeteksi blok duplikat. Jika seorang pemimpin mengirimkan blok yang berbeda kepada setiap node, setiap node akan memberikan vote pada pendahulu yang berbeda untuk slot yang sama. Namun, dalam epoch yang terdiri atas 65.000 slot, ukuran setiap vote dapat mencapai 2 MB dalam skenario paling ekstrem. Hal ini terjadi karena vote mungkin memerlukan hash 32 byte untuk masing-masing dari 65.000 slot tersebut. Topik ini akan dibahas lebih lanjut dalam artikel mendatang.

Validator mengelola “Vote Tower”, yaitu stack vote berurutan tempat setiap vote memperkuat suatu fork dan menjadi leluhur fork di atasnya dalam tower. Penambahan vote baru ke tower ini menggandakan lockout untuk semua vote sebelumnya dalam stack, sehingga secara bertahap meningkatkan komitmen dan periode lockout untuk keputusan terdahulu. Proses vote itu sendiri diatur oleh beberapa pemeriksaan: validator harus mematuhi periode lockout vote sebelumnya; memastikan sebagian besar jaringan (biasanya dua pertiga) juga berkomitmen pada fork yang sama; dan memperoleh mayoritas signifikan (lebih dari 38%) vote pada fork alternatif sebelum beralih ke fork baru.

Untuk blok pada slot n, vote dari pihak selain pemimpin mulai muncul secara on-chain paling cepat pada n+1. Tidak ada subkomite vote—semua validator berhak memberikan vote pada semua blok. Vote ini pertama kali muncul dalam blok dari validator lain yang dekat (berjarak satu hop) di pohon Turbine. Vote untuk slot n dapat muncul hingga slot n+512 karena validator diizinkan memberikan vote pada slot mana pun yang “slot hash”-nya masih diketahui, dan slot hash disimpan selama 512 slot (h/t Shinobi). Tidak ada batas atas yang telah ditentukan pada blok tertentu untuk slot n; namun, slot rooted yang dibangun di atas setidaknya 32 blok berkelanjutan tidak lagi menerima vote dan menjadi finalized.

Skema vote memiliki beberapa keunikan yang tidak sepenuhnya diberlakukan oleh runtime. Sebagai contoh, validator saat ini memiliki insentif untuk hanya memberikan vote pada slot “rooted” (mengabaikan ujung rantai), dan tindakan ini tidak dihukum oleh konsensus. Hal ini memungkinkan validator terus memperoleh kredit vote untuk fork yang hampir pasti menjadi kanonis tanpa berkontribusi pada ujung rantai untuk operasi konsensus yang sebenarnya. Hal ini terjadi saat ini, dengan sebuah validator memiliki rata-rata “latensi vote” lebih dari 68 slot. Fitur yang diusulkan bernama Timely Vote Credits bertujuan mengurangi ketidakselarasan insentif ini.

Aturan Pemilihan Fork Solana

Seperti Ethereum (LMD Ghost dan Casper FFG), Solana memiliki dua aturan konfirmasi—satu untuk pemilihan fork jangka pendek dan satu lagi untuk konsensus PoS penuh demi finalitas. Hal ini memungkinkan pengguna dan klien menyesuaikan pilihan UX berdasarkan aturan konfirmasi yang berbeda. Hal tersebut tercermin melalui dua tingkat komitmen: “confirmed” dan “finalized”.

Blok “confirmed” (juga dikenal sebagai konfirmasi optimistis) mengharuskan setidaknya 2/3 validator memberikan vote melalui transaksi vote pada blok tertentu. ~4,6% dari stake saat ini harus terkena slashing agar pelanggaran finalitas dapat terjadi. Blok “finalized” memerlukan vote pada setidaknya 32 slot berikutnya atau supermayoritas (>2/3) vote. Serangan berbahaya akan mengharuskan lebih dari 1/3 stake terkena slashing. Proses ini membutuhkan waktu jauh lebih lama daripada blok “confirmed” karena harus menunggu blok rooted dari 32 blok sebelumnya untuk mencapai finalitas penuh.

Aturan pemilihan fork memungkinkan jaringan mencapai konsensus mengenai head rantai. Implementasi Solana Labs terutama menangani pemilihan fork melalui file Rust sepanjang ~4.600 baris yang diberi nama tepat, yaitu heaviest_subtree_fork_choice.rs. File ini menyediakan logika yang diperlukan validator untuk menentukan fork yang paling mungkin menjadi kanonis. Uraian kode yang lebih mendetail akan dibahas dalam artikel mendatang, tetapi secara umum mekanisme pemilihan fork bekerja sebagai berikut:

1. Vote ditambahkan dengan add_votes():

Proses ini mengiterasi vote baru, mengurangi stake akun vote dari slot lama jika diperlukan, lalu menambahkan stake ke slot baru yang menerima vote.

2. generate_update_operations() dipanggil untuk membuat batch operasi pembaruan fork:

Proses ini:

• Mengurangi stake dari fork lama
• Menambahkan stake ke fork baru
• Mengagregasi stake pada setiap fork hingga root

3. process_update_operations():

• Memanggil mark_fork_valid()/invalid() jika diperlukan
• Memanggil aggregate_slot() pada setiap fork untuk memperbarui bobot fork
• Memanggil add_slot_stake()/subtract_slot_stake() untuk memperbarui stake

4. aggregate_slot():

• Menjumlahkan stake untuk semua slot anak
• Menemukan fork anak terberat berdasarkan stake-weight
• Menemukan fork anak terdalam berdasarkan ketinggian
• Meneruskan nilai-nilai ini ke atas untuk menemukan fork terberat/terdalam dari slot ini

5. select_forks():

• Mengembalikan fork terberat secara keseluruhan untuk produksi blok
• Mengembalikan fork terberat yang merupakan turunan vote terakhir

Stake ditambahkan atau dikurangi berdasarkan vote, agregasi menghitung ulang bobot dari bawah ke atas untuk setiap fork, dan root dengan subtree berbobot paling berat dipilih sebagai fork terbaik untuk dibangun dan diberi vote.

Kemungkinan Penyertaan

Kemungkinan transaksi disertakan berubah sepanjang siklus hidup transaksi setelah memenuhi persyaratan yang diperlukan untuk aturan konfirmasi terkait.

Walaupun slot dapat “dilewati”, seperti ketika pemimpin sedang offline, transaksi tersebut dapat masuk ke blok mendatang atau tidak masuk sama sekali.

Slot di sini merupakan perkiraan kasar, tetapi dimaksudkan untuk memberikan gambaran kepada pembaca mengenai waktu vote biasanya terakumulasi. Selain itu, hal ini berbeda untuk setiap blok (blok dapat mencapai tingkat konfirmasi “confirmed” atau “finalized” dalam durasi yang berbeda). Risiko pembalikan terus menurun sepanjang siklus hidup transaksi. Bahkan setelah blok menjadi finalized (rooted), secara teori blok tersebut masih dapat mengalami fork melalui konsensus sosial dan dihapus dari rantai “kanonis”.

Area Riset Mendatang dan Kesimpulan

Artikel ini menyoroti cara kerja internal Tower BFT, mekanisme konsensus Solana, dan mekanisme relevan lainnya. Kita telah membahas peran Proof-of-History, transaksi vote, dan pemilihan fork dalam konteks Solana untuk membuat fork kanonis bagi pengurutan transaksi.

Masih ada banyak arah riset dan formalisasi tambahan terkait mekanisme ini yang dapat dieksplorasi, seperti:

• Peneliti Ethereum telah mengukur nilai dari menjalankan Timing Games, ketika produsen blok menunggu hingga akhir slot untuk mengirimkan bloknya. Seperti apa permainan ini secara kuantitatif di Solana, dan apakah permainan tersebut sedang terjadi saat ini?
• Eksekusi asinkron tercantum dalam roadmap sebagai perubahan protokol utama untuk 2024. Apa saja potensi vektor serangan dan pertimbangan keamanan yang relevan bagi node yang hanya memberikan vote pada fork yang ada, alih-alih menghitung transisi status secara lokal?
• Saat ini, sebagian kecil tetapi signifikan dari validator (<20%) menjalankan modifikasi terhadap klien Solana Labs atau Jito-Solana. Ambang batas apa yang mereka ubah yang tidak diatur oleh runtime atau aturan konfirmasi?
• Menerapkan slashing terprogram. Saat ini, selain konsensus sosial, hanya ada sedikit insentif ekonomi untuk tidak menjalankan strategi perdagangan yang sangat menguntungkan tanpa terkena slashing.
• Seperti apa performa mekanisme konsensus Solana saat menjalankan dua klien yang sepenuhnya berbeda (meskipun keduanya berupaya mengikuti aturan konfirmasi yang sama)?
• Apa manfaat yang diharapkan dari subkomite vote terhadap performa dan pengurangan status?
• Apa saja potensi vektor serangan saat memulai ulang dari slot yang dikonfirmasi secara optimistis dibandingkan slot yang telah finalized? Bagaimana solusi off-chain pihak ketiga seperti bursa seharusnya mempertimbangkan penggunaan konfirmasi optimistis atau finalitas penuh?
• Apakah dana yang terkena slashing sebaiknya digunakan sebagai asuransi bagi transaksi yang disertakan dalam pelanggaran safety? Bagaimana mekanisme dan insentif untuk kumpulan asuransi berdenominasi SOL?

Dalam artikel ini, kita telah membahas beberapa mekanisme dan ambang batas yang diterapkan Solana dalam mekanisme konsensusnya serta kaitannya dengan produksi blok normal oleh pemimpin dalam slot tertentu. Peningkatan aktivitas terbaru di Solana memberikan pengujian liveness dan safety secara nyata terhadap mekanisme ini, seiring meningkatnya insentif untuk melakukan serangan berbahaya.

Terima kasih kepada anoushk (Tinydancer), dubbel06 (Overclock), Prithvi (Helius), Mert (Helius), dan Jarry (Ellipsis Labs) atas diskusi dan komentarnya.