Monoscope | Apa yang MonadBFT artikan bagi para pengembang dan pengguna (bag.2)

Lanjutan5/8/2025, 1:49:13 AM
Artikel ini memberikan pengantar rinci tentang finalitas spekulatif satu putaran MonadBFT dan responsif optimis. Fitur-fitur ini memungkinkan MonadBFT mencapai konfirmasi transaksi yang lebih cepat dan responsivitas jaringan yang lebih tinggi tanpa mengorbankan keamanan, sambil juga menawarkan kepada pengembang model finalitas yang lebih sederhana dan pengalaman pengguna yang lebih baik.

DiBagian 1,Kami memeriksa bagaimana konsensus PBFT klasik bekerja dan bagaimana versi sebelumnya dari HotStuff beroperasi. Kami juga melihat bagaimana MonadBFT menyelesaikan isu tail-forking HotStuff yang merupakan masalah di mana blok valid terkadang tertinggal dalam sistem pipelined.

Masalah tail-forking ini menciptakan dua masalah besar: 1) itu mengacaukan imbalan bagi pembangun blok jujur dan 2) bisa berpotensi membuat jaringan terhenti.

MonadBFT memperkenalkan aturan Reproposal dan mekanisme pemungutan suara No-Endorsement untuk menghilangkan masalah tail-forking, memastikan bahwa setiap blok yang disetujui dengan benar dari proposer yang jujur akan selalu masuk ke dalam rantai.

Pada bagian 2, kami akan menjelajahi dua karakteristik lain dari MonadBFT yang adalah 1) finalitas spekulatif dan 2) responsif optimis. Kami juga akan menjelajahi implikasi MonadBFT bagi para pengembang.

Finalitas spekulatif satu putaran

Selain ketahanan tail-fork, fitur utama lain dari MonadBFT adalah finalitas spekulatif dalam satu putaran.

Secara praktis, ini berarti bahwa klien dan pengguna dapat menerima konfirmasi untuk transaksi mereka segera setelah blok menerima mayoritas suara super, bahkan sebelum putaran berikutnya selesai.

Ingatlah bahwa dalam protokol dasar HotStuff, sebuah blok biasanya tidak dianggap final (tidak dapat diubah) sampai setidaknya telah melalui setidaknya dua fase (mis. Fast-Hotstuff & Diem-BFT): satu fase untuk mendapatkan Sertifikat Quorum (mengunci blok dengan ≥2f+1 suara), dan fase kedua di mana pemimpin berikutnya membangun berdasarkan QC tersebut dan mengkonfirmasi blok.

Komit dua fase ini diperlukan untuk memastikan keamanan: begitu cukup node jujur telah mengunci blok, tidak ada blok yang bertentangan yang dapat mengumpulkan kuorum, dan komit di putaran berikutnya menjadikannya permanen. Jadi biasanya, seorang klien mungkin harus menunggu blok atau putaran berikutnya diproduksi sebelum mereka tahu transaksi sebelumnya sudah final.

MonadBFT pada dasarnya memungkinkan transaksi dianggap cukup final (aman untuk dijalankan) setelah hanya satu putaran pemungutan suara. Ini disebut finalitas spekulatif.

Ketika seorang pemimpin mengusulkan blok dan para validator memberikan suara untuk membentuk QC untuk blok tersebut, blok tersebut sekarang berada dalam keadaan Voted (terkunci oleh kuorum). Dalam MonadBFT, para validator akan mengeksekusi transaksi blok segera setelah mereka membentuk QC dan bahkan mengirim konfirmasi awal kepada klien yang menunjukkan bahwa blok tersebut (secara spekulatif) diterima. Ini seperti mengatakan: "Kami memiliki mayoritas super setuju dengan blok ini. Kecuali terjadi sesuatu yang sangat tidak terduga, anggaplah blok ini sudah dikonfirmasi."

