Inti dari Blockchain adalah untuk mencapai suatu konsensus global yang ketat: artinya, terlepas dari di negara mana atau zona waktu mana jaringan node berada, semua peserta harus akhirnya mencapai kesepakatan tentang satu set hasil objektif.
Namun jaringan terdistribusi di dunia nyata tidak ideal: ada node yang terputus, ada node yang berbohong, bahkan ada orang yang sengaja merusak. Dalam keadaan seperti ini, bagaimana sistem dapat "bersatu dalam suara" dan tetap konsisten?
Inilah masalah yang ingin diselesaikan oleh protokol konsensus. Ini pada dasarnya adalah seperangkat aturan yang digunakan untuk membimbing sekelompok node yang independen satu sama lain, bahkan tidak sepenuhnya dapat dipercaya, tentang bagaimana mencapai keputusan yang seragam mengenai urutan dan isi setiap transaksi.
Dan begitu "konsensus ketat" ini terbangun, blockchain dapat membuka banyak fitur kunci, seperti perlindungan hak digital, model mata uang yang tahan inflasi, dan struktur kolaborasi sosial yang dapat diperluas. Namun, syaratnya adalah bahwa protokol konsensus itu sendiri harus menjamin dua aspek dasar secara bersamaan:
Tidak boleh ada dua blok yang saling bertentangan yang dikonfirmasi;
Jaringan harus terus maju, tidak boleh terhenti atau macet.
MonadBFT adalah terobosan teknologi terbaru yang dilakukan di arah ini.
Tinjauan singkat tentang evolusi protokol konsensus
Bidang mekanisme konsensus ini sebenarnya telah diteliti selama puluhan tahun. Protokol pertama, seperti PBFT (Practical Byzantine Fault Tolerance), sudah mampu menangani situasi yang sangat realistis: bahkan jika ada sebagian node di jaringan yang mengalami gangguan, berbuat jahat, atau berbicara omong kosong, selama mereka tidak melebihi 1/3 dari total jumlah, sistem masih dapat mencapai kesepakatan.
Desain dari protokol awal ini lebih "tradisional": setiap putaran memilih satu pemimpin, yang memulai usulan, dan validator lainnya melakukan pemungutan suara beberapa putaran untuk secara bertahap mengkonfirmasi urutan transaksi.
Seluruh proses pemungutan suara biasanya melalui beberapa tahap, seperti pre-prepare, prepare, commit, reply. Pada setiap tahap, semua validator harus berkomunikasi satu sama lain. Dengan kata lain, setiap orang harus berbicara dengan setiap orang, jumlah pesan meningkat secara "jaring" secara eksponensial.
Kompleksitas struktur komunikasi ini adalah n²—artinya, jika ada 100 validator di jaringan, maka setiap putaran konsensus mungkin perlu mengirim hampir 10.000 pesan.
Ini tidak menjadi masalah di jaringan kecil, tetapi begitu jumlah validator meningkat, beban komunikasi sistem akan dengan cepat menjadi sulit diterima, dan efisiensi akan langsung menurun.
Struktur komunikasi sekunder "setiap orang harus berkomunikasi dengan setiap orang" ini sebenarnya sangat tidak efisien. Misalnya, dalam jaringan yang memiliki 100 validator, setiap putaran konsensus mungkin harus memproses ribuan pesan.
Ini bisa ditangani dalam lingkaran kecil, tetapi jika diterapkan di jaringan blockchain global yang terbuka, beban komunikasi segera menjadi tidak dapat diterima. Oleh karena itu, protokol BFT awal seperti PBFT dan Tendermint biasanya hanya digunakan dalam skenario jaringan yang diizinkan (permissioned network) atau sistem dengan jumlah validator yang sangat sedikit, agar masih bisa berjalan.
Untuk memungkinkan protokol BFT juga dapat beradaptasi dengan lingkungan publik yang tidak memerlukan izin, beberapa desain generasi baru mulai beralih ke cara komunikasi yang lebih ringan: membuat setiap validator hanya berkomunikasi dengan pemimpin, bukan saling bertukar informasi di antara semua.
Ini mengurangi kompleksitas pesan dari n² sebelumnya, dioptimalkan menjadi n —— sangat mengurangi beban sistem.
Protokol HotStuff diusulkan pada tahun 2018, tepatnya untuk mengatasi masalah skalabilitas ini. Filosofi desainnya sangat jelas: menggantikan proses pemungutan suara PBFT yang rumit dengan struktur komunikasi yang lebih sederhana dan dipimpin oleh pemimpin.
Fitur kunci dari HotStuff adalah komunikasi linier (linear communication) yang disebut. Dalam mekanismenya, setiap validator hanya perlu mengirimkan suara mereka kepada pemimpin saat ini, dan pemimpin kemudian mengemas suara-suara ini untuk menghasilkan Quorum Certificate (QC, bukti mayoritas sah).
QC ini pada dasarnya adalah tanda tangan kolektif yang membuktikan kepada seluruh jaringan: "Sebagian besar node setuju dengan proposal ini."
Dalam perbandingan, mode komunikasi PBFT adalah "siaran semua", di mana setiap orang berbicara di grup, dan situasinya menjadi sangat kacau. Mode HotStuff lebih mirip dengan "satu orang mengumpulkan, satu kali mengemas", tidak peduli berapa banyak orang di jaringan, tetap dapat berfungsi dengan efisien.
Selain komunikasi linier, HotStuff juga dapat ditingkatkan lebih lanjut menjadi versi pipeline (pipelined HotStuff) untuk meningkatkan efisiensi.
Dalam HotStuff yang asli, satu validator akan terus menjabat sebagai pemimpin selama beberapa putaran, sampai sebuah blok sepenuhnya dikonfirmasi. Proses ini adalah "satu putaran memproses satu blok", seluruh energi difokuskan pada kemajuan blok yang sedang berjalan.
Dan di jalur produksi HotStuff, mekanismenya menjadi lebih fleksibel: setiap putaran akan memilih pemimpin baru, dan setiap pemimpin memiliki dua tugas:
Satu sisi mengemas suara dari putaran sebelumnya menjadi Quorum Certificate (QC), dan disiarkan ke seluruh jaringan;
Sambil mengajukan sebuah blok baru, bersiap untuk memulai putaran berikutnya.
Dengan kata lain, tidak lagi "mengonfirmasi satu sebelum memproses yang berikutnya", tetapi seperti jalur produksi, pemimpin yang berbeda bergiliran bertanggung jawab atas setiap tahap. Pemimpin sebelumnya mengajukan Blok, pemimpin berikutnya mengonfirmasinya dan melanjutkan untuk mengajukan blok baru, konsensus di blockchain berjalan seperti perlombaan estafet.
Inilah asal usul metafora "jalur produksi": blok saat ini masih dalam proses konfirmasi, sementara yang berikutnya sudah sedang dipersiapkan, beberapa langkah berjalan secara paralel, meningkatkan efisiensi throughput.
Secara keseluruhan, protokol seperti HotStuff telah membuat kemajuan signifikan dalam dua dimensi dibandingkan dengan BFT tradisional:
Pertama, komunikasi lebih ringan, setiap validator hanya perlu berkomunikasi dengan pemimpin;
Kedua, efisiensi pemrosesan lebih tinggi, beberapa proses konfirmasi blok dapat dilakukan secara paralel.
Ini membuat HotStuff menjadi template desain untuk banyak mekanisme konsensus PoS blockchain modern. Namun, setiap hal memiliki keuntungan dan kerugian—struktur jalur produksi meskipun berkinerja tinggi, juga secara diam-diam memperkenalkan risiko struktural yang sulit ditemukan.
Selanjutnya kita akan membahas masalah inti ini: Fork Ekor (Tail Forking).
Masalah Pemisahan Ekor (Tail-Forking)
Meskipun HotStuff — terutama versi pipelinenya — menyelesaikan masalah skalabilitas pada protokol konsensus, ia juga membawa beberapa tantangan baru. Salah satu yang paling krusial dan mudah diabaikan adalah masalah yang disebut "Tail Forking".
Apa itu fork akhir? Dapat dipahami secara sederhana sebagai: Blockchain mengalami reorganisasi blok yang tidak terduga di "ujung rantai" (reorg).
Secara spesifik, ada sebuah Blok yang valid, telah berhasil disebarkan ke sebagian besar validator, dan telah mendapatkan cukup dukungan suara. Seharusnya, ia segera dikonfirmasi dan ditulis ke dalam rantai utama. Namun akhirnya, ia "dilewati", dibuang (orphaned), dan digantikan oleh Blok baru lainnya pada ketinggian yang sama.
Ini bukan Bug, juga bukan serangan, melainkan karena struktur desain dari protokol itu sendiri, terdapat kemungkinan "jatuhnya ekor rantai". Apakah ini terdengar sedikit tidak adil? Lalu, bagaimana ini bisa terjadi?
Kami telah mengatakan sebelumnya, setiap pemimpin dalam alur kerja HotStuff memiliki dua tugas:
A. Usulkan sebuah blok baru (misalnya Bₙ₊₁)
B. Mengumpulkan suara untuk blok pemimpin sebelumnya, menghasilkan QC (seperti menyelesaikan konfirmasi akhir untuk Bₙ)
Kedua tugas ini dilakukan secara paralel, bergantian. Tapi masalahnya ada di sini.
Sebagai contoh: anggaplah Alice adalah pemimpin, dia mengajukan blok Bₙ pada ketinggian ke-n, blok ini memperoleh suara dari mayoritas super, sudah "hampir dikonfirmasi". Selanjutnya, Bob harus menjadi pemimpin, melanjutkan untuk mendorong blok berikutnya Bₙ₊₁, sekaligus juga harus mengemas QC (bukti mayoritas hukum) dari Bₙ ke dalam proposalnya, menyelesaikan konfirmasi akhir Bₙ.
Tetapi jika Bob sedang offline saat itu, atau sengaja tidak mengirimkan QC Bₙ, maka akan ada masalah.
Karena tidak ada yang menggantikan QC pengemasan blok Alice, catatan suara Bₙ tidak dapat disebarkan, blok yang seharusnya dikonfirmasi ini pun "ditangani dengan dingin", dan akhirnya diabaikan oleh seluruh jaringan.
Inilah esensi dari fork akhir: blok dari pemimpin sebelumnya dilewati karena kelalaian atau niat jahat dari pemimpin berikutnya.
Mengapa percabangan di akhir sangat parah?
Masalah pemisahan di bagian akhir terfokus pada dua aspek: 1) mekanisme insentif yang rusak, 2) aktivitas sistem yang terancam.
Pertama, hadiah ditelan: Jika sebuah blok dibuang, pemimpin yang mengajukan blok tersebut tidak akan mendapatkan hadiah apapun. Baik itu hadiah blok maupun biaya transaksi. Misalnya, Alice mengajukan sebuah blok yang sah dan mendapatkan dukungan suara mayoritas, tetapi karena kesalahan Bob atau tindakan jahat, blok ini tidak dapat dikonfirmasi, dan Alice pada akhirnya tidak mendapatkan satu sen pun. Ini akan menyebabkan struktur insentif yang salah: Node jahat seperti Bob dapat "memutus" sumber hadiah mereka dengan melewati blok lawan. Tindakan ini tidak memerlukan serangan teknis, hanya perlu "tidak kooperatif" secara sengaja, untuk melemahkan pendapatan pesaing. Jika hal ini terjadi berulang kali, seiring waktu, itu akan menurunkan partisipasi dan keadilan sistem secara keseluruhan, bahkan dapat memicu kolusi antar node.
Kedua, ruang serangan MEV semakin meluas: Pemisahan akhir juga akan membawa masalah yang lebih tersembunyi namun serius: ruang untuk manipulasi jahat MEV (nilai maksimum yang dapat diekstrak) semakin besar. Sebagai contoh: Misalkan dalam blok Alice terdapat transaksi arbitrase yang sangat berharga. Jika Bob berniat membuat masalah, ia dapat berkolusi dengan pemimpin berikutnya, Carol, untuk tidak menyebarkan blok Alice. Kemudian, Carol dapat membangun blok baru pada ketinggian yang sama dan "menyalin" transaksi arbitrase milik Alice—mengubah hasil MEV menjadi miliknya sendiri. Tindakan "pengaturan ulang rantai + kolusi pencurian" ini, secara kasat mata masih sesuai dengan aturan pembuatan blok, tetapi sebenarnya merupakan perampokan yang dirancang dengan baik. Yang lebih buruk, hal ini dapat mendorong terbangunnya "hubungan kolusi" di antara para pemimpin, menjadikan konfirmasi blok sebagai permainan distribusi keuntungan, bukan sebagai layanan publik.
Ketiga, merusak jaminan finalitas, memengaruhi pengalaman pengguna: Dibandingkan dengan protokol jenis Nakamoto, salah satu keunggulan besar BFT adalah finalitas deterministik: setelah blok diserahkan, tidak dapat dibatalkan. Namun, fork di bagian akhir merusak jaminan ini, terutama pada blok yang "telah mendapatkan suara tetapi belum secara resmi dikonfirmasi". Beberapa dapp dengan throughput tinggi biasanya berharap dapat langsung membaca data setelah blok mendapatkan suara untuk mengurangi latensi, dan jika blok tersebut tiba-tiba dibuang, dapat menyebabkan status pengguna kembali—misalnya saldo akun yang tidak normal, transaksi leverage tinggi yang baru saja diselesaikan menghilang tanpa alasan, status permainan yang tiba-tiba direset, dan lain-lain.
Keempat, dapat memicu kegagalan berantai: Secara umum, cabang akhir mungkin hanya membuat suatu blok terkonfirmasi terlambat satu putaran, dampaknya tidak terlalu besar. Namun, dalam beberapa skenario tepi, jika beberapa pemimpin berturut-turut memilih untuk melewatkan blok sebelumnya, sistem dapat terhenti, tidak ada yang bersedia "mengambil" blok sebelumnya. Seluruh kemajuan rantai terhenti, sampai akhirnya muncul seorang pemimpin yang "bersedia memikul tanggung jawab", jaringan akan terus maju.
Meskipun sebelumnya ada beberapa solusi, seperti mekanisme penghindaran fork di bagian akhir yang diusulkan oleh protokol BeeGees, seringkali harus mengorbankan kinerja, seperti memperkenalkan kembali kompleksitas komunikasi kedua, yang tidak sebanding dengan hasilnya.
Apa itu MonadBFT?
MonadBFT adalah protokol konsensus generasi baru yang dirancang khusus untuk menyelesaikan masalah percabangan akhir. Kelebihan utamanya adalah: dalam menyelesaikan risiko struktural, tidak mengorbankan keuntungan kinerja yang dibawa oleh pipeline HotStuff. Dengan kata lain, MonadBFT bukanlah sebuah pendekatan dari awal, melainkan melanjutkan optimasi berdasarkan kerangka inti HotStuff. Ini mempertahankan tiga fitur kunci:
Rotasi pemimpin (rotating leader): setiap putaran memilih pemimpin baru untuk memajukan blok;
Penerapan alur: beberapa proses konfirmasi blok dapat tumpang tindih;
Komunikasi linier (linear messaging): setiap validator hanya perlu berkomunikasi dengan pemimpin, menghemat banyak biaya jaringan.
Tetapi hanya mengandalkan tiga poin ini masih belum cukup aman. Untuk menutup celah struktural pada pemisahan akhir, MonadBFT menambahkan dua mekanisme kunci:
Mekanisme Pengajuan Ulang (Re-Proposal)
Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate)
Mekanisme Pengajuan Ulang (Re-Proposal)
Dalam protokol BFT, waktu dibagi menjadi beberapa putaran (disebut view), di mana setiap putaran memiliki satu pemimpin yang bertanggung jawab untuk mengusulkan blok baru. Jika pemimpin gagal (misalnya tidak mengusulkan blok tepat waktu, atau usulan tidak valid), sistem akan beralih ke putaran berikutnya dan memilih pemimpin baru.
MonadBFT menambahkan mekanisme yang memastikan bahwa selama proses pergantian view, setiap blok yang diajukan dengan jujur tidak akan "hilang" karena pergantian pemimpin.
Ketika pemimpin putaran saat ini gagal, validator akan mengeluarkan pesan perubahan putaran yang ditandatangani, menunjukkan bahwa putaran saat ini telah melebihi batas waktu.
Yang istimewa, pesan ini tidak hanya menunjukkan "waktu habis", tetapi juga harus menyertakan informasi blok dari suara terakhir validator tersebut, yang setara dengan mengatakan: "Saya tidak menerima proposal yang sah, ini adalah blok terbaru yang saya lihat."
Pemimpin baru akan mengumpulkan pesan timeout ini dari super mayoritas (2f+1) validator dan menggabungkannya menjadi satu bukti timeout (Timeout Certificate, TC). TC ini mewakili: ketika putaran sebelumnya gagal, seluruh jaringan memiliki snapshot kesepakatan tentang "blok kepala rantai". Pemimpin baru akan memilih blok dengan tinggi tertinggi (atau nomor tampilan terbaru), yang disebut high_tip.
MonadBFT mengharuskan: proposal pemimpin baru harus mencakup TC yang sah, dan harus mengusulkan kembali blok tertinggi yang tertunda dalam TC, sehingga blok ini mendapatkan kesempatan untuk dikonfirmasi lagi.
Mengapa? Seperti yang kami sebutkan sebelumnya: kami tidak ingin Blok yang hampir terkonfirmasi menghilang.
Contoh: Misalkan Alice adalah pemimpin view 5, mengajukan sebuah blok yang valid, dan mendapatkan suara mayoritas. Selanjutnya, pemimpin view 6 Bob offline, tidak dapat melanjutkan proses rantai. Ketika Carol menjabat sebagai pemimpin view 7, sesuai dengan aturan MonadBFT, dia harus menyertakan TC dan mengajukan kembali blok Alice. Dengan cara ini, kerja jujur Alice tidak akan sia-sia.
Jika Carol tidak memiliki blok Alice, dia dapat meminta dari node lain. Node dapat:
Sediakan blok ini, atau
Mengembalikan satu pesan "tanpa dukungan" yang ditandatangani (No-Endorsement, NE), yang menunjukkan bahwa dirinya tidak memiliki blok ini (mekanismenya akan dijelaskan kemudian). (Maksimal f node Bizantium mungkin memilih untuk mengabaikan permintaan, tanpa memberikan respons.)
Setelah Carol mengusulkan kembali blok Alice, dia akan mendapatkan satu kesempatan usulan tambahan, memastikan bahwa dia tidak akan "terkena dampak" karena kegagalan pemimpin sebelumnya.
Fungsi mekanisme pengusulan kembali ini adalah jelas: memastikan bahwa kemajuan rantai adalah adil, dan tidak ada pekerjaan yang valid yang akan diam-diam dibuang karena keberuntungan yang buruk atau karena seseorang mengganggu.
Sertifikat Tanpa Dukungan (NEC)
Melanjutkan contoh sebelumnya: Setelah waktu putaran Bob habis, Carol meminta validator lain untuk menyediakan blok high_tip (yaitu blok Alice). Pada saat ini, setidaknya 2f+1 validator akan merespons:
Berikan blok Alice
Kirim pesan NE yang ditandatangani, menunjukkan bahwa Anda tidak menerima blok Alice.
Selama Carol menerima blok dari Alice, dia harus mengusulkannya kembali sesuai aturan. Hanya jika setidaknya f+1 validator telah menandatangani pesan NE, Carol dapat melewati blok tersebut dan mengajukan yang baru.
Mengapa f+1? Dalam sistem BFT yang terdiri dari 3f+1 validator, hanya ada maksimal f yang mungkin berbuat jahat. Jika blok Alice benar-benar mendapatkan suara mayoritas super, maka setidaknya 2f+1 node yang jujur telah menerimanya.
Oleh karena itu, jika Carol mengklaim "saya tidak dapat mendapatkan blok Alice", maka dia harus menyajikan tanda tangan dari f+1 validator, membuktikan bahwa orang-orang ini tidak menerima. Ini membentuk sebuah Sertifikat Tanpa Dukungan (No-Endorsement Certificate, NEC).
NEC adalah sertifikat pemimpin "pengecualian": itu adalah bukti yang dapat diverifikasi, yang menunjukkan bahwa blok sebelumnya belum siap untuk dikonfirmasi, dan bukan karena melompati dengan niat jahat, tetapi dengan alasan yang jelas "melepaskan".
Usulan ulang + Sertifikat tanpa dukungan = Mengatasi percabangan akhir
MonadBFT menetapkan seperangkat aturan pemrosesan chain head yang ketat dan jelas dengan memperkenalkan mekanisme Re-Proposal dan Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate):
Selesaikan pengiriman akhir untuk blok yang "dekat dengan konfirmasi"; atau berikan bukti yang cukup untuk menunjukkan bahwa blok tersebut belum memenuhi syarat untuk dikonfirmasi, jika tidak, tidak diizinkan untuk melewati atau mengganti blok sebelumnya.
Mekanisme ini memastikan bahwa: blok yang telah mendapatkan suara mayoritas sah tidak akan ditinggalkan karena kesalahan pemimpin atau penghindaran yang disengaja. Risiko struktural dari percabangan akhir diselesaikan secara sistemik, dan protokol dapat membentuk batasan yang jelas terhadap perilaku melompat yang tidak pantas.
Jika seorang pemimpin mencoba melompati blok sebelumnya tanpa alasan dan gagal memberikan bukti NEC, protokol akan segera mengenali dan menolak tindakan tersebut. Tindakan melompati tanpa bukti kripto akan dianggap ilegal dan tidak akan mendapatkan dukungan konsensus jaringan.
Dari perspektif insentif ekonomi, desain ini memberikan perlindungan yang jelas bagi validator:
Selama blok yang diajukan secara jujur dan mendapatkan dukungan suara, hadiahnya tidak akan dicabut karena kegagalan pada tahap selanjutnya;
Bahkan dalam situasi ekstrem, seperti ketika suatu Node dengan sengaja melewatkan putaran proposalnya sendiri, berusaha membantu orang lain mengambil alih MEV dari Blok sebelumnya, protokol akan memaksa pemimpin berikutnya untuk mengajukan kembali Blok asli sebagai prioritas, sehingga penyerang tidak dapat memperoleh keuntungan ekonomi dengan melewati proses.
Lebih penting lagi, MonadBFT tidak mengorbankan kinerja protokol untuk meningkatkan keamanan.
Desain sebelumnya untuk menangani percabangan akhir (seperti protokol BeeGees) meskipun memiliki kemampuan perlindungan tertentu, sering kali bergantung pada kompleksitas komunikasi yang tinggi (n²) atau mengaktifkan proses komunikasi ulang di setiap putaran, yang dalam praktiknya dapat secara signifikan meningkatkan beban sistem.
Strategi desain MonadBFT lebih canggih:
Hanya memulai komunikasi tambahan (seperti pesan timeout, usulan kembali blok) saat tampilan gagal atau ada pengecualian. Dalam jalur reguler di mana pemimpin jujur terus-menerus menghasilkan blok, protokol tetap mempertahankan status operasi yang ringan dan efisien.
Keseimbangan dinamis antara kinerja dan keamanan ini adalah salah satu keunggulan inti MonadBFT dibandingkan dengan protokol generasi sebelumnya.
Ringkasan
Artikel ini mengulas mekanisme dasar konsensus PBFT tradisional, merangkum jalur perkembangan protokol HotStuff, dan secara khusus menjelaskan bagaimana MonadBFT menyelesaikan masalah pemisahan akhir yang timbul dari HotStuff secara struktural di tingkat protokol.
Pemisahan di akhir akan membengkokkan insentif ekonomi dari pengusul blok, dan juga menimbulkan ancaman potensial terhadap aktivitas jaringan. MonadBFT memastikan bahwa setiap blok yang diajukan oleh pemimpin yang jujur dan mendapatkan suara mayoritas yang sah tidak akan ditinggalkan atau dilewati dengan memperkenalkan mekanisme pengajuan ulang dan sertifikat tanpa dukungan (NEC).
Pada artikel berikutnya, kita akan terus membahas dua fitur inti lainnya dari MonadBFT:
Finalitas Spekulatif
Responsif Optimis
Dan menganalisis lebih lanjut makna praktis dari mekanisme ini bagi validator dan pengembang.
Belum selesai.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
MonadBFT Analisis (Bagian 1): Bagaimana Mengatasi Masalah Fork Akhir
Inti dari Blockchain adalah untuk mencapai suatu konsensus global yang ketat: artinya, terlepas dari di negara mana atau zona waktu mana jaringan node berada, semua peserta harus akhirnya mencapai kesepakatan tentang satu set hasil objektif.
Namun jaringan terdistribusi di dunia nyata tidak ideal: ada node yang terputus, ada node yang berbohong, bahkan ada orang yang sengaja merusak. Dalam keadaan seperti ini, bagaimana sistem dapat "bersatu dalam suara" dan tetap konsisten?
Inilah masalah yang ingin diselesaikan oleh protokol konsensus. Ini pada dasarnya adalah seperangkat aturan yang digunakan untuk membimbing sekelompok node yang independen satu sama lain, bahkan tidak sepenuhnya dapat dipercaya, tentang bagaimana mencapai keputusan yang seragam mengenai urutan dan isi setiap transaksi.
Dan begitu "konsensus ketat" ini terbangun, blockchain dapat membuka banyak fitur kunci, seperti perlindungan hak digital, model mata uang yang tahan inflasi, dan struktur kolaborasi sosial yang dapat diperluas. Namun, syaratnya adalah bahwa protokol konsensus itu sendiri harus menjamin dua aspek dasar secara bersamaan:
Tidak boleh ada dua blok yang saling bertentangan yang dikonfirmasi;
Jaringan harus terus maju, tidak boleh terhenti atau macet.
MonadBFT adalah terobosan teknologi terbaru yang dilakukan di arah ini.
Tinjauan singkat tentang evolusi protokol konsensus
Bidang mekanisme konsensus ini sebenarnya telah diteliti selama puluhan tahun. Protokol pertama, seperti PBFT (Practical Byzantine Fault Tolerance), sudah mampu menangani situasi yang sangat realistis: bahkan jika ada sebagian node di jaringan yang mengalami gangguan, berbuat jahat, atau berbicara omong kosong, selama mereka tidak melebihi 1/3 dari total jumlah, sistem masih dapat mencapai kesepakatan.
Desain dari protokol awal ini lebih "tradisional": setiap putaran memilih satu pemimpin, yang memulai usulan, dan validator lainnya melakukan pemungutan suara beberapa putaran untuk secara bertahap mengkonfirmasi urutan transaksi.
Seluruh proses pemungutan suara biasanya melalui beberapa tahap, seperti pre-prepare, prepare, commit, reply. Pada setiap tahap, semua validator harus berkomunikasi satu sama lain. Dengan kata lain, setiap orang harus berbicara dengan setiap orang, jumlah pesan meningkat secara "jaring" secara eksponensial.
Kompleksitas struktur komunikasi ini adalah n²—artinya, jika ada 100 validator di jaringan, maka setiap putaran konsensus mungkin perlu mengirim hampir 10.000 pesan.
Ini tidak menjadi masalah di jaringan kecil, tetapi begitu jumlah validator meningkat, beban komunikasi sistem akan dengan cepat menjadi sulit diterima, dan efisiensi akan langsung menurun.
Struktur komunikasi sekunder "setiap orang harus berkomunikasi dengan setiap orang" ini sebenarnya sangat tidak efisien. Misalnya, dalam jaringan yang memiliki 100 validator, setiap putaran konsensus mungkin harus memproses ribuan pesan.
Ini bisa ditangani dalam lingkaran kecil, tetapi jika diterapkan di jaringan blockchain global yang terbuka, beban komunikasi segera menjadi tidak dapat diterima. Oleh karena itu, protokol BFT awal seperti PBFT dan Tendermint biasanya hanya digunakan dalam skenario jaringan yang diizinkan (permissioned network) atau sistem dengan jumlah validator yang sangat sedikit, agar masih bisa berjalan.
Untuk memungkinkan protokol BFT juga dapat beradaptasi dengan lingkungan publik yang tidak memerlukan izin, beberapa desain generasi baru mulai beralih ke cara komunikasi yang lebih ringan: membuat setiap validator hanya berkomunikasi dengan pemimpin, bukan saling bertukar informasi di antara semua.
Ini mengurangi kompleksitas pesan dari n² sebelumnya, dioptimalkan menjadi n —— sangat mengurangi beban sistem.
Protokol HotStuff diusulkan pada tahun 2018, tepatnya untuk mengatasi masalah skalabilitas ini. Filosofi desainnya sangat jelas: menggantikan proses pemungutan suara PBFT yang rumit dengan struktur komunikasi yang lebih sederhana dan dipimpin oleh pemimpin.
Fitur kunci dari HotStuff adalah komunikasi linier (linear communication) yang disebut. Dalam mekanismenya, setiap validator hanya perlu mengirimkan suara mereka kepada pemimpin saat ini, dan pemimpin kemudian mengemas suara-suara ini untuk menghasilkan Quorum Certificate (QC, bukti mayoritas sah).
QC ini pada dasarnya adalah tanda tangan kolektif yang membuktikan kepada seluruh jaringan: "Sebagian besar node setuju dengan proposal ini."
Dalam perbandingan, mode komunikasi PBFT adalah "siaran semua", di mana setiap orang berbicara di grup, dan situasinya menjadi sangat kacau. Mode HotStuff lebih mirip dengan "satu orang mengumpulkan, satu kali mengemas", tidak peduli berapa banyak orang di jaringan, tetap dapat berfungsi dengan efisien.
Selain komunikasi linier, HotStuff juga dapat ditingkatkan lebih lanjut menjadi versi pipeline (pipelined HotStuff) untuk meningkatkan efisiensi.
Dalam HotStuff yang asli, satu validator akan terus menjabat sebagai pemimpin selama beberapa putaran, sampai sebuah blok sepenuhnya dikonfirmasi. Proses ini adalah "satu putaran memproses satu blok", seluruh energi difokuskan pada kemajuan blok yang sedang berjalan.
Dan di jalur produksi HotStuff, mekanismenya menjadi lebih fleksibel: setiap putaran akan memilih pemimpin baru, dan setiap pemimpin memiliki dua tugas:
Satu sisi mengemas suara dari putaran sebelumnya menjadi Quorum Certificate (QC), dan disiarkan ke seluruh jaringan;
Sambil mengajukan sebuah blok baru, bersiap untuk memulai putaran berikutnya.
Dengan kata lain, tidak lagi "mengonfirmasi satu sebelum memproses yang berikutnya", tetapi seperti jalur produksi, pemimpin yang berbeda bergiliran bertanggung jawab atas setiap tahap. Pemimpin sebelumnya mengajukan Blok, pemimpin berikutnya mengonfirmasinya dan melanjutkan untuk mengajukan blok baru, konsensus di blockchain berjalan seperti perlombaan estafet.
Inilah asal usul metafora "jalur produksi": blok saat ini masih dalam proses konfirmasi, sementara yang berikutnya sudah sedang dipersiapkan, beberapa langkah berjalan secara paralel, meningkatkan efisiensi throughput.
Secara keseluruhan, protokol seperti HotStuff telah membuat kemajuan signifikan dalam dua dimensi dibandingkan dengan BFT tradisional:
Pertama, komunikasi lebih ringan, setiap validator hanya perlu berkomunikasi dengan pemimpin;
Kedua, efisiensi pemrosesan lebih tinggi, beberapa proses konfirmasi blok dapat dilakukan secara paralel.
Ini membuat HotStuff menjadi template desain untuk banyak mekanisme konsensus PoS blockchain modern. Namun, setiap hal memiliki keuntungan dan kerugian—struktur jalur produksi meskipun berkinerja tinggi, juga secara diam-diam memperkenalkan risiko struktural yang sulit ditemukan.
Selanjutnya kita akan membahas masalah inti ini: Fork Ekor (Tail Forking).
Masalah Pemisahan Ekor (Tail-Forking)
Meskipun HotStuff — terutama versi pipelinenya — menyelesaikan masalah skalabilitas pada protokol konsensus, ia juga membawa beberapa tantangan baru. Salah satu yang paling krusial dan mudah diabaikan adalah masalah yang disebut "Tail Forking".
Apa itu fork akhir? Dapat dipahami secara sederhana sebagai: Blockchain mengalami reorganisasi blok yang tidak terduga di "ujung rantai" (reorg).
Secara spesifik, ada sebuah Blok yang valid, telah berhasil disebarkan ke sebagian besar validator, dan telah mendapatkan cukup dukungan suara. Seharusnya, ia segera dikonfirmasi dan ditulis ke dalam rantai utama. Namun akhirnya, ia "dilewati", dibuang (orphaned), dan digantikan oleh Blok baru lainnya pada ketinggian yang sama.
Ini bukan Bug, juga bukan serangan, melainkan karena struktur desain dari protokol itu sendiri, terdapat kemungkinan "jatuhnya ekor rantai". Apakah ini terdengar sedikit tidak adil? Lalu, bagaimana ini bisa terjadi?
Kami telah mengatakan sebelumnya, setiap pemimpin dalam alur kerja HotStuff memiliki dua tugas:
A. Usulkan sebuah blok baru (misalnya Bₙ₊₁)
B. Mengumpulkan suara untuk blok pemimpin sebelumnya, menghasilkan QC (seperti menyelesaikan konfirmasi akhir untuk Bₙ)
Kedua tugas ini dilakukan secara paralel, bergantian. Tapi masalahnya ada di sini.
Sebagai contoh: anggaplah Alice adalah pemimpin, dia mengajukan blok Bₙ pada ketinggian ke-n, blok ini memperoleh suara dari mayoritas super, sudah "hampir dikonfirmasi". Selanjutnya, Bob harus menjadi pemimpin, melanjutkan untuk mendorong blok berikutnya Bₙ₊₁, sekaligus juga harus mengemas QC (bukti mayoritas hukum) dari Bₙ ke dalam proposalnya, menyelesaikan konfirmasi akhir Bₙ.
Tetapi jika Bob sedang offline saat itu, atau sengaja tidak mengirimkan QC Bₙ, maka akan ada masalah.
Karena tidak ada yang menggantikan QC pengemasan blok Alice, catatan suara Bₙ tidak dapat disebarkan, blok yang seharusnya dikonfirmasi ini pun "ditangani dengan dingin", dan akhirnya diabaikan oleh seluruh jaringan.
Inilah esensi dari fork akhir: blok dari pemimpin sebelumnya dilewati karena kelalaian atau niat jahat dari pemimpin berikutnya.
Mengapa percabangan di akhir sangat parah?
Masalah pemisahan di bagian akhir terfokus pada dua aspek: 1) mekanisme insentif yang rusak, 2) aktivitas sistem yang terancam.
Pertama, hadiah ditelan: Jika sebuah blok dibuang, pemimpin yang mengajukan blok tersebut tidak akan mendapatkan hadiah apapun. Baik itu hadiah blok maupun biaya transaksi. Misalnya, Alice mengajukan sebuah blok yang sah dan mendapatkan dukungan suara mayoritas, tetapi karena kesalahan Bob atau tindakan jahat, blok ini tidak dapat dikonfirmasi, dan Alice pada akhirnya tidak mendapatkan satu sen pun. Ini akan menyebabkan struktur insentif yang salah: Node jahat seperti Bob dapat "memutus" sumber hadiah mereka dengan melewati blok lawan. Tindakan ini tidak memerlukan serangan teknis, hanya perlu "tidak kooperatif" secara sengaja, untuk melemahkan pendapatan pesaing. Jika hal ini terjadi berulang kali, seiring waktu, itu akan menurunkan partisipasi dan keadilan sistem secara keseluruhan, bahkan dapat memicu kolusi antar node.
Kedua, ruang serangan MEV semakin meluas: Pemisahan akhir juga akan membawa masalah yang lebih tersembunyi namun serius: ruang untuk manipulasi jahat MEV (nilai maksimum yang dapat diekstrak) semakin besar. Sebagai contoh: Misalkan dalam blok Alice terdapat transaksi arbitrase yang sangat berharga. Jika Bob berniat membuat masalah, ia dapat berkolusi dengan pemimpin berikutnya, Carol, untuk tidak menyebarkan blok Alice. Kemudian, Carol dapat membangun blok baru pada ketinggian yang sama dan "menyalin" transaksi arbitrase milik Alice—mengubah hasil MEV menjadi miliknya sendiri. Tindakan "pengaturan ulang rantai + kolusi pencurian" ini, secara kasat mata masih sesuai dengan aturan pembuatan blok, tetapi sebenarnya merupakan perampokan yang dirancang dengan baik. Yang lebih buruk, hal ini dapat mendorong terbangunnya "hubungan kolusi" di antara para pemimpin, menjadikan konfirmasi blok sebagai permainan distribusi keuntungan, bukan sebagai layanan publik.
Ketiga, merusak jaminan finalitas, memengaruhi pengalaman pengguna: Dibandingkan dengan protokol jenis Nakamoto, salah satu keunggulan besar BFT adalah finalitas deterministik: setelah blok diserahkan, tidak dapat dibatalkan. Namun, fork di bagian akhir merusak jaminan ini, terutama pada blok yang "telah mendapatkan suara tetapi belum secara resmi dikonfirmasi". Beberapa dapp dengan throughput tinggi biasanya berharap dapat langsung membaca data setelah blok mendapatkan suara untuk mengurangi latensi, dan jika blok tersebut tiba-tiba dibuang, dapat menyebabkan status pengguna kembali—misalnya saldo akun yang tidak normal, transaksi leverage tinggi yang baru saja diselesaikan menghilang tanpa alasan, status permainan yang tiba-tiba direset, dan lain-lain.
Keempat, dapat memicu kegagalan berantai: Secara umum, cabang akhir mungkin hanya membuat suatu blok terkonfirmasi terlambat satu putaran, dampaknya tidak terlalu besar. Namun, dalam beberapa skenario tepi, jika beberapa pemimpin berturut-turut memilih untuk melewatkan blok sebelumnya, sistem dapat terhenti, tidak ada yang bersedia "mengambil" blok sebelumnya. Seluruh kemajuan rantai terhenti, sampai akhirnya muncul seorang pemimpin yang "bersedia memikul tanggung jawab", jaringan akan terus maju.
Meskipun sebelumnya ada beberapa solusi, seperti mekanisme penghindaran fork di bagian akhir yang diusulkan oleh protokol BeeGees, seringkali harus mengorbankan kinerja, seperti memperkenalkan kembali kompleksitas komunikasi kedua, yang tidak sebanding dengan hasilnya.
Apa itu MonadBFT?
MonadBFT adalah protokol konsensus generasi baru yang dirancang khusus untuk menyelesaikan masalah percabangan akhir. Kelebihan utamanya adalah: dalam menyelesaikan risiko struktural, tidak mengorbankan keuntungan kinerja yang dibawa oleh pipeline HotStuff. Dengan kata lain, MonadBFT bukanlah sebuah pendekatan dari awal, melainkan melanjutkan optimasi berdasarkan kerangka inti HotStuff. Ini mempertahankan tiga fitur kunci:
Rotasi pemimpin (rotating leader): setiap putaran memilih pemimpin baru untuk memajukan blok;
Penerapan alur: beberapa proses konfirmasi blok dapat tumpang tindih;
Komunikasi linier (linear messaging): setiap validator hanya perlu berkomunikasi dengan pemimpin, menghemat banyak biaya jaringan.
Tetapi hanya mengandalkan tiga poin ini masih belum cukup aman. Untuk menutup celah struktural pada pemisahan akhir, MonadBFT menambahkan dua mekanisme kunci:
Mekanisme Pengajuan Ulang (Re-Proposal)
Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate)
Mekanisme Pengajuan Ulang (Re-Proposal)
Dalam protokol BFT, waktu dibagi menjadi beberapa putaran (disebut view), di mana setiap putaran memiliki satu pemimpin yang bertanggung jawab untuk mengusulkan blok baru. Jika pemimpin gagal (misalnya tidak mengusulkan blok tepat waktu, atau usulan tidak valid), sistem akan beralih ke putaran berikutnya dan memilih pemimpin baru.
MonadBFT menambahkan mekanisme yang memastikan bahwa selama proses pergantian view, setiap blok yang diajukan dengan jujur tidak akan "hilang" karena pergantian pemimpin.
Ketika pemimpin putaran saat ini gagal, validator akan mengeluarkan pesan perubahan putaran yang ditandatangani, menunjukkan bahwa putaran saat ini telah melebihi batas waktu.
Yang istimewa, pesan ini tidak hanya menunjukkan "waktu habis", tetapi juga harus menyertakan informasi blok dari suara terakhir validator tersebut, yang setara dengan mengatakan: "Saya tidak menerima proposal yang sah, ini adalah blok terbaru yang saya lihat."
Pemimpin baru akan mengumpulkan pesan timeout ini dari super mayoritas (2f+1) validator dan menggabungkannya menjadi satu bukti timeout (Timeout Certificate, TC). TC ini mewakili: ketika putaran sebelumnya gagal, seluruh jaringan memiliki snapshot kesepakatan tentang "blok kepala rantai". Pemimpin baru akan memilih blok dengan tinggi tertinggi (atau nomor tampilan terbaru), yang disebut high_tip.
MonadBFT mengharuskan: proposal pemimpin baru harus mencakup TC yang sah, dan harus mengusulkan kembali blok tertinggi yang tertunda dalam TC, sehingga blok ini mendapatkan kesempatan untuk dikonfirmasi lagi.
Mengapa? Seperti yang kami sebutkan sebelumnya: kami tidak ingin Blok yang hampir terkonfirmasi menghilang.
Contoh: Misalkan Alice adalah pemimpin view 5, mengajukan sebuah blok yang valid, dan mendapatkan suara mayoritas. Selanjutnya, pemimpin view 6 Bob offline, tidak dapat melanjutkan proses rantai. Ketika Carol menjabat sebagai pemimpin view 7, sesuai dengan aturan MonadBFT, dia harus menyertakan TC dan mengajukan kembali blok Alice. Dengan cara ini, kerja jujur Alice tidak akan sia-sia.
Jika Carol tidak memiliki blok Alice, dia dapat meminta dari node lain. Node dapat:
Sediakan blok ini, atau
Mengembalikan satu pesan "tanpa dukungan" yang ditandatangani (No-Endorsement, NE), yang menunjukkan bahwa dirinya tidak memiliki blok ini (mekanismenya akan dijelaskan kemudian). (Maksimal f node Bizantium mungkin memilih untuk mengabaikan permintaan, tanpa memberikan respons.)
Setelah Carol mengusulkan kembali blok Alice, dia akan mendapatkan satu kesempatan usulan tambahan, memastikan bahwa dia tidak akan "terkena dampak" karena kegagalan pemimpin sebelumnya.
Fungsi mekanisme pengusulan kembali ini adalah jelas: memastikan bahwa kemajuan rantai adalah adil, dan tidak ada pekerjaan yang valid yang akan diam-diam dibuang karena keberuntungan yang buruk atau karena seseorang mengganggu.
Sertifikat Tanpa Dukungan (NEC)
Melanjutkan contoh sebelumnya: Setelah waktu putaran Bob habis, Carol meminta validator lain untuk menyediakan blok high_tip (yaitu blok Alice). Pada saat ini, setidaknya 2f+1 validator akan merespons:
Berikan blok Alice
Kirim pesan NE yang ditandatangani, menunjukkan bahwa Anda tidak menerima blok Alice.
Selama Carol menerima blok dari Alice, dia harus mengusulkannya kembali sesuai aturan. Hanya jika setidaknya f+1 validator telah menandatangani pesan NE, Carol dapat melewati blok tersebut dan mengajukan yang baru.
Mengapa f+1? Dalam sistem BFT yang terdiri dari 3f+1 validator, hanya ada maksimal f yang mungkin berbuat jahat. Jika blok Alice benar-benar mendapatkan suara mayoritas super, maka setidaknya 2f+1 node yang jujur telah menerimanya.
Oleh karena itu, jika Carol mengklaim "saya tidak dapat mendapatkan blok Alice", maka dia harus menyajikan tanda tangan dari f+1 validator, membuktikan bahwa orang-orang ini tidak menerima. Ini membentuk sebuah Sertifikat Tanpa Dukungan (No-Endorsement Certificate, NEC).
NEC adalah sertifikat pemimpin "pengecualian": itu adalah bukti yang dapat diverifikasi, yang menunjukkan bahwa blok sebelumnya belum siap untuk dikonfirmasi, dan bukan karena melompati dengan niat jahat, tetapi dengan alasan yang jelas "melepaskan".
Usulan ulang + Sertifikat tanpa dukungan = Mengatasi percabangan akhir
MonadBFT menetapkan seperangkat aturan pemrosesan chain head yang ketat dan jelas dengan memperkenalkan mekanisme Re-Proposal dan Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate):
Selesaikan pengiriman akhir untuk blok yang "dekat dengan konfirmasi"; atau berikan bukti yang cukup untuk menunjukkan bahwa blok tersebut belum memenuhi syarat untuk dikonfirmasi, jika tidak, tidak diizinkan untuk melewati atau mengganti blok sebelumnya.
Mekanisme ini memastikan bahwa: blok yang telah mendapatkan suara mayoritas sah tidak akan ditinggalkan karena kesalahan pemimpin atau penghindaran yang disengaja. Risiko struktural dari percabangan akhir diselesaikan secara sistemik, dan protokol dapat membentuk batasan yang jelas terhadap perilaku melompat yang tidak pantas.
Jika seorang pemimpin mencoba melompati blok sebelumnya tanpa alasan dan gagal memberikan bukti NEC, protokol akan segera mengenali dan menolak tindakan tersebut. Tindakan melompati tanpa bukti kripto akan dianggap ilegal dan tidak akan mendapatkan dukungan konsensus jaringan.
Dari perspektif insentif ekonomi, desain ini memberikan perlindungan yang jelas bagi validator:
Selama blok yang diajukan secara jujur dan mendapatkan dukungan suara, hadiahnya tidak akan dicabut karena kegagalan pada tahap selanjutnya;
Bahkan dalam situasi ekstrem, seperti ketika suatu Node dengan sengaja melewatkan putaran proposalnya sendiri, berusaha membantu orang lain mengambil alih MEV dari Blok sebelumnya, protokol akan memaksa pemimpin berikutnya untuk mengajukan kembali Blok asli sebagai prioritas, sehingga penyerang tidak dapat memperoleh keuntungan ekonomi dengan melewati proses.
Lebih penting lagi, MonadBFT tidak mengorbankan kinerja protokol untuk meningkatkan keamanan.
Desain sebelumnya untuk menangani percabangan akhir (seperti protokol BeeGees) meskipun memiliki kemampuan perlindungan tertentu, sering kali bergantung pada kompleksitas komunikasi yang tinggi (n²) atau mengaktifkan proses komunikasi ulang di setiap putaran, yang dalam praktiknya dapat secara signifikan meningkatkan beban sistem.
Strategi desain MonadBFT lebih canggih:
Hanya memulai komunikasi tambahan (seperti pesan timeout, usulan kembali blok) saat tampilan gagal atau ada pengecualian. Dalam jalur reguler di mana pemimpin jujur terus-menerus menghasilkan blok, protokol tetap mempertahankan status operasi yang ringan dan efisien.
Keseimbangan dinamis antara kinerja dan keamanan ini adalah salah satu keunggulan inti MonadBFT dibandingkan dengan protokol generasi sebelumnya.
Ringkasan
Artikel ini mengulas mekanisme dasar konsensus PBFT tradisional, merangkum jalur perkembangan protokol HotStuff, dan secara khusus menjelaskan bagaimana MonadBFT menyelesaikan masalah pemisahan akhir yang timbul dari HotStuff secara struktural di tingkat protokol.
Pemisahan di akhir akan membengkokkan insentif ekonomi dari pengusul blok, dan juga menimbulkan ancaman potensial terhadap aktivitas jaringan. MonadBFT memastikan bahwa setiap blok yang diajukan oleh pemimpin yang jujur dan mendapatkan suara mayoritas yang sah tidak akan ditinggalkan atau dilewati dengan memperkenalkan mekanisme pengajuan ulang dan sertifikat tanpa dukungan (NEC).
Pada artikel berikutnya, kita akan terus membahas dua fitur inti lainnya dari MonadBFT:
Finalitas Spekulatif
Responsif Optimis
Dan menganalisis lebih lanjut makna praktis dari mekanisme ini bagi validator dan pengembang.
Belum selesai.