Inti dari blockchain adalah mencapai konsensus global yang ketat: yaitu, tidak peduli di mana simpul jaringan didistribusikan di negara atau zona waktu mana, semua peserta pada akhirnya harus mencapai konsensus tentang serangkaian hasil objektif.

Namun kenyataannya, jaringan terdistribusi tidak ideal: node-node offline, node-node berbohong, dan bahkan ada yang sengaja merusak. Dalam hal ini, bagaimana sistem dapat "berbicara dengan satu suara" dan menjaga konsistensi?

Ini adalah masalah yang ingin diselesaikan oleh protokol konsensus. Pada dasarnya, ini adalah serangkaian aturan untuk memandu sekelompok node independen dan bahkan sebagian tidak terpercaya tentang bagaimana mencapai keputusan bersama mengenai urutan dan isi setiap transaksi.

Dan setelah 'konsensus ketat' ini tercapai, blockchain dapat membuka banyak fitur kunci, seperti perlindungan hak milik digital, model mata uang anti-inflasi, dan struktur kolaborasi sosial yang dapat diskalakan. Tetapi premisnya adalah bahwa protokol konsensus itu sendiri harus memastikan dua aspek fundamental sekaligus:

• Dua blok yang bertentangan tidak dapat dikonfirmasi;
• Jaringan harus terus maju dan tidak boleh terjebak atau berhenti.

MonadBFT adalah terobosan teknologi terbaru dalam arah ini.

Sebuah tinjauan singkat tentang evolusi protokol konsensus

Dalam bidang mekanisme konsensus, sebenarnya telah dipelajari selama puluhan tahun. Sejumlah protokol awal, seperti PBFT (Practical Byzantine Fault Tolerance), sudah dapat menangani situasi yang sangat realistis: bahkan jika beberapa node dalam jaringan menjatuhkan rantai, bersikap jahat, atau berbicara omong kosong, selama tidak melebihi sepertiga dari jumlah total, sistem masih dapat mencapai konsensus.

Desain protokol awal ini lebih “tradisional”: seorang pemimpin dipilih di setiap putaran untuk memulai proposal, dan validator lain memberikan suara pada proposal ini dalam beberapa putaran untuk secara bertahap mengonfirmasi urutan transaksi.

Seluruh proses pemungutan suara biasanya melalui beberapa tahap, seperti pra-persiapan, persiapan, commit, dan balasan. Pada setiap tahap, semua validator perlu berkomunikasi satu sama lain. Dengan kata lain, semua orang harus memberi tahu semua orang lain, dan volume pesan tumbuh secara eksplosif dalam pola 'mesh'.

Kompleksitas struktur komunikasi ini adalah n² - artinya, jika ada 100 validator dalam jaringan, setiap putaran konsensus mungkin memerlukan pengiriman hampir 10.000 pesan.

Dalam jaringan kecil, ini bukanlah masalah, tetapi begitu jumlah validator meningkat, beban komunikasi sistem akan segera menjadi tidak tertahankan, langsung memengaruhi efisiensi.

Sumber informasi:https://medium.com/coinmonks/pbft-memahami-algoritma-b7a7869650ae

Struktur komunikasi sekunder 'semua orang berbicara dengan semua orang' sebenarnya sangat tidak efisien. Misalnya, dalam jaringan dengan 100 validator, setiap putaran konsensus mungkin perlu memproses puluhan ribu pesan.

Ini masih bisa dikelola dalam lingkaran kecil, tetapi ketika ditempatkan dalam jaringan rantai global, beban komunikasi segera menjadi tidak dapat diterima. Jadi protokol BFT awal seperti PBFT dan Tendermint biasanya hanya digunakan dalam jaringan berizin atau sistem dengan sangat sedikit validator untuk berfungsi dengan baik.

Untuk memungkinkan protokol BFT beradaptasi dengan lingkungan rantai publik tanpa izin, beberapa desain generasi berikutnya beralih ke metode komunikasi yang lebih ringan: memungkinkan setiap validator berkomunikasi hanya dengan pemimpin, bukan dengan semua anggota.

Ini mengoptimalkan kompleksitas pesan dari n² asli menjadi n, sangat mengurangi beban sistem.