Konfirmasi langsung ini optimis. Blok belum dicatat dalam buku besar. Itu akan terjadi ketika proposal berikutnya datang dan menyelesaikannya (QC-on QC), tetapi dalam kondisi normal, tidak ada yang akan mencabutnya. Satu-satunya skenario yang dapat mengembalikan blok yang dieksekusi secara spekulatif adalah jika pemimpin bersikap tidak konsisten (yaitu mengajukan dua blok yang berbeda pada ketinggian yang sama untuk membagi suara).

Anda dapat menganggap finalitas spekulatif sebagai hasil sampingan yang bagus dari ketahanan tail-forking. Ketahanan tail-forking menjamin bahwa bahkan jika pemimpin berikutnya mengalami kegagalan, proposal saat ini tidak akan ditinggalkan (berkat aturan reproposal dan NEC). Jadi satu-satunya waktu blok yang dieksekusi secara spekulatif dihapus adalah jika pengusul asli melakukan ekuivokasi (kesalahan double-signing yang terbukti bersifat jahat), yang: 1) dapat dideteksi melalui QCs yang bertentangan, 2) layak dipotong dan 3) sangat jarang.

Pada protokol sebelumnya, mereka tidak menjamin bahwa pemimpin berikutnya akan mengajukan kembali blok sebelumnya, sehingga tail-forking mungkin terjadi, yang dapat merusak asumsi spekulasi.

Optimisme Responsif

Dalam kebanyakan protokol konsensus, ada waktu tunggu bawaan setelah setiap putaran seperti periode buffer atau timeout. Hal ini untuk memastikan semua pesan telah tiba sebelum melanjutkan. Ini adalah mekanisme perlindungan yang dimaksudkan untuk menangani skenario terburuk seperti ketika pemimpin crash atau tidak mengirim apa pun sama sekali.

Timeout ini sering kali terlalu konservatif. Jika jaringan berfungsi normal dan semua validator berperilaku dengan benar, maka waktu tunggu tetap menjadi beban yang tidak perlu. Blok seharusnya dapat difinalisasi lebih cepat, tetapi protokol menahan diri hanya untuk jaga-jaga.

MonadBFT memperkenalkan responsif optimis yang berarti protokol dapat maju segera berdasarkan pesan jaringan, daripada selalu mengandalkan timer yang tetap. Prinsip desain di sini dapat dirangkum sebagai 'cepat saat bisa, sabar saat harus'.

MonadBFT dirancang sedemikian rupa sehingga dalam kasus normal maupun bahkan dalam pemulihan dari kesalahan, tidak berhenti selama waktu tunggu yang telah ditentukan jika memang tidak perlu.

  • Dalam jalur bahagia (berarti kita memiliki pemimpin yang jujur): Tidak ada penundaan bawaan dalam mengajukan atau memberikan suara. Begitu seorang pemimpin mendapat giliran, dia mengajukan blok. Begitu validator menerima proposal yang valid, mereka memberikan suara. Saat pemimpin (atau lebih tepatnya, pemimpin berikutnya, karena suara diberikan kepada pengusul berikutnya dalam HotStuff berpipa) mengumpulkan 2f+1 suara, QC terbentuk dan dapat disebarkan. Dalam desain responsif yang optimis, ini memicu fase berikutnya secara langsung.

Dalam praktiknya, ini berarti jika laten jaringan antara node adalah, katakanlah, 100ms, konsensus potensial dapat menyelesaikan putaran dalam hanya beberapa ratus milidetik (ditambah overhead komputasi dan agregasi).

Ini tidak menunggu, misalnya, selama satu detik penuh "waktu slot" jika tidak perlu. Hal ini berbeda dengan Ethereum mainnet yang mengikuti sebuahmodel slot-dan-epochDi Ethereum, produksi blok tetap pada interval 12 detik. Bahkan jika semua orang sudah siap lebih awal, protokol menunggu.

