# DAGコンセンサスの最適化: ShoalフレームワークがAptos上のBullsharkレイテンシーをドロップする方法Aptos Labsは最近、DAG BFTにおける2つの重要なオープン問題を解決し、レイテンシーを大幅にドロップし、初めて決定論的非同期プロトコルにおいてタイムアウトの必要性を排除しました。全体的に、Shoalフレームワークは無故障の場合に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は、目標の100k+ TPSを大きく下回る3500 TPSしか実現しませんでした。最近の突破は、データ伝播がリーダー合意の主要なボトルネックであることを認識し、並列化から利益を得ることができると気づいたことに起因しています。Narwhalシステムは、データ伝播とコア合意ロジックを分離し、すべてのバリデーターが同時にデータを伝播し、合意コンポーネントは少量のメタデータのみを順序付けるというアーキテクチャを提案しています。Narwhal論文は、160,000 TPSのスループットを報告しています。以前の記事では、Quorum Storeについて紹介しました。私たちのNarwhal実装は、データの伝播とコンセンサスを分離し、これを使用して現在のコンセンサスプロトコルJolteonを拡張する方法を示しています。Jolteonはリーダーベースのプロトコルで、Tendermintの線形高速パスとPBFTスタイルのビュー変更を組み合わせることで、Hotstuffのレイテンシーを33%低下させます。しかし、リーダーベースのコンセンサスプロトコルは明らかにNarwhalのスループットポテンシャルを十分に活用できません。データの伝播とコンセンサスを分離しているにもかかわらず、スループットが増加するにつれて、Hotstuff/Jolteonのリーダーは依然として制限を受けています。そのため、私たちはNarwhal DAGの上にBullsharkを展開することを決定しました。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では、これらのプロトコルに対して以下の観察を行いました:すべてのバリデーターは最初の順序付けられたアンカーポイントに同意します。## 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はパイプラインを通じて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インスタンスを一つずつ実行し、それぞれのインスタンスに対してアンカーはマッピングFによって事前に決定されます。各インスタンスはアンカーをソートし、次のインスタンスへの切り替えをトリガーします。最初,ShoalはDAGの第1ラウンドで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回目のラウンドでの順序付けされたアンカーポイントの因果的履歴に基づいて、新しいマッピングF'をr+1回目のラウンドから計算する必要があるということです。次に、バリデーションノードは、r+1回目のラウンドから更新されたアンカーポイント選択関数F'を使用してBullsharkの新しいインスタンスを実行します。! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/social/moments-859e732e16c3eee0e2c93422474debc2(## これ以上のタイムアウトはありませんタイムアウトは、すべてのリーダーベースの決定的部分同期BFT実装において重要な役割を果たします。しかし、彼らが導入する複雑さは、管理および観察する必要がある内部状態の数を増加させ、それがデバッグプロセスの複雑さを増し、より多くの可観察性技術を必要とします。タイムアウトはレイテンシーを大幅に増加させる可能性があります。なぜなら、それらを適切に設定することが非常に重要であり、環境)ネットワーク(に大きく依存しているため、通常は動的に調整する必要があります。次のリーダーに移行する前に、プロトコルは故障したリーダーに対して完全なタイムアウトレイテンシー罰則を支払います。したがって、タイムアウトの設定はあまり保守的であってはならず、しかしタイムアウト時間が短すぎると、プロトコルは良いリーダーをスキップする可能性があります。たとえば、高負荷の状況では、Jolteon/Hotstuffのリーダーが過負荷になり、彼らが進展を推進する前にタイムアウトが到達することを観察しました。残念ながら、リーダーベースのプロトコル)、HotstuffやJolteon(は、本質的にタイムアウトを必要とし、リーダーが故障するたびにプロトコルが進行することを保証します。タイムアウトがなければ、クラッシュしたリーダーでさえプロトコルを永遠に停止させる可能性があります。非同期期間中に故障したリーダーと遅いリーダーを区別できないため、タイムアウトは検証ノードがコンセンサスのアクティブ状態なしにすべてのリーダーの変更を確認する原因となる可能性があります。Bullsharkでは、タイムアウトがDAG構造に使用され、同期中に誠実なリーダーがアンカーポイントを追加することを保証します。
Shoalフレームワーク最適化DAGコンセンサス 大幅ドロップAptos上Bullsharkレイテンシー
DAGコンセンサスの最適化: ShoalフレームワークがAptos上のBullsharkレイテンシーをドロップする方法
Aptos Labsは最近、DAG BFTにおける2つの重要なオープン問題を解決し、レイテンシーを大幅にドロップし、初めて決定論的非同期プロトコルにおいてタイムアウトの必要性を排除しました。全体的に、Shoalフレームワークは無故障の場合に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は、目標の100k+ TPSを大きく下回る3500 TPSしか実現しませんでした。
最近の突破は、データ伝播がリーダー合意の主要なボトルネックであることを認識し、並列化から利益を得ることができると気づいたことに起因しています。Narwhalシステムは、データ伝播とコア合意ロジックを分離し、すべてのバリデーターが同時にデータを伝播し、合意コンポーネントは少量のメタデータのみを順序付けるというアーキテクチャを提案しています。Narwhal論文は、160,000 TPSのスループットを報告しています。
以前の記事では、Quorum Storeについて紹介しました。私たちのNarwhal実装は、データの伝播とコンセンサスを分離し、これを使用して現在のコンセンサスプロトコルJolteonを拡張する方法を示しています。Jolteonはリーダーベースのプロトコルで、Tendermintの線形高速パスとPBFTスタイルのビュー変更を組み合わせることで、Hotstuffのレイテンシーを33%低下させます。しかし、リーダーベースのコンセンサスプロトコルは明らかにNarwhalのスループットポテンシャルを十分に活用できません。データの伝播とコンセンサスを分離しているにもかかわらず、スループットが増加するにつれて、Hotstuff/Jolteonのリーダーは依然として制限を受けています。
そのため、私たちはNarwhal DAGの上にBullsharkを展開することを決定しました。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では、これらのプロトコルに対して以下の観察を行いました:
すべてのバリデーターは最初の順序付けられたアンカーポイントに同意します。
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はパイプラインを通じて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インスタンスを一つずつ実行し、それぞれのインスタンスに対してアンカーはマッピングFによって事前に決定されます。各インスタンスはアンカーをソートし、次のインスタンスへの切り替えをトリガーします。
最初,ShoalはDAGの第1ラウンドで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回目のラウンドでの順序付けされたアンカーポイントの因果的履歴に基づいて、新しいマッピングF'をr+1回目のラウンドから計算する必要があるということです。次に、バリデーションノードは、r+1回目のラウンドから更新されたアンカーポイント選択関数F'を使用してBullsharkの新しいインスタンスを実行します。
! [Shoalフレームワークを説明する10,000語:AptosでBullsharkのレイテンシーを減らす方法は? ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
これ以上のタイムアウトはありません
タイムアウトは、すべてのリーダーベースの決定的部分同期BFT実装において重要な役割を果たします。しかし、彼らが導入する複雑さは、管理および観察する必要がある内部状態の数を増加させ、それがデバッグプロセスの複雑さを増し、より多くの可観察性技術を必要とします。
タイムアウトはレイテンシーを大幅に増加させる可能性があります。なぜなら、それらを適切に設定することが非常に重要であり、環境)ネットワーク(に大きく依存しているため、通常は動的に調整する必要があります。次のリーダーに移行する前に、プロトコルは故障したリーダーに対して完全なタイムアウトレイテンシー罰則を支払います。したがって、タイムアウトの設定はあまり保守的であってはならず、しかしタイムアウト時間が短すぎると、プロトコルは良いリーダーをスキップする可能性があります。たとえば、高負荷の状況では、Jolteon/Hotstuffのリーダーが過負荷になり、彼らが進展を推進する前にタイムアウトが到達することを観察しました。
残念ながら、リーダーベースのプロトコル)、HotstuffやJolteon(は、本質的にタイムアウトを必要とし、リーダーが故障するたびにプロトコルが進行することを保証します。タイムアウトがなければ、クラッシュしたリーダーでさえプロトコルを永遠に停止させる可能性があります。非同期期間中に故障したリーダーと遅いリーダーを区別できないため、タイムアウトは検証ノードがコンセンサスのアクティブ状態なしにすべてのリーダーの変更を確認する原因となる可能性があります。
Bullsharkでは、タイムアウトがDAG構造に使用され、同期中に誠実なリーダーがアンカーポイントを追加することを保証します。