# Shoalフレームワーク: 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のスループットが報告されています。Aptosは以前にQuorum Store、つまりNarwhalの実装を紹介しました。これはデータの伝播とコンセンサスを分離し、現在のコンセンサスプロトコルJolteonの拡張にどのように利用できるかを示しています。Jolteonはリーダーベースのプロトコルで、Tendermintの線形高速パスとPBFTスタイルのビュー変更を組み合わせており、Hotstuffのレイテンシーを33%低減することができます。しかし、リーダーベースのコンセンサスプロトコルは明らかにNarwhalのスループットポテンシャルを十分に活用できません。データの伝播とコンセンサスを分離しても、スループットが増加するにつれて、Hotstuff/Jolteonのリーダーは依然として制限を受けています。したがって、AptosはNarwhal DAGの上にBullsharkを展開することを決定しました。これはゼロ通信オーバーヘッドのコンセンサスプロトコルです。不幸にも、Jolteonと比較して、Bullsharkの高スループットをサポートするDAG構造は50%のレイテンシーコストをもたらしました。この記事では、ShoalがBullsharkのレイテンシーを大幅に削減する方法について説明します。## 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-f6b6281c928e3fa7a2412a480c9c1806(## 一般的な注文追加の通信オーバーヘッドなしでDAG内のすべての頂点の総順序に合意することができます。そのために、DAG-Rider、Tusk、およびBullsharkの検証者は、DAGの構造を合意プロトコルとして解釈し、頂点は提案を、辺は投票を表します。DAG構造におけるグループインタセクションロジックは異なるが、すべての既存のNarwhalベースのコンセンサスプロトコルは以下の構造を持っている。1. 予約アンカーポイント: 数ラウンドごとに)、例えば、Bullsharkの2ラウンド(ごとに、あらかじめ決められたリーダーがいます。リーダーの頂点はアンカーポイントと呼ばれます。2. ソートアンカー: 検証者は独立しているが、どのアンカーをソートし、どのアンカーをスキップするかを決定する。3. 因果関係の履歴の順序付け: 検証者は、順序付けられたアンカーポイントのリストを1つずつ処理し、各アンカーポイントについて、いくつかの決定的なルールに従って因果関係の履歴の中のすべての以前の無秩序な頂点を順序付けます。安全性を満たすための鍵は、ステップ)2(で、すべての誠実な検証ノードが同じプレフィックスを共有するように、有序なアンカーポイントリストを作成することを保証することです。Shoalでは、上記のすべてのプロトコルについて次の観察がなされます:すべてのバリデーターは最初の順序付けられたアンカーポイントに同意します。## BullsharkのレイテンシーBullsharkのレイテンシーは、DAG内の順序付けられたアンカーポイント間のラウンド数に依存します。Bullsharkの最も実用的な部分は、同期バージョンが非同期バージョンよりも優れたレイテンシーを持っていますが、最適ではありません。問題1: 平均ブロックレイテンシー。Bullsharkでは、各偶数ラウンドにアンカーポイントがあり、各奇数ラウンドの頂点は投票として解釈されます。一般的な場合、アンカーポイントをソートするには2ラウンドのDAGが必要ですが、アンカーポイントの因果関係の履歴にある頂点は、アンカーポイントがソートされるのを待つためにより多くのラウンドが必要です。一般的な場合、奇数ラウンドの頂点には3ラウンドが必要で、偶数ラウンドの非アンカーポイントの頂点には4ラウンドが必要です。問題2:故障ケースレイテンシー。上述のレイテンシー分析は無故障の場合に適用される。一方で、一回のリーダーが十分に速くアンカーポイントをブロードキャストできなかった場合、アンカーポイントの順序を決定することができず)、そのためスキップされる(。このため、前のラウンドで順序付けされていないすべての頂点は、次のアンカーポイントが順序付けされるのを待たなければならない。これにより、地理的なレプリケーションネットワークの性能が著しく低下する、特にBullsharkはリーダーを待つためにタイムアウトを使用するため。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-b7ed8888da112bae8d34c0fdb338b138(## ShoalフレームワークShoalはこの2つのレイテンシー問題を解決しました。Bullshark)またはその他のNarwhalベースのBFTプロトコル(をパイプライン処理によって強化し、各ラウンドでアンカーポイントを持つことを可能にし、DAG内のすべての非アンカーポイントのレイテンシーを3ラウンドに削減しました。Shoalはまた、DAG内にゼロコストのリーダー評判メカニズムを導入し、迅速なリーダーへの選択を偏らせることを可能にしました。## チャレンジDAGプロトコルの背景において、パイプライン処理とリーダーの評判は困難な問題と見なされています。その理由は以下の通りです:1. 以前のパイプライン処理は核心Bullsharkロジックを修正しようとしましたが、これは本質的に不可能なようです。2. リーダーの評判はDiemBFTに導入され、Carouselで正式化されており、これはバリデーターの過去のパフォーマンスに基づいて将来のリーダーを動的に選択するという)Bullsharkのアンカー(に関するアイデアです。リーダーの地位に関する意見の相違は、これらのプロトコルのセキュリティを損なうことはありませんが、Bullsharkでは、完全に異なる順序を引き起こす可能性があり、これは問題の核心を引き起こします。すなわち、動的かつ決定的にラウンドアンカーを選択することはコンセンサスを解決するために必要であり、バリデーターは将来のアンカーを選択するために秩序ある履歴について合意する必要があります。問題の難易度の証拠として、Bullsharkの実装、現在の生産環境における実装を含め、これらの機能をサポートしていません。## プロトコル上記の課題が存在するにもかかわらず、解決策は単純なところに隠れています。Shoalでは、DAG上でローカル計算を実行する能力に依存し、以前の情報の保存と再解釈の能力を実現しています。すべてのバリデーターが最初の順序付きアンカーポイントに同意するという核心的な洞察により、Shoalは複数のBullsharkインスタンスを順番に組み合わせてそれらをパイプライン処理し、)の最初の順序付きアンカーポイントはインスタンスの切り替え点であり、(のアンカーポイントの因果関係の歴史がリーダーの評判を計算するために使用されます。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-46d37add0d9e81b2f295edf8eddd907f(## パイプライン処理 Vがラウンドをリーダーにマッピングします。ShoalはBullsharkのインスタンスを1つずつ実行し、各インスタンスに対して、アンカーはマッピングFによって事前に決定されます。各インスタンスは1つのアンカーをソートし、これが次のインスタンスへの切り替えをトリガーします。最初,ShoalはDAGの第一ラウンドでBullsharkの最初のインスタンスを起動し、最初の順序付けられたアンカーポイントが第rラウンドで決定されるまで実行します。全てのバリデーターはこのアンカーポイントに同意します。したがって、全てのバリデーターは第r+1ラウンドからDAGを再解釈することに確実に同意できます。Shoalは第r+1ラウンドで新しいBullsharkインスタンスを起動しました。最良のシナリオでは、Shoalは各ラウンドでアンカーを1つソートすることができます。最初のラウンドでは、アンカーポイントは最初のインスタンスによってソートされます。その後、Shoalは2ラウンド目に新しいインスタンスを開始し、そのインスタンス自体にアンカーがあり、そのアンカーはそのインスタンスによってソートされます。そして、3ラウンド目に別の新しいインスタンスがアンカーポイントをソートし、その後、このプロセスは続きます。! [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実装において重要な役割を果たします。しかし、それらがもたらす複雑さは、管理と観察が必要な内部状態の数を増加させ、デバッグプロセスの複雑さを増し、より多くの可観察性技術を必要とします。タイムアウトはレイテンシーを著しく増加させる可能性があるため、それらを適切に構成することが非常に重要であり、環境)ネットワーク(に高度に依存するため、通常は動的に調整する必要があります。次のリーダーに移行する前に、プロトコルは故障したリーダーに対して完全なタイムアウトレイテンシーの罰金を支払います。したがって、タイムアウト設定はあまり保守的であってはなりませんが、もしタイムアウト時間が短すぎると、プロトコルは良いリーダーをスキップする可能性があります。例えば、高負荷の状況では、Jolteon/Hotstuff内のリーダーが負荷に耐えられず、進行を推進する前にタイムアウトが到達してしまうことが観察されました。不幸にも、リーダーに基づいたプロトコル)のように
Shoalフレームワーク最適化Aptosコンセンサスプロトコル Bullsharkレイテンシー大幅ドロップ
Shoalフレームワーク: 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のスループットが報告されています。
Aptosは以前にQuorum Store、つまりNarwhalの実装を紹介しました。これはデータの伝播とコンセンサスを分離し、現在のコンセンサスプロトコルJolteonの拡張にどのように利用できるかを示しています。Jolteonはリーダーベースのプロトコルで、Tendermintの線形高速パスとPBFTスタイルのビュー変更を組み合わせており、Hotstuffのレイテンシーを33%低減することができます。しかし、リーダーベースのコンセンサスプロトコルは明らかにNarwhalのスループットポテンシャルを十分に活用できません。データの伝播とコンセンサスを分離しても、スループットが増加するにつれて、Hotstuff/Jolteonのリーダーは依然として制限を受けています。
したがって、AptosはNarwhal DAGの上にBullsharkを展開することを決定しました。これはゼロ通信オーバーヘッドのコンセンサスプロトコルです。不幸にも、Jolteonと比較して、Bullsharkの高スループットをサポートするDAG構造は50%のレイテンシーコストをもたらしました。
この記事では、ShoalがBullsharkのレイテンシーを大幅に削減する方法について説明します。
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-f6b6281c928e3fa7a2412a480c9c1806.webp(
一般的な注文
追加の通信オーバーヘッドなしでDAG内のすべての頂点の総順序に合意することができます。そのために、DAG-Rider、Tusk、およびBullsharkの検証者は、DAGの構造を合意プロトコルとして解釈し、頂点は提案を、辺は投票を表します。
DAG構造におけるグループインタセクションロジックは異なるが、すべての既存のNarwhalベースのコンセンサスプロトコルは以下の構造を持っている。
予約アンカーポイント: 数ラウンドごとに)、例えば、Bullsharkの2ラウンド(ごとに、あらかじめ決められたリーダーがいます。リーダーの頂点はアンカーポイントと呼ばれます。
ソートアンカー: 検証者は独立しているが、どのアンカーをソートし、どのアンカーをスキップするかを決定する。
因果関係の履歴の順序付け: 検証者は、順序付けられたアンカーポイントのリストを1つずつ処理し、各アンカーポイントについて、いくつかの決定的なルールに従って因果関係の履歴の中のすべての以前の無秩序な頂点を順序付けます。
安全性を満たすための鍵は、ステップ)2(で、すべての誠実な検証ノードが同じプレフィックスを共有するように、有序なアンカーポイントリストを作成することを保証することです。Shoalでは、上記のすべてのプロトコルについて次の観察がなされます:
すべてのバリデーターは最初の順序付けられたアンカーポイントに同意します。
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-b7ed8888da112bae8d34c0fdb338b138.webp(
Shoalフレームワーク
Shoalはこの2つのレイテンシー問題を解決しました。Bullshark)またはその他のNarwhalベースのBFTプロトコル(をパイプライン処理によって強化し、各ラウンドでアンカーポイントを持つことを可能にし、DAG内のすべての非アンカーポイントのレイテンシーを3ラウンドに削減しました。Shoalはまた、DAG内にゼロコストのリーダー評判メカニズムを導入し、迅速なリーダーへの選択を偏らせることを可能にしました。
チャレンジ
DAGプロトコルの背景において、パイプライン処理とリーダーの評判は困難な問題と見なされています。その理由は以下の通りです:
以前のパイプライン処理は核心Bullsharkロジックを修正しようとしましたが、これは本質的に不可能なようです。
リーダーの評判はDiemBFTに導入され、Carouselで正式化されており、これはバリデーターの過去のパフォーマンスに基づいて将来のリーダーを動的に選択するという)Bullsharkのアンカー(に関するアイデアです。リーダーの地位に関する意見の相違は、これらのプロトコルのセキュリティを損なうことはありませんが、Bullsharkでは、完全に異なる順序を引き起こす可能性があり、これは問題の核心を引き起こします。すなわち、動的かつ決定的にラウンドアンカーを選択することはコンセンサスを解決するために必要であり、バリデーターは将来のアンカーを選択するために秩序ある履歴について合意する必要があります。
問題の難易度の証拠として、Bullsharkの実装、現在の生産環境における実装を含め、これらの機能をサポートしていません。
プロトコル
上記の課題が存在するにもかかわらず、解決策は単純なところに隠れています。
Shoalでは、DAG上でローカル計算を実行する能力に依存し、以前の情報の保存と再解釈の能力を実現しています。すべてのバリデーターが最初の順序付きアンカーポイントに同意するという核心的な洞察により、Shoalは複数のBullsharkインスタンスを順番に組み合わせてそれらをパイプライン処理し、)の最初の順序付きアンカーポイントはインスタンスの切り替え点であり、(のアンカーポイントの因果関係の歴史がリーダーの評判を計算するために使用されます。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
パイプライン処理
Vがラウンドをリーダーにマッピングします。ShoalはBullsharkのインスタンスを1つずつ実行し、各インスタンスに対して、アンカーはマッピングFによって事前に決定されます。各インスタンスは1つのアンカーをソートし、これが次のインスタンスへの切り替えをトリガーします。
最初,ShoalはDAGの第一ラウンドでBullsharkの最初のインスタンスを起動し、最初の順序付けられたアンカーポイントが第rラウンドで決定されるまで実行します。全てのバリデーターはこのアンカーポイントに同意します。したがって、全てのバリデーターは第r+1ラウンドからDAGを再解釈することに確実に同意できます。Shoalは第r+1ラウンドで新しいBullsharkインスタンスを起動しました。
最良のシナリオでは、Shoalは各ラウンドでアンカーを1つソートすることができます。最初のラウンドでは、アンカーポイントは最初のインスタンスによってソートされます。その後、Shoalは2ラウンド目に新しいインスタンスを開始し、そのインスタンス自体にアンカーがあり、そのアンカーはそのインスタンスによってソートされます。そして、3ラウンド目に別の新しいインスタンスがアンカーポイントをソートし、その後、このプロセスは続きます。
! [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実装において重要な役割を果たします。しかし、それらがもたらす複雑さは、管理と観察が必要な内部状態の数を増加させ、デバッグプロセスの複雑さを増し、より多くの可観察性技術を必要とします。
タイムアウトはレイテンシーを著しく増加させる可能性があるため、それらを適切に構成することが非常に重要であり、環境)ネットワーク(に高度に依存するため、通常は動的に調整する必要があります。次のリーダーに移行する前に、プロトコルは故障したリーダーに対して完全なタイムアウトレイテンシーの罰金を支払います。したがって、タイムアウト設定はあまり保守的であってはなりませんが、もしタイムアウト時間が短すぎると、プロトコルは良いリーダーをスキップする可能性があります。例えば、高負荷の状況では、Jolteon/Hotstuff内のリーダーが負荷に耐えられず、進行を推進する前にタイムアウトが到達してしまうことが観察されました。
不幸にも、リーダーに基づいたプロトコル)のように