Pendekatan MonadBFT menghilangkan keterlambatan yang tidak perlu. Ini mempertahankan struktur HotStuff yang dipipelin tetapi menghapus aturan kaku 'Anda harus menunggu Δ detik' dalam kasus normal. Ini berarti dapat melebihi sistem berbasis waktu dalam responsivitas tanpa mengorbankan keamanan.

  • Dalam jalur tidak bahagia (kegagalan pemimpin): Dalam banyak protokol konsensus, ketika seorang pemimpin gagal mengusulkan blok, node lain hanya menyadari hal ini setelah waktu tunggu Δ berlalu. Jika Δ adalah, misalnya, 1 detik, waktu itu pada dasarnya hilang. MonadBFT menangani hal ini dengan cara yang berbeda. Ketika validator mendeteksi proposal yang hilang, mereka segera menyebarkan pesan timeout (TC atau Sertifikat Timeout). Begitu 2f+1 timeout ini terlihat, pemimpin berikutnya mengambil alih. Transisi ke tampilan baru dipicu oleh bukti berbasis kuarum, bukan oleh jam.

Perbandingan dengan konsensus keluarga hotstuff

MonadBFT membangun garis keturunan protokol konsensus keluarga HotStuff, tetapi menonjol dengan mencapai kombinasi properti yang diinginkan yang tidak ada desain sebelumnya yang mampu sepenuhnya mengintegrasikan tanpa adanya pengorbanan. Protokol sebelumnya sering dioptimalkan untuk beberapa dimensi seperti throughput berpipa atau komunikasi linier tetapi harus mengorbankan yang lain. MonadBFT secara unik berhasil menggabungkan kompleksitas pesan linear, komit berpipa, resistensi tail-forking yang kuat, responsivitas instan tanpa keterlambatan tetap, dan mekanisme pemulihan yang efisien, semuanya sambil mempertahankan finalitas cepat dan garansi kelangsungan hidup tinggi. Tabel di bawah ini merangkum bagaimana MonadBFT dibandingkan dengan protokol BFT pemimpin-putar lainnya di sepanjang dimensi kritis ini:

Apa arti ini bagi Pengembang dan Pengguna?

Bagi para pengembang, MonadBFT memiliki beberapa makna:

  • Model Finalitas yang Lebih Sederhana: Dengan MonadBFT, Anda dapat memperlakukan blok yang memiliki QC (suara mayoritas) sebagai efektif difinalisasi untuk kebanyakan tujuan, karena protokol akan memfinalisasikannya atau memotong jika tidak. Pengembang dapat dengan aman bertindak pada konfirmasi 1 blok dengan keyakinan tinggi.
  • Peningkatan UX untuk Aplikasi: Jika Anda sedang membangun aplikasi yang memiliki throughput tinggi (pertukaran, permainan, dll.), rendahnya latensi MonadBFT dan ketahanan terhadap fork menghasilkan pengalaman pengguna yang lebih lancar. Pengguna hampir seketika melihat tindakan mereka dikonfirmasi dan jarang mengalami reorgs atau rollback yang membingungkan. Hal ini memungkinkan Anda untuk merancang aplikasi yang mengasumsikan finalitas dan pembaruan yang cepat.
  • Perilaku Deterministik: Aturan yang lebih ketat dari MonadBFT (seperti persyaratan proposisi ulang) mengurangi ketidaktertentuan dalam penjelasan blok. Ada lebih sedikit skenario "sudut" di mana sebuah blok mungkin disertakan atau dilewati tergantung pada waktu yang halus seperti apakah suara atau waktu habis mencapai pemimpin terlebih dahulu. MonadBFT menggantikan ketidakjelasan yang sensitif terhadap waktu dengan aturan eksplisit dan bukti yang dapat diverifikasi. Hal ini memudahkan untuk memahami tentang kebenaran protokol dan mengujinya. Ini juga memberikan dasar yang jelas untuk mengidentifikasi node yang rusak (misalnya, jika seseorang gagal mempropose ulang atau mengusulkan blok yang bertentangan, Anda tahu mereka melanggar protokol).
  • Ruang Kepala Skalabilitas: Jika Anda seorang pengembang yang peduli dengan penskalaan, MonadBFT memberi Anda lebih banyak ruang kepala sebelum mencapai bottleneck. Anda dapat meningkatkan ukuran blok atau jumlah validator dengan lebih nyaman daripada pada protokol kuadratik. Dan fitur-fitur seperti penyebaran blok yang dihapus kode artinya Anda dapat mendorong banyak data melalui jaringan tanpa memberatkan node individu. Hal ini membuat mungkin untuk menyasar throughput yang lebih tinggi yang membuka ruang desain untuk aplikasi on-chain yang lebih ambisius.

