Pada bagian pertama, kami mempelajari cara kerja konsensus PBFT klasik (Practical Byzantine Fault Tolerance) dan bagaimana versi awal HotStuff beroperasi. Kami juga memahami bagaimana MonadBFT menyelesaikan masalah fork akhir HotStuff, yaitu masalah di mana blok yang valid terkadang dibuang dalam sistem pipeline.
Masalah fork ini menyebabkan dua masalah utama: 1) Itu mengganggu imbalan bagi pembangun blok yang jujur, 2) Itu dapat mengakibatkan jaringan macet.
MonadBFT memperkenalkan aturan pengajuan ulang dan mekanisme pemungutan suara tanpa dukungan untuk menghilangkan masalah fork akhir, memastikan bahwa setiap blok yang disetujui dengan tepat dari pengusul yang jujur dapat masuk ke dalam rantai.
Pada bagian kedua, kita akan membahas dua fitur lain dari MonadBFT: 1) finalitas spekulatif dan 2) responsif optimis. Kita juga akan membahas dampak MonadBFT terhadap pengembang.
Kepastian spekulasi satu putaran
Selain menolak fork di bagian akhir, fitur utama lainnya dari MonadBFT adalah finalitas spekulatif satu putaran.
Dalam aplikasi praktis, ini berarti klien dan pengguna dapat segera menerima konfirmasi transaksi setelah blok mendapatkan sebagian besar suara, bahkan sebelum putaran berikutnya selesai.
Mengingat kembali, dalam protokol HotStuff baseline, sebuah blok biasanya memerlukan setidaknya dua tahap (seperti Fast-Hotstuff dan Diem-BFT) sebelum dianggap final (tidak dapat dibalik): tahap pertama mendapatkan sertifikat kuorum (QC) (dengan ≥2f+1 suara mengunci blok), tahap kedua adalah pemimpin berikutnya yang membangun dan mengajukan blok berdasarkan sertifikat kuorum (QC) tersebut.
Dua tahap pengajuan ini diperlukan untuk memastikan keamanan: setelah cukup banyak node yang jujur mengunci sebuah blok, blok yang bertentangan tidak dapat mencapai jumlah suara yang sah, dan pengajuan pada putaran berikutnya akan membuatnya permanen. Oleh karena itu, klien biasanya mungkin perlu menunggu blok berikutnya atau putaran berikutnya untuk mengetahui apakah transaksi sebelumnya telah dikonfirmasi.
MonadBFT pada dasarnya memungkinkan transaksi dianggap cukup final hanya setelah satu putaran pemungutan suara (dapat beroperasi dengan aman). Ini yang disebut dengan finalitas spekulatif.
Ketika pemimpin mengusulkan sebuah Blok, dan para validator memberikan suara untuk membentuk QC dari Blok tersebut, maka Blok tersebut berada dalam status suara (telah dikunci oleh jumlah yang sah). Dalam MonadBFT, setelah validator membentuk QC, mereka akan segera mengeksekusi transaksi dari Blok tersebut, bahkan akan mengirimkan konfirmasi awal kepada klien, menunjukkan bahwa Blok tersebut diterima (secara spekulatif). Ini seperti mengatakan "kami memiliki sebagian besar orang yang setuju dengan Blok ini. Kecuali terjadi situasi yang sangat tidak terduga, Blok ini dapat dianggap telah dikonfirmasi."
Konfirmasi instan ini bersifat optimis. Blok belum diserahkan ke buku besar. Ini akan terjadi saat proposal berikutnya muncul dan mengonfirmasi itu (QC-on QC), tetapi dalam keadaan normal, tidak ada yang dapat membatalkannya. Satu-satunya situasi yang dapat membatalkan eksekusi spekulatif blok adalah ketika pemimpin mengalami serangan ekuivalen (yaitu mengajukan dua blok berbeda pada tinggi yang sama untuk membagi suara).
Anda dapat melihat finalitas spekulatif sebagai produk sampingan yang baik untuk melawan fork bagian ekor. Melawan fork bagian ekor menjamin bahwa bahkan jika pemimpin berikutnya gagal, proposal saat ini tidak akan dibuang (berkat aturan pengusulan kembali dan NEC). Satu-satunya keadaan di mana blok eksekusi spekulatif dibuang adalah ketika pengusul asli mengalami serangan ekuivalen (kesalahan tanda tangan ganda yang dapat dibuktikan jahat), dan keadaan ini: 1) dapat terdeteksi melalui QC konflik; 2) dapat dihukum; 3) sangat jarang.
Dalam protokol sebelumnya, mereka tidak menjamin bahwa pemimpin berikutnya akan mengajukan kembali blok sebelumnya, sehingga fork di akhir mungkin terjadi, yang melanggar asumsi spekulatif.
responsif optimis
Dalam sebagian besar protokol konsensus, setelah setiap putaran akan ada penantian bawaan, seperti periode penyangga atau waktu tunggu. Ini bertujuan untuk memastikan bahwa semua pesan telah tiba sebelum melanjutkan. Ini adalah mekanisme perlindungan yang dirancang untuk menangani situasi terburuk, seperti pemimpin yang mengalami keruntuhan atau tidak mengirimkan informasi sama sekali.
Waktu tunggu ini biasanya terlalu konservatif. Jika jaringan berjalan normal dan semua validator bertindak dengan benar, maka waktu tunggu yang tetap akan menjadi biaya yang tidak perlu. Blok seharusnya bisa diselesaikan lebih cepat, tetapi protokol menundanya untuk berjaga-jaga.
MonadBFT memperkenalkan responsif optimis, yang berarti protokol dapat langsung maju berdasarkan informasi jaringan, alih-alih selalu bergantung pada timer tetap. Prinsip desain di sini dapat diringkas sebagai "jika bisa cepat, maka cepat; hanya bersabar saat memang harus bersabar".
Desain MonadBFT memungkinkan bahwa dalam kondisi normal, bahkan saat pemulihan dari kegagalan, jika tidak diperlukan, ia tidak akan menghentikan untuk menunggu waktu tunggu yang dijadwalkan.
Pada jalur kebahagiaan (yang berarti kita memiliki pemimpin yang jujur): Tidak ada penundaan bawaan dalam usulan atau pemungutan suara. Begitu giliran pemimpin, ia akan mengusulkan sebuah Blok. Begitu validator menerima usulan yang valid, mereka akan segera memberikan suara. Ketika pemimpin (atau lebih tepatnya, pemimpin berikutnya, karena dalam saluran HotStuff, suara akan dikirim ke pengusul berikutnya) mengumpulkan 2f+1 suara, QC terbentuk dan dapat disebarkan. Dalam desain responsif optimis, ini akan segera memicu tahap berikutnya.
Dalam praktiknya, ini berarti bahwa jika latensi jaringan antara node adalah 100 milidetik, maka konsensus mungkin hanya memerlukan beberapa ratus milidetik untuk menyelesaikan satu putaran (ditambah biaya perhitungan dan penggabungan).
Jika tidak diperlukan, itu tidak akan menunggu, misalnya, "waktu slot" selama satu detik penuh. Ini berbeda dengan model slot-and-epoch yang digunakan oleh jaringan utama Ethereum. Di Ethereum, interval waktu produksi blok tetap adalah 12 detik. Bahkan jika semua orang sudah siap sebelumnya, protokol akan menunggu.
Metode MonadBFT menghilangkan penundaan yang tidak perlu. Ini mempertahankan struktur HotStuff yang dipipakan, tetapi menghapus ketentuan keras "harus menunggu Δ detik" dalam kondisi normal. Ini berarti bahwa ia dapat unggul dalam hal responsivitas dibandingkan dengan sistem yang terikat waktu tanpa mengorbankan keamanan.
Di jalur yang tidak bahagia (kegagalan pemimpin): Dalam banyak protokol konsensus, ketika pemimpin gagal mengajukan blok, node lain hanya akan menyadari hal ini setelah waktu habis Δ. Misalnya, jika Δ adalah 1 detik, maka waktu ini pada dasarnya terbuang percuma. Pendekatan MonadBFT berbeda. Ketika validator mendeteksi bahwa usulan hilang, mereka segera menyiarkan pesan waktu habis (TC atau sertifikat waktu habis). Setelah terjadi 2f+1 waktu habis, pemimpin berikutnya akan mengambil alih. Transisi ke sudut pandang baru dipicu oleh bukti berbasis kuorum, bukan oleh jam.
Perbandingan dengan konsensus hotstuff-family
MonadBFT dibangun di atas dasar protokol konsensus seri HotStuff, tetapi menonjol dengan mengimplementasikan kombinasi dari serangkaian karakteristik ideal. Protokol awal biasanya dioptimalkan untuk dimensi tertentu, seperti throughput pipelining atau komunikasi linier, tetapi harus mengorbankan aspek lainnya. MonadBFT secara unik menggabungkan kompleksitas pesan linier, komitmen pipelining, ketahanan fork akhir yang kuat, respons instan tanpa penundaan tetap, dan mekanisme pemulihan yang efisien, sambil tetap mempertahankan kepastian akhir yang cepat dan jaminan ketersediaan tinggi. Tabel di bawah ini merangkum perbandingan MonadBFT dengan protokol BFT kepemimpinan rotasi lainnya dalam dimensi kunci ini:
Apa artinya ini bagi pengembang dan pengguna?
Untuk pengembang, MonadBFT berarti beberapa hal:
Model kepastian akhir yang lebih sederhana: Dengan menggunakan MonadBFT, Anda dapat menganggap blok dengan QC (suara mayoritas) sebagai yang sebenarnya telah dipastikan, karena protokol akan memastikan kepastiannya atau memberikan hukuman. Pengembang dapat sangat yakin untuk mengoperasikan 1 konfirmasi blok dengan aman.
Meningkatkan pengalaman pengguna aplikasi: Jika Anda sedang membangun aplikasi dengan throughput tinggi (bursa, permainan, dll.), fitur latensi rendah dan ketahanan fork dari MonadBFT akan bertransformasi menjadi pengalaman pengguna yang lebih lancar. Pengguna hampir dapat segera melihat bahwa operasi mereka telah dikonfirmasi, dan tidak akan sering mengalami pengelompokan atau rollback yang membingungkan. Dengan cara ini, Anda dapat merancang aplikasi dengan kepastian akhir dan pembaruan cepat.
Perilaku deterministik: Aturan yang lebih ketat dari MonadBFT (seperti persyaratan pengajuan ulang) mengurangi ketidakpastian dalam pencantuman blok. Karena faktor waktu yang halus seperti apakah suara atau waktu habis tiba lebih dulu ke pemimpin, ada lebih sedikit "kasus tepi" di mana blok dicantumkan atau dilewati. MonadBFT menggantikan ketidakjelasan yang sensitif terhadap waktu ini dengan aturan yang jelas dan bukti yang dapat diverifikasi. Ini membuat pembuktian kebenaran protokol dan pengujian menjadi lebih mudah. Ini juga memberikan dasar yang jelas untuk mengidentifikasi node yang gagal (misalnya, jika seseorang gagal untuk mengajukan ulang atau mengajukan blok yang bertentangan, Anda tahu mereka telah melanggar protokol).
Ruang skalabilitas: Jika Anda adalah pengembang yang peduli dengan skalabilitas, MonadBFT memberikan lebih banyak ruang sebelum Anda menghadapi kendala. Dibandingkan dengan protokol sekunder, Anda dapat lebih mudah meningkatkan ukuran blok atau jumlah validator. Selain itu, fitur seperti penyebaran blok pengkodean penghapusan memungkinkan Anda untuk mendorong sejumlah besar data melalui jaringan tanpa menghabiskan sumber daya node tunggal secara berlebihan. Ini memungkinkan penargetan throughput yang lebih tinggi, membuka ruang desain untuk aplikasi on-chain yang lebih ambisius.
Untuk pengguna akhir: Pengguna biasa tidak akan memahami apa pun yang kita diskusikan di sini, tetapi mereka akan merasakan dampaknya. Dengan MonadBFT sebagai dasar untuk rantai Monad, pengguna dapat mengharapkan semua fitur baik berikut ini tanpa mengorbankan desentralisasi dan menahan sensor.
Konfirmasi yang lebih cepat: Transaksi (seperti mengirim token, menukar aset, mencetak NFT, melakukan transaksi) akan cepat dikonfirmasi.
Mengurangi kejadian yang tidak diinginkan: konsistensi status rantai lebih tinggi karena hal-hal yang secara esensial merupakan reorganisasi seperti fork akhir telah dihilangkan.
Keadilan dan transparansi: Peningkatan konsensus secara tidak langsung berarti operasi rantai lebih adil. Tidak ada validator tunggal yang dapat dengan mudah memeriksa transaksi atau memanipulasi urutan antar blok.
Kesimpulan
Ringkasnya, MonadBFT memperkenalkan empat inovasi inti berdasarkan konsensus gaya HotStuff yang terpipeline:
Menangkal fork di akhir: MonadBFT adalah protokol BFT pipeline pertama yang menghilangkan serangan fork di akhir. Ini mencapainya dengan cara pemimpin berikutnya mengajukan kembali blok yang telah dipilih sebelumnya jika pemimpin sebelumnya gagal, atau menunjukkan sertifikat tanpa dukungan (NEC), yang membuktikan bahwa blok tersebut tidak memiliki dukungan. Ini menjamin bahwa setiap blok yang mendapatkan dukungan mayoritas tidak akan dibuang, melindungi imbalan pemimpin yang jujur, dan mencegah reorganisasi jahat serta ekstraksi MEV lintas blok.
Finalitas spekulatif satu putaran: Validator dapat mengonfirmasi blok setelah komunikasi satu putaran (satu pemimpin mengusulkan dan memberikan suara), memberikan jaminan inklusi instan kepada klien. Konfirmasi spekulatif ini hanya akan dipulihkan dalam kasus serangan ekuivalen pemimpin (perilaku yang dapat dibuktikan dan dihukum), menjadikannya asumsi keamanan dalam praktik.
Responsif optimis: Protokol berjalan dengan kecepatan jaringan, tanpa penundaan bawaan. Pemimpin segera memajukan konsensus setelah menerima suara yang diperlukan, perubahan pandangan terjadi segera setelah waktu habis untuk jumlah yang sah diamati, alih-alih menunggu interval waktu tetap. Desain responsif optimis ini meminimalkan waktu tunggu dan memaksimalkan throughput, sambil tetap mampu menangani secara robust saat terjadi asinkron dan kegagalan.
Komunikasi linier: Di jalur bahagia (yaitu pemimpin jujur), kompleksitas pesan dan verifikasi memiliki hubungan linier dengan jumlah verifier. MonadBFT mempertahankan pola komunikasi efisien HotStuff, menggunakan tanda tangan agregat dan pemimpin sederhana untuk siaran ke verifier, memungkinkan protokol untuk berkembang hingga ratusan verifier tanpa mengalami kemacetan kinerja.
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 2): Apa Artinya bagi Pengembang dan Pengguna
Pada bagian pertama, kami mempelajari cara kerja konsensus PBFT klasik (Practical Byzantine Fault Tolerance) dan bagaimana versi awal HotStuff beroperasi. Kami juga memahami bagaimana MonadBFT menyelesaikan masalah fork akhir HotStuff, yaitu masalah di mana blok yang valid terkadang dibuang dalam sistem pipeline.
Masalah fork ini menyebabkan dua masalah utama: 1) Itu mengganggu imbalan bagi pembangun blok yang jujur, 2) Itu dapat mengakibatkan jaringan macet.
MonadBFT memperkenalkan aturan pengajuan ulang dan mekanisme pemungutan suara tanpa dukungan untuk menghilangkan masalah fork akhir, memastikan bahwa setiap blok yang disetujui dengan tepat dari pengusul yang jujur dapat masuk ke dalam rantai.
Pada bagian kedua, kita akan membahas dua fitur lain dari MonadBFT: 1) finalitas spekulatif dan 2) responsif optimis. Kita juga akan membahas dampak MonadBFT terhadap pengembang.
Kepastian spekulasi satu putaran
Selain menolak fork di bagian akhir, fitur utama lainnya dari MonadBFT adalah finalitas spekulatif satu putaran.
Dalam aplikasi praktis, ini berarti klien dan pengguna dapat segera menerima konfirmasi transaksi setelah blok mendapatkan sebagian besar suara, bahkan sebelum putaran berikutnya selesai.
Mengingat kembali, dalam protokol HotStuff baseline, sebuah blok biasanya memerlukan setidaknya dua tahap (seperti Fast-Hotstuff dan Diem-BFT) sebelum dianggap final (tidak dapat dibalik): tahap pertama mendapatkan sertifikat kuorum (QC) (dengan ≥2f+1 suara mengunci blok), tahap kedua adalah pemimpin berikutnya yang membangun dan mengajukan blok berdasarkan sertifikat kuorum (QC) tersebut.
Dua tahap pengajuan ini diperlukan untuk memastikan keamanan: setelah cukup banyak node yang jujur mengunci sebuah blok, blok yang bertentangan tidak dapat mencapai jumlah suara yang sah, dan pengajuan pada putaran berikutnya akan membuatnya permanen. Oleh karena itu, klien biasanya mungkin perlu menunggu blok berikutnya atau putaran berikutnya untuk mengetahui apakah transaksi sebelumnya telah dikonfirmasi.
MonadBFT pada dasarnya memungkinkan transaksi dianggap cukup final hanya setelah satu putaran pemungutan suara (dapat beroperasi dengan aman). Ini yang disebut dengan finalitas spekulatif.
Ketika pemimpin mengusulkan sebuah Blok, dan para validator memberikan suara untuk membentuk QC dari Blok tersebut, maka Blok tersebut berada dalam status suara (telah dikunci oleh jumlah yang sah). Dalam MonadBFT, setelah validator membentuk QC, mereka akan segera mengeksekusi transaksi dari Blok tersebut, bahkan akan mengirimkan konfirmasi awal kepada klien, menunjukkan bahwa Blok tersebut diterima (secara spekulatif). Ini seperti mengatakan "kami memiliki sebagian besar orang yang setuju dengan Blok ini. Kecuali terjadi situasi yang sangat tidak terduga, Blok ini dapat dianggap telah dikonfirmasi."
Konfirmasi instan ini bersifat optimis. Blok belum diserahkan ke buku besar. Ini akan terjadi saat proposal berikutnya muncul dan mengonfirmasi itu (QC-on QC), tetapi dalam keadaan normal, tidak ada yang dapat membatalkannya. Satu-satunya situasi yang dapat membatalkan eksekusi spekulatif blok adalah ketika pemimpin mengalami serangan ekuivalen (yaitu mengajukan dua blok berbeda pada tinggi yang sama untuk membagi suara).
Anda dapat melihat finalitas spekulatif sebagai produk sampingan yang baik untuk melawan fork bagian ekor. Melawan fork bagian ekor menjamin bahwa bahkan jika pemimpin berikutnya gagal, proposal saat ini tidak akan dibuang (berkat aturan pengusulan kembali dan NEC). Satu-satunya keadaan di mana blok eksekusi spekulatif dibuang adalah ketika pengusul asli mengalami serangan ekuivalen (kesalahan tanda tangan ganda yang dapat dibuktikan jahat), dan keadaan ini: 1) dapat terdeteksi melalui QC konflik; 2) dapat dihukum; 3) sangat jarang.
Dalam protokol sebelumnya, mereka tidak menjamin bahwa pemimpin berikutnya akan mengajukan kembali blok sebelumnya, sehingga fork di akhir mungkin terjadi, yang melanggar asumsi spekulatif.
responsif optimis
Dalam sebagian besar protokol konsensus, setelah setiap putaran akan ada penantian bawaan, seperti periode penyangga atau waktu tunggu. Ini bertujuan untuk memastikan bahwa semua pesan telah tiba sebelum melanjutkan. Ini adalah mekanisme perlindungan yang dirancang untuk menangani situasi terburuk, seperti pemimpin yang mengalami keruntuhan atau tidak mengirimkan informasi sama sekali.
Waktu tunggu ini biasanya terlalu konservatif. Jika jaringan berjalan normal dan semua validator bertindak dengan benar, maka waktu tunggu yang tetap akan menjadi biaya yang tidak perlu. Blok seharusnya bisa diselesaikan lebih cepat, tetapi protokol menundanya untuk berjaga-jaga.
MonadBFT memperkenalkan responsif optimis, yang berarti protokol dapat langsung maju berdasarkan informasi jaringan, alih-alih selalu bergantung pada timer tetap. Prinsip desain di sini dapat diringkas sebagai "jika bisa cepat, maka cepat; hanya bersabar saat memang harus bersabar".
Desain MonadBFT memungkinkan bahwa dalam kondisi normal, bahkan saat pemulihan dari kegagalan, jika tidak diperlukan, ia tidak akan menghentikan untuk menunggu waktu tunggu yang dijadwalkan.
Pada jalur kebahagiaan (yang berarti kita memiliki pemimpin yang jujur): Tidak ada penundaan bawaan dalam usulan atau pemungutan suara. Begitu giliran pemimpin, ia akan mengusulkan sebuah Blok. Begitu validator menerima usulan yang valid, mereka akan segera memberikan suara. Ketika pemimpin (atau lebih tepatnya, pemimpin berikutnya, karena dalam saluran HotStuff, suara akan dikirim ke pengusul berikutnya) mengumpulkan 2f+1 suara, QC terbentuk dan dapat disebarkan. Dalam desain responsif optimis, ini akan segera memicu tahap berikutnya.
Dalam praktiknya, ini berarti bahwa jika latensi jaringan antara node adalah 100 milidetik, maka konsensus mungkin hanya memerlukan beberapa ratus milidetik untuk menyelesaikan satu putaran (ditambah biaya perhitungan dan penggabungan).
Jika tidak diperlukan, itu tidak akan menunggu, misalnya, "waktu slot" selama satu detik penuh. Ini berbeda dengan model slot-and-epoch yang digunakan oleh jaringan utama Ethereum. Di Ethereum, interval waktu produksi blok tetap adalah 12 detik. Bahkan jika semua orang sudah siap sebelumnya, protokol akan menunggu.
Metode MonadBFT menghilangkan penundaan yang tidak perlu. Ini mempertahankan struktur HotStuff yang dipipakan, tetapi menghapus ketentuan keras "harus menunggu Δ detik" dalam kondisi normal. Ini berarti bahwa ia dapat unggul dalam hal responsivitas dibandingkan dengan sistem yang terikat waktu tanpa mengorbankan keamanan.
Di jalur yang tidak bahagia (kegagalan pemimpin): Dalam banyak protokol konsensus, ketika pemimpin gagal mengajukan blok, node lain hanya akan menyadari hal ini setelah waktu habis Δ. Misalnya, jika Δ adalah 1 detik, maka waktu ini pada dasarnya terbuang percuma. Pendekatan MonadBFT berbeda. Ketika validator mendeteksi bahwa usulan hilang, mereka segera menyiarkan pesan waktu habis (TC atau sertifikat waktu habis). Setelah terjadi 2f+1 waktu habis, pemimpin berikutnya akan mengambil alih. Transisi ke sudut pandang baru dipicu oleh bukti berbasis kuorum, bukan oleh jam.
Perbandingan dengan konsensus hotstuff-family
MonadBFT dibangun di atas dasar protokol konsensus seri HotStuff, tetapi menonjol dengan mengimplementasikan kombinasi dari serangkaian karakteristik ideal. Protokol awal biasanya dioptimalkan untuk dimensi tertentu, seperti throughput pipelining atau komunikasi linier, tetapi harus mengorbankan aspek lainnya. MonadBFT secara unik menggabungkan kompleksitas pesan linier, komitmen pipelining, ketahanan fork akhir yang kuat, respons instan tanpa penundaan tetap, dan mekanisme pemulihan yang efisien, sambil tetap mempertahankan kepastian akhir yang cepat dan jaminan ketersediaan tinggi. Tabel di bawah ini merangkum perbandingan MonadBFT dengan protokol BFT kepemimpinan rotasi lainnya dalam dimensi kunci ini:
Apa artinya ini bagi pengembang dan pengguna?
Untuk pengembang, MonadBFT berarti beberapa hal:
Model kepastian akhir yang lebih sederhana: Dengan menggunakan MonadBFT, Anda dapat menganggap blok dengan QC (suara mayoritas) sebagai yang sebenarnya telah dipastikan, karena protokol akan memastikan kepastiannya atau memberikan hukuman. Pengembang dapat sangat yakin untuk mengoperasikan 1 konfirmasi blok dengan aman.
Meningkatkan pengalaman pengguna aplikasi: Jika Anda sedang membangun aplikasi dengan throughput tinggi (bursa, permainan, dll.), fitur latensi rendah dan ketahanan fork dari MonadBFT akan bertransformasi menjadi pengalaman pengguna yang lebih lancar. Pengguna hampir dapat segera melihat bahwa operasi mereka telah dikonfirmasi, dan tidak akan sering mengalami pengelompokan atau rollback yang membingungkan. Dengan cara ini, Anda dapat merancang aplikasi dengan kepastian akhir dan pembaruan cepat.
Perilaku deterministik: Aturan yang lebih ketat dari MonadBFT (seperti persyaratan pengajuan ulang) mengurangi ketidakpastian dalam pencantuman blok. Karena faktor waktu yang halus seperti apakah suara atau waktu habis tiba lebih dulu ke pemimpin, ada lebih sedikit "kasus tepi" di mana blok dicantumkan atau dilewati. MonadBFT menggantikan ketidakjelasan yang sensitif terhadap waktu ini dengan aturan yang jelas dan bukti yang dapat diverifikasi. Ini membuat pembuktian kebenaran protokol dan pengujian menjadi lebih mudah. Ini juga memberikan dasar yang jelas untuk mengidentifikasi node yang gagal (misalnya, jika seseorang gagal untuk mengajukan ulang atau mengajukan blok yang bertentangan, Anda tahu mereka telah melanggar protokol).
Ruang skalabilitas: Jika Anda adalah pengembang yang peduli dengan skalabilitas, MonadBFT memberikan lebih banyak ruang sebelum Anda menghadapi kendala. Dibandingkan dengan protokol sekunder, Anda dapat lebih mudah meningkatkan ukuran blok atau jumlah validator. Selain itu, fitur seperti penyebaran blok pengkodean penghapusan memungkinkan Anda untuk mendorong sejumlah besar data melalui jaringan tanpa menghabiskan sumber daya node tunggal secara berlebihan. Ini memungkinkan penargetan throughput yang lebih tinggi, membuka ruang desain untuk aplikasi on-chain yang lebih ambisius.
Untuk pengguna akhir: Pengguna biasa tidak akan memahami apa pun yang kita diskusikan di sini, tetapi mereka akan merasakan dampaknya. Dengan MonadBFT sebagai dasar untuk rantai Monad, pengguna dapat mengharapkan semua fitur baik berikut ini tanpa mengorbankan desentralisasi dan menahan sensor.
Konfirmasi yang lebih cepat: Transaksi (seperti mengirim token, menukar aset, mencetak NFT, melakukan transaksi) akan cepat dikonfirmasi.
Mengurangi kejadian yang tidak diinginkan: konsistensi status rantai lebih tinggi karena hal-hal yang secara esensial merupakan reorganisasi seperti fork akhir telah dihilangkan.
Keadilan dan transparansi: Peningkatan konsensus secara tidak langsung berarti operasi rantai lebih adil. Tidak ada validator tunggal yang dapat dengan mudah memeriksa transaksi atau memanipulasi urutan antar blok.
Kesimpulan
Ringkasnya, MonadBFT memperkenalkan empat inovasi inti berdasarkan konsensus gaya HotStuff yang terpipeline:
Menangkal fork di akhir: MonadBFT adalah protokol BFT pipeline pertama yang menghilangkan serangan fork di akhir. Ini mencapainya dengan cara pemimpin berikutnya mengajukan kembali blok yang telah dipilih sebelumnya jika pemimpin sebelumnya gagal, atau menunjukkan sertifikat tanpa dukungan (NEC), yang membuktikan bahwa blok tersebut tidak memiliki dukungan. Ini menjamin bahwa setiap blok yang mendapatkan dukungan mayoritas tidak akan dibuang, melindungi imbalan pemimpin yang jujur, dan mencegah reorganisasi jahat serta ekstraksi MEV lintas blok.
Finalitas spekulatif satu putaran: Validator dapat mengonfirmasi blok setelah komunikasi satu putaran (satu pemimpin mengusulkan dan memberikan suara), memberikan jaminan inklusi instan kepada klien. Konfirmasi spekulatif ini hanya akan dipulihkan dalam kasus serangan ekuivalen pemimpin (perilaku yang dapat dibuktikan dan dihukum), menjadikannya asumsi keamanan dalam praktik.
Responsif optimis: Protokol berjalan dengan kecepatan jaringan, tanpa penundaan bawaan. Pemimpin segera memajukan konsensus setelah menerima suara yang diperlukan, perubahan pandangan terjadi segera setelah waktu habis untuk jumlah yang sah diamati, alih-alih menunggu interval waktu tetap. Desain responsif optimis ini meminimalkan waktu tunggu dan memaksimalkan throughput, sambil tetap mampu menangani secara robust saat terjadi asinkron dan kegagalan.
Komunikasi linier: Di jalur bahagia (yaitu pemimpin jujur), kompleksitas pesan dan verifikasi memiliki hubungan linier dengan jumlah verifier. MonadBFT mempertahankan pola komunikasi efisien HotStuff, menggunakan tanda tangan agregat dan pemimpin sederhana untuk siaran ke verifier, memungkinkan protokol untuk berkembang hingga ratusan verifier tanpa mengalami kemacetan kinerja.