# Shoal Framework: Aptos の Bullshark のレイテンシーを劇的に削減Aptos Labsは最近、DAG BFTにおける2つの重要なオープン問題を解決し、レイテンシーを大幅に低下させ、初めて決定的実用プロトコルにおいてタイムアウトの必要性を排除しました。全体として、故障がない場合にはBullsharkのレイテンシーが40%改善され、故障がある場合には80%改善されました。Shoalは、パイプラインとリーダーの評判メカニズムを通じて、Narwhalに基づくコンセンサスプロトコル(を強化するフレームワークです。パイプラインは、各ラウンドでアンカーを導入することでDAGソートのレイテンシーを減少させ、リーダーの評判は、アンカーを最も速い検証ノードに関連付けることでレイテンシーの問題をさらに改善します。加えて、リーダーの評判により、Shoalは非同期DAG構築を利用して全てのシナリオでタイムアウトを排除できます。これにより、Shoalは一般的な応答性の属性を提供し、通常必要とされる楽観的な応答を含んでいます。この技術は非常にシンプルで、順番に底層プロトコルの複数のインスタンスを実行することを含んでいます。したがって、Bullsharkをインスタンス化すると、リレー競技を行っている「サメ」の群れが得られます。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-8d6acd885bad7b8f911bdce15a7c884f(## 背景ブロックチェーンネットワークの高性能を追求する過程で、人々は通信の複雑さを低減することに注目してきました。しかし、このアプローチはスループットの著しい向上にはつながりませんでした。例えば、Diemの初期バージョンで実装されたHotstuffは3500 TPSにしか達せず、10万+ TPSの目標には遠く及びませんでした。最近の突破は、データ伝播がリーダー協定に基づく主要なボトルネックであることを認識し、並列化から利益を得ることができることに起因しています。Narwhalシステムはデータ伝播とコアコンセンサスロジックを分離し、すべての検証者が同時にデータを伝播し、コンセンサスコンポーネントは少量のメタデータを並べ替えるというアーキテクチャを提案しています。Narwhal論文は16万TPSのスループットを報告しています。以前、私たちはQuorum Storeについて紹介しました。これは、私たちのNarwhal実装がデータの伝播と合意を分離し、現在の合意プロトコルJolteonを拡張する方法です。Jolteonはリーダーに基づくプロトコルで、Tendermintの線形迅速経路とPBFTスタイルのビュー変更を組み合わせ、Hotstuffのレイテンシーを33%削減します。しかし、リーダーに基づく合意プロトコルはNarwhalのスループットの潜在能力を十分に活用できないことは明らかです。データの伝播と合意が分かれているにもかかわらず、スループットが増加するにつれて、Hotstuff/Jolteonのリーダーは依然として制限されています。そのため、私たちはNarwhal DAGの上にBullsharkを展開することを決定しました。これはゼロ通信オーバーヘッドの合意プロトコルです。不幸にも、Jolteonと比較して、Bullsharkの高スループットをサポートするDAG構造は50％のレイテンシーコストをもたらしました。本文では、ShoalがBullsharkのレイテンシーを大幅に削減する方法について説明します。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-f6b6281c928e3fa7a2412a480c9c1806(## DAG-BFTの背景Narwhal DAGの各頂点は、1つのラウンドに関連しています。第rラウンドに入るためには、バリデーターはまず第r-1ラウンドに属するn-f個の頂点を獲得する必要があります。各バリデーターは各ラウンドで1つの頂点をブロードキャストでき、各頂点は前のラウンドのn-f個の頂点を少なくとも参照する必要があります。ネットワークの非同期性により、異なるバリデーターは任意の時点でDAGの異なるローカルビューを観察する可能性があります。DAGの重要な特性は曖昧でないことです: もし二つの検証ノードがそれぞれのDAGのローカルビューにおいて同じ頂点vを持っているなら、それらは完全に同じvの因果履歴を持っています。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-b7ed8888da112bae8d34c0fdb338b138(## 一般的な注文追加の通信オーバーヘッドなしにDAG内のすべての頂点の総合的な順序を合意できます。そのために、DAG-Rider、Tusk、およびBullsharkの検証者は、DAGの構造を合意プロトコルとして解釈し、頂点は提案を、辺は投票を表します。DAG構造におけるグループの交差ロジックは異なるが、すべての既存のNarwhalベースのコンセンサスプロトコルは以下の構造を持っている：1. 予約されたアンカーポイント: 数ラウンドごとに)、Bullsharkの2ラウンド(ごとに、あらかじめ決まったリーダーがいます。リーダーの頂点はアンカーポイントと呼ばれます。2. ソートアンカー: バリデーターは独立しているが、決定論的にどのアンカーをソートし、どのアンカーをスキップするかを決定する。3. 因果の歴史の順序付け: バリデーターは順序付けられたアンカーポイントのリストを一つずつ処理し、各アンカーポイントについて、特定の決定論的ルールに従ってその因果の歴史の中のすべての以前の無秩序な頂点を順序付けます。安全性を満たすための鍵は、ステップ)2(において、すべての誠実な検証ノードが作成した順序付けられたアンカーポイントリストが同じ接頭辞を共有することを保証することです。Shoalでは、これらすべてのプロトコルに関して以下の観察を行いました:すべてのバリデーターが最初の順序付けられたアンカーポイントに同意しました。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-46d37add0d9e81b2f295edf8eddd907f(## BullsharkのレイテンシーBullsharkのレイテンシーは、DAG内の順序付けされたアンカーポイント間のラウンド数に依存します。Bullsharkの最も実用的な部分である同期バージョンは、非同期バージョンよりもレイテンシーが良好ですが、最適とは言えません。問題1:平均ブロックレイテンシー。Bullsharkでは、各偶数ラウンドにアンカーポイントがあり、各奇数ラウンドの頂点は投票として解釈されます。一般的なケースでは、アンカーポイントをソートするために2ラウンドのDAGが必要ですが、アンカーポイントの因果履歴にある頂点は、アンカーポイントがソートされるのを待つためにより多くのラウンドが必要です。一般的なケースでは、奇数ラウンドの頂点は3ラウンドを必要とし、偶数ラウンドの非アンカーポイントの頂点は4ラウンドを必要とします。問題2:故障状況レイテンシー。上記のレイテンシー分析は無故障状況に適用されますが、他方で、あるラウンドのリーダーが十分に速くアンカーポイントをブロードキャストできなかった場合、そのアンカーポイントをソートすることができず)、したがってスキップされます(。したがって、前のラウンドでソートされていないすべての頂点は、次のアンカーポイントがソートされるのを待たなければなりません。これは、特にBullsharkがリーダーを待つためにタイムアウトを使用するため、地理的複製ネットワークのパフォーマンスを大幅に低下させます。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-0b0928cb6240e994c1514c75e080a4b2(## ShoalフレームワークShoalはこの2つのレイテンシー問題を解決しました。Bullshark)または他のNarwhalベースのBFTプロトコル(をパイプラインで強化することにより、各ラウンドにアンカーポイントを持たせ、DAG内のすべての非アンカーポイントの頂点のレイテンシーを3ラウンドに削減します。Shoalはまた、DAG内にゼロコストのリーダー評判メカニズムを導入し、これにより迅速なリーダーを選択する傾向があります。## チャレンジDAGプロトコルの背景において、パイプラインとリーダーの評判は困難な問題と見なされています。その理由は次のとおりです:1. 以前のパイプラインの試みは、コアBullsharkロジックを修正しようとしましたが、これは本質的に不可能であるように思えます。2. DiemBFTにおけるリーダーの評判は導入され、Carouselで正式化されており、これはバリデーターの過去のパフォーマンスに基づいて将来のリーダー)Bullsharkのアンカー(を動的に選択するという考え方です。リーダーの地位に関する意見の相違がこれらのプロトコルの安全性に違反することはありませんが、Bullsharkではまったく異なる順序につながる可能性があり、これは動的かつ決定的にローテーションアンカーを選択することが合意を解決するために必要であるという問題の核心を引き起こします。バリデーターは、将来のアンカーを選択するために秩序のある履歴に関して合意に達する必要があります。問題の難易度の証拠として、私たちはBullsharkの実装、現在生産環境での実装がこれらの機能をサポートしていないことに注意しました。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-859e732e16c3eee0e2c93422474debc2(## プロトコル上述の課題が存在するにもかかわらず、解決策はシンプルな中に隠れていることが証明されています。Shoalでは、DAG上でのローカル計算を実行する能力に依存し、過去の情報を保存して再解釈する能力を実現しています。すべてのバリデーターが最初の順序付けられたアンカーポイントに同意するという核心的な洞察力を持って、Shoalは複数のBullsharkインスタンスを順次組み合わせてパイプライン処理を行い、)1(最初の順序付けられたアンカーポイントがインスタンスの切り替え点となり、)2(アンカーポイントの因果関係の歴史がリーダーの評判を計算するために使用されます。## パイプライン Vがあります。ShoalはBullsharkのインスタンスを一つずつ実行し、各インスタンスのアンカーはマッピングFによって事前に決定されます。各インスタンスはアンカーをソートし、次のインスタンスへの切り替えをトリガーします。最初、ShoalはDAGの第一ラウンドでBullsharkの最初のインスタンスを立ち上げ、最初の順序付けされたアンカーポイントを確定するまでそれを実行します。例えば、第rラウンドのように。全てのバリデーターはこのアンカーポイントに合意します。したがって、全てのバリデーターは第r+1ラウンドからDAGを再解釈することに確定的に同意できます。Shoalは第r+1ラウンドで新しいBullsharkインスタンスを立ち上げただけです。最良のシナリオでは、Shoalは各ラウンドでアンカーをソートすることを許可します。最初のラウンドのアンカーポイントは最初のインスタンスによってソートされます。次に、Shoalは第二ラウンドで新しいインスタンスを開始し、それ自体にアンカーがあり、そのアンカーはそのインスタンスによってソートされます。そして、第三ラウンドでは別の新しいインスタンスがアンカーポイントをソートし、その後プロセスは続きます。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-9f789cb669f6fcc244ea7ff7648e48b4(## リーダーの評判Bullsharkのソート中にアンカーポイントをスキップすると、レイテンシーが増加します。この場合、パイプライン技術は無力であり、前のインスタンスのアンカーポイントのソートが完了する前に新しいインスタンスを起動することができません。Shoalは、各検証ノードの最近の活動履歴に基づいて各検証ノードにスコアを割り当てる評判メカニズムを使用することで、将来的に失われたアンカーポイントを処理するリーダーが選ばれる可能性を低くします。プロトコルに応じて応答し参加する検証者は高得点を獲得しますが、そうでない場合は、検証ノードは低得点が割り当てられます。なぜなら、それはクラッシュする可能性があるか、遅いか、悪意があるからです。その理念は、スコアが更新されるたびに、確定的にラウンドからリーダーへの事前定義されたマッピングFを再計算し、高得点のリーダーに偏ることです。検証者が新しいマッピングに合意するためには、スコアについて合意し、スコアを導出するための歴史において合意に達する必要があります。Shoalでは、パイプラインとリーダーの評判が自然に結合されることができ、なぜならそれらはすべて同じコア技術、すなわち最初の順序付けられたアンカーポイントに合意した後にDAGを再解釈することを使用しているからです。実際のところ、唯一の違いは、第rラウンドでアンカーポイントをソートした後、検証者は第rラウンドで順序付けられたアンカーポイントの因果的履歴に基づいて、第r+1ラウンドから新しいマッピングF'を計算する必要があるということです。それから、検証ノードは第r+1ラウンドから更新されたアンカーポイント選択関数F'を使用してBullsharkの新しいインスタンスを実行します。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-1baf540693f376d93cb18ef3193593cc(## これ以上のタイムアウトはありませんタイムアウトは、すべてのリーダーに基づく決定的部分同期BFT実装において重要な役割を果たします。しかし、それらがもたらす複雑さは、管理および観察する必要のある内部状態の数を増加させ、デバッグプロセスの複雑さを増し、より多くの可観測性技術を必要とします。タイムアウトはレイテンシーを著しく増加させる可能性があり、適切に設定することが非常に重要であり、通常は動的に調整する必要があります。これは環境)ネットワーク(に高度に依存しています。次のリーダーに移行する前に、プロトコルは障害が発生したリーダーに対して完全なタイムアウトレイテンシー罰を支払います。
ShoalフレームワークがAptosブロックチェーンBullsharkレイテンシーを大幅にドロップします。
Shoal Framework: Aptos の Bullshark のレイテンシーを劇的に削減
Aptos Labsは最近、DAG BFTにおける2つの重要なオープン問題を解決し、レイテンシーを大幅に低下させ、初めて決定的実用プロトコルにおいてタイムアウトの必要性を排除しました。全体として、故障がない場合にはBullsharkのレイテンシーが40%改善され、故障がある場合には80%改善されました。
Shoalは、パイプラインとリーダーの評判メカニズムを通じて、Narwhalに基づくコンセンサスプロトコル(を強化するフレームワークです。パイプラインは、各ラウンドでアンカーを導入することでDAGソートのレイテンシーを減少させ、リーダーの評判は、アンカーを最も速い検証ノードに関連付けることでレイテンシーの問題をさらに改善します。加えて、リーダーの評判により、Shoalは非同期DAG構築を利用して全てのシナリオでタイムアウトを排除できます。これにより、Shoalは一般的な応答性の属性を提供し、通常必要とされる楽観的な応答を含んでいます。
この技術は非常にシンプルで、順番に底層プロトコルの複数のインスタンスを実行することを含んでいます。したがって、Bullsharkをインスタンス化すると、リレー競技を行っている「サメ」の群れが得られます。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
背景
ブロックチェーンネットワークの高性能を追求する過程で、人々は通信の複雑さを低減することに注目してきました。しかし、このアプローチはスループットの著しい向上にはつながりませんでした。例えば、Diemの初期バージョンで実装されたHotstuffは3500 TPSにしか達せず、10万+ TPSの目標には遠く及びませんでした。
最近の突破は、データ伝播がリーダー協定に基づく主要なボトルネックであることを認識し、並列化から利益を得ることができることに起因しています。Narwhalシステムはデータ伝播とコアコンセンサスロジックを分離し、すべての検証者が同時にデータを伝播し、コンセンサスコンポーネントは少量のメタデータを並べ替えるというアーキテクチャを提案しています。Narwhal論文は16万TPSのスループットを報告しています。
以前、私たちはQuorum Storeについて紹介しました。これは、私たちのNarwhal実装がデータの伝播と合意を分離し、現在の合意プロトコルJolteonを拡張する方法です。Jolteonはリーダーに基づくプロトコルで、Tendermintの線形迅速経路とPBFTスタイルのビュー変更を組み合わせ、Hotstuffのレイテンシーを33%削減します。しかし、リーダーに基づく合意プロトコルはNarwhalのスループットの潜在能力を十分に活用できないことは明らかです。データの伝播と合意が分かれているにもかかわらず、スループットが増加するにつれて、Hotstuff/Jolteonのリーダーは依然として制限されています。
そのため、私たちはNarwhal DAGの上にBullsharkを展開することを決定しました。これはゼロ通信オーバーヘッドの合意プロトコルです。不幸にも、Jolteonと比較して、Bullsharkの高スループットをサポートするDAG構造は50％のレイテンシーコストをもたらしました。
本文では、ShoalがBullsharkのレイテンシーを大幅に削減する方法について説明します。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
DAG-BFTの背景
Narwhal DAGの各頂点は、1つのラウンドに関連しています。第rラウンドに入るためには、バリデーターはまず第r-1ラウンドに属するn-f個の頂点を獲得する必要があります。各バリデーターは各ラウンドで1つの頂点をブロードキャストでき、各頂点は前のラウンドのn-f個の頂点を少なくとも参照する必要があります。ネットワークの非同期性により、異なるバリデーターは任意の時点でDAGの異なるローカルビューを観察する可能性があります。
DAGの重要な特性は曖昧でないことです: もし二つの検証ノードがそれぞれのDAGのローカルビューにおいて同じ頂点vを持っているなら、それらは完全に同じvの因果履歴を持っています。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
一般的な注文
追加の通信オーバーヘッドなしにDAG内のすべての頂点の総合的な順序を合意できます。そのために、DAG-Rider、Tusk、およびBullsharkの検証者は、DAGの構造を合意プロトコルとして解釈し、頂点は提案を、辺は投票を表します。
DAG構造におけるグループの交差ロジックは異なるが、すべての既存のNarwhalベースのコンセンサスプロトコルは以下の構造を持っている：
予約されたアンカーポイント: 数ラウンドごとに)、Bullsharkの2ラウンド(ごとに、あらかじめ決まったリーダーがいます。リーダーの頂点はアンカーポイントと呼ばれます。
ソートアンカー: バリデーターは独立しているが、決定論的にどのアンカーをソートし、どのアンカーをスキップするかを決定する。
因果の歴史の順序付け: バリデーターは順序付けられたアンカーポイントのリストを一つずつ処理し、各アンカーポイントについて、特定の決定論的ルールに従ってその因果の歴史の中のすべての以前の無秩序な頂点を順序付けます。
安全性を満たすための鍵は、ステップ)2(において、すべての誠実な検証ノードが作成した順序付けられたアンカーポイントリストが同じ接頭辞を共有することを保証することです。Shoalでは、これらすべてのプロトコルに関して以下の観察を行いました:
すべてのバリデーターが最初の順序付けられたアンカーポイントに同意しました。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Bullsharkのレイテンシー
Bullsharkのレイテンシーは、DAG内の順序付けされたアンカーポイント間のラウンド数に依存します。Bullsharkの最も実用的な部分である同期バージョンは、非同期バージョンよりもレイテンシーが良好ですが、最適とは言えません。
問題1:平均ブロックレイテンシー。Bullsharkでは、各偶数ラウンドにアンカーポイントがあり、各奇数ラウンドの頂点は投票として解釈されます。一般的なケースでは、アンカーポイントをソートするために2ラウンドのDAGが必要ですが、アンカーポイントの因果履歴にある頂点は、アンカーポイントがソートされるのを待つためにより多くのラウンドが必要です。一般的なケースでは、奇数ラウンドの頂点は3ラウンドを必要とし、偶数ラウンドの非アンカーポイントの頂点は4ラウンドを必要とします。
問題2:故障状況レイテンシー。上記のレイテンシー分析は無故障状況に適用されますが、他方で、あるラウンドのリーダーが十分に速くアンカーポイントをブロードキャストできなかった場合、そのアンカーポイントをソートすることができず)、したがってスキップされます(。したがって、前のラウンドでソートされていないすべての頂点は、次のアンカーポイントがソートされるのを待たなければなりません。これは、特にBullsharkがリーダーを待つためにタイムアウトを使用するため、地理的複製ネットワークのパフォーマンスを大幅に低下させます。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Shoalフレームワーク
Shoalはこの2つのレイテンシー問題を解決しました。Bullshark)または他のNarwhalベースのBFTプロトコル(をパイプラインで強化することにより、各ラウンドにアンカーポイントを持たせ、DAG内のすべての非アンカーポイントの頂点のレイテンシーを3ラウンドに削減します。Shoalはまた、DAG内にゼロコストのリーダー評判メカニズムを導入し、これにより迅速なリーダーを選択する傾向があります。
チャレンジ
DAGプロトコルの背景において、パイプラインとリーダーの評判は困難な問題と見なされています。その理由は次のとおりです:
以前のパイプラインの試みは、コアBullsharkロジックを修正しようとしましたが、これは本質的に不可能であるように思えます。
DiemBFTにおけるリーダーの評判は導入され、Carouselで正式化されており、これはバリデーターの過去のパフォーマンスに基づいて将来のリーダー)Bullsharkのアンカー(を動的に選択するという考え方です。リーダーの地位に関する意見の相違がこれらのプロトコルの安全性に違反することはありませんが、Bullsharkではまったく異なる順序につながる可能性があり、これは動的かつ決定的にローテーションアンカーを選択することが合意を解決するために必要であるという問題の核心を引き起こします。バリデーターは、将来のアンカーを選択するために秩序のある履歴に関して合意に達する必要があります。
問題の難易度の証拠として、私たちはBullsharkの実装、現在生産環境での実装がこれらの機能をサポートしていないことに注意しました。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
プロトコル
上述の課題が存在するにもかかわらず、解決策はシンプルな中に隠れていることが証明されています。
Shoalでは、DAG上でのローカル計算を実行する能力に依存し、過去の情報を保存して再解釈する能力を実現しています。すべてのバリデーターが最初の順序付けられたアンカーポイントに同意するという核心的な洞察力を持って、Shoalは複数のBullsharkインスタンスを順次組み合わせてパイプライン処理を行い、)1(最初の順序付けられたアンカーポイントがインスタンスの切り替え点となり、)2(アンカーポイントの因果関係の歴史がリーダーの評判を計算するために使用されます。
パイプライン
Vがあります。ShoalはBullsharkのインスタンスを一つずつ実行し、各インスタンスのアンカーはマッピングFによって事前に決定されます。各インスタンスはアンカーをソートし、次のインスタンスへの切り替えをトリガーします。
最初、ShoalはDAGの第一ラウンドでBullsharkの最初のインスタンスを立ち上げ、最初の順序付けされたアンカーポイントを確定するまでそれを実行します。例えば、第rラウンドのように。全てのバリデーターはこのアンカーポイントに合意します。したがって、全てのバリデーターは第r+1ラウンドからDAGを再解釈することに確定的に同意できます。Shoalは第r+1ラウンドで新しいBullsharkインスタンスを立ち上げただけです。
最良のシナリオでは、Shoalは各ラウンドでアンカーをソートすることを許可します。最初のラウンドのアンカーポイントは最初のインスタンスによってソートされます。次に、Shoalは第二ラウンドで新しいインスタンスを開始し、それ自体にアンカーがあり、そのアンカーはそのインスタンスによってソートされます。そして、第三ラウンドでは別の新しいインスタンスがアンカーポイントをソートし、その後プロセスは続きます。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
リーダーの評判
Bullsharkのソート中にアンカーポイントをスキップすると、レイテンシーが増加します。この場合、パイプライン技術は無力であり、前のインスタンスのアンカーポイントのソートが完了する前に新しいインスタンスを起動することができません。Shoalは、各検証ノードの最近の活動履歴に基づいて各検証ノードにスコアを割り当てる評判メカニズムを使用することで、将来的に失われたアンカーポイントを処理するリーダーが選ばれる可能性を低くします。プロトコルに応じて応答し参加する検証者は高得点を獲得しますが、そうでない場合は、検証ノードは低得点が割り当てられます。なぜなら、それはクラッシュする可能性があるか、遅いか、悪意があるからです。
その理念は、スコアが更新されるたびに、確定的にラウンドからリーダーへの事前定義されたマッピングFを再計算し、高得点のリーダーに偏ることです。検証者が新しいマッピングに合意するためには、スコアについて合意し、スコアを導出するための歴史において合意に達する必要があります。
Shoalでは、パイプラインとリーダーの評判が自然に結合されることができ、なぜならそれらはすべて同じコア技術、すなわち最初の順序付けられたアンカーポイントに合意した後にDAGを再解釈することを使用しているからです。
実際のところ、唯一の違いは、第rラウンドでアンカーポイントをソートした後、検証者は第rラウンドで順序付けられたアンカーポイントの因果的履歴に基づいて、第r+1ラウンドから新しいマッピングF'を計算する必要があるということです。それから、検証ノードは第r+1ラウンドから更新されたアンカーポイント選択関数F'を使用してBullsharkの新しいインスタンスを実行します。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
これ以上のタイムアウトはありません
タイムアウトは、すべてのリーダーに基づく決定的部分同期BFT実装において重要な役割を果たします。しかし、それらがもたらす複雑さは、管理および観察する必要のある内部状態の数を増加させ、デバッグプロセスの複雑さを増し、より多くの可観測性技術を必要とします。
タイムアウトはレイテンシーを著しく増加させる可能性があり、適切に設定することが非常に重要であり、通常は動的に調整する必要があります。これは環境)ネットワーク(に高度に依存しています。次のリーダーに移行する前に、プロトコルは障害が発生したリーダーに対して完全なタイムアウトレイテンシー罰を支払います。