Untuk Pengguna Akhir: Pengguna normie mungkin tidak tahu tentang hal-hal yang dibahas di sini, tetapi mereka merasakan efeknya. Dengan MonadBFT sebagai dasar Monad jaringan, pengguna dapat mengharapkan semua kualitas bagus di bawah ini tanpa mengorbankan desentralisasi dan ketahanan sensor.

  • Konfirmasi Lebih Cepat: Transaksi (seperti mengirim token, menukar aset, mencetak NFT, mengeksekusi perdagangan) akan segera dikonfirmasi.
  • Lebih Sedikit Kejutan: Konsistensi dari keadaan rantai lebih tinggi karena hal-hal seperti tail-forking, yang pada dasarnya adalah re-org, dihilangkan
  • Keadilan dan Transparansi: Peningkatan dalam konsensus secara tidak langsung berarti bahwa operasi rantai lebih adil. Tidak ada validator tunggal yang dapat dengan mudah menyensor transaksi atau bermain curang dalam pengurutan blok.

Kesimpulan

Untuk mengulangi, MonadBFT memperkenalkan empat inovasi inti di atas konsensus gaya HotStuff berpipa:

Resistensi Tail-Forking: MonadBFT adalah protokol BFT berpipa pertama yang menghilangkan serangan tail-forking​. Ini dicapai dengan menuntut pemimpin berikutnya untuk mengusulkan ulang blok yang terakhir disetujui jika pemimpin sebelumnya gagal, atau menunjukkan Sertifikat Tanpa-Endorsement (NEC) sebagai bukti bahwa blok tersebut kurang dukungan. Ini menjamin bahwa tidak ada blok yang didukung oleh supermayoritas akan ditinggalkan, melindungi imbalan pemimpin jujur dan mencegah reorgs jahat dan ekstraksi MEV melintasi blok.

Finalitas Spekulatif dalam Satu Putaran: Validator dapat mengonfirmasi sebuah blok setelah satu putaran komunikasi (satu proposal pemimpin dan suara), memberikan jaminan inklusi yang langsung kepada klien. Konfirmasi spekulatif ini hanya akan dibalik jika pemimpin melakukan ekivokasi (tindakan yang dapat dibuktikan dan dihukum), menjadikannya asumsi yang aman dalam praktik.

Responsif Optimis: Protokol beroperasi dengan kecepatan jaringan tanpa keterlambatan bawaan. Para pemimpin memajukan konsensus segera setelah suara yang diperlukan diterima, dan perubahan pandangan terjadi segera setelah kuorum waktu habis diamati, daripada menunggu interval waktu tetap. Desain responsif secara optimis ini meminimalkan waktu tunggu dan memaksimalkan throughput, sambil tetap mengatasi asinkroni dan kegagalan dengan kokoh saat terjadi.

Komunikasi Linear: Pada jalur bahagia (artinya pemimpin jujur), kompleksitas pesan dan otentikasi adalah linear dalam jumlah validator. MonadBFT mempertahankan pola komunikasi efisien HotStuff, menggunakan tanda tangan terkumpul dan siaran pemimpin ke validator yang sederhana, yang memungkinkan protokol untuk meluas hingga ratusan validator tanpa hambatan kinerja.

Disclaimer:

  1. Artikel ini dicetak ulang dari [michael_lwy]. Semua hak cipta adalah milik penulis asli [michael_lwy]. Jika ada keberatan terhadap cetak ulang ini, harap hubungiGate Belajartim, dan mereka akan menanganinya dengan cepat.
  2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
  3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.
* The information is not intended to be and does not constitute financial advice or any other recommendation of any sort offered or endorsed by Gate.io.
* This article may not be reproduced, transmitted or copied without referencing Gate.io. Contravention is an infringement of Copyright Act and may be subject to legal action.