Protokol HotStuff diusulkan pada tahun 2018 untuk mengatasi masalah skalabilitas ini. Filosofi desainnya sangat jelas: menggantikan proses pemungutan suara kompleks PBFT dengan struktur komunikasi yang lebih ringkas dan dipimpin oleh pemimpin.

Salah satu fitur kunci dari HotStuff adalah komunikasi linear yang disebut demikian. Dalam mekanismenya, setiap validator hanya perlu mengirim suara mereka ke pemimpin saat ini, yang kemudian mengemas suara-suar ini untuk menghasilkan Sertifikat Kuorum (QC).

QC ini pada dasarnya merupakan tanda tangan kolektif, membuktikan kepada seluruh jaringan: ‘Sebagian besar node setuju dengan proposal ini.’

Sebaliknya, mode komunikasi PBFT adalah 'dikirim ke semua', di mana semua orang berbicara dalam kelompok, menyebabkan kekacauan pada beberapa saat. Mode HotStuff lebih seperti 'satu mengumpulkan, satu mengemas pada satu waktu', yang dapat menjaga operasi yang efisien terlepas dari berapa banyak orang yang ada di jaringan.

Gambar membandingkan struktur komunikasi fan-out dari HotStuff dengan mode terhubung penuh dari PBFT Sumber:

https://www.mdpi.com/1424-8220/24/16/5417

Selain komunikasi linear, HotStuff dapat ditingkatkan lebih lanjut ke versi pipelined, digunakan untuk meningkatkan efisiensi.

Dalam HotStuff asli, validator yang sama akan bertindak sebagai pemimpin untuk beberapa putaran berturut-turut, sampai blok sepenuhnya dikonfirmasi. Proses ini adalah 'memproses satu blok per putaran', dengan semua upaya difokuskan pada memajukan yang saat ini.

Dalam pipa HotStuff, mekanismenya bahkan lebih fleksibel: seorang pemimpin baru dipilih di setiap putaran, dan setiap pemimpin memiliki dua tugas:

• Masukkan putaran suara terakhir ke dalam Sertifikat Quorum (QC) di satu sisi dan siarkan ke seluruh jaringan;
• Di satu sisi, usulkan blok baru, siap memulai putaran berikutnya.

Dengan kata lain, bukan lagi “mengonfirmasi satu sebelum memproses yang berikutnya”, tetapi seperti jalur produksi, pemimpin yang berbeda bergantian bertanggung jawab untuk setiap langkah. Yang sebelumnya mengajukan blok, yang berikutnya mengonfirmasinya dan melanjutkan untuk mengajukan blok baru, dan konsensus di rantai disampaikan seperti perlombaan estafet.

Ini adalah asal usul metafora dari 'garis perakitan': blok saat ini masih dalam proses konfirmasi, sementara yang berikutnya sudah dalam persiapan, beberapa langkah berjalan sejajar, meningkatkan efisiensi throughput.

Secara ringkas, protokol seperti HotStuff telah membuat peningkatan signifikan dibandingkan BFT tradisional dalam dua dimensi:

• Pertama, komunikasinya lebih ringan, dengan setiap validator hanya perlu berkomunikasi dengan pemimpin;
• Kedua, efisiensi pemrosesan lebih tinggi, dan proses konfirmasi blok multipel dapat berjalan secara paralel.

Hal ini membuat HotStuff menjadi sebuah template desain untuk banyak mekanisme konsensus blockchain PoS modern. Namun, setiap hal memiliki sisi positif dan negatifnya - meskipun struktur pipa sangat kuat dalam kinerja, ia juga secara diam-diam memperkenalkan risiko struktural yang tidak mudah ditemukan.

Selanjutnya, kita akan menyelami masalah inti ini: Tail Forking.

Masalah Tail-Forking di akhir

Meskipun HotStuff, terutama versi berpipa, mengatasi masalah skalabilitas dari protokol konsensus, namun juga memperkenalkan beberapa tantangan baru. Yang paling penting dan seringkali terabaikan adalah masalah yang disebut “Tail Forking”.

Apa itu garpu ekor? Ini dapat dimengerti secara sederhana sebagai: sebuah blockchain mengalami reorganisasi blok yang tidak sengaja di 'ekor' rantai.

