Kerangka Shoal secara signifikan menurunkan latensi Bullshark on-chain Aptos

Kerangka Shoal: Bagaimana Drop latensi Bullshark di Aptos

Aptos labs telah menyelesaikan dua masalah terbuka penting dalam DAG BFT, secara signifikan menurunkan latensi, dan untuk pertama kalinya menghilangkan kebutuhan akan timeout dalam protokol nyata yang deterministik. Secara keseluruhan, kerangka Shoal meningkatkan latensi Bullshark sebesar 40% dalam kondisi tanpa kegagalan, dan meningkatkan 80% dalam kondisi dengan kegagalan.

Shoal adalah sebuah protokol konsensus berbasis Narwhal ( yang meningkatkan melalui pipeline dan reputasi pemimpin seperti kerangka DAG-Rider, Tusk, Bullshark ). Pipeline mengurangi latensi pengurutan DAG dengan memperkenalkan satu titik jangkar setiap putaran, sementara reputasi pemimpin lebih lanjut memperbaiki masalah latensi dengan memastikan bahwa titik jangkar terkait dengan node verifikasi tercepat. Selain itu, reputasi pemimpin memungkinkan Shoal memanfaatkan konstruksi DAG asinkron untuk menghilangkan timeout dalam semua skenario. Ini memungkinkan Shoal untuk menyediakan atribut yang kami sebut sebagai respons universal, yang mencakup respons optimis yang biasanya diperlukan.

Teknologi Shoal sangat sederhana, melibatkan menjalankan beberapa instance dari protokol dasar secara berurutan satu per satu. Oleh karena itu, ketika diinstansiasi dengan Bullshark, kita mendapatkan sekelompok "ikan hiu" yang melakukan perlombaan estafet.

Penjelasan Lengkap tentang Kerangka Shoal: Bagaimana Mengurangi latensi Bullshark di Aptos?

Latar Belakang

Dalam mengejar kinerja tinggi jaringan blockchain, orang selalu memperhatikan Drop kompleksitas komunikasi. Namun, pendekatan ini tidak menghasilkan peningkatan throughput yang signifikan. Misalnya, Hotstuff yang diimplementasikan dalam versi awal Diem hanya mencapai 3500 TPS, jauh di bawah target 100k+ TPS.

Terobosan terbaru berasal dari pemahaman bahwa penyebaran data adalah kendala utama yang didasarkan pada protokol pemimpin, dan dapat memperoleh manfaat dari paralelisasi. Sistem Narwhal memisahkan penyebaran data dari logika konsensus inti, mengusulkan arsitektur di mana semua validator menyebarkan data secara bersamaan, sementara komponen konsensus hanya mengurutkan sejumlah kecil metadata. Makalah Narwhal melaporkan throughput 160.000 TPS.

Aptos sebelumnya memperkenalkan Quorum Store, ini adalah implementasi Narwhal mereka, yang memisahkan penyebaran data dari konsensus, dan digunakan untuk memperluas protokol konsensus saat ini Jolteon. Jolteon adalah protokol berbasis pemimpin yang menggabungkan jalur cepat linier Tendermint dan perubahan tampilan gaya PBFT, yang dapat mengurangi latensi Hotstuff sebesar 33%. Namun, protokol konsensus berbasis pemimpin tidak dapat memanfaatkan potensi throughput Narwhal secara maksimal. Meskipun penyebaran data dipisahkan dari konsensus, pemimpin Hotstuff/Jolteon tetap terbatas seiring dengan peningkatan throughput.

Oleh karena itu, Aptos memutuskan untuk menerapkan Bullshark di atas Narwhal DAG, sebuah protokol konsensus dengan nol biaya komunikasi. Sayangnya, dibandingkan dengan Jolteon, struktur DAG yang mendukung Bullshark dengan throughput tinggi membawa biaya latensi sebesar 50%.

Artikel ini memperkenalkan bagaimana Shoal secara signifikan mengurangi latensi Bullshark.

Latar Belakang DAG-BFT

Setiap simpul dalam Narwhal DAG terkait dengan satu 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 n-f simpul dari putaran sebelumnya. Karena asinkronisitas jaringan, validator yang berbeda mungkin mengamati pandangan lokal DAG yang berbeda pada waktu yang berbeda.

Salah satu atribut kunci dari DAG tidak ambigu: jika dua node validasi memiliki vertex v yang sama dalam pandangan lokal DAG mereka, maka mereka memiliki sejarah sebab-akibat v yang sepenuhnya sama.

Penjelasan Detail Shoal Framework: Bagaimana Mengurangi latensi Bullshark di Aptos?

Urutan Total