Monoscope | Apa yang MonadBFT artikan bagi para pengembang dan pengguna (bag.2)

Lanjutan5/8/2025, 1:49:13 AM
Artikel ini memberikan pengantar rinci tentang finalitas spekulatif satu putaran MonadBFT dan responsif optimis. Fitur-fitur ini memungkinkan MonadBFT mencapai konfirmasi transaksi yang lebih cepat dan responsivitas jaringan yang lebih tinggi tanpa mengorbankan keamanan, sambil juga menawarkan kepada pengembang model finalitas yang lebih sederhana dan pengalaman pengguna yang lebih baik.

DiBagian 1,Kami memeriksa bagaimana konsensus PBFT klasik bekerja dan bagaimana versi sebelumnya dari HotStuff beroperasi. Kami juga melihat bagaimana MonadBFT menyelesaikan isu tail-forking HotStuff yang merupakan masalah di mana blok valid terkadang tertinggal dalam sistem pipelined.

Masalah tail-forking ini menciptakan dua masalah besar: 1) itu mengacaukan imbalan bagi pembangun blok jujur dan 2) bisa berpotensi membuat jaringan terhenti.

MonadBFT memperkenalkan aturan Reproposal dan mekanisme pemungutan suara No-Endorsement untuk menghilangkan masalah tail-forking, memastikan bahwa setiap blok yang disetujui dengan benar dari proposer yang jujur akan selalu masuk ke dalam rantai.

Pada bagian 2, kami akan menjelajahi dua karakteristik lain dari MonadBFT yang adalah 1) finalitas spekulatif dan 2) responsif optimis. Kami juga akan menjelajahi implikasi MonadBFT bagi para pengembang.

Finalitas spekulatif satu putaran

Selain ketahanan tail-fork, fitur utama lain dari MonadBFT adalah finalitas spekulatif dalam satu putaran.

Secara praktis, ini berarti bahwa klien dan pengguna dapat menerima konfirmasi untuk transaksi mereka segera setelah blok menerima mayoritas suara super, bahkan sebelum putaran berikutnya selesai.

Ingatlah bahwa dalam protokol dasar HotStuff, sebuah blok biasanya tidak dianggap final (tidak dapat diubah) sampai setidaknya telah melalui setidaknya dua fase (mis. Fast-Hotstuff & Diem-BFT): satu fase untuk mendapatkan Sertifikat Quorum (mengunci blok dengan ≥2f+1 suara), dan fase kedua di mana pemimpin berikutnya membangun berdasarkan QC tersebut dan mengkonfirmasi blok.

Komit dua fase ini diperlukan untuk memastikan keamanan: begitu cukup node jujur telah mengunci blok, tidak ada blok yang bertentangan yang dapat mengumpulkan kuorum, dan komit di putaran berikutnya menjadikannya permanen. Jadi biasanya, seorang klien mungkin harus menunggu blok atau putaran berikutnya diproduksi sebelum mereka tahu transaksi sebelumnya sudah final.

MonadBFT pada dasarnya memungkinkan transaksi dianggap cukup final (aman untuk dijalankan) setelah hanya satu putaran pemungutan suara. Ini disebut finalitas spekulatif.

Ketika seorang pemimpin mengusulkan blok dan para validator memberikan suara untuk membentuk QC untuk blok tersebut, blok tersebut sekarang berada dalam keadaan Voted (terkunci oleh kuorum). Dalam MonadBFT, para validator akan mengeksekusi transaksi blok segera setelah mereka membentuk QC dan bahkan mengirim konfirmasi awal kepada klien yang menunjukkan bahwa blok tersebut (secara spekulatif) diterima. Ini seperti mengatakan: "Kami memiliki mayoritas super setuju dengan blok ini. Kecuali terjadi sesuatu yang sangat tidak terduga, anggaplah blok ini sudah dikonfirmasi."