Secara khusus, ada blok yang valid, telah berhasil dipropagasi ke sebagian besar validator, dan telah menerima cukup suara. Secara teori, seharusnya dikonfirmasi dan ditulis ke rantai utama segera. Namun, pada akhirnya, blok tersebut 'dilewati,' menjadi yatim piatu, dan digantikan oleh blok baru lainnya pada ketinggian yang sama.

Ini bukan Bug, bukan serangan, tetapi karena dalam struktur desain protokol itu sendiri, ada kemungkinan 'ekor rantai' ini. Apakah ini terdengar sedikit tidak adil? Jadi, bagaimana ini terjadi?

Seperti yang kami sebutkan sebelumnya, setiap pemimpin dari pipeline HotStuff memiliki dua tugas:

• A. Usulkan blok baru (seperti Bₙ₊₁)
• B. Mengumpulkan suara untuk blok pemimpin sebelumnya untuk menghasilkan QC (misalnya, untuk akhirnya mengonfirmasi Bₙ)

Kedua tugas ini berjalan sejajar, bergantian untuk melewatkan. Tetapi masalah muncul di sini.

Sebagai contoh, misalkan Alice adalah pemimpin, dan dia mengusulkan blok Bₙ pada ketinggian n, yang menerima suara mayoritas besar dan hampir dikonfirmasi.

Selanjutnya, seharusnya giliran Bob untuk mengambil peran sebagai pemimpin, terus maju ke blok berikutnya Bₙ₊₁ dari rantai, dan juga menyertakan QC (Qualified Commitment) dari Bₙ dalam proposalnya untuk menyelesaikan konfirmasi akhir dari Bₙ.

Tetapi jika Bob tidak online pada saat ini, atau sengaja tidak mengirimkan QC dari Bₙ, maka akan ada masalah.

Karena tidak ada yang mengemas blok Alice dengan QC, catatan pemungutan suara Bₙ tidak tersebar. Blok ini, yang seharusnya sudah dikonfirmasi, akhirnya 'diproses dingin' dan akhirnya diabaikan oleh seluruh jaringan.

Ini adalah inti dari sebuah fork ekor: sebuah blok dari pemimpin sebelumnya dilewati karena kelalaian atau niat jahat dari pemimpin berikutnya.

Mengapa garpu ekor begitu parah?

Masalah tail fork terutama berfokus pada dua aspek: 1) mekanisme insentif terganggu, 2) aktivitas sistem terancam.

Pertama, hadiah ditelan:

Jika sebuah blok ditinggalkan, pemimpin yang mengusulkannya tidak akan menerima imbalan apa pun, baik imbalan blok maupun biaya transaksi. Sebagai contoh, jika Alice mengusulkan blok yang valid dan mendapatkan dukungan yang sangat besar dalam pemungutan suara, tetapi karena kesalahan atau operasi jahat Bob, blok tersebut tidak dapat dikonfirmasi, Alice tidak akan menerima sedikit pun. Hal ini akan menyebabkan struktur insentif yang cacat: node jahat seperti Bob dapat ‘memutus’ sumber imbalan mereka dengan melewati blok lawan mereka. Perilaku ini tidak memerlukan serangan teknis, hanya ‘non-kerjasama’ yang disengaja untuk melemahkan keuntungan pesaing. Jika ini terjadi secara berulang, dari waktu ke waktu, partisipasi dan keadilan dari seluruh sistem akan menurun, dan bahkan memicu kolusi di antara node.

Kedua, permukaan serangan MEV melebar:

Garpu ekor juga menimbulkan masalah yang lebih berbahaya tetapi serius: ada lebih banyak ruang bagi MEV (Maximum Extractable Value) untuk dimanipulasi dengan jahat. Berikut contohnya: Katakanlah Alice memiliki perdagangan arbitrase yang berharga di bloknya. Jika Bob ingin membuat masalah, dia bisa berkolusi dengan pemimpin berikutnya, Carol, dan dengan sengaja tidak menyebarkan blok Alice. Carol kemudian merekonstruksi blok baru pada ketinggian yang sama, "mencuri" perdagangan arbitrase asli Alice - membuat MEV mendapatkan miliknya sendiri. Praktek "penataan ulang kepala rantai + kolusi dan perampasan" ini masih merupakan blok menurut aturan di permukaan, tetapi sebenarnya adalah penjarahan yang dirancang dengan baik. Lebih buruk lagi, itu menyebabkan "kolusi" antara para pemimpin, mengubah konfirmasi blok menjadi permainan pembagian manfaat daripada layanan publik.

