Kerangka Shoal: Solusi Inovatif untuk Meningkatkan Kinerja Blockchain Aptos
Aptos Labs baru-baru ini mengajukan kerangka Shoal, yang bertujuan untuk menyelesaikan dua masalah kunci dalam konsensus DAG BFT, secara signifikan mengurangi latensi dan untuk pertama kalinya menghilangkan ketergantungan pada timeout dalam protokol asinkron deterministik. Secara keseluruhan, Shoal meningkatkan latensi Bullshark sebesar 40% dalam kondisi tanpa kegagalan, dan meningkat sebesar 80% dalam kondisi kegagalan.
Shoal meningkatkan protokol konsensus berbasis Narwhal ( seperti DAG-Rider, Tusk, Bullshark, dan lainnya ) melalui teknologi pipeline dan mekanisme reputasi pemimpin. Teknologi pipeline mengurangi latensi pengurutan DAG dengan memperkenalkan satu titik jangkar setiap putaran, sementara mekanisme reputasi pemimpin lebih lanjut meningkatkan latensi dengan memastikan bahwa titik jangkar terkait dengan node validasi tercepat. Selain itu, reputasi pemimpin memungkinkan Shoal memanfaatkan pembangunan DAG asinkron untuk menghilangkan timeout di semua skenario, sehingga mencapai responsivitas yang universal.
Pemikiran inti Shoal adalah menjalankan beberapa instance dari protokol dasar secara berurutan. Mengambil Bullshark sebagai contoh, dapat dibayangkan sebagai sekelompok "ikan hiu" yang sedang berlari dalam perlombaan estafet.
Motivasi
Jaringan blockchain selalu berusaha untuk mencapai kinerja yang lebih tinggi, di mana perhatian awalnya terutama pada pengurangan 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 merupakan hambatan utama yang didasarkan pada protokol pemimpin, yang dapat diuntungkan melalui paralelisasi. Sistem Narwhal memisahkan penyebaran data dari logika konsensus inti, mengusulkan arsitektur di mana semua validator secara bersamaan menyebarkan data, dan komponen konsensus hanya mengurutkan sejumlah kecil metadata, mencapai throughput 160.000 TPS.
Aptos sebelumnya memperkenalkan Quorum Store, yaitu implementasi Narwhal, yang memisahkan penyebaran data dan konsensus, dan digunakan untuk memperluas protokol konsensus saat ini, Jolteon. Jolteon menggabungkan jalur cepat linier Tendermint dan perubahan tampilan gaya PBFT, yang 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. Namun, dukungan Bullshark untuk struktur DAG dengan throughput tinggi membawa biaya latensi sebesar 50%. Tujuan dari kerangka Shoal adalah untuk secara signifikan mengurangi latensi Bullshark.
Latar Belakang DAG-BFT
Setiap simpul dalam Narwhal DAG terkait dengan satu putaran. Untuk memasuki putaran ke-r, perlu terlebih dahulu mendapatkan n-f simpul dari putaran r-1. Setiap validator dapat menyiarkan satu simpul per putaran, dan setiap simpul harus merujuk setidaknya n-f simpul dari putaran sebelumnya. Karena asinkronitas jaringan, validator yang berbeda mungkin mengamati pandangan lokal DAG yang berbeda.
Salah satu fitur kunci dari DAG adalah non-ambiguity: jika dua node validasi memiliki vertex v yang sama dalam tampilan DAG lokal mereka, maka mereka memiliki sejarah kausal v yang sepenuhnya sama.
Urut penuh
Konsensus mengenai urutan total semua simpul dalam DAG dapat dicapai tanpa biaya komunikasi tambahan. Protokol seperti DAG-Rider, Tusk, dan Bullshark menginterpretasikan struktur DAG sebagai protokol konsensus, di mana simpul mewakili proposal dan tepi mewakili suara.
Meskipun logika spesifik berbeda, semua protokol konsensus berbasis Narwhal memiliki struktur berikut:
Titik jangkar yang telah ditentukan: Setiap beberapa putaran, ada seorang pemimpin yang telah ditentukan sebelumnya, yang puncaknya disebut sebagai titik jangkar.
Titik urut: Validator secara independen tetapi deterministik menentukan titik mana yang akan diurutkan atau dilewati.
Urutan sejarah kausal: validator memproses daftar titik jangkar yang terurut satu per satu, mengurutkan simpul yang belum terurut dalam sejarah kausal masing-masing titik jangkar.
Kunci untuk memenuhi keamanan adalah memastikan bahwa semua node verifikasi yang jujur membuat daftar titik jangkar terurut yang berbagi awalan yang sama. Shoal memberikan pengamatan penting terhadap semua protokol ini: semua validator setuju pada titik jangkar terurut pertama.
Masalah Keterlambatan Bullshark
Penundaan Bullshark tergantung pada jumlah putaran antara titik jangkar terurut dalam DAG. Meskipun beberapa versi sinkron memiliki penundaan yang lebih rendah dibandingkan versi asinkron, masih jauh dari optimal.
Ada dua masalah utama:
Rata-rata penundaan blok: Dalam situasi umum, puncak putaran ganjil memerlukan tiga putaran untuk diurutkan, sedangkan puncak non-penambat putaran genap memerlukan empat putaran.
Situasi Kegagalan Tertunda: Jika pemimpin dalam satu putaran gagal untuk segera menyiarkan titik jangkar, titik jangkar tersebut akan dilewati, dan semua simpul yang belum terurut dari beberapa putaran sebelumnya harus menunggu penyortiran titik jangkar berikutnya. Ini secara signifikan mengurangi kinerja jaringan yang terdistribusi secara geografis, terutama karena Bullshark menggunakan waktu tunggu untuk pemimpin.
Kerangka Shoal
Shoal meningkatkan Bullshark( atau protokol BFT berbasis Narwhal) melalui jalur aliran, memungkinkan setiap putaran memiliki titik jangkar, mengurangi latensi semua titik puncak non-jangkar menjadi tiga putaran. Shoal juga memperkenalkan mekanisme reputasi pemimpin tanpa biaya dalam DAG, yang cenderung memilih pemimpin cepat.
Tantangan
Menerapkan pipeline dan reputasi pemimpin dalam protokol DAG dianggap sulit:
Sebelumnya mencoba memodifikasi logika inti Bullshark tampaknya tidak berhasil.
Reputasi pemimpin dapat menyebabkan urutan yang berbeda, dan validator perlu mencapai konsensus mengenai sejarah yang terurut untuk memilih titik jangkar di masa depan.
Sebagai bukti tingkat kesulitan masalah, implementasi Bullshark saat ini di lingkungan produksi tidak mendukung fitur-fitur ini.
Protokol
Solusi Shoal relatif sederhana. Ini memanfaatkan kemampuan untuk melakukan perhitungan lokal di atas DAG, yang memungkinkan penyimpanan dan reinterpretasi informasi dari beberapa putaran sebelumnya. Berdasarkan pemahaman bahwa semua validator setuju pada titik jangkar yang terurut pertama, Shoal menggabungkan beberapa instance Bullshark secara berurutan untuk pemrosesan pipeline, sehingga:
Titik jangkar terurut pertama adalah titik peralihan instance
Sejarah kausal titik jangkar digunakan untuk menghitung reputasi pemimpin
Jalur Produksi
V yang memetakan putaran ke pemimpin. Shoal menjalankan instansi Bullshark secara berurutan, setiap instansi mengurutkan satu titik jangkar dan memicu perpindahan ke instansi berikutnya.
Shoal memulai instance pertama Bullshark dari putaran pertama DAG, hingga menentukan titik jangkar terurut pertama ( yang diasumsikan berada di putaran r ). Semua validator menyetujui titik jangkar ini, sehingga dapat secara deterministik setuju untuk menginterpretasikan ulang DAG dari putaran r+1. Shoal memulai instance Bullshark baru di putaran r+1.
Dalam kondisi ideal, ini memungkinkan Shoal untuk mengurutkan satu titik jangkar per putaran. Titik jangkar putaran pertama diurutkan oleh instansi pertama, kemudian pada putaran kedua instansi baru mengurutkan titik jangkar putaran itu, dan seterusnya.
Reputasi Pemimpin
Ketika Bullshark melompati titik jangkar, keterlambatan akan meningkat. Teknologi jalur tidak berdaya dalam situasi ini karena harus menunggu urutan titik jangkar dari instansi sebelumnya sebelum memulai instansi baru. Shoal memberikan skor untuk setiap node verifikasi berdasarkan mekanisme reputasi, sesuai dengan riwayat aktivitas terbaru mereka. Validator yang responsif mendapatkan skor tinggi, sebaliknya mendapatkan skor rendah.
Ide adalah untuk menghitung kembali pemetaan F dari ronde ke pemimpin dengan deterministik setiap kali skor diperbarui, mengutamakan pemimpin dengan skor tinggi. Agar validator mencapai konsensus pada pemetaan baru, mereka perlu mencapai konsensus pada skor, dan kemudian mencapai konsensus pada sejarah yang digunakan untuk menurunkan skor.
Di Shoal, reputasi pipeline dan pemimpin dapat digabungkan secara alami, karena keduanya didasarkan pada reinterpretasi DAG setelah konsensus dicapai pada titik jangkar terurut pertama. Perbedaan satu-satunya adalah, setelah titik jangkar urutan r, validator menghitung pemetaan baru F' mulai dari r+1 berdasarkan sejarah kausal titik jangkar tersebut. Kemudian mulai dari r+1, contoh Bullshark baru dieksekusi menggunakan F' yang diperbarui.
Hapus waktu habis
Timeout sangat penting dalam semua implementasi BFT deterministik berbasis pemimpin. Namun, mereka menambah kompleksitas, memerlukan lebih banyak manajemen status internal dan pengamatan, yang membuat proses debugging menjadi lebih sulit.
Timeout juga akan secara signifikan meningkatkan latensi, karena konfigurasi yang benar sangat penting dan biasanya perlu disesuaikan secara dinamis. Sebelum beralih ke pemimpin berikutnya, protokol harus membayar denda latensi timeout penuh untuk pemimpin yang gagal. Oleh karena itu, pengaturan timeout tidak boleh terlalu konservatif, tetapi jika terlalu pendek, bisa melewatkan pemimpin yang baik.
Sayangnya, protokol berbasis pemimpin ( seperti Hotstuff dan Jolteon ) pada dasarnya memerlukan waktu habis untuk memastikan kemajuan saat pemimpin mengalami kegagalan. Tanpa waktu habis, bahkan pemimpin yang gagal mungkin dapat menghentikan protokol selamanya. Karena selama periode asinkron tidak mungkin membedakan antara kegagalan dan pemimpin yang lambat, waktu habis dapat menyebabkan node verifikasi mengganti semua pemimpin tanpa adanya aktivitas konsensus.
Di Bullshark, waktu habis digunakan untuk membangun DAG, untuk memastikan pemimpin yang jujur cukup cepat menambahkan titik jangkar ke DAG untuk pengurutan selama proses sinkronisasi.
Kami mengamati bahwa pembangunan DAG menyediakan sebuah "jam" untuk memperkirakan kecepatan jaringan. Selama n-f validator yang jujur terus menambahkan simpul ke DAG, putaran akan maju. Meskipun Bullshark mungkin tidak dapat mengurutkan dengan kecepatan jaringan, DAG tetap tumbuh dengan kecepatan jaringan. Akhirnya, ketika seorang pemimpin tanpa kesalahan cukup cepat untuk menyiarkan titik jangkar, seluruh sejarah kausal dari titik jangkar akan diurutkan.
Dalam evaluasi, kami membandingkan Bullshark dengan dan tanpa timeout:
Pemimpin Cepat: Dua metode memiliki penundaan yang sama, karena titik jangkar sudah diurutkan dan tidak menggunakan waktu tunggu.
Pemimpin yang salah: Bullshark tanpa timeout memiliki keterlambatan yang lebih rendah, karena node validator akan segera melewati titik jangkar mereka.
Pemimpin yang lambat: Ada Bullshark tanpa batas waktu yang berkinerja lebih baik, karena validator akan menunggu titik jangkar, sedangkan tanpa batas waktu mungkin melewatkan titik jangkar.
Di Shoal, menghindari timeout sangat terkait dengan reputasi pemimpin. Menunggu pemimpin yang lambat berulang kali akan meningkatkan latensi, sedangkan mekanisme reputasi mengecualikan validator yang lambat dari pemilihan sebagai pemimpin. Dengan cara ini, sistem dapat beroperasi dengan kecepatan jaringan dalam semua skenario nyata.
Perlu dicatat bahwa hasil ketidakmungkinan FLP menunjukkan bahwa tidak ada protokol konsensus deterministik yang dapat sepenuhnya menghindari timeout. Shoal tidak dapat menghindari hasil ini, karena secara teori ada jadwal peristiwa antagonis yang dapat mencegah semua titik jangkar diurutkan. Sebaliknya, setelah jumlah titik jangkar yang dapat dikonfigurasi dilewati, Shoal akan kembali ke timeout. Namun, dalam praktiknya, situasi ini sangat tidak mungkin terjadi.
Respon Umum
Makalah Hotstuff mempopulerkan konsep respons optimis, yang secara intuitif berarti bahwa protokol dapat beroperasi pada kecepatan jaringan ( termasuk pemimpin cepat dan jaringan yang disinkronkan ) dalam kondisi baik.
Shoal menyediakan fitur yang lebih baik, yang disebut responsivitas universal. Secara khusus, dibandingkan dengan Hotstuff, meskipun pemimpin gagal dalam jumlah putaran berkelanjutan yang dapat dikonfigurasi atau jaringan mengalami periode asinkron, Shoal akan terus berjalan dengan kecepatan jaringan.
Responsivitas umum memberikan jaminan kemajuan yang jauh lebih baik pada periode asinkron dan ketika terjadi kegagalan pemimpin. Selama sinkronisasi dengan pemimpin yang lambat, karakteristik ini tidak dapat dibandingkan secara langsung, karena tergantung pada kecepatan pemimpin. Namun, mengingat mekanisme reputasi pemimpin, pemimpin yang lambat seharusnya jarang muncul di Shoal.
![Penjelasan detail tentang kerangka Shoal: Bagaimana mengurangi
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.
18 Suka
Hadiah
18
7
Posting ulang
Bagikan
Komentar
0/400
GasGrillMaster
· 15jam yang lalu
Wah, latensi dipotong setengah, bull!
Lihat AsliBalas0
MysteriousZhang
· 08-12 04:51
Empat puluh persen saja berani sombong? kkk
Lihat AsliBalas0
SerumSquirter
· 08-12 04:50
Akhirnya bisa terus mengeluarkan uang ke sini.
Lihat AsliBalas0
ContractCollector
· 08-12 04:48
Optimasi latensi kali ini sangat hebat!
Lihat AsliBalas0
LiquidityWitch
· 08-12 04:44
Ini terlalu keras, latensi meningkat 40
Lihat AsliBalas0
GateUser-26d7f434
· 08-12 04:41
Apakah dapat berjalan di Mainnet dengan kecepatan 40% lebih cepat?
Lihat AsliBalas0
YieldHunter
· 08-12 04:41
secara teknis... 40% tidak buruk tapi tampilkan statistik hasilnya
Kerangka Shoal: Peningkatan latensi 40% pada rantai Aptos dan penghapusan ketergantungan waktu habis
Kerangka Shoal: Solusi Inovatif untuk Meningkatkan Kinerja Blockchain Aptos
Aptos Labs baru-baru ini mengajukan kerangka Shoal, yang bertujuan untuk menyelesaikan dua masalah kunci dalam konsensus DAG BFT, secara signifikan mengurangi latensi dan untuk pertama kalinya menghilangkan ketergantungan pada timeout dalam protokol asinkron deterministik. Secara keseluruhan, Shoal meningkatkan latensi Bullshark sebesar 40% dalam kondisi tanpa kegagalan, dan meningkat sebesar 80% dalam kondisi kegagalan.
Shoal meningkatkan protokol konsensus berbasis Narwhal ( seperti DAG-Rider, Tusk, Bullshark, dan lainnya ) melalui teknologi pipeline dan mekanisme reputasi pemimpin. Teknologi pipeline mengurangi latensi pengurutan DAG dengan memperkenalkan satu titik jangkar setiap putaran, sementara mekanisme reputasi pemimpin lebih lanjut meningkatkan latensi dengan memastikan bahwa titik jangkar terkait dengan node validasi tercepat. Selain itu, reputasi pemimpin memungkinkan Shoal memanfaatkan pembangunan DAG asinkron untuk menghilangkan timeout di semua skenario, sehingga mencapai responsivitas yang universal.
Pemikiran inti Shoal adalah menjalankan beberapa instance dari protokol dasar secara berurutan. Mengambil Bullshark sebagai contoh, dapat dibayangkan sebagai sekelompok "ikan hiu" yang sedang berlari dalam perlombaan estafet.
Motivasi
Jaringan blockchain selalu berusaha untuk mencapai kinerja yang lebih tinggi, di mana perhatian awalnya terutama pada pengurangan 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 merupakan hambatan utama yang didasarkan pada protokol pemimpin, yang dapat diuntungkan melalui paralelisasi. Sistem Narwhal memisahkan penyebaran data dari logika konsensus inti, mengusulkan arsitektur di mana semua validator secara bersamaan menyebarkan data, dan komponen konsensus hanya mengurutkan sejumlah kecil metadata, mencapai throughput 160.000 TPS.
Aptos sebelumnya memperkenalkan Quorum Store, yaitu implementasi Narwhal, yang memisahkan penyebaran data dan konsensus, dan digunakan untuk memperluas protokol konsensus saat ini, Jolteon. Jolteon menggabungkan jalur cepat linier Tendermint dan perubahan tampilan gaya PBFT, yang 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. Namun, dukungan Bullshark untuk struktur DAG dengan throughput tinggi membawa biaya latensi sebesar 50%. Tujuan dari kerangka Shoal adalah untuk secara signifikan mengurangi latensi Bullshark.
Latar Belakang DAG-BFT
Setiap simpul dalam Narwhal DAG terkait dengan satu putaran. Untuk memasuki putaran ke-r, perlu terlebih dahulu mendapatkan n-f simpul dari putaran r-1. Setiap validator dapat menyiarkan satu simpul per putaran, dan setiap simpul harus merujuk setidaknya n-f simpul dari putaran sebelumnya. Karena asinkronitas jaringan, validator yang berbeda mungkin mengamati pandangan lokal DAG yang berbeda.
Salah satu fitur kunci dari DAG adalah non-ambiguity: jika dua node validasi memiliki vertex v yang sama dalam tampilan DAG lokal mereka, maka mereka memiliki sejarah kausal v yang sepenuhnya sama.
Urut penuh
Konsensus mengenai urutan total semua simpul dalam DAG dapat dicapai tanpa biaya komunikasi tambahan. Protokol seperti DAG-Rider, Tusk, dan Bullshark menginterpretasikan struktur DAG sebagai protokol konsensus, di mana simpul mewakili proposal dan tepi mewakili suara.
Meskipun logika spesifik berbeda, semua protokol konsensus berbasis Narwhal memiliki struktur berikut:
Titik jangkar yang telah ditentukan: Setiap beberapa putaran, ada seorang pemimpin yang telah ditentukan sebelumnya, yang puncaknya disebut sebagai titik jangkar.
Titik urut: Validator secara independen tetapi deterministik menentukan titik mana yang akan diurutkan atau dilewati.
Urutan sejarah kausal: validator memproses daftar titik jangkar yang terurut satu per satu, mengurutkan simpul yang belum terurut dalam sejarah kausal masing-masing titik jangkar.
Kunci untuk memenuhi keamanan adalah memastikan bahwa semua node verifikasi yang jujur membuat daftar titik jangkar terurut yang berbagi awalan yang sama. Shoal memberikan pengamatan penting terhadap semua protokol ini: semua validator setuju pada titik jangkar terurut pertama.
Masalah Keterlambatan Bullshark
Penundaan Bullshark tergantung pada jumlah putaran antara titik jangkar terurut dalam DAG. Meskipun beberapa versi sinkron memiliki penundaan yang lebih rendah dibandingkan versi asinkron, masih jauh dari optimal.
Ada dua masalah utama:
Rata-rata penundaan blok: Dalam situasi umum, puncak putaran ganjil memerlukan tiga putaran untuk diurutkan, sedangkan puncak non-penambat putaran genap memerlukan empat putaran.
Situasi Kegagalan Tertunda: Jika pemimpin dalam satu putaran gagal untuk segera menyiarkan titik jangkar, titik jangkar tersebut akan dilewati, dan semua simpul yang belum terurut dari beberapa putaran sebelumnya harus menunggu penyortiran titik jangkar berikutnya. Ini secara signifikan mengurangi kinerja jaringan yang terdistribusi secara geografis, terutama karena Bullshark menggunakan waktu tunggu untuk pemimpin.
Kerangka Shoal
Shoal meningkatkan Bullshark( atau protokol BFT berbasis Narwhal) melalui jalur aliran, memungkinkan setiap putaran memiliki titik jangkar, mengurangi latensi semua titik puncak non-jangkar menjadi tiga putaran. Shoal juga memperkenalkan mekanisme reputasi pemimpin tanpa biaya dalam DAG, yang cenderung memilih pemimpin cepat.
Tantangan
Menerapkan pipeline dan reputasi pemimpin dalam protokol DAG dianggap sulit:
Sebelumnya mencoba memodifikasi logika inti Bullshark tampaknya tidak berhasil.
Reputasi pemimpin dapat menyebabkan urutan yang berbeda, dan validator perlu mencapai konsensus mengenai sejarah yang terurut untuk memilih titik jangkar di masa depan.
Sebagai bukti tingkat kesulitan masalah, implementasi Bullshark saat ini di lingkungan produksi tidak mendukung fitur-fitur ini.
Protokol
Solusi Shoal relatif sederhana. Ini memanfaatkan kemampuan untuk melakukan perhitungan lokal di atas DAG, yang memungkinkan penyimpanan dan reinterpretasi informasi dari beberapa putaran sebelumnya. Berdasarkan pemahaman bahwa semua validator setuju pada titik jangkar yang terurut pertama, Shoal menggabungkan beberapa instance Bullshark secara berurutan untuk pemrosesan pipeline, sehingga:
Jalur Produksi
V yang memetakan putaran ke pemimpin. Shoal menjalankan instansi Bullshark secara berurutan, setiap instansi mengurutkan satu titik jangkar dan memicu perpindahan ke instansi berikutnya.
Shoal memulai instance pertama Bullshark dari putaran pertama DAG, hingga menentukan titik jangkar terurut pertama ( yang diasumsikan berada di putaran r ). Semua validator menyetujui titik jangkar ini, sehingga dapat secara deterministik setuju untuk menginterpretasikan ulang DAG dari putaran r+1. Shoal memulai instance Bullshark baru di putaran r+1.
Dalam kondisi ideal, ini memungkinkan Shoal untuk mengurutkan satu titik jangkar per putaran. Titik jangkar putaran pertama diurutkan oleh instansi pertama, kemudian pada putaran kedua instansi baru mengurutkan titik jangkar putaran itu, dan seterusnya.
Reputasi Pemimpin
Ketika Bullshark melompati titik jangkar, keterlambatan akan meningkat. Teknologi jalur tidak berdaya dalam situasi ini karena harus menunggu urutan titik jangkar dari instansi sebelumnya sebelum memulai instansi baru. Shoal memberikan skor untuk setiap node verifikasi berdasarkan mekanisme reputasi, sesuai dengan riwayat aktivitas terbaru mereka. Validator yang responsif mendapatkan skor tinggi, sebaliknya mendapatkan skor rendah.
Ide adalah untuk menghitung kembali pemetaan F dari ronde ke pemimpin dengan deterministik setiap kali skor diperbarui, mengutamakan pemimpin dengan skor tinggi. Agar validator mencapai konsensus pada pemetaan baru, mereka perlu mencapai konsensus pada skor, dan kemudian mencapai konsensus pada sejarah yang digunakan untuk menurunkan skor.
Di Shoal, reputasi pipeline dan pemimpin dapat digabungkan secara alami, karena keduanya didasarkan pada reinterpretasi DAG setelah konsensus dicapai pada titik jangkar terurut pertama. Perbedaan satu-satunya adalah, setelah titik jangkar urutan r, validator menghitung pemetaan baru F' mulai dari r+1 berdasarkan sejarah kausal titik jangkar tersebut. Kemudian mulai dari r+1, contoh Bullshark baru dieksekusi menggunakan F' yang diperbarui.
Hapus waktu habis
Timeout sangat penting dalam semua implementasi BFT deterministik berbasis pemimpin. Namun, mereka menambah kompleksitas, memerlukan lebih banyak manajemen status internal dan pengamatan, yang membuat proses debugging menjadi lebih sulit.
Timeout juga akan secara signifikan meningkatkan latensi, karena konfigurasi yang benar sangat penting dan biasanya perlu disesuaikan secara dinamis. Sebelum beralih ke pemimpin berikutnya, protokol harus membayar denda latensi timeout penuh untuk pemimpin yang gagal. Oleh karena itu, pengaturan timeout tidak boleh terlalu konservatif, tetapi jika terlalu pendek, bisa melewatkan pemimpin yang baik.
Sayangnya, protokol berbasis pemimpin ( seperti Hotstuff dan Jolteon ) pada dasarnya memerlukan waktu habis untuk memastikan kemajuan saat pemimpin mengalami kegagalan. Tanpa waktu habis, bahkan pemimpin yang gagal mungkin dapat menghentikan protokol selamanya. Karena selama periode asinkron tidak mungkin membedakan antara kegagalan dan pemimpin yang lambat, waktu habis dapat menyebabkan node verifikasi mengganti semua pemimpin tanpa adanya aktivitas konsensus.
Di Bullshark, waktu habis digunakan untuk membangun DAG, untuk memastikan pemimpin yang jujur cukup cepat menambahkan titik jangkar ke DAG untuk pengurutan selama proses sinkronisasi.
Kami mengamati bahwa pembangunan DAG menyediakan sebuah "jam" untuk memperkirakan kecepatan jaringan. Selama n-f validator yang jujur terus menambahkan simpul ke DAG, putaran akan maju. Meskipun Bullshark mungkin tidak dapat mengurutkan dengan kecepatan jaringan, DAG tetap tumbuh dengan kecepatan jaringan. Akhirnya, ketika seorang pemimpin tanpa kesalahan cukup cepat untuk menyiarkan titik jangkar, seluruh sejarah kausal dari titik jangkar akan diurutkan.
Dalam evaluasi, kami membandingkan Bullshark dengan dan tanpa timeout:
Pemimpin Cepat: Dua metode memiliki penundaan yang sama, karena titik jangkar sudah diurutkan dan tidak menggunakan waktu tunggu.
Pemimpin yang salah: Bullshark tanpa timeout memiliki keterlambatan yang lebih rendah, karena node validator akan segera melewati titik jangkar mereka.
Pemimpin yang lambat: Ada Bullshark tanpa batas waktu yang berkinerja lebih baik, karena validator akan menunggu titik jangkar, sedangkan tanpa batas waktu mungkin melewatkan titik jangkar.
Di Shoal, menghindari timeout sangat terkait dengan reputasi pemimpin. Menunggu pemimpin yang lambat berulang kali akan meningkatkan latensi, sedangkan mekanisme reputasi mengecualikan validator yang lambat dari pemilihan sebagai pemimpin. Dengan cara ini, sistem dapat beroperasi dengan kecepatan jaringan dalam semua skenario nyata.
Perlu dicatat bahwa hasil ketidakmungkinan FLP menunjukkan bahwa tidak ada protokol konsensus deterministik yang dapat sepenuhnya menghindari timeout. Shoal tidak dapat menghindari hasil ini, karena secara teori ada jadwal peristiwa antagonis yang dapat mencegah semua titik jangkar diurutkan. Sebaliknya, setelah jumlah titik jangkar yang dapat dikonfigurasi dilewati, Shoal akan kembali ke timeout. Namun, dalam praktiknya, situasi ini sangat tidak mungkin terjadi.
Respon Umum
Makalah Hotstuff mempopulerkan konsep respons optimis, yang secara intuitif berarti bahwa protokol dapat beroperasi pada kecepatan jaringan ( termasuk pemimpin cepat dan jaringan yang disinkronkan ) dalam kondisi baik.
Shoal menyediakan fitur yang lebih baik, yang disebut responsivitas universal. Secara khusus, dibandingkan dengan Hotstuff, meskipun pemimpin gagal dalam jumlah putaran berkelanjutan yang dapat dikonfigurasi atau jaringan mengalami periode asinkron, Shoal akan terus berjalan dengan kecepatan jaringan.
Responsivitas umum memberikan jaminan kemajuan yang jauh lebih baik pada periode asinkron dan ketika terjadi kegagalan pemimpin. Selama sinkronisasi dengan pemimpin yang lambat, karakteristik ini tidak dapat dibandingkan secara langsung, karena tergantung pada kecepatan pemimpin. Namun, mengingat mekanisme reputasi pemimpin, pemimpin yang lambat seharusnya jarang muncul di Shoal.
![Penjelasan detail tentang kerangka Shoal: Bagaimana mengurangi