Konfirmasi langsung ini optimis. Blok belum dicatat dalam buku besar. Itu akan terjadi ketika proposal berikutnya datang dan menyelesaikannya (QC-on QC), tetapi dalam kondisi normal, tidak ada yang akan mencabutnya. Satu-satunya skenario yang dapat mengembalikan blok yang dieksekusi secara spekulatif adalah jika pemimpin bersikap tidak konsisten (yaitu mengajukan dua blok yang berbeda pada ketinggian yang sama untuk membagi suara).

Anda dapat menganggap finalitas spekulatif sebagai hasil sampingan yang bagus dari ketahanan tail-forking. Ketahanan tail-forking menjamin bahwa bahkan jika pemimpin berikutnya mengalami kegagalan, proposal saat ini tidak akan ditinggalkan (berkat aturan reproposal dan NEC). Jadi satu-satunya waktu blok yang dieksekusi secara spekulatif dihapus adalah jika pengusul asli melakukan ekuivokasi (kesalahan double-signing yang terbukti bersifat jahat), yang: 1) dapat dideteksi melalui QCs yang bertentangan, 2) layak dipotong dan 3) sangat jarang.

Pada protokol sebelumnya, mereka tidak menjamin bahwa pemimpin berikutnya akan mengajukan kembali blok sebelumnya, sehingga tail-forking mungkin terjadi, yang dapat merusak asumsi spekulasi.

Optimisme Responsif

Dalam kebanyakan protokol konsensus, ada waktu tunggu bawaan setelah setiap putaran seperti periode buffer atau timeout. Hal ini untuk memastikan semua pesan telah tiba sebelum melanjutkan. Ini adalah mekanisme perlindungan yang dimaksudkan untuk menangani skenario terburuk seperti ketika pemimpin crash atau tidak mengirim apa pun sama sekali.

Timeout ini sering kali terlalu konservatif. Jika jaringan berfungsi normal dan semua validator berperilaku dengan benar, maka waktu tunggu tetap menjadi beban yang tidak perlu. Blok seharusnya dapat difinalisasi lebih cepat, tetapi protokol menahan diri hanya untuk jaga-jaga.

MonadBFT memperkenalkan responsif optimis yang berarti protokol dapat maju segera berdasarkan pesan jaringan, daripada selalu mengandalkan timer yang tetap. Prinsip desain di sini dapat dirangkum sebagai 'cepat saat bisa, sabar saat harus'.

MonadBFT dirancang sedemikian rupa sehingga dalam kasus normal maupun bahkan dalam pemulihan dari kesalahan, tidak berhenti selama waktu tunggu yang telah ditentukan jika memang tidak perlu.

  • Dalam jalur bahagia (berarti kita memiliki pemimpin yang jujur): Tidak ada penundaan bawaan dalam mengajukan atau memberikan suara. Begitu seorang pemimpin mendapat giliran, dia mengajukan blok. Begitu validator menerima proposal yang valid, mereka memberikan suara. Saat pemimpin (atau lebih tepatnya, pemimpin berikutnya, karena suara diberikan kepada pengusul berikutnya dalam HotStuff berpipa) mengumpulkan 2f+1 suara, QC terbentuk dan dapat disebarkan. Dalam desain responsif yang optimis, ini memicu fase berikutnya secara langsung.

Dalam praktiknya, ini berarti jika laten jaringan antara node adalah, katakanlah, 100ms, konsensus potensial dapat menyelesaikan putaran dalam hanya beberapa ratus milidetik (ditambah overhead komputasi dan agregasi).

Ini tidak menunggu, misalnya, selama satu detik penuh "waktu slot" jika tidak perlu. Hal ini berbeda dengan Ethereum mainnet yang mengikuti sebuahmodel slot-dan-epochDi Ethereum, produksi blok tetap pada interval 12 detik. Bahkan jika semua orang sudah siap lebih awal, protokol menunggu.