Ketiga, menggoyahkan jaminan finalitas, memengaruhi pengalaman pengguna:

Dibandingkan dengan protokol mirip Nakamoto, satu keuntungan utama dari BFT adalah finalitas deterministik: setelah sebuah blok dikonfirmasi, blok tersebut tidak dapat digulung kembali. Namun, tail fork mengganggu jaminan ini, terutama pada blok yang 'telah dikonfirmasi namun belum secara resmi dikonfirmasi.' Beberapa dapps high-throughput sering ingin membaca data segera setelah pemungutan suara blok untuk mengurangi latensi, dan jika blok tiba-tiba dibatalkan, hal itu dapat menyebabkan pengembalian keadaan pengguna—seperti saldo rekening yang tidak normal, perdagangan leverage tinggi yang baru saja selesai menghilang tanpa alasan, atau reset keadaan permainan tiba-tiba.

Keempat, dapat menyebabkan kegagalan reaksi berantai:

Secara umum, sebuah fork ekor mungkin hanya menunda konfirmasi blok untuk satu putaran, yang bukan dampak besar. Namun, dalam beberapa kasus tertentu, jika beberapa pemimpin berturut-turut memilih untuk melewati blok sebelumnya, sistem dapat terjebak, dan tidak ada yang bersedia untuk “mengambil alih” blok sebelumnya. Seluruh rantai terjebak sampai seorang pemimpin yang bersedia mengambil tanggung jawab akhirnya muncul, dan jaringan akan terus bergerak maju.

Meskipun telah ada beberapa solusi sebelumnya, seperti mekanisme penghindaran fork ekor yang diusulkan oleh protokol BeeGees, mereka sering membutuhkan pengorbanan kinerja, seperti memperkenalkan kembali kompleksitas komunikasi sekunder, yang tidak sebanding dengan kerugiannya.

Apa itu MonadBFT?

MonadBFT adalah protokol konsensus generasi baru yang dirancang khusus untuk mengatasi masalah fork ekor. Kelebihannya terletak pada: sambil mengatasi kerentanan struktural, ia tidak mengorbankan keuntungan kinerja yang dibawa oleh pipa HotStuff. Dengan kata lain, MonadBFT tidak memulai dari awal, melainkan terus mengoptimalkan berdasarkan kerangka inti HotStuff. Ini mempertahankan tiga karakteristik kunci:

1) Pemimpin yang berputar: Pilih seorang pemimpin baru untuk setiap putaran untuk mendorong rantai maju;
2) Komit bersaf: Proses konfirmasi blok ganda dapat tumpang tindih;
3) Komunikasi Linear (pesan linear): Setiap validator hanya perlu berkomunikasi dengan pemimpin, menghemat banyak overhead jaringan.

Namun hanya mengandalkan tiga poin ini tidak cukup aman. Untuk menutupi kerentanan struktural dari garpu ekor, MonadBFT telah menambahkan dua mekanisme kunci:

1) Mekanisme re-proposal wajib (Re-Proposal)
2) Sertifikat Tanpa Pengesahan (NEC)

Mekanisme Re-Proposal

Dalam protokol BFT, waktu dibagi menjadi putaran (dikenal sebagai tampilan), dengan seorang pemimpin di setiap putaran bertanggung jawab untuk mengusulkan blok baru. Jika pemimpin gagal (misalnya, dengan tidak mengusulkan blok tepat waktu atau dengan usulan yang tidak valid), sistem beralih ke putaran berikutnya dan memilih pemimpin baru.

MonadBFT telah menambahkan mekanisme untuk memastikan bahwa blok yang diusulkan secara jujur selama proses pergantian tampilan tidak akan 'menjatuhkan rantai' karena rotasi pemimpin.

Ketika pemimpin saat ini gagal, para validator akan mengirim pesan yang ditandatangani untuk beralih putaran (perubahan tampilan), menunjukkan bahwa putaran saat ini telah habis waktu.

