Kerangka Shoal: Mengurangi latensi Bullshark di Aptos secara signifikan
Aptos labs baru-baru ini menyelesaikan dua masalah terbuka penting dalam DAG BFT, secara signifikan mengurangi latensi, dan untuk pertama kalinya menghilangkan kebutuhan akan timeout dalam protokol praktis deterministik. Secara keseluruhan, kerangka Shoal meningkatkan latensi Bullshark sebesar 40% dalam kondisi tanpa kegagalan, dan meningkatkan 80% dalam kondisi dengan kegagalan.
Shoal adalah sebuah mekanisme yang meningkatkan protokol konsensus berbasis Narwhal seperti DAG-Rider, Tusk, Bullshark ( melalui pipeline dan mekanisme reputasi pemimpin. Pipeline mengurangi latensi pengurutan DAG dengan memperkenalkan titik jangkar di setiap putaran, sementara reputasi pemimpin lebih lanjut memperbaiki latensi dengan memastikan titik jangkar terhubung dengan node validasi tercepat. Selain itu, reputasi pemimpin memungkinkan Shoal untuk memanfaatkan pembangunan DAG asinkron untuk menghilangkan semua skenario timeout. Ini memungkinkan Shoal untuk menyediakan fitur yang disebut respons universal, yang mencakup respons optimis yang biasanya diperlukan.
Inti dari Shoal sangat sederhana, yaitu menjalankan beberapa instance dari protokol dasar secara berurutan. Oleh karena itu, ketika diinstansiasi dengan Bullshark, kita mendapatkan sekelompok "ikan hiu" yang sedang melakukan perlombaan estafet.
![Penjelasan Detail Kerangka Shoal: Bagaimana Mengurangi Latensi Bullshark di Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivasi
Dalam upaya mencapai kinerja tinggi jaringan blockchain, orang-orang selalu memperhatikan Drop kompleksitas komunikasi. Namun, pendekatan ini tidak membawa peningkatan throughput yang signifikan. Misalnya, Hotstuff yang diimplementasikan dalam versi awal Diem hanya mencapai 3500 TPS, jauh di bawah target 100.000+ TPS.
Terobosan terbaru berasal dari pemahaman bahwa penyebaran data adalah kendala utama yang didasarkan pada protokol pemimpin, yang dapat mendapatkan manfaat melalui pararel. Sistem Narwhal memisahkan penyebaran data dari logika konsensus inti, mengusulkan sebuah arsitektur di mana semua validator secara bersamaan menyebarkan data, sementara komponen konsensus hanya mengurutkan sejumlah kecil metadata. Makalah Narwhal melaporkan throughput 160.000 TPS.
Dalam artikel sebelumnya, kami memperkenalkan Quorum Store - implementasi Narwhal kami, yang memisahkan penyebaran data dari konsensus, serta bagaimana kami menggunakannya untuk memperluas protokol konsensus saat ini, Jolteon. Jolteon adalah protokol berbasis pemimpin yang menggabungkan jalur cepat linier Tendermint dan perubahan pandangan gaya PBFT, yang dapat menurunkan latensi Hotstuff sebesar 33%. Namun, jelas bahwa protokol konsensus berbasis pemimpin tidak dapat memanfaatkan potensi throughput Narwhal sepenuhnya. Meskipun pemisahan penyebaran data dari konsensus, pemimpin Hotstuff/Jolteon masih dibatasi seiring dengan peningkatan throughput.
Oleh karena itu, kami memutuskan untuk menerapkan Bullshark di atas Narwhal DAG, yang merupakan protokol konsensus tanpa biaya komunikasi. Sayangnya, dibandingkan dengan Jolteon, struktur DAG yang mendukung Bullshark dengan throughput tinggi membawa biaya latensi sebesar 50%.
Artikel ini menjelaskan bagaimana Shoal berhasil menurunkan latensi Bullshark secara signifikan.
Latar Belakang DAG-BFT
Setiap simpul di Narwhal DAG terkait dengan sebuah putaran. Untuk memasuki putaran ke-r, validator harus terlebih dahulu mendapatkan n-f simpul yang termasuk dalam putaran ke-r-1. Setiap validator dapat menyiarkan satu simpul per putaran, dan setiap simpul harus merujuk setidaknya pada n-f simpul dari putaran sebelumnya. Karena asinkronisitas jaringan, validator yang berbeda mungkin mengamati pandangan lokal DAG yang berbeda pada titik waktu mana pun.
Salah satu atribut kunci dari DAG adalah tidak ambigu: jika dua node validasi memiliki vertex v yang sama dalam pandangan lokal DAG mereka, maka mereka memiliki sejarah kausal v yang sepenuhnya sama.
![Penjelasan Lengkap Kerangka Shoal: Bagaimana Mengurangi latensi Bullshark di Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Pengantar
Dapat mencapai konsensus tentang urutan total semua simpul di DAG tanpa biaya komunikasi tambahan. Untuk ini, validator dalam DAG-Rider, Tusk, dan Bullshark menginterpretasikan struktur DAG sebagai protokol konsensus, di mana simpul mewakili proposal dan tepi mewakili suara.
Meskipun logika interseksi kelompok pada struktur DAG berbeda, semua protokol konsensus berbasis Narwhal yang ada memiliki struktur berikut:
Titik jangkar yang dijadwalkan: Setiap beberapa putaran ) seperti dua putaran di Bullshark ( akan ada seorang pemimpin yang dijadwalkan, puncak pemimpin disebut sebagai titik jangkar.
Titik jangkar pengurutan: validator secara independen namun deterministik memutuskan titik jangkar mana yang harus diurutkan dan mana yang harus dilewati.
Urutan sejarah kausal: Validator memproses daftar titik jangkar yang terurut satu per satu, untuk setiap titik jangkar, mengurutkan semua titik sebelumnya yang tidak terurut dalam sejarah kausalnya berdasarkan aturan deterministik.
Kunci untuk memenuhi keamanan adalah memastikan bahwa pada langkah )2(, semua node validasi yang jujur membuat daftar titik jangkar yang terurut, sehingga semua daftar berbagi awalan yang sama. Di Shoal, kami membuat pengamatan berikut tentang semua protokol di atas:
Semua validator setuju pada titik jangkar yang terurut pertama.
Bullshark latensi
Latensi Bullshark tergantung pada jumlah putaran antara titik jangkar terurut dalam DAG. Meskipun versi sinkron Bullshark yang paling praktis memiliki latensi yang lebih baik dibandingkan versi asinkron, itu masih jauh dari yang terbaik.
Pertanyaan 1: Rata-rata latensi blok. Di Bullshark, setiap putaran genap memiliki titik jangkar, dan setiap titik puncak di putaran ganjil diartikan sebagai suara. Dalam kasus umum, diperlukan dua putaran DAG untuk mengurutkan titik jangkar, namun, titik puncak dalam sejarah sebab akibat titik jangkar memerlukan lebih banyak putaran untuk menunggu titik jangkar diurutkan. Dalam kasus umum, titik puncak di putaran ganjil memerlukan tiga putaran, sedangkan titik puncak non-titik jangkar di putaran genap memerlukan empat putaran.
Masalah 2: Kasus kegagalan latensi. Analisis latensi di atas berlaku untuk situasi tanpa kegagalan, sebaliknya, jika pemimpin dalam satu putaran gagal menyebarkan titik jangkar dengan cukup cepat, maka titik jangkar tidak dapat diurutkan ) sehingga dilewati (, oleh karena itu semua simpul yang tidak terurut di beberapa putaran sebelumnya harus menunggu titik jangkar berikutnya diurutkan. Ini akan secara signifikan menurunkan kinerja jaringan replikasi geografis, terutama karena Bullshark menggunakan waktu tunggu untuk menunggu pemimpin.
![Penjelasan detail Shoal Framework: Bagaimana cara mengurangi latensi Bullshark di Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Kerangka Shoal
Shoal menyelesaikan dua masalah latensi ini, dengan meningkatkan Bullshark) atau protokol BFT berbasis Narwhal lainnya( melalui pipa, memungkinkan adanya satu titik jangkar di setiap putaran, dan mengurangi latensi semua simpul non-jangkar di DAG menjadi tiga putaran. Shoal juga memperkenalkan mekanisme reputasi pemimpin tanpa biaya di DAG, yang membuat pemilihan cenderung berpihak pada pemimpin yang cepat.
Tantangan
Dalam konteks protokol DAG, pipa dan reputasi pemimpin dianggap sebagai masalah yang sulit, alasannya sebagai berikut:
Upaya sebelumnya untuk memodifikasi logika inti Bullshark tampaknya pada dasarnya tidak mungkin.
Reputasi pemimpin diperkenalkan dalam DiemBFT dan dipformalkan di Carousel, berdasarkan kinerja masa lalu validator untuk secara dinamis memilih pemimpin masa depan ide jangkar di Bullshark ). Meskipun adanya perbedaan dalam identitas pemimpin tidak melanggar keamanan dalam protokol ini, di Bullshark, hal ini dapat menyebabkan urutan yang sangat berbeda, yang mengarah pada inti masalah, yaitu memilih jangkar secara dinamis dan deterministik diperlukan untuk menyelesaikan konsensus, dan validator perlu mencapai kesepakatan tentang sejarah yang terurut untuk memilih jangkar masa depan.
Sebagai bukti tingkat kesulitan masalah, kami memperhatikan bahwa implementasi Bullshark, termasuk yang saat ini di lingkungan produksi, tidak mendukung fitur-fitur ini.
Protokol
Meskipun ada tantangan di atas, kenyataannya solusi tersembunyi dalam kesederhanaan.
Di Shoal, kami bergantung pada kemampuan untuk melakukan komputasi lokal di atas DAG, dan mewujudkan kemampuan untuk menyimpan dan menginterpretasikan kembali informasi dari beberapa putaran sebelumnya. Dengan semua validator setuju pada wawasan inti dari titik jangkar terurut pertama, Shoal secara berurutan menggabungkan beberapa instansi Bullshark untuk memprosesnya secara paralel, sehingga ( titik jangkar terurut pertama adalah titik peralihan dari instansi, serta ) sejarah kausal dari titik jangkar digunakan untuk menghitung reputasi pemimpin.
Jalur Produksi
V yang memetakan putaran ke pemimpin. Shoal menjalankan instance Bullshark satu per satu, sehingga untuk setiap instance, anchor ditentukan sebelumnya oleh pemetaan F. Setiap instance mengurutkan sebuah anchor, yang akan memicu peralihan ke instance berikutnya.
Pada awalnya, Shoal meluncurkan instance pertama Bullshark di putaran pertama DAG dan menjalankannya sampai titik jangkar terurut pertama ditentukan, misalnya di putaran r. Semua validator setuju dengan titik jangkar ini. Oleh karena itu, semua validator dapat secara pasti setuju untuk menafsirkan ulang DAG mulai dari putaran r+1. Shoal hanya meluncurkan instance Bullshark baru di putaran r+1.
Dalam skenario terbaik, ini memungkinkan Shoal untuk mengurutkan sebuah jangkar di setiap putaran. Jangkar pada putaran pertama diurutkan berdasarkan instance pertama. Kemudian, Shoal memulai instance baru di putaran kedua, yang memiliki jangkar sendiri, jangkar tersebut diurutkan oleh instance itu, lalu, instance baru lainnya mengurutkan jangkar di putaran ketiga, dan proses ini berlanjut.
Reputasi Pemimpin
Selama periode urutan Bullshark, melewatkan titik jangkar akan meningkatkan latensi. Dalam hal ini, teknologi pipeline tidak dapat berbuat apa-apa, karena tidak mungkin memulai instans baru sebelum urutan titik jangkar dari instans sebelumnya. Shoal memastikan bahwa pemimpin yang sesuai untuk menangani titik jangkar yang hilang kemungkinan besar tidak akan dipilih di masa depan dengan memberikan skor kepada setiap node validasi berdasarkan sejarah aktivitas terbaru mereka menggunakan mekanisme reputasi. Validator yang merespons dan berpartisipasi dalam protokol akan mendapatkan skor tinggi, sebaliknya, node validasi akan diberikan skor rendah, karena mungkin mengalami keruntuhan, lambat, atau berbuat jahat.
Konsepnya adalah untuk secara deterministik menghitung kembali pemetaan F yang telah ditentukan dari putaran ke pemimpin setiap kali pembaruan skor dilakukan, yang menguntungkan pemimpin dengan skor lebih tinggi. Agar para validator dapat mencapai konsensus pada pemetaan baru, mereka harus mencapai konsensus pada skor, sehingga mencapai konsensus pada sejarah yang digunakan untuk menurunkan skor.
Di Shoal, pipeline dan reputasi pemimpin dapat secara alami digabungkan, karena keduanya menggunakan teknologi inti yang sama, yaitu menafsirkan ulang DAG setelah mencapai konsensus pada titik jangkar terurut pertama.
Sebenarnya, satu-satunya perbedaan adalah, setelah mengurutkan titik jangkar di putaran ke-r, validator hanya perlu menghitung pemetaan baru F' mulai dari putaran ke-r+1 berdasarkan sejarah kausal dari titik jangkar yang terurut di putaran ke-r. Kemudian, node validator mulai menggunakan fungsi pemilihan titik jangkar yang diperbarui F' untuk melaksanakan instance baru Bullshark mulai dari putaran ke-r+1.
Tidak ada lagi waktu habis
Timeout memainkan peran yang sangat penting dalam semua implementasi BFT sinkronisasi deterministik berbasis pemimpin. Namun, kompleksitas yang mereka perkenalkan meningkatkan jumlah status internal yang perlu dikelola dan diamati, yang meningkatkan kompleksitas proses debugging, dan memerlukan lebih banyak teknik observabilitas.
Waktu habis juga akan secara signifikan meningkatkan latensi, karena sangat penting untuk mengonfigurasi mereka dengan tepat, dan biasanya perlu disesuaikan secara dinamis, karena sangat bergantung pada lingkungan ( jaringan ). Sebelum beralih ke pemimpin berikutnya, protokol akan membayar penalti latensi waktu habis penuh untuk pemimpin yang mengalami kegagalan. Oleh karena itu, pengaturan waktu habis tidak boleh terlalu konservatif, tetapi jika waktu habis terlalu pendek, protokol mungkin akan melewatkan pemimpin yang baik. Misalnya, kami mengamati bahwa dalam kondisi beban tinggi, pemimpin di Jolteon/Hotstuff kewalahan, dan waktu habis telah berakhir sebelum mereka mendorong kemajuan.
Sayangnya, berdasarkan protokol pemimpin ( seperti Hotstuff
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
16 Suka
Hadiah
16
10
Posting ulang
Bagikan
Komentar
0/400
TokenomicsTrapper
· 07-16 23:24
rokok klasik vc asap dan cermin... 40% tidak berarti apa-apa jika latensi dasar jelek sejujurnya
Lihat AsliBalas0
rekt_but_resilient
· 07-16 17:01
latensi turun delapan puluh persen? Mau To da moon!
Lihat AsliBalas0
NestedFox
· 07-16 09:09
Perbaikan delapan puluh derajat luar biasa
Lihat AsliBalas0
Blockwatcher9000
· 07-15 13:37
Masih mengalahkan latensi, ya! Kuat!
Lihat AsliBalas0
GasFeePhobia
· 07-14 02:57
40 tidak 80 terlalu hebat ya? Efeknya bisa ya
Lihat AsliBalas0
MEVHunterBearish
· 07-14 02:55
Ini ada gunanya? Kita hanya bullish dan tidak turun.
Lihat AsliBalas0
WalletsWatcher
· 07-14 02:55
Ah, ini akhirnya berhasil mengatasi latensi.
Lihat AsliBalas0
CryptoFortuneTeller
· 07-14 02:45
Beli aptos beli aptos cepat habis semua
Lihat AsliBalas0
MetamaskMechanic
· 07-14 02:43
Login, ada yang bermain latensi optimasi lagi.
Lihat AsliBalas0
LeverageAddict
· 07-14 02:42
Bullshark bull ah bisa berlari lebih cepat sekarang.
Kerangka Shoal secara signifikan menurunkan latensi Bullshark di Aptos, mewujudkan konsensus deterministik tanpa batas waktu.
Kerangka Shoal: Mengurangi latensi Bullshark di Aptos secara signifikan
Aptos labs baru-baru ini menyelesaikan dua masalah terbuka penting dalam DAG BFT, secara signifikan mengurangi latensi, dan untuk pertama kalinya menghilangkan kebutuhan akan timeout dalam protokol praktis deterministik. Secara keseluruhan, kerangka Shoal meningkatkan latensi Bullshark sebesar 40% dalam kondisi tanpa kegagalan, dan meningkatkan 80% dalam kondisi dengan kegagalan.
Shoal adalah sebuah mekanisme yang meningkatkan protokol konsensus berbasis Narwhal seperti DAG-Rider, Tusk, Bullshark ( melalui pipeline dan mekanisme reputasi pemimpin. Pipeline mengurangi latensi pengurutan DAG dengan memperkenalkan titik jangkar di setiap putaran, sementara reputasi pemimpin lebih lanjut memperbaiki latensi dengan memastikan titik jangkar terhubung dengan node validasi tercepat. Selain itu, reputasi pemimpin memungkinkan Shoal untuk memanfaatkan pembangunan DAG asinkron untuk menghilangkan semua skenario timeout. Ini memungkinkan Shoal untuk menyediakan fitur yang disebut respons universal, yang mencakup respons optimis yang biasanya diperlukan.
Inti dari Shoal sangat sederhana, yaitu menjalankan beberapa instance dari protokol dasar secara berurutan. Oleh karena itu, ketika diinstansiasi dengan Bullshark, kita mendapatkan sekelompok "ikan hiu" yang sedang melakukan perlombaan estafet.
![Penjelasan Detail Kerangka Shoal: Bagaimana Mengurangi Latensi Bullshark di Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivasi
Dalam upaya mencapai kinerja tinggi jaringan blockchain, orang-orang selalu memperhatikan Drop kompleksitas komunikasi. Namun, pendekatan ini tidak membawa peningkatan throughput yang signifikan. Misalnya, Hotstuff yang diimplementasikan dalam versi awal Diem hanya mencapai 3500 TPS, jauh di bawah target 100.000+ TPS.
Terobosan terbaru berasal dari pemahaman bahwa penyebaran data adalah kendala utama yang didasarkan pada protokol pemimpin, yang dapat mendapatkan manfaat melalui pararel. Sistem Narwhal memisahkan penyebaran data dari logika konsensus inti, mengusulkan sebuah arsitektur di mana semua validator secara bersamaan menyebarkan data, sementara komponen konsensus hanya mengurutkan sejumlah kecil metadata. Makalah Narwhal melaporkan throughput 160.000 TPS.
Dalam artikel sebelumnya, kami memperkenalkan Quorum Store - implementasi Narwhal kami, yang memisahkan penyebaran data dari konsensus, serta bagaimana kami menggunakannya untuk memperluas protokol konsensus saat ini, Jolteon. Jolteon adalah protokol berbasis pemimpin yang menggabungkan jalur cepat linier Tendermint dan perubahan pandangan gaya PBFT, yang dapat menurunkan latensi Hotstuff sebesar 33%. Namun, jelas bahwa protokol konsensus berbasis pemimpin tidak dapat memanfaatkan potensi throughput Narwhal sepenuhnya. Meskipun pemisahan penyebaran data dari konsensus, pemimpin Hotstuff/Jolteon masih dibatasi seiring dengan peningkatan throughput.
Oleh karena itu, kami memutuskan untuk menerapkan Bullshark di atas Narwhal DAG, yang merupakan protokol konsensus tanpa biaya komunikasi. Sayangnya, dibandingkan dengan Jolteon, struktur DAG yang mendukung Bullshark dengan throughput tinggi membawa biaya latensi sebesar 50%.
Artikel ini menjelaskan bagaimana Shoal berhasil menurunkan latensi Bullshark secara signifikan.
Latar Belakang DAG-BFT
Setiap simpul di Narwhal DAG terkait dengan sebuah putaran. Untuk memasuki putaran ke-r, validator harus terlebih dahulu mendapatkan n-f simpul yang termasuk dalam putaran ke-r-1. Setiap validator dapat menyiarkan satu simpul per putaran, dan setiap simpul harus merujuk setidaknya pada n-f simpul dari putaran sebelumnya. Karena asinkronisitas jaringan, validator yang berbeda mungkin mengamati pandangan lokal DAG yang berbeda pada titik waktu mana pun.
Salah satu atribut kunci dari DAG adalah tidak ambigu: jika dua node validasi memiliki vertex v yang sama dalam pandangan lokal DAG mereka, maka mereka memiliki sejarah kausal v yang sepenuhnya sama.
![Penjelasan Lengkap Kerangka Shoal: Bagaimana Mengurangi latensi Bullshark di Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Pengantar
Dapat mencapai konsensus tentang urutan total semua simpul di DAG tanpa biaya komunikasi tambahan. Untuk ini, validator dalam DAG-Rider, Tusk, dan Bullshark menginterpretasikan struktur DAG sebagai protokol konsensus, di mana simpul mewakili proposal dan tepi mewakili suara.
Meskipun logika interseksi kelompok pada struktur DAG berbeda, semua protokol konsensus berbasis Narwhal yang ada memiliki struktur berikut:
Titik jangkar yang dijadwalkan: Setiap beberapa putaran ) seperti dua putaran di Bullshark ( akan ada seorang pemimpin yang dijadwalkan, puncak pemimpin disebut sebagai titik jangkar.
Titik jangkar pengurutan: validator secara independen namun deterministik memutuskan titik jangkar mana yang harus diurutkan dan mana yang harus dilewati.
Urutan sejarah kausal: Validator memproses daftar titik jangkar yang terurut satu per satu, untuk setiap titik jangkar, mengurutkan semua titik sebelumnya yang tidak terurut dalam sejarah kausalnya berdasarkan aturan deterministik.
Kunci untuk memenuhi keamanan adalah memastikan bahwa pada langkah )2(, semua node validasi yang jujur membuat daftar titik jangkar yang terurut, sehingga semua daftar berbagi awalan yang sama. Di Shoal, kami membuat pengamatan berikut tentang semua protokol di atas:
Semua validator setuju pada titik jangkar yang terurut pertama.
Bullshark latensi
Latensi Bullshark tergantung pada jumlah putaran antara titik jangkar terurut dalam DAG. Meskipun versi sinkron Bullshark yang paling praktis memiliki latensi yang lebih baik dibandingkan versi asinkron, itu masih jauh dari yang terbaik.
Pertanyaan 1: Rata-rata latensi blok. Di Bullshark, setiap putaran genap memiliki titik jangkar, dan setiap titik puncak di putaran ganjil diartikan sebagai suara. Dalam kasus umum, diperlukan dua putaran DAG untuk mengurutkan titik jangkar, namun, titik puncak dalam sejarah sebab akibat titik jangkar memerlukan lebih banyak putaran untuk menunggu titik jangkar diurutkan. Dalam kasus umum, titik puncak di putaran ganjil memerlukan tiga putaran, sedangkan titik puncak non-titik jangkar di putaran genap memerlukan empat putaran.
Masalah 2: Kasus kegagalan latensi. Analisis latensi di atas berlaku untuk situasi tanpa kegagalan, sebaliknya, jika pemimpin dalam satu putaran gagal menyebarkan titik jangkar dengan cukup cepat, maka titik jangkar tidak dapat diurutkan ) sehingga dilewati (, oleh karena itu semua simpul yang tidak terurut di beberapa putaran sebelumnya harus menunggu titik jangkar berikutnya diurutkan. Ini akan secara signifikan menurunkan kinerja jaringan replikasi geografis, terutama karena Bullshark menggunakan waktu tunggu untuk menunggu pemimpin.
![Penjelasan detail Shoal Framework: Bagaimana cara mengurangi latensi Bullshark di Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Kerangka Shoal
Shoal menyelesaikan dua masalah latensi ini, dengan meningkatkan Bullshark) atau protokol BFT berbasis Narwhal lainnya( melalui pipa, memungkinkan adanya satu titik jangkar di setiap putaran, dan mengurangi latensi semua simpul non-jangkar di DAG menjadi tiga putaran. Shoal juga memperkenalkan mekanisme reputasi pemimpin tanpa biaya di DAG, yang membuat pemilihan cenderung berpihak pada pemimpin yang cepat.
Tantangan
Dalam konteks protokol DAG, pipa dan reputasi pemimpin dianggap sebagai masalah yang sulit, alasannya sebagai berikut:
Upaya sebelumnya untuk memodifikasi logika inti Bullshark tampaknya pada dasarnya tidak mungkin.
Reputasi pemimpin diperkenalkan dalam DiemBFT dan dipformalkan di Carousel, berdasarkan kinerja masa lalu validator untuk secara dinamis memilih pemimpin masa depan ide jangkar di Bullshark ). Meskipun adanya perbedaan dalam identitas pemimpin tidak melanggar keamanan dalam protokol ini, di Bullshark, hal ini dapat menyebabkan urutan yang sangat berbeda, yang mengarah pada inti masalah, yaitu memilih jangkar secara dinamis dan deterministik diperlukan untuk menyelesaikan konsensus, dan validator perlu mencapai kesepakatan tentang sejarah yang terurut untuk memilih jangkar masa depan.
Sebagai bukti tingkat kesulitan masalah, kami memperhatikan bahwa implementasi Bullshark, termasuk yang saat ini di lingkungan produksi, tidak mendukung fitur-fitur ini.
Protokol
Meskipun ada tantangan di atas, kenyataannya solusi tersembunyi dalam kesederhanaan.
Di Shoal, kami bergantung pada kemampuan untuk melakukan komputasi lokal di atas DAG, dan mewujudkan kemampuan untuk menyimpan dan menginterpretasikan kembali informasi dari beberapa putaran sebelumnya. Dengan semua validator setuju pada wawasan inti dari titik jangkar terurut pertama, Shoal secara berurutan menggabungkan beberapa instansi Bullshark untuk memprosesnya secara paralel, sehingga ( titik jangkar terurut pertama adalah titik peralihan dari instansi, serta ) sejarah kausal dari titik jangkar digunakan untuk menghitung reputasi pemimpin.
Jalur Produksi
V yang memetakan putaran ke pemimpin. Shoal menjalankan instance Bullshark satu per satu, sehingga untuk setiap instance, anchor ditentukan sebelumnya oleh pemetaan F. Setiap instance mengurutkan sebuah anchor, yang akan memicu peralihan ke instance berikutnya.
Pada awalnya, Shoal meluncurkan instance pertama Bullshark di putaran pertama DAG dan menjalankannya sampai titik jangkar terurut pertama ditentukan, misalnya di putaran r. Semua validator setuju dengan titik jangkar ini. Oleh karena itu, semua validator dapat secara pasti setuju untuk menafsirkan ulang DAG mulai dari putaran r+1. Shoal hanya meluncurkan instance Bullshark baru di putaran r+1.
Dalam skenario terbaik, ini memungkinkan Shoal untuk mengurutkan sebuah jangkar di setiap putaran. Jangkar pada putaran pertama diurutkan berdasarkan instance pertama. Kemudian, Shoal memulai instance baru di putaran kedua, yang memiliki jangkar sendiri, jangkar tersebut diurutkan oleh instance itu, lalu, instance baru lainnya mengurutkan jangkar di putaran ketiga, dan proses ini berlanjut.
Reputasi Pemimpin
Selama periode urutan Bullshark, melewatkan titik jangkar akan meningkatkan latensi. Dalam hal ini, teknologi pipeline tidak dapat berbuat apa-apa, karena tidak mungkin memulai instans baru sebelum urutan titik jangkar dari instans sebelumnya. Shoal memastikan bahwa pemimpin yang sesuai untuk menangani titik jangkar yang hilang kemungkinan besar tidak akan dipilih di masa depan dengan memberikan skor kepada setiap node validasi berdasarkan sejarah aktivitas terbaru mereka menggunakan mekanisme reputasi. Validator yang merespons dan berpartisipasi dalam protokol akan mendapatkan skor tinggi, sebaliknya, node validasi akan diberikan skor rendah, karena mungkin mengalami keruntuhan, lambat, atau berbuat jahat.
Konsepnya adalah untuk secara deterministik menghitung kembali pemetaan F yang telah ditentukan dari putaran ke pemimpin setiap kali pembaruan skor dilakukan, yang menguntungkan pemimpin dengan skor lebih tinggi. Agar para validator dapat mencapai konsensus pada pemetaan baru, mereka harus mencapai konsensus pada skor, sehingga mencapai konsensus pada sejarah yang digunakan untuk menurunkan skor.
Di Shoal, pipeline dan reputasi pemimpin dapat secara alami digabungkan, karena keduanya menggunakan teknologi inti yang sama, yaitu menafsirkan ulang DAG setelah mencapai konsensus pada titik jangkar terurut pertama.
Sebenarnya, satu-satunya perbedaan adalah, setelah mengurutkan titik jangkar di putaran ke-r, validator hanya perlu menghitung pemetaan baru F' mulai dari putaran ke-r+1 berdasarkan sejarah kausal dari titik jangkar yang terurut di putaran ke-r. Kemudian, node validator mulai menggunakan fungsi pemilihan titik jangkar yang diperbarui F' untuk melaksanakan instance baru Bullshark mulai dari putaran ke-r+1.
Tidak ada lagi waktu habis
Timeout memainkan peran yang sangat penting dalam semua implementasi BFT sinkronisasi deterministik berbasis pemimpin. Namun, kompleksitas yang mereka perkenalkan meningkatkan jumlah status internal yang perlu dikelola dan diamati, yang meningkatkan kompleksitas proses debugging, dan memerlukan lebih banyak teknik observabilitas.
Waktu habis juga akan secara signifikan meningkatkan latensi, karena sangat penting untuk mengonfigurasi mereka dengan tepat, dan biasanya perlu disesuaikan secara dinamis, karena sangat bergantung pada lingkungan ( jaringan ). Sebelum beralih ke pemimpin berikutnya, protokol akan membayar penalti latensi waktu habis penuh untuk pemimpin yang mengalami kegagalan. Oleh karena itu, pengaturan waktu habis tidak boleh terlalu konservatif, tetapi jika waktu habis terlalu pendek, protokol mungkin akan melewatkan pemimpin yang baik. Misalnya, kami mengamati bahwa dalam kondisi beban tinggi, pemimpin di Jolteon/Hotstuff kewalahan, dan waktu habis telah berakhir sebelum mereka mendorong kemajuan.
Sayangnya, berdasarkan protokol pemimpin ( seperti Hotstuff