# Shoalフレームワーク: AptosにおけるBullsharkコンセンサスレイテンシーの最適化Aptos Labsは最近、DAG BFTにおける2つの重要なオープン問題を解決し、レイテンシーを大幅に減少させ、初めて決定論的実際のプロトコルにおけるタイムアウトの必要性を排除しました。全体として、故障がない場合にBullsharkのレイテンシーを40%改善し、故障がある場合は80%改善しました。Shoalは、パイプライン処理とリーダーの評判メカニズムを通じて、Narwhalに基づくコンセンサスプロトコル(を強化するフレームワークです。パイプラインは、各ラウンドにおいてアンカーポイントを導入することでDAGのソートレイテンシーを削減し、リーダーの評判は、アンカーポイントが最速の検証ノードと関連付けられることを保証することでレイテンシーの問題をさらに改善します。さらに、リーダーの評判により、Shoalは非同期DAG構造を利用して、すべてのシナリオでタイムアウトを排除することができます。これにより、Shoalは普遍的な応答特性を提供し、通常必要とされる楽観的な応答を含んでいます。Shoalの技術は比較的シンプルで、主に順番に1つずつ基盤プロトコルの複数のインスタンスを実行します。Bullsharkをインスタンス化すると、一群の"サメ"がリレーを行います。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-8d6acd885bad7b8f911bdce15a7c884f(## 背景と動機ブロックチェーンネットワークの高性能を追求する過程で、通信の複雑さを低減することは常に注目のポイントでした。しかし、この方法は顕著なスループット向上をもたらしませんでした。例えば、初期バージョンのDiemで実装されたHotstuffは、3500 TPSにしか達せず、100k+ TPSの目標を大きく下回っています。最近のブレークスルーは、データ伝播がリーダーのプロトコルに基づく主要なボトルネックであることを認識し、並列化から恩恵を受けることができるようになったことに起因しています。Narwhalシステムはデータ伝播とコアのコンセンサスロジックを分離し、すべてのバリデーターが同時にデータを伝播し、コンセンサスコンポーネントは少量のメタデータのみをソートするというアーキテクチャを提案しています。Narwhal論文は160,000 TPSのスループットを報告しています。Aptosは以前にQuorum Store、すなわちNarwhalの実装を紹介し、データの伝播とコンセンサスを分離し、これを使用して現在のコンセンサスプロトコルJolteonを拡張する方法を説明しました。Jolteonはリーダーに基づくプロトコルで、Tendermintの線形迅速パスとPBFTスタイルのビュー変更を組み合わせて、Hotstuffのレイテンシーを33%削減します。しかし、明らかにリーダーに基づくコンセンサスプロトコルはNarwhalのスループットの潜在能力を十分に活用できません。データの伝播とコンセンサスを分けたにもかかわらず、スループットの増加に伴い、Hotstuff/Jolteonのリーダーは依然として制限されています。したがって、AptosはNarwhal DAGの上にBullsharkを展開することを決定しました。これは、ゼロ通信オーバーヘッドのコンセンサスプロトコルです。残念ながら、Jolteonと比較して、Bullsharkの高スループットをサポートするDAG構造は50%のレイテンシーコストをもたらします。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-f6b6281c928e3fa7a2412a480c9c1806(## DAG-BFTの背景Narwhal DAGの各頂点は、あるラウンドに関連付けられています。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において、上記のすべてのプロトコルについて以下の観察がなされます：全ての検証者は最初の順序付けられたアンカーポイントに同意します。## BullsharkのレイテンシーBullsharkのレイテンシーはDAGにおける順序付きアンカー間のラウンド数によって決まります。Bullsharkの最も実用的な部分は、同期版が非同期版よりもレイテンシーが良好ですが、依然として最適ではありません。主に2つの問題があります:1. 平均ブロックレイテンシー: Bullsharkでは、各偶数ラウンドにアンカーがあり、各奇数ラウンドの頂点は投票として解釈されます。一般的なケースでは、アンカーをソートするには2ラウンドのDAGが必要ですが、アンカーの因果歴の頂点はアンカーがソートされるのを待つためにより多くのラウンドを必要とします。一般的なケースでは、奇数ラウンドの頂点は3ラウンドを必要とし、偶数ラウンドの非アンカートップは4ラウンドを必要とします。2. 障害事例レイテンシー: もし一回のリーダーが十分に速くアンカーポイントをブロードキャストできなかった場合、アンカーポイントをソートすることができず)スキップされます(。前の数回のすべての未ソートの頂点は、次のアンカーポイントがソートされるのを待たなければなりません。これは、特にBullsharkがリーダーを待つためにタイムアウトを使用するため、地理的複製ネットワークのパフォーマンスを著しく低下させます。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-46d37add0d9e81b2f295edf8eddd907f(## ShoalフレームワークShoalは、Bullshark)やその他のNarwhalベースのBFTプロトコル(の処理をパイプライン化することで、各ラウンドにおいてアンカーポイントを持たせ、DAG内のすべての非アンカーポイントのレイテンシーを3ラウンドに削減しました。Shoalはまた、DAG内にゼロコストのリーダーの評判メカニズムを導入し、選択を迅速なリーダーに偏らせています。## チャレンジDAGプロトコルの背景において、パイプライン処理とリーダーの評判は難しい問題と考えられています。その理由は以下の通りです:1. 以前のパイプライン処理はコアBullsharkロジックを変更しようとしましたが、これは本質的に不可能なようです。2. リーダーの評判はDiemBFTに導入され、Carouselで正式化されており、バリデーターの過去のパフォーマンスに基づいて将来のリーダー)Bullsharkのアンカー(を動的に選択するという考え方です。リーダーのアイデンティティに関して意見の相違があることは、これらのプロトコルの安全性を侵害するものではありませんが、Bullsharkでは、まったく異なる順序につながる可能性があります。これは、動的かつ決定的にホイールアンカーを選択することがコンセンサスを解決するために必要であり、バリデーターが将来のアンカーを選択するために秩序ある歴史に合意する必要があるという問題の核心を浮き彫りにします。## プロトコル上述の課題が存在するにもかかわらず、解決策はシンプルなところに隠れています。Shoalでは、DAG上でローカル計算を実行する能力を利用して、前のラウンドの情報を保存し再解釈する能力を実現しました。すべてのバリデーターが最初の順序付きアンカーポイントに同意するという核心的な洞察を持って、Shoalは複数のBullsharkインスタンスを順次組み合わせてパイプライン処理を行います。1. 最初のオーダーアンカーはインスタンスの切り替えポイントです。2. アンカーの因果関係の歴史はリーダーの評判を計算するために使用されます。) パイプライン処理Bullsharkに似て、バリデーターは潜在的なアンカーに事前にコンセンサスを達成します。これは、ラウンドをリーダーにマッピングする既知のマッピングF:R → Vがあることを意味します。ShoalはBullsharkのインスタンスを1つずつ実行し、各インスタンスに対してアンカーはマッピング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-0b0928cb6240e994c1514c75e080a4b2() リーダーの評判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-859e732e16c3eee0e2c93422474debc2() 超過時間は必要ありませんタイムアウトは、リーダーベースの決定的部分同期BFT実装において重要な役割を果たします。しかし、これらが導入する複雑性は、管理および観察が必要な内部状態の数を増加させ、デバッグプロセスの複雑性を高め、さらに多くの可観測性技術を必要とします。タイムアウトはレイテンシーを大幅に増加させる可能性があるため、それらを適切に設定することが非常に重要で、環境###ネットワーク(に高度に依存しているため、通常は動的に調整する必要があります。次のリーダーに移行する前に、プロトコルは故障したリーダーに対して完全なタイムアウトレイテンシーの罰則を支払います。したがって、タイムアウト設定は過度に保守的であってはならず、しかしタイムアウト時間が短すぎると、プロトコルは優れたリーダーをスキップする可能性があります。残念ながら、リーダーに基づくプロトコル)（HotstuffやJolteon(のように）は、リーダーが故障するたびにプロトコルが進行することを保証するために、タイムアウトを必要とします。タイムアウトがなければ、クラッシュしたリーダーでさえもプロトコルを永遠に停止させる可能性があります。非同期の期間中に故障したリーダーと遅いリーダーを区別できないため、タイムアウトは、共通のコンセンサスアクティビティがない状態で、検証ノードがすべてのリーダーを変更するのを引き起こす可能性があります。Bullsharkでは、レイテンシーはDAG構築に使用され、同期中に誠実なリーダーがDAにアンカーポイントを追加することを保証します。
Aptosの革新的なShoalフレームワーク：Bullsharkコンセンサスに40-80%のレイテンシー最適化をもたらす
Shoalフレームワーク: AptosにおけるBullsharkコンセンサスレイテンシーの最適化
Aptos Labsは最近、DAG BFTにおける2つの重要なオープン問題を解決し、レイテンシーを大幅に減少させ、初めて決定論的実際のプロトコルにおけるタイムアウトの必要性を排除しました。全体として、故障がない場合にBullsharkのレイテンシーを40%改善し、故障がある場合は80%改善しました。
Shoalは、パイプライン処理とリーダーの評判メカニズムを通じて、Narwhalに基づくコンセンサスプロトコル(を強化するフレームワークです。パイプラインは、各ラウンドにおいてアンカーポイントを導入することでDAGのソートレイテンシーを削減し、リーダーの評判は、アンカーポイントが最速の検証ノードと関連付けられることを保証することでレイテンシーの問題をさらに改善します。さらに、リーダーの評判により、Shoalは非同期DAG構造を利用して、すべてのシナリオでタイムアウトを排除することができます。これにより、Shoalは普遍的な応答特性を提供し、通常必要とされる楽観的な応答を含んでいます。
Shoalの技術は比較的シンプルで、主に順番に1つずつ基盤プロトコルの複数のインスタンスを実行します。Bullsharkをインスタンス化すると、一群の"サメ"がリレーを行います。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
背景と動機
ブロックチェーンネットワークの高性能を追求する過程で、通信の複雑さを低減することは常に注目のポイントでした。しかし、この方法は顕著なスループット向上をもたらしませんでした。例えば、初期バージョンのDiemで実装されたHotstuffは、3500 TPSにしか達せず、100k+ TPSの目標を大きく下回っています。
最近のブレークスルーは、データ伝播がリーダーのプロトコルに基づく主要なボトルネックであることを認識し、並列化から恩恵を受けることができるようになったことに起因しています。Narwhalシステムはデータ伝播とコアのコンセンサスロジックを分離し、すべてのバリデーターが同時にデータを伝播し、コンセンサスコンポーネントは少量のメタデータのみをソートするというアーキテクチャを提案しています。Narwhal論文は160,000 TPSのスループットを報告しています。
Aptosは以前にQuorum Store、すなわちNarwhalの実装を紹介し、データの伝播とコンセンサスを分離し、これを使用して現在のコンセンサスプロトコルJolteonを拡張する方法を説明しました。Jolteonはリーダーに基づくプロトコルで、Tendermintの線形迅速パスとPBFTスタイルのビュー変更を組み合わせて、Hotstuffのレイテンシーを33%削減します。しかし、明らかにリーダーに基づくコンセンサスプロトコルはNarwhalのスループットの潜在能力を十分に活用できません。データの伝播とコンセンサスを分けたにもかかわらず、スループットの増加に伴い、Hotstuff/Jolteonのリーダーは依然として制限されています。
したがって、AptosはNarwhal DAGの上にBullsharkを展開することを決定しました。これは、ゼロ通信オーバーヘッドのコンセンサスプロトコルです。残念ながら、Jolteonと比較して、Bullsharkの高スループットをサポートするDAG構造は50%のレイテンシーコストをもたらします。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
DAG-BFTの背景
Narwhal DAGの各頂点は、あるラウンドに関連付けられています。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において、上記のすべてのプロトコルについて以下の観察がなされます：全ての検証者は最初の順序付けられたアンカーポイントに同意します。
Bullsharkのレイテンシー
BullsharkのレイテンシーはDAGにおける順序付きアンカー間のラウンド数によって決まります。Bullsharkの最も実用的な部分は、同期版が非同期版よりもレイテンシーが良好ですが、依然として最適ではありません。
主に2つの問題があります:
平均ブロックレイテンシー: Bullsharkでは、各偶数ラウンドにアンカーがあり、各奇数ラウンドの頂点は投票として解釈されます。一般的なケースでは、アンカーをソートするには2ラウンドのDAGが必要ですが、アンカーの因果歴の頂点はアンカーがソートされるのを待つためにより多くのラウンドを必要とします。一般的なケースでは、奇数ラウンドの頂点は3ラウンドを必要とし、偶数ラウンドの非アンカートップは4ラウンドを必要とします。
障害事例レイテンシー: もし一回のリーダーが十分に速くアンカーポイントをブロードキャストできなかった場合、アンカーポイントをソートすることができず)スキップされます(。前の数回のすべての未ソートの頂点は、次のアンカーポイントがソートされるのを待たなければなりません。これは、特にBullsharkがリーダーを待つためにタイムアウトを使用するため、地理的複製ネットワークのパフォーマンスを著しく低下させます。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Shoalフレームワーク
Shoalは、Bullshark)やその他のNarwhalベースのBFTプロトコル(の処理をパイプライン化することで、各ラウンドにおいてアンカーポイントを持たせ、DAG内のすべての非アンカーポイントのレイテンシーを3ラウンドに削減しました。Shoalはまた、DAG内にゼロコストのリーダーの評判メカニズムを導入し、選択を迅速なリーダーに偏らせています。
チャレンジ
DAGプロトコルの背景において、パイプライン処理とリーダーの評判は難しい問題と考えられています。その理由は以下の通りです:
以前のパイプライン処理はコアBullsharkロジックを変更しようとしましたが、これは本質的に不可能なようです。
リーダーの評判はDiemBFTに導入され、Carouselで正式化されており、バリデーターの過去のパフォーマンスに基づいて将来のリーダー)Bullsharkのアンカー(を動的に選択するという考え方です。リーダーのアイデンティティに関して意見の相違があることは、これらのプロトコルの安全性を侵害するものではありませんが、Bullsharkでは、まったく異なる順序につながる可能性があります。これは、動的かつ決定的にホイールアンカーを選択することがコンセンサスを解決するために必要であり、バリデーターが将来のアンカーを選択するために秩序ある歴史に合意する必要があるという問題の核心を浮き彫りにします。
プロトコル
上述の課題が存在するにもかかわらず、解決策はシンプルなところに隠れています。Shoalでは、DAG上でローカル計算を実行する能力を利用して、前のラウンドの情報を保存し再解釈する能力を実現しました。すべてのバリデーターが最初の順序付きアンカーポイントに同意するという核心的な洞察を持って、Shoalは複数のBullsharkインスタンスを順次組み合わせてパイプライン処理を行います。
) パイプライン処理
Bullsharkに似て、バリデーターは潜在的なアンカーに事前にコンセンサスを達成します。これは、ラウンドをリーダーにマッピングする既知のマッピングF:R → Vがあることを意味します。ShoalはBullsharkのインスタンスを1つずつ実行し、各インスタンスに対してアンカーはマッピング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-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.webp(
) 超過時間は必要ありません
タイムアウトは、リーダーベースの決定的部分同期BFT実装において重要な役割を果たします。しかし、これらが導入する複雑性は、管理および観察が必要な内部状態の数を増加させ、デバッグプロセスの複雑性を高め、さらに多くの可観測性技術を必要とします。
タイムアウトはレイテンシーを大幅に増加させる可能性があるため、それらを適切に設定することが非常に重要で、環境###ネットワーク(に高度に依存しているため、通常は動的に調整する必要があります。次のリーダーに移行する前に、プロトコルは故障したリーダーに対して完全なタイムアウトレイテンシーの罰則を支払います。したがって、タイムアウト設定は過度に保守的であってはならず、しかしタイムアウト時間が短すぎると、プロトコルは優れたリーダーをスキップする可能性があります。
残念ながら、リーダーに基づくプロトコル)（HotstuffやJolteon(のように）は、リーダーが故障するたびにプロトコルが進行することを保証するために、タイムアウトを必要とします。タイムアウトがなければ、クラッシュしたリーダーでさえもプロトコルを永遠に停止させる可能性があります。非同期の期間中に故障したリーダーと遅いリーダーを区別できないため、タイムアウトは、共通のコンセンサスアクティビティがない状態で、検証ノードがすべてのリーダーを変更するのを引き起こす可能性があります。
Bullsharkでは、レイテンシーはDAG構築に使用され、同期中に誠実なリーダーがDAにアンカーポイントを追加することを保証します。