Mengurangi keterlambatan Bullshark di Aptos: Penjelasan kerangka Shoal
Aptos labs telah menyelesaikan dua masalah terbuka penting dalam DAG BFT, secara signifikan mengurangi latensi, dan untuk pertama kalinya menghilangkan kebutuhan untuk jeda dalam protokol nyata yang deterministik. Secara keseluruhan, latensi Bullshark telah ditingkatkan sebesar 40% dalam kondisi tanpa kegagalan, dan 80% dalam kondisi dengan kegagalan.
Kerangka Shoal memperkuat protokol konsensus berbasis Narwhal ( melalui pipeline dan mekanisme reputasi pemimpin seperti DAG-Rider, Tusk, Bullshark ). Pipeline memperkenalkan satu titik jangkar setiap putaran untuk mengurangi penundaan pengurutan DAG, reputasi pemimpin memastikan titik jangkar terkait dengan node validasi tercepat, yang lebih lanjut meningkatkan penundaan. Selain itu, reputasi pemimpin memungkinkan Shoal untuk memanfaatkan konstruksi DAG asinkron untuk menghilangkan waktu habis dalam semua skenario, sehingga mencapai sifat respons universal.
Teknologi Shoal sangat sederhana, menjalankan beberapa instance protokol dasar secara berurutan. Ketika diinstansiasi dengan Bullshark, itu seperti sekumpulan "ikan hiu" yang sedang melakukan estafet.
Latar Belakang
Dalam mengejar kinerja tinggi jaringan blockchain, orang-orang selalu memperhatikan pengurangan kompleksitas komunikasi, tetapi ini tidak menyebabkan peningkatan throughput yang signifikan. Misalnya, Hotstuff yang diimplementasikan di Diem awal hanya mencapai 3500 TPS, jauh di bawah target 100k+ TPS.
Peningkatan baru-baru ini berasal dari pemahaman bahwa penyebaran data adalah hambatan utama yang didasarkan pada protokol pemimpin, dan dapat diuntungkan dari paralelisasi. Sistem Narwhal memisahkan penyebaran data dari logika konsensus inti, di mana semua validator secara bersamaan menyebarkan data, dan komponen konsensus hanya mengurutkan sejumlah kecil metadata. Makalah Narwhal melaporkan throughput 160.000 TPS.
Aptos sebelumnya memperkenalkan Quorum Store, yaitu implementasi Narwhal, yang memisahkan penyebaran data dari konsensus, dan digunakan untuk memperluas protokol konsensus saat ini Jolteon. Jolteon menggabungkan jalur cepat linier Tendermint dan perubahan tampilan gaya PBFT, mengurangi latensi Hotstuff sebesar 33%. Namun, protokol konsensus berbasis pemimpin tidak dapat memanfaatkan potensi throughput Narwhal secara maksimal.
Oleh karena itu, Aptos memutuskan untuk menerapkan Bullshark di atas Narwhal DAG, sebuah protokol konsensus tanpa biaya komunikasi. Sayangnya, struktur DAG yang mendukung Bullshark dengan throughput tinggi membawa biaya latensi sebesar 50%.
Artikel ini menjelaskan bagaimana Shoal secara signifikan mengurangi latensi Bullshark.
Latar Belakang DAG-BFT
Setiap simpul dalam Narwhal DAG terkait dengan sebuah putaran. Pada putaran ke-r, validator harus memperoleh n-f simpul dari putaran ke-r-1. Setiap validator dapat menyiarkan satu simpul per putaran, dan setiap simpul harus merujuk pada setidaknya n-f simpul dari putaran sebelumnya. Karena asinkronisitas jaringan, validator yang berbeda mungkin mengamati pandangan lokal DAG yang berbeda.
Salah satu atribut kunci DAG adalah tidak ambigu: jika dua node validasi memiliki titik v yang sama dalam tampilan DAG lokal mereka, maka mereka memiliki sejarah kausal v yang sepenuhnya sama.
Urutan Total
Dapat mencapai konsensus tentang urutan total semua simpul di DAG tanpa biaya komunikasi tambahan. Validator di 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 yang berbasis Narwhal memiliki struktur berikut:
Titik jangkar yang ditentukan: Setiap beberapa putaran ada seorang pemimpin yang telah ditentukan sebelumnya, yang puncaknya disebut titik jangkar.
Titik urut: Validator secara independen tetapi dengan kepastian memutuskan titik mana yang diurutkan dan mana yang dilewati.
Sejarah kausal terurut: Validasi memproses daftar titik jangkar yang terurut satu per satu, mengurutkan simpul yang tidak terurut sebelumnya dalam sejarah kausal setiap titik jangkar.
Kunci untuk memenuhi keamanan adalah memastikan bahwa dalam langkah (2), semua daftar titik jangkar terurut yang dibuat oleh node validasi yang jujur berbagi awalan yang sama. Di Shoal, kami mengamati:
Semua validator setuju pada titik jangkar terurut pertama.
Bullshark Tertunda
Keterlambatan Bullshark tergantung pada jumlah putaran antara titik jangkar yang terurut di dalam DAG. Versi sinkron sebagian memiliki keterlambatan yang lebih baik dibandingkan dengan versi asinkron, tetapi masih tidak optimal.
Pertanyaan 1: Rata-rata keterlambatan blok. Dalam Bullshark, setiap putaran genap memiliki satu titik jangkar, dan puncak putaran ganjil diartikan sebagai suara. Dalam kasus umum, dibutuhkan dua putaran DAG untuk mengurutkan titik jangkar, tetapi puncak dalam sejarah kausal titik jangkar memerlukan lebih banyak putaran untuk menunggu titik jangkar diurutkan. Dalam kasus umum, puncak putaran ganjil memerlukan tiga putaran, dan puncak bukan jangkar putaran genap memerlukan empat putaran.
Pertanyaan 2: Keterlambatan dalam situasi kegagalan. Jika seorang pemimpin tidak berhasil mengumumkan titik jangkar tepat waktu, maka tidak dapat dilakukan pengurutan ( yang dilewati ), semua titik yang belum terurut dari beberapa putaran sebelumnya harus menunggu titik jangkar berikutnya untuk diurutkan. Ini secara signifikan mengurangi kinerja jaringan replikasi geografis, terutama karena Bullshark menggunakan waktu tunggu untuk pemimpin.
Kerangka Shoal
Shoal meningkatkan Bullshark( atau protokol BFT berbasis Narwhal) melalui jalur aliran, memungkinkan satu titik jangkar setiap putaran, mengurangi latensi semua titik puncak non-jangkar dalam DAG menjadi tiga putaran. Shoal juga memperkenalkan mekanisme reputasi pemimpin tanpa biaya dalam DAG, yang condong untuk memilih pemimpin yang cepat.
Tantangan
Dalam protokol DAG, masalah pipeline 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 diformalkan dalam Carousel, memilih pemimpin masa depan secara dinamis berdasarkan kinerja masa lalu para validator (Jangkar di Bullshark ). Meskipun perbedaan identitas pemimpin tidak melanggar keamanan protokol ini, hal itu dapat menyebabkan urutan yang sangat berbeda di Bullshark, mengangkat inti masalah: memilih jangkar roda secara dinamis dan deterministik adalah penting untuk menyelesaikan konsensus, para validator perlu mencapai kesepakatan tentang sejarah terurut untuk memilih jangkar masa depan.
Sebagai bukti kesulitan masalah, implementasi Bullshark ( termasuk ) di lingkungan produksi saat ini tidak mendukung fitur-fitur ini.
Protokol
Meskipun ada tantangan di atas, solusi tersembunyi dalam kesederhanaan.
Shoal bergantung pada kemampuan untuk melakukan perhitungan lokal di atas DAG, mewujudkan kemampuan untuk menyimpan dan menafsirkan kembali informasi dari putaran sebelumnya. Berdasarkan wawasan bahwa semua validator setuju pada titik jangkar terurut pertama, Shoal menggabungkan beberapa contoh Bullshark secara berurutan untuk pemrosesan pipeline, menjadikan ( titik pergantian untuk contoh pada titik jangkar terurut pertama, dan ) sejarah kausal titik jangkar digunakan untuk menghitung reputasi pemimpin.
( Jalur Produksi
V yang memetakan putaran ke pemimpin. Shoal menjalankan instansi Bullshark secara berurutan, di mana jangkar setiap instansi ditentukan sebelumnya oleh pemetaan F. Setiap instansi mengurutkan satu jangkar, memicu perpindahan ke instansi berikutnya.
Pada awalnya, Shoal meluncurkan instansi pertama Bullshark dalam putaran pertama DAG, berjalan hingga titik jangkar terurut pertama ) ditentukan seperti pada putaran r ###. Semua validator setuju dengan titik jangkar ini, sehingga dapat disepakati dengan pasti untuk menafsirkan ulang DAG dari putaran r+1. Shoal meluncurkan instansi Bullshark baru pada putaran r+1.
Dalam kondisi terbaik, ini memungkinkan Shoal untuk menyortir satu jangkar setiap putaran. Jangkar titik pertama disortir oleh instansi pertama. Kemudian, Shoal memulai instansi baru di putaran kedua, yang memiliki jangkar titiknya sendiri dan disortir oleh instansi tersebut, kemudian instansi baru lainnya menyortir jangkar titik di putaran ketiga, dan seterusnya.
( Kredibilitas Pemimpin
Ketika Bullshark melewatkan titik jangkar, keterlambatan meningkat. Dalam kasus ini, jalur tidak dapat berfungsi, karena tidak mungkin memulai instance baru sebelum titik jangkar instance sebelumnya diurutkan. Shoal memberikan skor untuk setiap node validasi melalui mekanisme reputasi, memastikan bahwa pemimpin yang sesuai untuk menangani titik jangkar yang hilang kemungkinan besar tidak akan dipilih di masa depan berdasarkan sejarah aktivitas terakhir mereka. Validator yang merespons dan berpartisipasi dalam protokol mendapatkan skor tinggi, jika tidak, mereka diberikan skor rendah ) dapat macet, lambat, atau berbuat jahat ###.
Ide adalah untuk secara deterministik menghitung ulang pemetaan yang telah ditentukan F dari putaran ke pemimpin setiap kali skor diperbarui, yang menguntungkan pemimpin dengan skor tinggi. Agar para validator mencapai konsensus pada pemetaan baru, mereka harus mencapai konsensus pada skor, sehingga mencapai kesepakatan pada sejarah yang digunakan untuk menghasilkan skor.
Di Shoal, alur kerja dan reputasi pemimpin secara alami terintegrasi, karena mereka menggunakan teknologi inti yang sama: menafsirkan kembali DAG setelah mencapai konsensus pada titik jangkar berurutan pertama.
Satu-satunya perbedaan adalah, setelah urutan titik acuan di putaran ke-r, validator menghitung pemetaan baru F' mulai dari putaran ke-r+1 berdasarkan sejarah kausal titik acuan terurut di putaran ke-r. Kemudian, node validator mulai dari putaran ke-r+1 menggunakan fungsi pemilihan titik acuan yang diperbarui F' untuk menjalankan instance baru Bullshark.
( Tidak perlu lebih banyak waktu habis
Keterlambatan sangat penting dalam semua implementasi BFT yang berbasis pemimpin yang deterministik. Namun, kompleksitas yang mereka perkenalkan meningkatkan jumlah status internal yang perlu dikelola dan dipantau, meningkatkan kompleksitas proses debugging, yang membutuhkan lebih banyak teknik observabilitas.
Timeout juga secara signifikan meningkatkan latensi, karena konfigurasi yang tepat sangat penting, biasanya memerlukan penyesuaian dinamis, sangat bergantung pada lingkungan ) jaringan ###. Sebelum beralih ke pemimpin berikutnya, protokol membayar penalti latensi timeout penuh untuk pemimpin yang bermasalah. Oleh karena itu, pengaturan timeout tidak boleh terlalu konservatif, tetapi jika terlalu pendek, protokol mungkin melewatkan pemimpin yang baik. Misalnya, kami mengamati bahwa di bawah beban tinggi, pemimpin dalam Jolteon/Hotstuff tidak dapat menangani beban, dan timeout sudah habis sebelum kemajuan dapat didorong.
Sayangnya, protokol kepemimpinan ( seperti Hotstuff dan Jolteon) pada dasarnya memerlukan timeout untuk memastikan bahwa protokol dapat melanjutkan setiap kali pemimpin gagal. Tanpa timeout, bahkan pemimpin yang mengalami keruntuhan mungkin akan menghentikan protokol selamanya. Karena selama periode asinkron tidak mungkin untuk membedakan antara pemimpin yang gagal dan yang lambat, timeout dapat menyebabkan node verifikasi melihat perubahan semua pemimpin tanpa adanya aktivitas konsensus.
Di Bullshark, waktu habis digunakan untuk konstruksi DAG, untuk memastikan bahwa pemimpin yang jujur menambahkan titik jangkar ke DAG dengan kecepatan yang cukup cepat selama sinkronisasi, agar dapat diurutkan.
Kami mengamati bahwa konstruksi DAG menyediakan "jam" untuk memperkirakan kecepatan jaringan. Tanpa jeda, selama n-f validator yang jujur terus menambahkan simpul ke DAG, putaran akan terus maju. Meskipun Bullshark mungkin tidak dapat mengurutkan ( dengan kecepatan jaringan karena masalah pemimpin ), DAG tetap tumbuh dengan kecepatan jaringan, meskipun beberapa pemimpin bermasalah atau jaringan tidak sinkron. Pada akhirnya, ketika pemimpin tanpa kesalahan cukup cepat untuk menyiarkan titik jangkar, seluruh sejarah kausal titik jangkar akan diurutkan.
Dalam penilaian, kami membandingkan Bullshark dalam situasi dengan dan tanpa waktu habis:
Pemimpin cepat, setidaknya lebih cepat daripada validator lainnya. Dalam kasus ini, kedua metode memberikan latensi yang sama, karena jangkar terurut dan tidak menggunakan timeout.
Pemimpin yang salah, dalam hal ini, Bullshark tanpa jeda menyediakan latensi yang lebih baik, karena node validator akan langsung melewati titik jangkar mereka, sementara validator dengan jeda akan menunggu sampai mereka kedaluwarsa sebelum melanjutkan.
Pemimpin yang lambat, ini adalah satu-satunya situasi di mana kinerja Bullshark lebih baik. Karena tanpa jeda, titik jangkar mungkin terlewat karena pemimpin tidak dapat menyebarkannya cukup cepat, sementara dengan jeda, validator akan menunggu titik jangkar.
Dalam Shoal, menghindari timeout sangat terkait dengan reputasi pemimpin. Menunggu berulang kali.
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.
17 Suka
Hadiah
17
8
Bagikan
Komentar
0/400
MevWhisperer
· 52menit yang lalu
Optimasi peningkatan sangat hebat
Lihat AsliBalas0
MEVictim
· 13jam yang lalu
Optimalisasi telah meningkatkan efisiensi secara signifikan
Aptos memperkenalkan kerangka Shoal yang secara signifikan Drop keterlambatan Bullshark dan menghilangkan kebutuhan timeout
Mengurangi keterlambatan Bullshark di Aptos: Penjelasan kerangka Shoal
Aptos labs telah menyelesaikan dua masalah terbuka penting dalam DAG BFT, secara signifikan mengurangi latensi, dan untuk pertama kalinya menghilangkan kebutuhan untuk jeda dalam protokol nyata yang deterministik. Secara keseluruhan, latensi Bullshark telah ditingkatkan sebesar 40% dalam kondisi tanpa kegagalan, dan 80% dalam kondisi dengan kegagalan.
Kerangka Shoal memperkuat protokol konsensus berbasis Narwhal ( melalui pipeline dan mekanisme reputasi pemimpin seperti DAG-Rider, Tusk, Bullshark ). Pipeline memperkenalkan satu titik jangkar setiap putaran untuk mengurangi penundaan pengurutan DAG, reputasi pemimpin memastikan titik jangkar terkait dengan node validasi tercepat, yang lebih lanjut meningkatkan penundaan. Selain itu, reputasi pemimpin memungkinkan Shoal untuk memanfaatkan konstruksi DAG asinkron untuk menghilangkan waktu habis dalam semua skenario, sehingga mencapai sifat respons universal.
Teknologi Shoal sangat sederhana, menjalankan beberapa instance protokol dasar secara berurutan. Ketika diinstansiasi dengan Bullshark, itu seperti sekumpulan "ikan hiu" yang sedang melakukan estafet.
Latar Belakang
Dalam mengejar kinerja tinggi jaringan blockchain, orang-orang selalu memperhatikan pengurangan kompleksitas komunikasi, tetapi ini tidak menyebabkan peningkatan throughput yang signifikan. Misalnya, Hotstuff yang diimplementasikan di Diem awal hanya mencapai 3500 TPS, jauh di bawah target 100k+ TPS.
Peningkatan baru-baru ini berasal dari pemahaman bahwa penyebaran data adalah hambatan utama yang didasarkan pada protokol pemimpin, dan dapat diuntungkan dari paralelisasi. Sistem Narwhal memisahkan penyebaran data dari logika konsensus inti, di mana semua validator secara bersamaan menyebarkan data, dan komponen konsensus hanya mengurutkan sejumlah kecil metadata. Makalah Narwhal melaporkan throughput 160.000 TPS.
Aptos sebelumnya memperkenalkan Quorum Store, yaitu implementasi Narwhal, yang memisahkan penyebaran data dari konsensus, dan digunakan untuk memperluas protokol konsensus saat ini Jolteon. Jolteon menggabungkan jalur cepat linier Tendermint dan perubahan tampilan gaya PBFT, mengurangi latensi Hotstuff sebesar 33%. Namun, protokol konsensus berbasis pemimpin tidak dapat memanfaatkan potensi throughput Narwhal secara maksimal.
Oleh karena itu, Aptos memutuskan untuk menerapkan Bullshark di atas Narwhal DAG, sebuah protokol konsensus tanpa biaya komunikasi. Sayangnya, struktur DAG yang mendukung Bullshark dengan throughput tinggi membawa biaya latensi sebesar 50%.
Artikel ini menjelaskan bagaimana Shoal secara signifikan mengurangi latensi Bullshark.
Latar Belakang DAG-BFT
Setiap simpul dalam Narwhal DAG terkait dengan sebuah putaran. Pada putaran ke-r, validator harus memperoleh n-f simpul dari putaran ke-r-1. Setiap validator dapat menyiarkan satu simpul per putaran, dan setiap simpul harus merujuk pada setidaknya n-f simpul dari putaran sebelumnya. Karena asinkronisitas jaringan, validator yang berbeda mungkin mengamati pandangan lokal DAG yang berbeda.
Salah satu atribut kunci DAG adalah tidak ambigu: jika dua node validasi memiliki titik v yang sama dalam tampilan DAG lokal mereka, maka mereka memiliki sejarah kausal v yang sepenuhnya sama.
Urutan Total
Dapat mencapai konsensus tentang urutan total semua simpul di DAG tanpa biaya komunikasi tambahan. Validator di 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 yang berbasis Narwhal memiliki struktur berikut:
Titik jangkar yang ditentukan: Setiap beberapa putaran ada seorang pemimpin yang telah ditentukan sebelumnya, yang puncaknya disebut titik jangkar.
Titik urut: Validator secara independen tetapi dengan kepastian memutuskan titik mana yang diurutkan dan mana yang dilewati.
Sejarah kausal terurut: Validasi memproses daftar titik jangkar yang terurut satu per satu, mengurutkan simpul yang tidak terurut sebelumnya dalam sejarah kausal setiap titik jangkar.
Kunci untuk memenuhi keamanan adalah memastikan bahwa dalam langkah (2), semua daftar titik jangkar terurut yang dibuat oleh node validasi yang jujur berbagi awalan yang sama. Di Shoal, kami mengamati:
Semua validator setuju pada titik jangkar terurut pertama.
Bullshark Tertunda
Keterlambatan Bullshark tergantung pada jumlah putaran antara titik jangkar yang terurut di dalam DAG. Versi sinkron sebagian memiliki keterlambatan yang lebih baik dibandingkan dengan versi asinkron, tetapi masih tidak optimal.
Pertanyaan 1: Rata-rata keterlambatan blok. Dalam Bullshark, setiap putaran genap memiliki satu titik jangkar, dan puncak putaran ganjil diartikan sebagai suara. Dalam kasus umum, dibutuhkan dua putaran DAG untuk mengurutkan titik jangkar, tetapi puncak dalam sejarah kausal titik jangkar memerlukan lebih banyak putaran untuk menunggu titik jangkar diurutkan. Dalam kasus umum, puncak putaran ganjil memerlukan tiga putaran, dan puncak bukan jangkar putaran genap memerlukan empat putaran.
Pertanyaan 2: Keterlambatan dalam situasi kegagalan. Jika seorang pemimpin tidak berhasil mengumumkan titik jangkar tepat waktu, maka tidak dapat dilakukan pengurutan ( yang dilewati ), semua titik yang belum terurut dari beberapa putaran sebelumnya harus menunggu titik jangkar berikutnya untuk diurutkan. Ini secara signifikan mengurangi kinerja jaringan replikasi geografis, terutama karena Bullshark menggunakan waktu tunggu untuk pemimpin.
Kerangka Shoal
Shoal meningkatkan Bullshark( atau protokol BFT berbasis Narwhal) melalui jalur aliran, memungkinkan satu titik jangkar setiap putaran, mengurangi latensi semua titik puncak non-jangkar dalam DAG menjadi tiga putaran. Shoal juga memperkenalkan mekanisme reputasi pemimpin tanpa biaya dalam DAG, yang condong untuk memilih pemimpin yang cepat.
Tantangan
Dalam protokol DAG, masalah pipeline 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 diformalkan dalam Carousel, memilih pemimpin masa depan secara dinamis berdasarkan kinerja masa lalu para validator (Jangkar di Bullshark ). Meskipun perbedaan identitas pemimpin tidak melanggar keamanan protokol ini, hal itu dapat menyebabkan urutan yang sangat berbeda di Bullshark, mengangkat inti masalah: memilih jangkar roda secara dinamis dan deterministik adalah penting untuk menyelesaikan konsensus, para validator perlu mencapai kesepakatan tentang sejarah terurut untuk memilih jangkar masa depan.
Sebagai bukti kesulitan masalah, implementasi Bullshark ( termasuk ) di lingkungan produksi saat ini tidak mendukung fitur-fitur ini.
Protokol
Meskipun ada tantangan di atas, solusi tersembunyi dalam kesederhanaan.
Shoal bergantung pada kemampuan untuk melakukan perhitungan lokal di atas DAG, mewujudkan kemampuan untuk menyimpan dan menafsirkan kembali informasi dari putaran sebelumnya. Berdasarkan wawasan bahwa semua validator setuju pada titik jangkar terurut pertama, Shoal menggabungkan beberapa contoh Bullshark secara berurutan untuk pemrosesan pipeline, menjadikan ( titik pergantian untuk contoh pada titik jangkar terurut pertama, dan ) sejarah kausal titik jangkar digunakan untuk menghitung reputasi pemimpin.
( Jalur Produksi
V yang memetakan putaran ke pemimpin. Shoal menjalankan instansi Bullshark secara berurutan, di mana jangkar setiap instansi ditentukan sebelumnya oleh pemetaan F. Setiap instansi mengurutkan satu jangkar, memicu perpindahan ke instansi berikutnya.
Pada awalnya, Shoal meluncurkan instansi pertama Bullshark dalam putaran pertama DAG, berjalan hingga titik jangkar terurut pertama ) ditentukan seperti pada putaran r ###. Semua validator setuju dengan titik jangkar ini, sehingga dapat disepakati dengan pasti untuk menafsirkan ulang DAG dari putaran r+1. Shoal meluncurkan instansi Bullshark baru pada putaran r+1.
Dalam kondisi terbaik, ini memungkinkan Shoal untuk menyortir satu jangkar setiap putaran. Jangkar titik pertama disortir oleh instansi pertama. Kemudian, Shoal memulai instansi baru di putaran kedua, yang memiliki jangkar titiknya sendiri dan disortir oleh instansi tersebut, kemudian instansi baru lainnya menyortir jangkar titik di putaran ketiga, dan seterusnya.
( Kredibilitas Pemimpin
Ketika Bullshark melewatkan titik jangkar, keterlambatan meningkat. Dalam kasus ini, jalur tidak dapat berfungsi, karena tidak mungkin memulai instance baru sebelum titik jangkar instance sebelumnya diurutkan. Shoal memberikan skor untuk setiap node validasi melalui mekanisme reputasi, memastikan bahwa pemimpin yang sesuai untuk menangani titik jangkar yang hilang kemungkinan besar tidak akan dipilih di masa depan berdasarkan sejarah aktivitas terakhir mereka. Validator yang merespons dan berpartisipasi dalam protokol mendapatkan skor tinggi, jika tidak, mereka diberikan skor rendah ) dapat macet, lambat, atau berbuat jahat ###.
Ide adalah untuk secara deterministik menghitung ulang pemetaan yang telah ditentukan F dari putaran ke pemimpin setiap kali skor diperbarui, yang menguntungkan pemimpin dengan skor tinggi. Agar para validator mencapai konsensus pada pemetaan baru, mereka harus mencapai konsensus pada skor, sehingga mencapai kesepakatan pada sejarah yang digunakan untuk menghasilkan skor.
Di Shoal, alur kerja dan reputasi pemimpin secara alami terintegrasi, karena mereka menggunakan teknologi inti yang sama: menafsirkan kembali DAG setelah mencapai konsensus pada titik jangkar berurutan pertama.
Satu-satunya perbedaan adalah, setelah urutan titik acuan di putaran ke-r, validator menghitung pemetaan baru F' mulai dari putaran ke-r+1 berdasarkan sejarah kausal titik acuan terurut di putaran ke-r. Kemudian, node validator mulai dari putaran ke-r+1 menggunakan fungsi pemilihan titik acuan yang diperbarui F' untuk menjalankan instance baru Bullshark.
( Tidak perlu lebih banyak waktu habis
Keterlambatan sangat penting dalam semua implementasi BFT yang berbasis pemimpin yang deterministik. Namun, kompleksitas yang mereka perkenalkan meningkatkan jumlah status internal yang perlu dikelola dan dipantau, meningkatkan kompleksitas proses debugging, yang membutuhkan lebih banyak teknik observabilitas.
Timeout juga secara signifikan meningkatkan latensi, karena konfigurasi yang tepat sangat penting, biasanya memerlukan penyesuaian dinamis, sangat bergantung pada lingkungan ) jaringan ###. Sebelum beralih ke pemimpin berikutnya, protokol membayar penalti latensi timeout penuh untuk pemimpin yang bermasalah. Oleh karena itu, pengaturan timeout tidak boleh terlalu konservatif, tetapi jika terlalu pendek, protokol mungkin melewatkan pemimpin yang baik. Misalnya, kami mengamati bahwa di bawah beban tinggi, pemimpin dalam Jolteon/Hotstuff tidak dapat menangani beban, dan timeout sudah habis sebelum kemajuan dapat didorong.
Sayangnya, protokol kepemimpinan ( seperti Hotstuff dan Jolteon) pada dasarnya memerlukan timeout untuk memastikan bahwa protokol dapat melanjutkan setiap kali pemimpin gagal. Tanpa timeout, bahkan pemimpin yang mengalami keruntuhan mungkin akan menghentikan protokol selamanya. Karena selama periode asinkron tidak mungkin untuk membedakan antara pemimpin yang gagal dan yang lambat, timeout dapat menyebabkan node verifikasi melihat perubahan semua pemimpin tanpa adanya aktivitas konsensus.
Di Bullshark, waktu habis digunakan untuk konstruksi DAG, untuk memastikan bahwa pemimpin yang jujur menambahkan titik jangkar ke DAG dengan kecepatan yang cukup cepat selama sinkronisasi, agar dapat diurutkan.
Kami mengamati bahwa konstruksi DAG menyediakan "jam" untuk memperkirakan kecepatan jaringan. Tanpa jeda, selama n-f validator yang jujur terus menambahkan simpul ke DAG, putaran akan terus maju. Meskipun Bullshark mungkin tidak dapat mengurutkan ( dengan kecepatan jaringan karena masalah pemimpin ), DAG tetap tumbuh dengan kecepatan jaringan, meskipun beberapa pemimpin bermasalah atau jaringan tidak sinkron. Pada akhirnya, ketika pemimpin tanpa kesalahan cukup cepat untuk menyiarkan titik jangkar, seluruh sejarah kausal titik jangkar akan diurutkan.
Dalam penilaian, kami membandingkan Bullshark dalam situasi dengan dan tanpa waktu habis:
Pemimpin cepat, setidaknya lebih cepat daripada validator lainnya. Dalam kasus ini, kedua metode memberikan latensi yang sama, karena jangkar terurut dan tidak menggunakan timeout.
Pemimpin yang salah, dalam hal ini, Bullshark tanpa jeda menyediakan latensi yang lebih baik, karena node validator akan langsung melewati titik jangkar mereka, sementara validator dengan jeda akan menunggu sampai mereka kedaluwarsa sebelum melanjutkan.
Pemimpin yang lambat, ini adalah satu-satunya situasi di mana kinerja Bullshark lebih baik. Karena tanpa jeda, titik jangkar mungkin terlewat karena pemimpin tidak dapat menyebarkannya cukup cepat, sementara dengan jeda, validator akan menunggu titik jangkar.
Dalam Shoal, menghindari timeout sangat terkait dengan reputasi pemimpin. Menunggu berulang kali.