Secara khusus, pesan ini tidak hanya menunjukkan 'waktu habis', tetapi juga harus mencakup informasi blok suara terbaru validator, yang setara dengan mengatakan, 'Saya tidak menerima proposal yang valid, ini adalah blok terbaru yang saat ini saya lihat.'

Para pemimpin baru akan mengumpulkan pesan timeout ini dari mayoritas super (2f+1) validator dan menggabungkannya ke dalam Sertifikat Time Out (TC). TC ini mewakili gambaran kognitif yang bersatu dari 'blok kepala rantai' dari seluruh jaringan ketika putaran sebelumnya gagal. Pemimpin baru akan memilih blok dengan ketinggian tertinggi (atau nomor tampilan terbaru), yang dikenal sebagai high_tip, dari blok tersebut.

MonadBFT memerlukan: Usulan pemimpin baru harus mencakup TC yang valid dan harus mengusulkan blok tertunda tertinggi dalam TC untuk memberikan blok ini kesempatan lain untuk dikonfirmasi.

Mengapa? Seperti yang disebutkan sebelumnya: kami tidak ingin blok yang hampir dikonfirmasi menghilang.

Sebagai contoh, misalkan Alice adalah pemimpin dari tampilan 5, mengusulkan blok yang valid, dan menerima mayoritas suara. Selanjutnya, ketika pemimpin dari tampilan 6, Bob, sedang offline dan gagal untuk memajukan proses rantai, pada saat Carol mengambil alih sebagai pemimpin dari tampilan 7, sesuai dengan aturan MonadBFT, dia harus menyertakan TC dan mengusulkan ulang 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:

• Berikan blok, atau
• Kembalikan pesan ‘No-Endorsement (NE)’ yang ditandatangani, menunjukkan bahwa pengirim tidak memiliki blok ini (mekanisme ini dijelaskan nanti). (Hingga f node Byzantine dapat memilih untuk mengabaikan permintaan dan tidak merespons.)

Setelah Carol memproposes ulang blok Alice, dia akan mendapatkan kesempatan proposal tambahan untuk memastikan bahwa dia tidak 'terlibat' akibat kegagalan pemimpin sebelumnya.

Peran mekanisme ini jelas: untuk memastikan kemajuan rantai yang adil, dan tidak ada pekerjaan valid yang dibuang diam-diam karena nasib buruk atau sabotase seseorang.

Sertifikat Non-Endorsable (NEC)

Melanjutkan dengan contoh sebelumnya: Setelah giliran Bob habis, Carol meminta validator lain untuk memberikan blok high_tip (yaitu, blok Alice). Pada titik ini, setidaknya 2f+1 validator akan merespons:

• Berikan blok Alice
• Kirimkan pesan NE yang ditandatangani menunjukkan bahwa Anda belum menerima blok Alice.

Selama Carol menerima blok Alice, dia harus mengusulkan ulang sesuai dengan aturan. Carol hanya bisa melewati blok dan mengusulkan yang baru ketika setidaknya f+1 validator telah menandatangani pesan NE.

Mengapa f+1? Dalam sistem BFT yang terdiri dari 3f+1 validator, paling banyak hanya f yang boleh jahat. Jika blok milik Alice memang menerima mayoritas suara, maka setidaknya 2f+1 node jujur menerimanya.

Oleh karena itu, jika Carol mengklaim, “Saya tidak bisa mendapatkan blok Alice,” dia harus menghasilkan tanda tangan validator f+1 untuk membuktikan bahwa tidak ada satupun dari mereka yang menerimanya. Ini merupakan Sertifikat Tanpa Pengesahan (NEC).

NEC adalah kredensial "penafian" pemimpin: ini adalah bukti yang dapat diverifikasi bahwa pemblokiran sebelumnya belum siap untuk dikonfirmasi, tidak dilewati dengan jahat, tetapi "ditinggalkan" dengan alasan.

Re-proposal + Sertifikat yang Tidak Didukung = Menyelesaikan garpu ekor

MonadBFT memperkenalkan seperangkat aturan pemrosesan kepala rantai yang ketat dan jelas dengan memperkenalkan mekanisme re-proposal dan Sertifikat Tanpa-Endorsement (NEC).