Pendekatan MonadBFT menghilangkan keterlambatan yang tidak perlu. Ini mempertahankan struktur HotStuff yang dipipelin tetapi menghapus aturan kaku 'Anda harus menunggu Δ detik' dalam kasus normal. Ini berarti dapat melebihi sistem berbasis waktu dalam responsivitas tanpa mengorbankan keamanan.

  • Dalam jalur tidak bahagia (kegagalan pemimpin): Dalam banyak protokol konsensus, ketika seorang pemimpin gagal mengusulkan blok, node lain hanya menyadari hal ini setelah waktu tunggu Δ berlalu. Jika Δ adalah, misalnya, 1 detik, waktu itu pada dasarnya hilang. MonadBFT menangani hal ini dengan cara yang berbeda. Ketika validator mendeteksi proposal yang hilang, mereka segera menyebarkan pesan timeout (TC atau Sertifikat Timeout). Begitu 2f+1 timeout ini terlihat, pemimpin berikutnya mengambil alih. Transisi ke tampilan baru dipicu oleh bukti berbasis kuarum, bukan oleh jam.

Perbandingan dengan konsensus keluarga hotstuff

MonadBFT membangun garis keturunan protokol konsensus keluarga HotStuff, tetapi menonjol dengan mencapai kombinasi properti yang diinginkan yang tidak ada desain sebelumnya yang mampu sepenuhnya mengintegrasikan tanpa adanya pengorbanan. Protokol sebelumnya sering dioptimalkan untuk beberapa dimensi seperti throughput berpipa atau komunikasi linier tetapi harus mengorbankan yang lain. MonadBFT secara unik berhasil menggabungkan kompleksitas pesan linear, komit berpipa, resistensi tail-forking yang kuat, responsivitas instan tanpa keterlambatan tetap, dan mekanisme pemulihan yang efisien, semuanya sambil mempertahankan finalitas cepat dan garansi kelangsungan hidup tinggi. Tabel di bawah ini merangkum bagaimana MonadBFT dibandingkan dengan protokol BFT pemimpin-putar lainnya di sepanjang dimensi kritis ini:

Apa arti ini bagi Pengembang dan Pengguna?

Bagi para pengembang, MonadBFT memiliki beberapa makna:

  • Model Finalitas yang Lebih Sederhana: Dengan MonadBFT, Anda dapat memperlakukan blok yang memiliki QC (suara mayoritas) sebagai efektif difinalisasi untuk kebanyakan tujuan, karena protokol akan memfinalisasikannya atau memotong jika tidak. Pengembang dapat dengan aman bertindak pada konfirmasi 1 blok dengan keyakinan tinggi.
  • Peningkatan UX untuk Aplikasi: Jika Anda sedang membangun aplikasi yang memiliki throughput tinggi (pertukaran, permainan, dll.), rendahnya latensi MonadBFT dan ketahanan terhadap fork menghasilkan pengalaman pengguna yang lebih lancar. Pengguna hampir seketika melihat tindakan mereka dikonfirmasi dan jarang mengalami reorgs atau rollback yang membingungkan. Hal ini memungkinkan Anda untuk merancang aplikasi yang mengasumsikan finalitas dan pembaruan yang cepat.
  • Perilaku Deterministik: Aturan yang lebih ketat dari MonadBFT (seperti persyaratan proposisi ulang) mengurangi ketidaktertentuan dalam penjelasan blok. Ada lebih sedikit skenario "sudut" di mana sebuah blok mungkin disertakan atau dilewati tergantung pada waktu yang halus seperti apakah suara atau waktu habis mencapai pemimpin terlebih dahulu. MonadBFT menggantikan ketidakjelasan yang sensitif terhadap waktu dengan aturan eksplisit dan bukti yang dapat diverifikasi. Hal ini memudahkan untuk memahami tentang kebenaran protokol dan mengujinya. Ini juga memberikan dasar yang jelas untuk mengidentifikasi node yang rusak (misalnya, jika seseorang gagal mempropose ulang atau mengusulkan blok yang bertentangan, Anda tahu mereka melanggar protokol).
  • Ruang Kepala Skalabilitas: Jika Anda seorang pengembang yang peduli dengan penskalaan, MonadBFT memberi Anda lebih banyak ruang kepala sebelum mencapai bottleneck. Anda dapat meningkatkan ukuran blok atau jumlah validator dengan lebih nyaman daripada pada protokol kuadratik. Dan fitur-fitur seperti penyebaran blok yang dihapus kode artinya Anda dapat mendorong banyak data melalui jaringan tanpa memberatkan node individu. Hal ini membuat mungkin untuk menyasar throughput yang lebih tinggi yang membuka ruang desain untuk aplikasi on-chain yang lebih ambisius.