Konsensus tentang urutan total semua simpul dalam DAG dapat dicapai tanpa biaya komunikasi tambahan. Untuk itu, 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 dalam struktur DAG berbeda, semua protokol konsensus berbasis Narwhal yang ada memiliki struktur berikut:

  1. Titik jangkar yang dijadwalkan: Setiap beberapa putaran ( seperti dua putaran di Bullshark ) akan ada seorang pemimpin yang ditentukan sebelumnya, puncak pemimpin disebut titik jangkar.

  2. titik jangkar urut: validator secara independen tetapi pasti memutuskan urutan titik jangkar mana yang akan diurutkan dan mana yang akan dilewati.

  3. urutan sejarah kausal: validator memproses satu per satu daftar titik jangkar mereka yang terurut, dan untuk setiap titik jangkar, mengurutkan semua simpul tidak terurut sebelumnya dalam sejarah kausal mereka berdasarkan beberapa aturan deterministik.

Kunci untuk memenuhi keamanan adalah memastikan bahwa dalam langkah di atas (2), semua node validasi yang jujur membuat daftar jangkar terurut, sehingga semua daftar berbagi awalan yang sama. Di Shoal, berikut adalah pengamatan terhadap semua protokol di atas:

Semua validator setuju pada titik jangkar yang terurut pertama.

Penjelasan lengkap tentang kerangka Shoal: Bagaimana cara mengurangi latensi Bullshark di Aptos?

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 satu titik jangkar, dan setiap titik puncak pada putaran ganjil diinterpretasikan sebagai suara. Dalam kasus umum, dibutuhkan dua putaran DAG untuk mengurutkan titik jangkar, namun, titik puncak dalam sejarah kausal dari anchor membutuhkan lebih banyak putaran untuk menunggu anchor diurutkan. Dalam kasus umum, titik puncak pada putaran ganjil membutuhkan tiga putaran, sementara titik puncak non-anchor pada putaran genap membutuhkan empat putaran.

Pertanyaan 2: Kasus kegagalan latensi, analisis latensi di atas berlaku untuk situasi tanpa kegagalan, di sisi lain, jika pemimpin dalam satu putaran tidak cukup cepat untuk menyiarkan titik jangkar, maka tidak dapat mengurutkan titik jangkar ( sehingga dilewati ), sehingga semua simpul yang tidak terurut dalam beberapa putaran sebelumnya harus menunggu titik jangkar berikutnya diurutkan. Ini akan secara signifikan menurunkan kinerja jaringan replikasi geografis, terutama karena Bullshark timeout digunakan untuk menunggu pemimpin.

Penjelasan lengkap tentang kerangka Shoal: Bagaimana cara mengurangi latensi Bullshark di Aptos?

Kerangka Shoal

Shoal menyelesaikan dua masalah latensi ini, dengan meningkatkan Bullshark( atau protokol BFT berbasis Narwhal lainnya) melalui alur kerja, memungkinkan adanya satu titik jangkar di setiap putaran, dan mengurangi latensi semua vertex non-jangkar di DAG menjadi tiga putaran. Shoal juga memperkenalkan mekanisme reputasi pemimpin tanpa biaya di DAG, yang membuat pemilihan lebih condong pada pemimpin yang cepat.

Tantangan

