Inti dari blockchain adalah untuk mencapai suatu konsensus global yang ketat: yaitu, terlepas dari di mana node jaringan berada, di negara mana, atau zona waktu mana, semua peserta pada akhirnya harus 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 bisa "berbicara serempak" 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 yang tidak sepenuhnya dapat dipercaya, tentang bagaimana mencapai keputusan yang seragam mengenai urutan dan konten setiap transaksi.
Dan begitu "konsensus ketat" ini terbentuk, 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, 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 terhambat atau terhenti.
MonadBFT adalah terobosan teknologi terbaru yang dilakukan dalam arah ini.
Tinjauan singkat evolusi protokol konsensus
Bidang mekanisme konsensus sebenarnya telah diteliti selama puluhan tahun. Protokol pertama, seperti PBFT (Practical Byzantine Fault Tolerance), sudah dapat menangani situasi yang sangat realistis: meskipun ada sebagian node di jaringan yang mengalami kegagalan, berbuat jahat, atau berbicara sembarangan, selama jumlah mereka tidak melebihi 1/3 dari total, sistem masih dapat mencapai kesepakatan.
Desain protokol awal ini lebih "tradisional": setiap putaran memilih seorang pemimpin yang mengajukan proposal, dan validator lainnya melakukan pemungutan suara berulang kali untuk mengonfirmasi urutan transaksi langkah demi langkah.
Proses voting biasanya melalui beberapa tahapan, seperti pre-prepare, prepare, commit, dan reply. Pada setiap tahap, semua validator berkomunikasi satu sama lain. Dengan kata lain, setiap orang harus memberi tahu semua orang, dan volume pesan tumbuh secara eksplosif di "jaring".
Kompleksitas struktur komunikasi ini adalah n²—artinya, jika ada 100 validator di jaringan, maka setiap putaran konsensus mungkin harus mengirimkan hampir 10.000 pesan.
Ini bukan masalah besar dalam jaringan kecil, tetapi begitu jumlah validator meningkat, beban komunikasi pada sistem dapat dengan cepat menjadi tak tertahankan, dan efisiensi akan langsung berkurang.
Sumber data:
Struktur komunikasi kedua yang "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 masih dapat ditangani dalam lingkaran kecil, tetapi jika diterapkan di jaringan blockchain yang terbuka dan global, beban komunikasi segera menjadi tidak dapat diterima. Oleh karena itu, protokol BFT awal seperti PBFT dan Tendermint biasanya hanya digunakan dalam skenario yang terizinkan (permissioned network) atau sistem dengan jumlah validator yang sangat sedikit, sehingga masih dapat berjalan.
Untuk menyesuaikan protokol BFT dengan lingkungan rantai publik tanpa izin, beberapa desain generasi berikutnya telah mulai bergerak menuju cara komunikasi yang lebih ringan: setiap validator hanya berkomunikasi dengan pemimpin, bukan semua anggota tim.
Ini mengoptimalkan kompleksitas pesan dari n² ke n - sangat mengurangi beban pada sistem.
Protokol HotStuff diperkenalkan pada tahun 2018, yang bertujuan untuk menyelesaikan masalah skalabilitas ini. Prinsip desainnya sangat jelas: menggantikan proses pemungutan suara PBFT yang kompleks dengan struktur komunikasi yang lebih sederhana dan dipimpin oleh pemimpin.
Fitur kunci dari HotStuff adalah apa yang disebut komunikasi linier (linear communication). Dalam mekanismenya, setiap validator hanya perlu mengirimkan suaranya kepada pemimpin saat ini, dan pemimpin kemudian mengemas suara-suara tersebut untuk menghasilkan Quorum Certificate (QC, sertifikat mayoritas yang sah).
QC ini pada dasarnya adalah tanda tangan kolektif yang membuktikan kepada seluruh jaringan: "Kebanyakan node setuju dengan proposal ini."
Jika dibandingkan, mode komunikasi PBFT adalah "siaran semua orang", di mana setiap orang berbicara di grup, dan situasinya menjadi sangat kacau. Mode HotStuff lebih mirip dengan "satu orang mengumpulkan, satu kali mengemas", terlepas dari berapa banyak orang di jaringan, tetap dapat beroperasi dengan efisien.
Gambar di atas membandingkan struktur komunikasi fan-out HotStuff dengan mode interkoneksi seluruh jaringan PBFT.
Sumber data:
Selain komunikasi linier, HotStuff juga dapat ditingkatkan lebih lanjut menjadi versi pipelined (pipelined HotStuff) untuk meningkatkan efisiensi.
Dalam HotStuff yang asli, validator yang sama akan terus berfungsi sebagai pemimpin dalam beberapa putaran hingga sebuah blok sepenuhnya dikonfirmasi. Proses ini adalah "satu putaran menangani satu blok", semua energi difokuskan untuk mendorong blok saat ini.
Dan dalam jalur produksi HotStuff, mekanismenya menjadi lebih fleksibel: setiap putaran akan memilih pemimpin baru, dan setiap pemimpin memiliki dua tugas:
Sambil mengemas suara dari putaran sebelumnya menjadi Quorum Certificate (QC), disiarkan ke seluruh jaringan;
Mengajukan blok baru, bersiap untuk memulai putaran berikutnya.
Ini berarti, tidak lagi "mengonfirmasi satu dan kemudian memproses yang berikutnya", tetapi seperti jalur produksi, di mana pemimpin yang berbeda bergiliran bertanggung jawab untuk setiap tahap. Pemimpin sebelumnya mengusulkan blok, pemimpin berikutnya mengonfirmasi itu dan melanjutkan untuk mengusulkan blok baru, konsensus di atas rantai berjalan seperti estafet.
Inilah asal usul metafora "jalur perakitan": blok saat ini masih dalam proses konfirmasi, sementara yang berikutnya sudah dalam persiapan, beberapa langkah dilakukan secara paralel untuk meningkatkan efisiensi throughput.
Singkatnya, protokol seperti HotStuff membuat perbaikan signifikan atas BFT tradisional dalam dua dimensi:
Pertama, komunikasi menjadi lebih ringan, setiap validator hanya perlu berkomunikasi dengan pemimpin;
Kedua, efisiensi pemrosesan lebih tinggi, beberapa proses konfirmasi blok dapat dilakukan secara paralel.
Ini menjadikan HotStuff sebagai template desain untuk banyak mekanisme konsensus blockchain PoS modern. Namun, setiap hal memiliki kelebihan dan kekurangan—struktur aliran meskipun memiliki kinerja yang kuat, juga diam-diam memperkenalkan risiko struktural yang tidak mudah terdeteksi.
Selanjutnya, kita akan membahas secara mendalam tentang masalah inti ini: Tail Forking.
Masalah Percabangan Ekor (Tail-Forking)
Meskipun HotStuff — terutama versi pipelinenya — menyelesaikan masalah skalabilitas protokol konsensus, ia juga memperkenalkan beberapa tantangan baru. Salah satu yang paling kritis dan mudah diabaikan adalah masalah yang disebut "Tail Forking".
Apa itu fork bagian belakang? Dapat dengan mudah dipahami sebagai: terjadi reorganisasi blok yang tidak terduga di "ujung rantai" blockchain (reorg).
Secara spesifik, ada sebuah blok yang valid, telah berhasil disebarluaskan ke sebagian besar validator, dan telah mendapatkan cukup banyak dukungan suara. Seharusnya, blok ini segera dikonfirmasi dan ditulis ke dalam rantai utama. Namun akhirnya, blok tersebut "dilewati", dibuang (orphaned), dan digantikan oleh blok baru lainnya pada tinggi yang sama.
Ini bukan Bug, juga bukan serangan, melainkan karena struktur desain dari protokol itu sendiri, terdapat kemungkinan "jatuhnya rantai". Apakah ini terdengar agak tidak adil? Lalu, bagaimana ini bisa terjadi?
Kita sudah membahas sebelumnya, setiap pemimpin dalam jalur HotStuff memiliki dua tugas:
A. Usulkan blok baru (misalnya Bₙ₊₁)
B. Mengumpulkan suara untuk blok pemimpin sebelumnya, menghasilkan QC (misalnya menyelesaikan konfirmasi akhir untuk Bₙ)
Kedua tugas ini berjalan secara paralel, bergantian. Tapi masalahnya muncul di sini.
Misalnya: anggaplah Alice adalah pemimpin, dia mengajukan blok Bₙ pada ketinggian ke-n, blok ini telah mendapatkan suara mayoritas yang besar, dan sudah "hampir dikonfirmasi."
Selanjutnya, Bob harus menjadi pemimpin dan melanjutkan kemajuan blok berikutnya Bₙ₊₁ dari rantai, sambil juga mengemas QC (bukti mayoritas sah) dari Bₙ ke dalam proposalnya, untuk menyelesaikan konfirmasi akhir Bₙ.
Namun, jika Bob sedang offline saat itu, atau sengaja tidak mengirimkan QC Bₙ, maka akan ada masalah.
Karena tidak ada yang menyelesaikan QC packaging untuk blok Alice, catatan suara Bₙ tidak dapat disebarluaskan, blok yang seharusnya dikonfirmasi ini pun "ditangani dengan dingin" dan akhirnya diabaikan oleh seluruh jaringan.
Inilah esensi dari percabangan akhir: blok pemimpin sebelumnya dilewati karena kelalaian atau niat jahat pemimpin berikutnya.
Mengapa percabangan ekor begitu parah?
Masalah percabangan di akhir terutama terfokus pada dua aspek: 1) mekanisme insentif yang terganggu, 2) aktivitas sistem yang terancam.
Pertama, hadiah ditelan:
Jika sebuah blok dibuang, pemimpin yang mengusulkannya tidak akan mendapatkan hadiah apa pun. Baik itu hadiah pembuatan blok atau biaya transaksi. Misalnya, Alice mengusulkan sebuah blok yang sah, dan mendapatkan dukungan suara mayoritas super, tetapi karena kesalahan Bob atau tindakan jahat, blok ini tidak dapat dikonfirmasi, dan Alice akhirnya tidak mendapatkan satu sen pun. Ini akan mengakibatkan struktur insentif yang salah: node jahat seperti Bob dapat "memutuskan" sumber hadiah mereka dengan melewatkan blok lawan. Tindakan ini tidak memerlukan serangan teknis, hanya perlu "tidak bekerja sama" dengan sengaja untuk melemahkan pendapatan pesaing. Jika hal ini terjadi berulang kali, seiring waktu, akan menurunkan partisipasi dan keadilan sistem secara keseluruhan, bahkan dapat memicu kolusi antar node.
Kedua, ruang serangan MEV diperluas:
Pemisahan di bagian akhir juga dapat menyebabkan masalah yang lebih tersembunyi namun serius: ruang untuk manipulasi jahat MEV (nilai maksimum yang dapat diekstraksi) menjadi lebih besar. Misalnya: anggaplah bahwa di blok Alice terdapat transaksi arbitrase yang sangat bernilai. Jika Bob berniat untuk membuat masalah, dia bisa berkolusi dengan pemimpin berikutnya, Carol, untuk sengaja tidak menyebarkan blok Alice. Kemudian Carol membangun kembali blok baru pada ketinggian yang sama, "menyalin" transaksi arbitrase yang seharusnya dimiliki oleh Alice — mengubah hasil MEV menjadi miliknya sendiri. Tindakan "pengaturan ulang kepala rantai + kolusi penyalahgunaan" ini, meskipun secara permukaan mengikuti aturan dalam memproduksi blok, sebenarnya merupakan sebuah perampokan yang dirancang dengan cermat. Yang lebih buruk, ini dapat mendorong para pemimpin untuk membangun "hubungan kolusi", menjadikan konfirmasi blok sebagai permainan distribusi keuntungan, bukan layanan publik.
Salah satu keuntungan besar BFT dibandingkan protokol seperti Nakamoto adalah finalitas deterministik: setelah blok dilakukan, blok tidak dapat dibatalkan. Tetapi garpu ekor merusak jaminan ini, terutama pada blok yang telah "dipilih tetapi tidak dikonfirmasi secara resmi." Beberapa dapp throughput tinggi biasanya ingin dapat membaca data segera setelah blok dipilih untuk mengurangi latensi, dan jika blok tiba-tiba dibuang, itu dapat menyebabkan kemunduran status pengguna - seperti saldo akun yang tidak normal, transaksi leverage tinggi yang baru saja selesai menghilang tanpa alasan, reset tiba-tiba dari status game, dll.
Keempat, mungkin menyebabkan kegagalan berantai:
Secara umum, cabang akhir mungkin hanya menyebabkan suatu blok terkonfirmasi terlambat satu putaran, sehingga dampaknya tidak terlalu besar. Namun, dalam beberapa skenario tepi, jika beberapa pemimpin berturut-turut memilih untuk melewatkan blok sebelumnya, sistem dapat terjebak dalam keadaan stagnasi, di mana tidak ada yang bersedia untuk "mengambil" blok sebelumnya. Seluruh kemajuan rantai terhenti, sampai akhirnya muncul seorang pemimpin yang "bersedia untuk memikul tanggung jawab", jaringan baru akan terus maju.
Meskipun sebelumnya ada beberapa solusi, seperti mekanisme penghindaran fork di akhir yang diusulkan oleh protokol BeeGees, seringkali harus牺牲 kinerja, seperti memperkenalkan kembali kompleksitas komunikasi kedua, yang tidak sebanding.
Apa itu MonadBFT?
MonadBFT adalah protokol konsensus generasi baru yang dirancang khusus untuk mengatasi masalah cabang akhir. Keunggulan utamanya adalah: dalam menyelesaikan risiko struktural, tidak mengorbankan keuntungan kinerja yang dibawa oleh HotStuff yang berbasis jalur. Dengan kata lain, MonadBFT bukanlah membongkar dan membangun kembali, melainkan melanjutkan optimasi berdasarkan kerangka inti HotStuff. Ini mempertahankan tiga fitur kunci:
Rotasi Pemimpin (rotating leader): Setiap putaran memilih pemimpin baru untuk memajukan rantai;
2）Pengajuan pipelined: Proses konfirmasi beberapa blok dapat dilakukan secara bersamaan;
Komunikasi linier (linear messaging): Setiap validator hanya perlu berkomunikasi dengan pemimpin, menghemat banyak biaya jaringan.
Namun hanya mengandalkan tiga poin ini masih belum cukup aman. Untuk menutup celah struktural pada bagian akhir cabang ini, MonadBFT menambahkan dua mekanisme kunci:
1）Mekanisme Pengajuan Ulang (Re-Proposal)
2）Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate)
Mekanisme Pengajuan Ulang (Re-Proposal)
Dalam protokol BFT, waktu dibagi menjadi putaran-putaran (disebut view), di mana setiap putaran memiliki seorang pemimpin yang bertanggung jawab untuk mengajukan blok baru. Jika pemimpin gagal (misalnya tidak mengajukan blok tepat waktu, atau proposal tidak valid), sistem akan beralih ke putaran berikutnya dan memilih pemimpin baru.
MonadBFT menambahkan mekanisme yang memastikan bahwa selama proses pergantian view, blok yang diajukan secara jujur tidak akan "terputus" karena pergantian pemimpin.
Ketika pemimpin dari putaran saat ini gagal, para validator akan mengeluarkan pesan pergantian putaran yang ditandatangani (view change), yang menunjukkan bahwa putaran saat ini telah melewati batas waktu.
Yang khusus adalah, pesan ini tidak hanya menunjukkan "timeout", tetapi juga harus menyertakan informasi blok terakhir yang dipilih oleh 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 sebuah sertifikat timeout (Timeout Certificate, TC). TC ini mewakili: ketika putaran sebelumnya gagal, seluruh jaringan memiliki snapshot kesepakatan yang bersatu tentang "blok kepala rantai". Pemimpin baru akan memilih blok dengan tinggi tertinggi (atau nomor tampilan terbaru), yang disebut sebagai high_tip.
Persyaratan MonadBFT: Proposal pemimpin baru harus mencakup TC yang sah, dan harus mengajukan kembali blok tertunda tertinggi dalam TC, memberi blok ini kesempatan untuk dikonfirmasi kembali.
Mengapa? Seperti yang telah kami sebutkan sebelumnya: kami tidak ingin blok yang hampir terkonfirmasi menghilang begitu saja.
Berikut contohnya: Katakanlah Alice adalah pemimpin pandangan 5, mengusulkan blok yang valid, dan mendapat suara mayoritas. Selanjutnya, Bob, pemimpin tampilan 6, offline dan gagal memajukan proses rantai. Pada saat Carol mengambil peran sebagai pemimpin pandangan 7, dia harus memasukkan TC sesuai dengan aturan MonadBFT, dan mengusulkan kembali blok Alice. Dengan cara ini, kerja jujur Alice tidak akan-.
Jika Carol tidak memiliki blok Alice, dia dapat meminta dari node lain. Node dapat:
Sediakan blok tersebut, atau
Mengembalikan sebuah "Pesan Tanpa Dukungan" (No-Endorsement, NE) yang menandakan bahwa dirinya tidak memiliki blok tersebut (mekanismenya akan dijelaskan kemudian). (Paling banyak f node Bizantium mungkin memilih untuk mengabaikan permintaan dan tidak memberikan respons.)
Setelah Carol mengusulkan kembali blok Alice, dia akan mendapatkan satu kesempatan proposal tambahan, memastikan bahwa dia tidak akan "terkait" karena kegagalan pemimpin putaran sebelumnya.
Fungsi dari mekanisme usulan ulang 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 seseorang yang mengganggu.
Sertifikat Tanpa Dukungan (NEC)
Melanjutkan contoh sebelumnya: Setelah Bob melewati batas waktu, Carol meminta validator lain untuk memberikan blok high_tip (yaitu blok Alice). Pada saat ini, setidaknya 2f+1 validator akan memberikan respons:
Berikan blok Alice atau tidak
Kirim pesan NE yang ditandatangani, menyatakan bahwa saya belum menerima blok Alice.
Selama Carol menerima blok dari Alice, dia harus mengajukan ulang sesuai aturan. Carol hanya dapat melewatkan blok tersebut dan mengajukan yang baru jika setidaknya f+1 validator telah menandatangani pesan NE.
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 ada 2f+1 node yang jujur telah menerimanya.
Oleh karena itu, jika Carol mengklaim "saya tidak dapat mendapatkan blok Alice", maka dia harus menunjukkan 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 pemimpin dalam "pengecualian": ini adalah bukti yang dapat diverifikasi, yang menunjukkan bahwa blok sebelumnya belum siap untuk dikonfirmasi, bukan karena dengan sengaja dilewati, tetapi dengan alasan yang jelas "melepaskan".
Usulan ulang + Sertifikat tanpa dukungan = Menyelesaikan pemisahan akhir
MonadBFT menetapkan seperangkat aturan pengolahan chain head yang ketat dan jelas dengan memperkenalkan mekanisme Re-Proposal dan Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate):
Selesaikan pengajuan akhir untuk blok yang "dekat dikonfirmasi";
Berikan bukti yang cukup untuk membuktikan bahwa blok tersebut belum memenuhi syarat untuk dikonfirmasi,
Jika tidak, tidak diperbolehkan untuk melewati atau mengganti blok sebelumnya.
Mekanisme ini memastikan bahwa: setiap blok yang telah memperoleh suara mayoritas sah tidak akan ditinggalkan karena kesalahan pemimpin atau penghindaran yang disengaja.
Risiko struktural dari percabangan ekor diatasi secara sistematis, dan protokol dapat membentuk batasan yang jelas terhadap perilaku melompati yang tidak pantas.
Jika seorang pemimpin mencoba untuk melompati blok sebelumnya tanpa alasan, tetapi gagal memberikan bukti NEC, protokol akan segera mengidentifikasi dan menolak tindakan tersebut. Tindakan melompati tanpa bukti kripto akan dianggap ilegal dan tidak akan mendapatkan dukungan konsensus jaringan.
Dari segi 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 di tahap selanjutnya;
Bahkan dalam situasi ekstrem, seperti ketika suatu node dengan sengaja melewati putaran proposalnya sendiri, berusaha membantu orang lain untuk merebut MEV dari blok sebelumnya, protokol akan memaksa pemimpin berikutnya untuk mengutamakan mengusulkan kembali blok asli, sehingga penyerang tidak dapat memperoleh keuntungan ekonomi dengan melewati proses.
Lebih penting lagi, MonadBFT tidak牺牲 kinerja protokol untuk meningkatkan keamanan.
Beberapa desain sebelumnya untuk menangani pemisahan bagian 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 akan secara signifikan meningkatkan beban sistem.
Strategi desain MonadBFT lebih canggih:
Komunikasi tambahan (seperti pesan timeout, pengajuan ulang blok) hanya dimulai saat ada kegagalan tampilan atau adanya pengecualian. Di jalur reguler di mana sebagian besar pemimpin yang jujur terus 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 sebelumnya.
ringkasan
Artikel ini mengulas mekanisme dasar konsensus PBFT tradisional, menguraikan jalur pengembangan protokol HotStuff, dan secara khusus menjelaskan bagaimana MonadBFT menyelesaikan masalah percabangan akhir yang melekat dalam HotStuff melalui struktur lapisan protokol.
Pemisahan di bagian akhir dapat memutarbalik insentif ekonomi proposer blok dan juga menimbulkan ancaman potensial terhadap aktivitas jaringan. MonadBFT memastikan bahwa setiap blok yang diajukan oleh pemimpin yang jujur dan memperoleh suara mayoritas yang sah tidak akan ditinggalkan atau dilewati dengan memperkenalkan mekanisme pengajuan ulang dan sertifikat tanpa dukungan (NEC).
Dalam artikel selanjutnya, kami akan melanjutkan untuk membahas dua fitur inti lain dari MonadBFT:
dan lebih lanjut menganalisis arti praktis dari mekanisme ini untuk 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: Mendefinisikan ulang keamanan konsensus Blockchain,告别尾部分叉风险
Penulis: michaellwy
Inti dari blockchain adalah untuk mencapai suatu konsensus global yang ketat: yaitu, terlepas dari di mana node jaringan berada, di negara mana, atau zona waktu mana, semua peserta pada akhirnya harus 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 bisa "berbicara serempak" 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 yang tidak sepenuhnya dapat dipercaya, tentang bagaimana mencapai keputusan yang seragam mengenai urutan dan konten setiap transaksi.
Dan begitu "konsensus ketat" ini terbentuk, 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, 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 terhambat atau terhenti.
MonadBFT adalah terobosan teknologi terbaru yang dilakukan dalam arah ini.
Tinjauan singkat evolusi protokol konsensus
Bidang mekanisme konsensus sebenarnya telah diteliti selama puluhan tahun. Protokol pertama, seperti PBFT (Practical Byzantine Fault Tolerance), sudah dapat menangani situasi yang sangat realistis: meskipun ada sebagian node di jaringan yang mengalami kegagalan, berbuat jahat, atau berbicara sembarangan, selama jumlah mereka tidak melebihi 1/3 dari total, sistem masih dapat mencapai kesepakatan.
Desain protokol awal ini lebih "tradisional": setiap putaran memilih seorang pemimpin yang mengajukan proposal, dan validator lainnya melakukan pemungutan suara berulang kali untuk mengonfirmasi urutan transaksi langkah demi langkah.
Proses voting biasanya melalui beberapa tahapan, seperti pre-prepare, prepare, commit, dan reply. Pada setiap tahap, semua validator berkomunikasi satu sama lain. Dengan kata lain, setiap orang harus memberi tahu semua orang, dan volume pesan tumbuh secara eksplosif di "jaring".
Kompleksitas struktur komunikasi ini adalah n²—artinya, jika ada 100 validator di jaringan, maka setiap putaran konsensus mungkin harus mengirimkan hampir 10.000 pesan.
Ini bukan masalah besar dalam jaringan kecil, tetapi begitu jumlah validator meningkat, beban komunikasi pada sistem dapat dengan cepat menjadi tak tertahankan, dan efisiensi akan langsung berkurang.
Sumber data:
Struktur komunikasi kedua yang "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 masih dapat ditangani dalam lingkaran kecil, tetapi jika diterapkan di jaringan blockchain yang terbuka dan global, beban komunikasi segera menjadi tidak dapat diterima. Oleh karena itu, protokol BFT awal seperti PBFT dan Tendermint biasanya hanya digunakan dalam skenario yang terizinkan (permissioned network) atau sistem dengan jumlah validator yang sangat sedikit, sehingga masih dapat berjalan.
Untuk menyesuaikan protokol BFT dengan lingkungan rantai publik tanpa izin, beberapa desain generasi berikutnya telah mulai bergerak menuju cara komunikasi yang lebih ringan: setiap validator hanya berkomunikasi dengan pemimpin, bukan semua anggota tim.
Ini mengoptimalkan kompleksitas pesan dari n² ke n - sangat mengurangi beban pada sistem.
Protokol HotStuff diperkenalkan pada tahun 2018, yang bertujuan untuk menyelesaikan masalah skalabilitas ini. Prinsip desainnya sangat jelas: menggantikan proses pemungutan suara PBFT yang kompleks dengan struktur komunikasi yang lebih sederhana dan dipimpin oleh pemimpin.
Fitur kunci dari HotStuff adalah apa yang disebut komunikasi linier (linear communication). Dalam mekanismenya, setiap validator hanya perlu mengirimkan suaranya kepada pemimpin saat ini, dan pemimpin kemudian mengemas suara-suara tersebut untuk menghasilkan Quorum Certificate (QC, sertifikat mayoritas yang sah).
QC ini pada dasarnya adalah tanda tangan kolektif yang membuktikan kepada seluruh jaringan: "Kebanyakan node setuju dengan proposal ini."
Jika dibandingkan, mode komunikasi PBFT adalah "siaran semua orang", di mana setiap orang berbicara di grup, dan situasinya menjadi sangat kacau. Mode HotStuff lebih mirip dengan "satu orang mengumpulkan, satu kali mengemas", terlepas dari berapa banyak orang di jaringan, tetap dapat beroperasi dengan efisien.
Gambar di atas membandingkan struktur komunikasi fan-out HotStuff dengan mode interkoneksi seluruh jaringan PBFT.
Sumber data:
Selain komunikasi linier, HotStuff juga dapat ditingkatkan lebih lanjut menjadi versi pipelined (pipelined HotStuff) untuk meningkatkan efisiensi.
Dalam HotStuff yang asli, validator yang sama akan terus berfungsi sebagai pemimpin dalam beberapa putaran hingga sebuah blok sepenuhnya dikonfirmasi. Proses ini adalah "satu putaran menangani satu blok", semua energi difokuskan untuk mendorong blok saat ini.
Dan dalam jalur produksi HotStuff, mekanismenya menjadi lebih fleksibel: setiap putaran akan memilih pemimpin baru, dan setiap pemimpin memiliki dua tugas:
Sambil mengemas suara dari putaran sebelumnya menjadi Quorum Certificate (QC), disiarkan ke seluruh jaringan;
Mengajukan blok baru, bersiap untuk memulai putaran berikutnya.
Ini berarti, tidak lagi "mengonfirmasi satu dan kemudian memproses yang berikutnya", tetapi seperti jalur produksi, di mana pemimpin yang berbeda bergiliran bertanggung jawab untuk setiap tahap. Pemimpin sebelumnya mengusulkan blok, pemimpin berikutnya mengonfirmasi itu dan melanjutkan untuk mengusulkan blok baru, konsensus di atas rantai berjalan seperti estafet.
Inilah asal usul metafora "jalur perakitan": blok saat ini masih dalam proses konfirmasi, sementara yang berikutnya sudah dalam persiapan, beberapa langkah dilakukan secara paralel untuk meningkatkan efisiensi throughput.
Singkatnya, protokol seperti HotStuff membuat perbaikan signifikan atas BFT tradisional dalam dua dimensi:
Pertama, komunikasi menjadi lebih ringan, setiap validator hanya perlu berkomunikasi dengan pemimpin;
Kedua, efisiensi pemrosesan lebih tinggi, beberapa proses konfirmasi blok dapat dilakukan secara paralel.
Ini menjadikan HotStuff sebagai template desain untuk banyak mekanisme konsensus blockchain PoS modern. Namun, setiap hal memiliki kelebihan dan kekurangan—struktur aliran meskipun memiliki kinerja yang kuat, juga diam-diam memperkenalkan risiko struktural yang tidak mudah terdeteksi.
Selanjutnya, kita akan membahas secara mendalam tentang masalah inti ini: Tail Forking.
Masalah Percabangan Ekor (Tail-Forking)
Meskipun HotStuff — terutama versi pipelinenya — menyelesaikan masalah skalabilitas protokol konsensus, ia juga memperkenalkan beberapa tantangan baru. Salah satu yang paling kritis dan mudah diabaikan adalah masalah yang disebut "Tail Forking".
Apa itu fork bagian belakang? Dapat dengan mudah dipahami sebagai: terjadi reorganisasi blok yang tidak terduga di "ujung rantai" blockchain (reorg).
Secara spesifik, ada sebuah blok yang valid, telah berhasil disebarluaskan ke sebagian besar validator, dan telah mendapatkan cukup banyak dukungan suara. Seharusnya, blok ini segera dikonfirmasi dan ditulis ke dalam rantai utama. Namun akhirnya, blok tersebut "dilewati", dibuang (orphaned), dan digantikan oleh blok baru lainnya pada tinggi yang sama.
Ini bukan Bug, juga bukan serangan, melainkan karena struktur desain dari protokol itu sendiri, terdapat kemungkinan "jatuhnya rantai". Apakah ini terdengar agak tidak adil? Lalu, bagaimana ini bisa terjadi?
Kita sudah membahas sebelumnya, setiap pemimpin dalam jalur HotStuff memiliki dua tugas:
A. Usulkan blok baru (misalnya Bₙ₊₁)
B. Mengumpulkan suara untuk blok pemimpin sebelumnya, menghasilkan QC (misalnya menyelesaikan konfirmasi akhir untuk Bₙ)
Kedua tugas ini berjalan secara paralel, bergantian. Tapi masalahnya muncul di sini.
Misalnya: anggaplah Alice adalah pemimpin, dia mengajukan blok Bₙ pada ketinggian ke-n, blok ini telah mendapatkan suara mayoritas yang besar, dan sudah "hampir dikonfirmasi."
Selanjutnya, Bob harus menjadi pemimpin dan melanjutkan kemajuan blok berikutnya Bₙ₊₁ dari rantai, sambil juga mengemas QC (bukti mayoritas sah) dari Bₙ ke dalam proposalnya, untuk menyelesaikan konfirmasi akhir Bₙ.
Namun, jika Bob sedang offline saat itu, atau sengaja tidak mengirimkan QC Bₙ, maka akan ada masalah.
Karena tidak ada yang menyelesaikan QC packaging untuk blok Alice, catatan suara Bₙ tidak dapat disebarluaskan, blok yang seharusnya dikonfirmasi ini pun "ditangani dengan dingin" dan akhirnya diabaikan oleh seluruh jaringan.
Inilah esensi dari percabangan akhir: blok pemimpin sebelumnya dilewati karena kelalaian atau niat jahat pemimpin berikutnya.
Mengapa percabangan ekor begitu parah?
Masalah percabangan di akhir terutama terfokus pada dua aspek: 1) mekanisme insentif yang terganggu, 2) aktivitas sistem yang terancam.
Pertama, hadiah ditelan:
Jika sebuah blok dibuang, pemimpin yang mengusulkannya tidak akan mendapatkan hadiah apa pun. Baik itu hadiah pembuatan blok atau biaya transaksi. Misalnya, Alice mengusulkan sebuah blok yang sah, dan mendapatkan dukungan suara mayoritas super, tetapi karena kesalahan Bob atau tindakan jahat, blok ini tidak dapat dikonfirmasi, dan Alice akhirnya tidak mendapatkan satu sen pun. Ini akan mengakibatkan struktur insentif yang salah: node jahat seperti Bob dapat "memutuskan" sumber hadiah mereka dengan melewatkan blok lawan. Tindakan ini tidak memerlukan serangan teknis, hanya perlu "tidak bekerja sama" dengan sengaja untuk melemahkan pendapatan pesaing. Jika hal ini terjadi berulang kali, seiring waktu, akan menurunkan partisipasi dan keadilan sistem secara keseluruhan, bahkan dapat memicu kolusi antar node.
Kedua, ruang serangan MEV diperluas:
Pemisahan di bagian akhir juga dapat menyebabkan masalah yang lebih tersembunyi namun serius: ruang untuk manipulasi jahat MEV (nilai maksimum yang dapat diekstraksi) menjadi lebih besar. Misalnya: anggaplah bahwa di blok Alice terdapat transaksi arbitrase yang sangat bernilai. Jika Bob berniat untuk membuat masalah, dia bisa berkolusi dengan pemimpin berikutnya, Carol, untuk sengaja tidak menyebarkan blok Alice. Kemudian Carol membangun kembali blok baru pada ketinggian yang sama, "menyalin" transaksi arbitrase yang seharusnya dimiliki oleh Alice — mengubah hasil MEV menjadi miliknya sendiri. Tindakan "pengaturan ulang kepala rantai + kolusi penyalahgunaan" ini, meskipun secara permukaan mengikuti aturan dalam memproduksi blok, sebenarnya merupakan sebuah perampokan yang dirancang dengan cermat. Yang lebih buruk, ini dapat mendorong para pemimpin untuk membangun "hubungan kolusi", menjadikan konfirmasi blok sebagai permainan distribusi keuntungan, bukan layanan publik.
Ketiga, merusak jaminan finalitas, mempengaruhi pengalaman pengguna:
Salah satu keuntungan besar BFT dibandingkan protokol seperti Nakamoto adalah finalitas deterministik: setelah blok dilakukan, blok tidak dapat dibatalkan. Tetapi garpu ekor merusak jaminan ini, terutama pada blok yang telah "dipilih tetapi tidak dikonfirmasi secara resmi." Beberapa dapp throughput tinggi biasanya ingin dapat membaca data segera setelah blok dipilih untuk mengurangi latensi, dan jika blok tiba-tiba dibuang, itu dapat menyebabkan kemunduran status pengguna - seperti saldo akun yang tidak normal, transaksi leverage tinggi yang baru saja selesai menghilang tanpa alasan, reset tiba-tiba dari status game, dll.
Keempat, mungkin menyebabkan kegagalan berantai:
Secara umum, cabang akhir mungkin hanya menyebabkan suatu blok terkonfirmasi terlambat satu putaran, sehingga dampaknya tidak terlalu besar. Namun, dalam beberapa skenario tepi, jika beberapa pemimpin berturut-turut memilih untuk melewatkan blok sebelumnya, sistem dapat terjebak dalam keadaan stagnasi, di mana tidak ada yang bersedia untuk "mengambil" blok sebelumnya. Seluruh kemajuan rantai terhenti, sampai akhirnya muncul seorang pemimpin yang "bersedia untuk memikul tanggung jawab", jaringan baru akan terus maju.
Meskipun sebelumnya ada beberapa solusi, seperti mekanisme penghindaran fork di akhir yang diusulkan oleh protokol BeeGees, seringkali harus牺牲 kinerja, seperti memperkenalkan kembali kompleksitas komunikasi kedua, yang tidak sebanding.
Apa itu MonadBFT?
MonadBFT adalah protokol konsensus generasi baru yang dirancang khusus untuk mengatasi masalah cabang akhir. Keunggulan utamanya adalah: dalam menyelesaikan risiko struktural, tidak mengorbankan keuntungan kinerja yang dibawa oleh HotStuff yang berbasis jalur. Dengan kata lain, MonadBFT bukanlah membongkar dan membangun kembali, melainkan melanjutkan optimasi berdasarkan kerangka inti HotStuff. Ini mempertahankan tiga fitur kunci:
2）Pengajuan pipelined: Proses konfirmasi beberapa blok dapat dilakukan secara bersamaan;
Namun hanya mengandalkan tiga poin ini masih belum cukup aman. Untuk menutup celah struktural pada bagian akhir cabang ini, MonadBFT menambahkan dua mekanisme kunci:
1）Mekanisme Pengajuan Ulang (Re-Proposal)
2）Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate)
Mekanisme Pengajuan Ulang (Re-Proposal)
Dalam protokol BFT, waktu dibagi menjadi putaran-putaran (disebut view), di mana setiap putaran memiliki seorang pemimpin yang bertanggung jawab untuk mengajukan blok baru. Jika pemimpin gagal (misalnya tidak mengajukan blok tepat waktu, atau proposal tidak valid), sistem akan beralih ke putaran berikutnya dan memilih pemimpin baru.
MonadBFT menambahkan mekanisme yang memastikan bahwa selama proses pergantian view, blok yang diajukan secara jujur tidak akan "terputus" karena pergantian pemimpin.
Ketika pemimpin dari putaran saat ini gagal, para validator akan mengeluarkan pesan pergantian putaran yang ditandatangani (view change), yang menunjukkan bahwa putaran saat ini telah melewati batas waktu.
Yang khusus adalah, pesan ini tidak hanya menunjukkan "timeout", tetapi juga harus menyertakan informasi blok terakhir yang dipilih oleh 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 sebuah sertifikat timeout (Timeout Certificate, TC). TC ini mewakili: ketika putaran sebelumnya gagal, seluruh jaringan memiliki snapshot kesepakatan yang bersatu tentang "blok kepala rantai". Pemimpin baru akan memilih blok dengan tinggi tertinggi (atau nomor tampilan terbaru), yang disebut sebagai high_tip.
Persyaratan MonadBFT: Proposal pemimpin baru harus mencakup TC yang sah, dan harus mengajukan kembali blok tertunda tertinggi dalam TC, memberi blok ini kesempatan untuk dikonfirmasi kembali.
Mengapa? Seperti yang telah kami sebutkan sebelumnya: kami tidak ingin blok yang hampir terkonfirmasi menghilang begitu saja.
Berikut contohnya: Katakanlah Alice adalah pemimpin pandangan 5, mengusulkan blok yang valid, dan mendapat suara mayoritas. Selanjutnya, Bob, pemimpin tampilan 6, offline dan gagal memajukan proses rantai. Pada saat Carol mengambil peran sebagai pemimpin pandangan 7, dia harus memasukkan TC sesuai dengan aturan MonadBFT, dan mengusulkan kembali blok Alice. Dengan cara ini, kerja jujur Alice tidak akan-.
Jika Carol tidak memiliki blok Alice, dia dapat meminta dari node lain. Node dapat:
Sediakan blok tersebut, atau
Mengembalikan sebuah "Pesan Tanpa Dukungan" (No-Endorsement, NE) yang menandakan bahwa dirinya tidak memiliki blok tersebut (mekanismenya akan dijelaskan kemudian). (Paling banyak f node Bizantium mungkin memilih untuk mengabaikan permintaan dan tidak memberikan respons.)
Setelah Carol mengusulkan kembali blok Alice, dia akan mendapatkan satu kesempatan proposal tambahan, memastikan bahwa dia tidak akan "terkait" karena kegagalan pemimpin putaran sebelumnya.
Fungsi dari mekanisme usulan ulang 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 seseorang yang mengganggu.
Sertifikat Tanpa Dukungan (NEC)
Melanjutkan contoh sebelumnya: Setelah Bob melewati batas waktu, Carol meminta validator lain untuk memberikan blok high_tip (yaitu blok Alice). Pada saat ini, setidaknya 2f+1 validator akan memberikan respons:
Berikan blok Alice atau tidak
Kirim pesan NE yang ditandatangani, menyatakan bahwa saya belum menerima blok Alice.
Selama Carol menerima blok dari Alice, dia harus mengajukan ulang sesuai aturan. Carol hanya dapat melewatkan blok tersebut dan mengajukan yang baru jika setidaknya f+1 validator telah menandatangani pesan NE.
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 ada 2f+1 node yang jujur telah menerimanya.
Oleh karena itu, jika Carol mengklaim "saya tidak dapat mendapatkan blok Alice", maka dia harus menunjukkan 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 pemimpin dalam "pengecualian": ini adalah bukti yang dapat diverifikasi, yang menunjukkan bahwa blok sebelumnya belum siap untuk dikonfirmasi, bukan karena dengan sengaja dilewati, tetapi dengan alasan yang jelas "melepaskan".
Usulan ulang + Sertifikat tanpa dukungan = Menyelesaikan pemisahan akhir
MonadBFT menetapkan seperangkat aturan pengolahan chain head yang ketat dan jelas dengan memperkenalkan mekanisme Re-Proposal dan Sertifikat Tanpa Dukungan (NEC, No-Endorsement Certificate):
Selesaikan pengajuan akhir untuk blok yang "dekat dikonfirmasi";
Berikan bukti yang cukup untuk membuktikan bahwa blok tersebut belum memenuhi syarat untuk dikonfirmasi,
Jika tidak, tidak diperbolehkan untuk melewati atau mengganti blok sebelumnya.
Mekanisme ini memastikan bahwa: setiap blok yang telah memperoleh suara mayoritas sah tidak akan ditinggalkan karena kesalahan pemimpin atau penghindaran yang disengaja.
Risiko struktural dari percabangan ekor diatasi secara sistematis, dan protokol dapat membentuk batasan yang jelas terhadap perilaku melompati yang tidak pantas.
Jika seorang pemimpin mencoba untuk melompati blok sebelumnya tanpa alasan, tetapi gagal memberikan bukti NEC, protokol akan segera mengidentifikasi dan menolak tindakan tersebut. Tindakan melompati tanpa bukti kripto akan dianggap ilegal dan tidak akan mendapatkan dukungan konsensus jaringan.
Dari segi 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 di tahap selanjutnya;
Bahkan dalam situasi ekstrem, seperti ketika suatu node dengan sengaja melewati putaran proposalnya sendiri, berusaha membantu orang lain untuk merebut MEV dari blok sebelumnya, protokol akan memaksa pemimpin berikutnya untuk mengutamakan mengusulkan kembali blok asli, sehingga penyerang tidak dapat memperoleh keuntungan ekonomi dengan melewati proses.
Lebih penting lagi, MonadBFT tidak牺牲 kinerja protokol untuk meningkatkan keamanan.
Beberapa desain sebelumnya untuk menangani pemisahan bagian 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 akan secara signifikan meningkatkan beban sistem.
Strategi desain MonadBFT lebih canggih:
Komunikasi tambahan (seperti pesan timeout, pengajuan ulang blok) hanya dimulai saat ada kegagalan tampilan atau adanya pengecualian. Di jalur reguler di mana sebagian besar pemimpin yang jujur terus 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 sebelumnya.
ringkasan
Artikel ini mengulas mekanisme dasar konsensus PBFT tradisional, menguraikan jalur pengembangan protokol HotStuff, dan secara khusus menjelaskan bagaimana MonadBFT menyelesaikan masalah percabangan akhir yang melekat dalam HotStuff melalui struktur lapisan protokol.
Pemisahan di bagian akhir dapat memutarbalik insentif ekonomi proposer blok dan juga menimbulkan ancaman potensial terhadap aktivitas jaringan. MonadBFT memastikan bahwa setiap blok yang diajukan oleh pemimpin yang jujur dan memperoleh suara mayoritas yang sah tidak akan ditinggalkan atau dilewati dengan memperkenalkan mekanisme pengajuan ulang dan sertifikat tanpa dukungan (NEC).
Dalam artikel selanjutnya, kami akan melanjutkan untuk membahas dua fitur inti lain dari MonadBFT:
1）Finalitas Spekulatif
2）Responsivitas Optimis (Optimistic Responsiveness)
dan lebih lanjut menganalisis arti praktis dari mekanisme ini untuk validator dan pengembang.
Belum selesai.