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