Dalam konteks protokol DAG, pipeline dan reputasi pemimpin dianggap sebagai masalah yang sulit, alasannya adalah sebagai berikut:

  1. Sebelumnya, jalur aliran berusaha untuk mengubah logika inti Bullshark, tetapi ini tampaknya secara esensial tidak mungkin.

  2. Reputasi pemimpin diperkenalkan dalam DiemBFT dan resmi dalam Carousel, yang memilih pemimpin masa depan secara dinamis berdasarkan kinerja validator di masa lalu, ide dari jangkar di Bullshark (. Meskipun perbedaan dalam identitas pemimpin tidak melanggar keamanan dalam protokol ini, di Bullshark, ini dapat menyebabkan urutan yang sama sekali berbeda, yang mengarah ke inti masalah, yaitu memilih jangkar roda dengan cara dinamis dan deterministik diperlukan untuk menyelesaikan konsensus, dan validator perlu mencapai kesepakatan tentang sejarah terurut untuk memilih jangkar di masa depan.

Sebagai bukti tingkat kesulitan masalah, implementasi Bullshark, termasuk yang saat ini ada di lingkungan produksi, tidak mendukung fitur-fitur ini.

![Penjelasan mendetail tentang kerangka Shoal: Bagaimana mengurangi latensi Bullshark di Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(

Protokol

Meskipun ada tantangan di atas, seperti kata pepatah, fakta menunjukkan bahwa solusi tersembunyi di balik yang sederhana.

Di Shoal, kami mengandalkan kemampuan untuk menjalankan komputasi lokal di atas DAG dan mewujudkan kemampuan untuk menyimpan dan menafsirkan kembali informasi dari beberapa putaran sebelumnya. Dengan semua validator setuju pada wawasan inti tentang titik jangkar terurut pertama, Shoal secara berurutan menggabungkan beberapa instance Bullshark untuk memprosesnya secara pipeline, sehingga ) titik jangkar terurut pertama adalah titik peralihan dari instance, serta ( sejarah kausal dari titik jangkar digunakan untuk menghitung reputasi pemimpin.

) jalur aliran

V yang memetakan putaran ke pemimpin. Shoal menjalankan instance Bullshark satu per satu, sehingga untuk setiap instance, jangkar ditentukan sebelumnya oleh pemetaan F. Setiap instance mengurutkan satu jangkar, yang akan memicu perpindahan ke instance berikutnya.

Pada awalnya, Shoal meluncurkan instance pertama Bullshark dalam putaran pertama DAG dan menjalankannya hingga titik jangkar terurut pertama ditentukan, misalnya di putaran r. Semua validator setuju dengan titik jangkar ini. Oleh karena itu, semua validator dapat dengan pasti setuju untuk menafsirkan ulang DAG mulai dari putaran r+1. Shoal hanya meluncurkan instance Bullshark baru di putaran r+1.

Dalam kasus terbaik, ini memungkinkan Shoal untuk mengurutkan sebuah jangkar di setiap putaran. Jangkar pada putaran pertama diurutkan berdasarkan instance pertama. Kemudian, Shoal memulai instance baru pada putaran kedua, yang sendiri memiliki sebuah jangkar, yang diurutkan oleh instance tersebut, lalu, instance baru lainnya mengurutkan jangkar pada putaran ketiga, dan kemudian proses ini berlanjut.

Penjelasan lengkap tentang kerangka Shoal: Bagaimana cara mengurangi latensi Bullshark di Aptos?

Reputasi Pemimpin

Selama periode pengurutan Bullshark, melewatkan titik jangkar akan meningkatkan latensi. Dalam kasus ini, teknologi pipeline tidak dapat berfungsi, karena tidak mungkin memulai instance baru sebelum titik jangkar pengurutan instance 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 masing-masing node validasi menggunakan mekanisme reputasi. Validator yang merespons dan berpartisipasi dalam protokol akan mendapatkan skor tinggi, jika tidak, node validasi akan diberikan skor rendah, karena mungkin mengalami keruntuhan, lambat, atau berperilaku jahat.

Konsepnya adalah untuk secara deterministik menghitung kembali pemetaan F yang telah ditentukan dari putaran ke pemimpin setiap kali pembaruan skor, yang menguntungkan pemimpin dengan skor yang 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 menghasilkan skor.

Di Shoal, pipeline dan reputasi pemimpin dapat secara alami bergabung, 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 r, validator hanya perlu menghitung pemetaan baru F' mulai dari putaran r+1 berdasarkan sejarah kausal titik jangkar yang terurut di putaran r. Kemudian, node validator mulai menggunakan fungsi pemilihan titik jangkar yang diperbarui F' untuk menjalankan instance baru Bullshark mulai dari putaran r+1.

Penjelasan lengkap tentang kerangka Shoal: Bagaimana cara mengurangi latensi Bullshark di Aptos?

Tidak ada lagi waktu habis

Waktu habis memainkan peran penting dalam semua implementasi BFT sinkron 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.

Timeout juga akan secara signifikan meningkatkan latensi, karena penting untuk mengonfigurasinya dengan tepat, dan sering kali perlu disesuaikan secara dinamis, karena sangat bergantung pada lingkungan ( jaringan ). Sebelum beralih ke pemimpin berikutnya, protokol akan membayar hukuman latensi timeout penuh untuk pemimpin yang gagal. Oleh karena itu, pengaturan timeout tidak boleh terlalu konservatif, tetapi jika waktu timeout terlalu singkat, protokol mungkin

APT1.21%
Lihat Asli
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.
  • Hadiah
  • 7
  • Bagikan
Komentar
0/400
just_here_for_vibesvip
· 8jam yang lalu
Kinerja meningkat sebanyak ini? Ayo gulung!
Lihat AsliBalas0
BridgeNomadvip
· 07-26 20:35
hmm... latensi yang ditingkatkan terlihat bagus tetapi masih perlu memvalidasi vektor kepercayaan sejujurnya
Lihat AsliBalas0
BearMarketHustlervip
· 07-26 20:30
Wah, Aptos cukup hebat ya!
Lihat AsliBalas0
Whale_Whisperervip
· 07-26 20:28
Perbaikan ini luar biasa, simpan sedikit apt dulu.
Lihat AsliBalas0
CryptoMotivatorvip
· 07-26 20:17
Aptos gogo~latensi 80% itu memang hebat
Lihat AsliBalas0
StakeHouseDirectorvip
· 07-26 20:17
pro ah, optimasi kinerja ini benar-benar hebat
Lihat AsliBalas0
Layer2Observervip
· 07-26 20:08
latensi meningkat 80% agak hardcore, menantikan data pengujian
Lihat AsliBalas0
Perdagangkan Kripto Di Mana Saja Kapan Saja
qrCode
Pindai untuk mengunduh aplikasi Gate
Komunitas
Bahasa Indonesia
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)