Untuk Pengguna Akhir: Pengguna normie mungkin tidak tahu tentang hal-hal yang dibahas di sini, tetapi mereka merasakan efeknya. Dengan MonadBFT sebagai dasar Monad jaringan, pengguna dapat mengharapkan semua kualitas bagus di bawah ini tanpa mengorbankan desentralisasi dan ketahanan sensor.

  • Konfirmasi Lebih Cepat: Transaksi (seperti mengirim token, menukar aset, mencetak NFT, mengeksekusi perdagangan) akan segera dikonfirmasi.
  • Lebih Sedikit Kejutan: Konsistensi dari keadaan rantai lebih tinggi karena hal-hal seperti tail-forking, yang pada dasarnya adalah re-org, dihilangkan
  • Keadilan dan Transparansi: Peningkatan dalam konsensus secara tidak langsung berarti bahwa operasi rantai lebih adil. Tidak ada validator tunggal yang dapat dengan mudah menyensor transaksi atau bermain curang dalam pengurutan blok.

Kesimpulan

Untuk mengulangi, MonadBFT memperkenalkan empat inovasi inti di atas konsensus gaya HotStuff berpipa:

Resistensi Tail-Forking: MonadBFT adalah protokol BFT berpipa pertama yang menghilangkan serangan tail-forking​. Ini dicapai dengan menuntut pemimpin berikutnya untuk mengusulkan ulang blok yang terakhir disetujui jika pemimpin sebelumnya gagal, atau menunjukkan Sertifikat Tanpa-Endorsement (NEC) sebagai bukti bahwa blok tersebut kurang dukungan. Ini menjamin bahwa tidak ada blok yang didukung oleh supermayoritas akan ditinggalkan, melindungi imbalan pemimpin jujur dan mencegah reorgs jahat dan ekstraksi MEV melintasi blok.

Finalitas Spekulatif dalam Satu Putaran: Validator dapat mengonfirmasi sebuah blok setelah satu putaran komunikasi (satu proposal pemimpin dan suara), memberikan jaminan inklusi yang langsung kepada klien. Konfirmasi spekulatif ini hanya akan dibalik jika pemimpin melakukan ekivokasi (tindakan yang dapat dibuktikan dan dihukum), menjadikannya asumsi yang aman dalam praktik.

Responsif Optimis: Protokol beroperasi dengan kecepatan jaringan tanpa keterlambatan bawaan. Para pemimpin memajukan konsensus segera setelah suara yang diperlukan diterima, dan perubahan pandangan terjadi segera setelah kuorum waktu habis diamati, daripada menunggu interval waktu tetap. Desain responsif secara optimis ini meminimalkan waktu tunggu dan memaksimalkan throughput, sambil tetap mengatasi asinkroni dan kegagalan dengan kokoh saat terjadi.

Komunikasi Linear: Pada jalur bahagia (artinya pemimpin jujur), kompleksitas pesan dan otentikasi adalah linear dalam jumlah validator. MonadBFT mempertahankan pola komunikasi efisien HotStuff, menggunakan tanda tangan terkumpul dan siaran pemimpin ke validator yang sederhana, yang memungkinkan protokol untuk meluas hingga ratusan validator tanpa hambatan kinerja.

Disclaimer:

  1. Artikel ini dicetak ulang dari [michael_lwy]. Semua hak cipta adalah milik penulis asli [michael_lwy]. Jika ada keberatan terhadap cetak ulang ini, harap hubungiGate Belajartim, dan mereka akan menanganinya dengan cepat.
  2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
  3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.
* The information is not intended to be and does not constitute financial advice or any other recommendation of any sort offered or endorsed by Gate.io.
* This article may not be reproduced, transmitted or copied without referencing Gate.io. Contravention is an infringement of Copyright Act and may be subject to legal action.
Start Now
Sign up and get a
$100
Voucher!