Entah akhirnya berkomitmen pada blok 'dekat dikonfirmasi';

Berikan bukti yang cukup untuk membuktikan bahwa blok tersebut belum siap untuk dikonfirmasi,

Selain itu, tidak diperbolehkan untuk melewati atau menggantikan blok sebelumnya.

Mekanisme ini memastikan bahwa setiap blok yang telah menerima mayoritas suara legal tidak akan ditinggalkan karena kesalahan pemimpin atau penyelundupan yang disengaja.

Risiko struktural dari garpu ekor secara sistematis diatasi, dan protokol dapat dengan jelas membatasi perilaku melompat yang tidak pantas.

Jika seorang pemimpin mencoba untuk melewati blok sebelumnya tanpa memberikan bukti NEC, protokol akan segera mengenali dan menolak perilaku tersebut. Perilaku melompat tanpa bukti kriptografis akan dianggap ilegal dan tidak akan mendapatkan dukungan konsensus jaringan.

Dari perspektif insentif ekonomi, desain ini memberikan perlindungan yang jelas bagi validator:

• Selama blok diajukan dengan jujur dan mendapatkan dukungan suara, imbalannya tidak akan dicabut karena kegagalan selanjutnya.
• Bahkan dalam situasi ekstrem, seperti ketika sebuah node dengan sengaja melewatkan putaran proposal sendiri dan mencoba membantu orang lain dalam merebut MEV dari blok sebelumnya, protokol akan memaksa pemimpin berikutnya untuk memprioritaskan memproposalkan blok asli, mencegah penyerang dari mendapatkan keuntungan ekonomi dengan melewatkan proses tersebut.

Lebih pentingnya lagi, MonadBFT tidak mengorbankan kinerja protokol untuk meningkatkan keamanan.

Beberapa desain yang mengatasi fork ekor (seperti protokol BeeGees) di masa lalu memiliki kemampuan perlindungan tertentu, tetapi sering bergantung pada kompleksitas komunikasi tinggi (n²) atau memungkinkan proses komunikasi yang berat di setiap putaran, yang secara signifikan meningkatkan beban sistem dalam praktik.

Strategi desain MonadBFT lebih canggih:

Komunikasi tambahan (seperti pesan waktu habis, re-proposal blok) hanya diinisiasi ketika tampilan gagal atau anomali ada. Pada jalur reguler di mana sebagian besar pemimpin jujur terus menerus menghasilkan blok, protokol masih menjaga keadaan operasional yang ringan dan efisien.

Keseimbangan dinamis antara kinerja dan keamanan adalah salah satu keunggulan inti MonadBFT dibandingkan protokol pendahulunya.

Ringkasan

Artikel ini meninjau mekanisme dasar konsensus PBFT tradisional, menyusun jalur pengembangan protokol HotStuff, dan berfokus pada bagaimana MonadBFT menyelesaikan masalah tail fork bawaan dari pipeline HotStuff pada struktur lapisan protokol.

Rear forks dapat merusak insentif ekonomi para penawar blok dan menimbulkan ancaman potensial terhadap aktivitas jaringan. MonadBFT memastikan bahwa setiap blok yang diajukan oleh pemimpin yang jujur dan disetujui oleh suara mayoritas yang sah tidak akan ditinggalkan atau dilewati dengan memperkenalkan mekanisme re-proposal dan Sertifikat Non-Disetujui (NEC).

Dalam artikel berikutnya, kami akan terus menjelajahi dua fitur inti lain dari MonadBFT:

1）Finalitas Spekulatif
2）Responsif Optimis

Analisis lebih lanjut mengenai mekanisme-mekanisme ini dan signifikansi praktisnya bagi validator dan pengembang.

Pernyataan:

1. Artikel ini diambil dari [michael_lwy], hak cipta milik penulis asli [michael_lwy]，jika Anda memiliki keberatan terhadap cetak ulang, silakan hubungi Tim Pembelajaran Gate)，tim akan menanganinya sesegera mungkin sesuai dengan proses yang relevan.
2. Penyangkalan: Pandangan dan opini yang diungkapkan dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Versi bahasa lain dari artikel diterjemahkan oleh tim Gate Learn, tanpa menyebutkanGate.ioJangan menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan tanpa izin.