ブロックチェーンのセマンティクスでは、BFT コンセンサスは、N 個の検証ノード (最大で f 個のビザンチン ノード) が無限に成長する一連の提案 (ブロックまたはトランザクション セット) についてコンセンサスに到達できるようにするメカニズムです。
ご存知のように、従来の BFT ベースのコンセンサス アルゴリズムは、PBFT であろうと改良された HotStuff であろうと、ネットワークが不安定な場合、通信の複雑さが比較的高く、スケーラビリティが低く、遅延が大きくなります。
近年、ブロックチェーンでの DAG 技術の幅広い適用により、DAG ベースの BFT コンセンサスが提案され、DAG の効率的な実装とその自然な非同期通信メカニズムを使用してコンセンサスのスケーラビリティを向上させ、継続的に改善されています。確認時間を短縮し、トランザクションのスループットを向上させるという明らかな利点があります。ただし、DAG は非同期操作であるため、グローバルな並べ替えメカニズムを持たないため、一定期間実行すると、ノード間で格納されたデータに偏差が生じる可能性があります.このような偏差の下で、最終的にシーケンスのコンセンサスに到達する方法が DAG です。コンセンサス エッセンシャル。
この記事では、最初に基本理論である DAG ベースの BFT コンセンサスとラウンドベースの BFT コンセンサスを紹介し、次に DAGRider、Tusk、および Bullshark プロトコルについて詳しく説明します。
DAG ベースの BFT コンセンサス
DAG、英語の正式名称有向非巡回グラフ、中国語は有向非巡回グラフを意味します。
グラフは 2 つの部分で構成されます: 頂点とエッジ. いわゆる有向非巡回グラフは実際には: 方向エッジです. これらのエッジはグラフ内で閉ループを形成しません.
上記は、有向木、DAG グラフ、および有向グラフの概略図であり、そこから 3 つの違いを見ることができます。
- 有向木: 各頂点は前の 1 つの頂点のみを指すことができ、データ全体には明らかな流れ方向があります
- DAG グラフ: 各頂点は複数の前の頂点を指すことができ、データ フロー全体にも明らかな方向性があります
- 有向グラフ: DAG とは異なり、有向グラフではデータが逆流し、構造全体のデータ フローの方向が明確ではありません。
コンセンサスにおけるDAGの適用
DAG ベースのコンセンサスでは、各コンセンサス メッセージには提案 (ブロックまたはトランザクションのセット) と以前のメッセージへの参照のセットが含まれています. ここでの参照は次のように理解できます: 、メッセージを引用するとは、メッセージの承認と投票を意味します。
それに対応して、DAG グラフでは、メッセージは頂点であり、その参照はエッジであるため、すべてのコンセンサス メッセージが一緒になって成長する DAG グラフを形成します。
DAG ベースのコンセンサスは、次の 2 つの層に分けることができます。
- ネットワーク通信層: 提案の確実な配布と受信、メッセージの投票、メッセージの DAG グラフへの描画を担当します。
- 通信オーバーヘッドがゼロのシーケンシング レイヤー: 各検証ノードは、追加のメッセージを送信せずに、ローカルの DAG コピーを解析することにより、提案の公開順序を個別に抽出し、すべての検証ノードが最終的に提案のシリアル送信順序について満場一致でコンセンサスに達するようにすることができます。
メッセージの生成からメッセージの最終送信まで、ネットワークの非同期性により、異なる検証ノードの DAG ビューは常にわずかに異なる可能性があるため、すべての検証ノードが最終的にコンセンサスに到達することを保証する方法提出の順序は、すべての DAG ベースのコンセンサス アルゴリズムの重要なポイントと困難の鍵です。
従来のBFTとの比較
従来の BFT ベースのコンセンサス アルゴリズムは、それが PBFT であろうと改良された HotStuff であろうと、3 段階の相互作用 (事前準備、準備、コミット) の後、ブロックを生成し、ブロードキャストし、他のノードから投票を受け取るためにトランザクションを収集するリーダー ノードを必要とします。最終的にブロックの提出についてコンセンサスに達し、プロトコルはノード間のコンセンサスメッセージの信頼できる配信にもっと依存しています。
DAG コンセンサスに基づいて、DAG グラフはネットワーク通信層を抽象化するために使用され、メッセージの配布はコンセンサス ロジック (提案の順序付け) から分離されます。この分離の利点は、各ノードがコンセンサス状態と送信シーケンスを非同期に計算できることで、通信プロセスの遅延とネットワーク オーバーヘッドを削減します. さらに、DAG の効率的な実装により、DAG ベースのコンセンサスがより効率的になります.優れたスケーラビリティと高いスループット。
ラウンドベースの BFT コンセンサス
ラウンドベースの DAG では、各頂点は整数 (ラウンド数) に関連付けられています。各検証ノードは、各ラウンドで 1 つのメッセージのみをブロードキャストし、各メッセージは前のラウンドで少なくとも N-f 個のメッセージを参照します。すなわち、ｒ番目のラウンドに進むために、検証ノードは、最初にｒ－１ラウンドで異なる検証ノードからＮ－ｆ個のメッセージを取得する必要がある。
上の図はラウンドベースの BFT の例です. 図には 4 つの検証ノードがあります. 各ラウンドの各メッセージは, 前のラウンドからの少なくとも 3 つのメッセージを参照します. ラウンドが 3 つのメッセージすべてを受信できない場合, ラウンドは次のラウンドに進むことはできません.次のラウンド。
これは、HotStuff アルゴリズムにいくぶん似ています。各ブロックの投票メッセージは、前のブロックの親クォーラムを運ぶ必要があります。クォーラム BFT フォールト トレラント コンセンサスの基礎。
3つの特徴
ラウンドベースの DAG コンセンサス プロトコルでは、メッセージが DAG に挿入されたことが確認されると、次の保証があります。
- 信頼性: メッセージのコピーが十分な数の検証ノードに保存されるため、最終的にすべての正直な参加ノードがメッセージをダウンロードできます。
- 不平等: 任意のバリデータ v とラウンド r について、両方のバリデータが v からの頂点を r のローカル ビューに持つ場合、両方のバリデータはまったく同じ頂点と、同一の頂点間の参照関係を持ちます。
- 因果的順序付け: メッセージは、配信されたメッセージの前のラウンドへの明示的な参照を運びます。したがって、これにより、頂点にコミットするすべてのバリデーターが、部分ビューでその頂点のまったく同じ因果関係の履歴 (前のラウンドからのメッセージ) を持つことが保証されます。
前述のように、DAG ベースの BFT コンセンサス プロトコルでは、各検証ノードがローカルの DAG グラフを解釈するだけで、最終的にサブミッション シーケンスの合意に達することができるため、上記の機能を使用することがこの問題を解決する鍵となります。
同時に、これらの特性がビザンチンノードが悪を行う能力を排除するためであり、従来のBFTアルゴリズムと比較して、コンセンサスロジックを簡素化し、プロトコルの設計を簡素化できます。
DAG-Rider、Tusk、および Bullshark は、比較的成熟しており、ホイールベースの BFT コンセンサス プロトコルとして人気があります. 以下では、これら 3 つのプロトコルを詳細に紹介し、比較します.
DAGライダー
DAG-Rider プロトコルでは、各検証ノードがローカル DAG グラフを連続する 4 ラウンド単位で Wave に分割し、各 Wave の最終ラウンドで最初のラウンドからランダムにリーダーを選択して頂点の提出を試みます。
下の図では、各水平線は 4 つの異なる検証ノードを表し、各頂点は各ラウンドで異なる検証ノードによって送信されたコンセンサス メッセージを表し、頂点 v2 と v3 はそれぞれ wave2 と wave3 のランダムに選択されたリーダーです。
頂点の送信プロセス:
- wave2 の round8 で頂点 v2 を提出しようとしたが、round8 で v2 につながる頂点が 2 つ (2f+1 未満) しかないため、round8 で v2 が提出条件を満たさない
- v3 に至る round12 には 2f+1 個の頂点があるため、v3 は commit ルールに従います。
- 同時に v3 から v2 へのパスがあるため、最初に v2 -> v3 を wave3 にサブミットします。
コミットの最終的な一貫性を確保する方法
ネットワークの非同期性により、異なるバリデーターのローカル DAG グラフは常にわずかに異なる場合があります。言い換えれば、いくつかの頂点は、特定の波の終わりにいくつかのノード (ここでは M1 と仮定) によって送信される可能性がありますが、一部のノード (M2) は送信せずに次の波に直接入るため、M2 ノードは送信されます。次のウェーブ? しかし、前のウェーブで選択された頂点はまだ送信できず、各ノードのステータスに矛盾が生じますか?
実際、これは不可能です. M1 が頂点を提出できる理由は、ラウンド 8 で v2 につながる頂点が少なくとも 2f+1 個あり、ラウンド 9 の v3 が前のラウンドで少なくとも 2f+1 個の異なる頂点を参照している必要があるためです。 v3 から v2 へのパスは少なくとも f+1 個あります。
牙
Tuskの設計思想はDAG-Riderをベースに改良されています。Tusk の各ウェーブは 3 ラウンドで構成され、各ウェーブの最後のラウンドが次のウェーブの最初のラウンドになります。
下図のr1~r3はwave1、r3~r5はwave2を表し、頂点L1とL2はランダムに選択された2つのwaveのリーダーです。
頂点の送信プロセス:
- ラウンド1では、各検証ノードがブロックを生成してブロードキャストします
- ラウンド 2 では、各検証ノードが前のラウンドの頂点 (つまり、ラウンド 1 を参照する頂点) に投票します。
- ラウンド3でランダムコインが選ばれます（つまり、リーダーはラウンド1でランダムに選ばれ、図のL1）
- ラウンド 2 で L1 を参照する頂点が f+1 個ある場合はそれを送信し、そうでない場合は直接次のウェーブに進みます
この図では、ラウンド 2 の頂点が 1 つしか L1 を参照していないため、L1 をすぐにコミットすることはできません。L2 が選出されると、round4 で L2 が f+1 個以上の頂点によって参照され、L2 は提出ルールに準拠し、L2 から L1 へのパスが存在するため、L1 -> L2 が wave2 で最初に提出されます。
同様に、一部のノードが wave1 で L1 を送信した場合、ラウンド 2 の L1 につながる少なくとも f+1 個の頂点が存在し、ラウンド 3 の L2 は前のラウンドの少なくとも 2f+1 個の異なる頂点を参照する必要があるため、L2 は次の場所に存在します。 L1 への最小パス。これにより、すべてのバリデーターが最終的に提出の順序に同意することも保証されます。
DAG-Riderとの比較
通常の状況では、DAG-Rider は頂点を送信するのに 4 ラウンドを必要としますが、Tusk は送信に 3 ラウンドしか必要としないため、送信の遅延が短縮されます。
ただし、4 ラウンドの投票を通じて、DAG-Rider は各ウェーブで頂点を送信する確率が少なくとも 2/3 であることを保証できますが、Tusk の投票ラウンドは 1 回少ないため、各ウェーブで頂点を送信する確率は波は 1/3 です。
つまり、非同期の状況では、DAG-Rider は頂点を送信するのに 3/2 ウェーブ (6 ラウンド) しか必要としませんが、Tusk は頂点を送信するために 3 つのウェーブを通過する必要があります.各ウェーブには 3 ラウンドが含まれることが知られています. 、各ウェーブの最後のラウンドは次のウェーブの最初のラウンドであるため、Tusk は頂点を送信するのに 7 ラウンド必要です。
メジロザメ属のサメ
Bullshark の論文では、2 つのバージョンのプロトコルが提案されています。
- 非同期バージョン: 通常の場合、頂点を送信するのに 2 ラウンドしかかかりません。DAG-Rider や Tusk と比較して、提出遅延がさらに短縮されます
- 部分同期バージョン: Tusk に基づいており、頂点を送信するのに 2 ラウンドしかかからないため、ブロック生成ラウンドの遅延が減少します
非同期バージョン
DAG-Rider と同様に、非同期プロトコル バージョンでも各ウェーブに 4 ラウンドが含まれます。ただし、BullShark には各ウェーブに 3 つのリーダーがあり、最初のラウンドからランダムに選択されたフォールバック リーダーと、最初と 3 番目のラウンドで事前に定義された定常状態のリーダーです。
下の図では、S1A と S1B は定常状態のリーダーであり、F1 はフォールバック リーダーです (各ウェーブの最後のラウンドでランダムに生成されます)。
頂点の送信プロセス:
- ラウンド 2 で、ノードは 2f+1 個のノードが S1A に投票したことを検出し、S1A を送信できます。
- ラウンド4で、ノードはS1Bに1票しか投じられずS1Bを提出できなかったことを発見し、wave2の検証ノードの投票タイプはフォールバックタイプに変更されまし
た - ラウンド 5 では、ノードはラウンド 4 で他の 2f+1 ノードを観察し、いずれも S1B を送信できないことを発見したため、現在のノードは、wave2 の他のノードがすべてフォールバック投票タイプであり、wave2 の定常状態リーダーであると判断できます。 (S2A と S2B) は提出の機会を失った
- ラウンド 8 で、ノードは 2f+1 個のノードが F2 に投票したことを検出したため、F2 を送信し、F2 を送信する前に S1B を送信しようとしますが、S1B は送信ルールを満たしていないため (現在のノードのローカル ビューでは、S1B f+ 1 ref) 未満であるため、この時点では F2 のみを送信します。
通常の状況下では、定常状態のリーダーを 2 ラウンドごとに送信できることがわかります。これは、Tusk プロトコルと比較してさらに最適化されています。同時に、フォールバック リーダーの設計により、最悪の非同期状態でも条件、コンセンサスはまだアクティブです。
コード分析
送信プロセスの疑似コード:
try_ordering 関数から、次のことがわかります。
- ラウンド %4==1 ラウンド中: 前のウェーブの 3 番目のラウンドで steayd リーダーまたはフォールバック リーダーを送信しようとし、現在のウェーブで自分と他のバリデーターの投票ステータスを確認します
- ラウンド %4==3 ラウンド中: 現在のウェーブの最初のラウンドのステエイド ステート リーダーのみを提出する必要があります
ブルシャークは頂点を提出できるかどうかを判断するだけでなく、過半数を決定する必要があるため、Tusk の f+1 とは異なり、ここでは 2f+1 が頂点提出投票の数として使用されていることが try_steady_commit と try_fallback_commit からわかります ( 2f+ 以上 1) ノードは次のウェーブで同じ投票状態にあります。
コミットリーダー
以前の知識から、頂点を提出するとき、現在のウェーブの下で私たちと同じ投票タイプに少なくとも 2f+1 個のノードがあると判断できました。
commit の役割は、特定の頂点を送信できると判断された後、前のラウンドで一時的にコミット解除された頂点を再帰的に送信することです。
リーダーの最後のラウンドが他のノードによって送信された場合、少なくとも 2f+1 票があり、少なくとも 2f+1 個のノードが同じ投票状態にあるという条件を満たしているため、現在のバリデーターの場合、そのローカル ビューに少なくとも f+1 票。
部分同期バージョン
このバージョンは Tusk コンセンサス プロトコルを簡略化したもので、コーディングが容易で、現在 Sui コンセンサス メカニズムに実装されています。
すべてのリーダー頂点がランダムに生成される Tusk とは異なり、Bullshark の部分同期バージョンの DAG の各奇数ラウンドには、定義済みのリーダー頂点があります (下の画像で緑色の実線で強調表示されています)。頂点のコミット ルールは単純です。リーダーが次のラウンドで少なくとも f+1 票を獲得した場合、リーダーをコミットします。図では、L3 は 3 票で提出されましたが、L1 と L2 は f+1 票未満で提出されませんでした。
ただし、ネットワークの非同期性により、DAG のローカル ビューは、検証ノードごとに異なる場合があります. 一部のノードは、以前のラウンドで L1 頂点と L2 頂点を正常に送信した可能性があります. したがって、L3 頂点を送信するときは、 L3 から開始して、L2 へのパスが存在するかどうかを確認します。L1 へのパスが存在する場合は、前のラウンドの頂点を最初に送信する必要があります。図では L3 から L2 へのパスがないので L2 はスキップできますが、L3 から L1 へのパスがあるので L1 → L3 を先に提出してください。
性能比較
Bullshark の論文を参照すると、以下は、通常の条件下で異なる数の検証ノードについて、HotStuff、Tusk、BullShark の 3 つのプロトコルの遅延とスループットを比較したものです。
- HotStuff: 10 ノード、20 ノード、50 ノードのコンセンサスの下で、スループットはそれぞれ 70,000 tx/s、50,000 tx/s、30,000 tx/s であり、レイテンシは低く、約 2 秒です。
- Tusk: Tusk のスループットは HotStuff のスループットよりも大幅に高くなります. 10 ノード コンセンサスの場合、そのピーク値は 110,000 tx/s であり、20 または 50 ノードの場合、そのピーク値は約 160,000 tx/s です. スループットは、ノードサイズの増加 (これは DAG の効率的な実装のおかげです)。スループットが高いにもかかわらず、Tusk のレイテンシは HotStuff よりも長く、約 3 秒です。
- BullShark: BullShark は、Tusk の高スループットと HotStuff の低レイテンシーのバランスを取ります。スループットも HotStuff よりも大幅に高く、10 ノード コンセンサスと 50 ノード コンセンサスでそれぞれ 110,000 tx/s と 130,000 tx/s に達します。 、その遅延は約2秒です
要約する
- Tusk プロトコルの理論的な出発点は DAG-Rider です。これは DAG-Rider に基づく改良版であり、通常の状況下でのブロック生成ラウンドの遅延を減らします。
- Bullshark の同期バージョンは、Tusk に基づいて引き続き最適化されます。これにより、待ち時間がさらに短縮され、実装がより簡単になります。ただし、HotStuff と同様に、最終的な同期の仮定が成り立たない場合、有効性は保証されません。
- Bullshark の非同期バージョンは、定常モードに基づくフォールバック投票モードを追加するため、通常の状況では同期バージョンと同じ低レイテンシであり、非同期条件下での活性を保証できます。
この記事では, 主に 3 つのラウンドベースの BFT コンセンサスについて説明します. 実際には, Fantom の lachesis など, ラウンドベースのアルゴリズムに厳密に従わない DAG ベースの BFT コンセンサスが数多くあります. このコンセンサスは、考え。より多くのプロジェクトが追加されると、DAG コンセンサスはより完全で多様になり、ブロックチェーンのスケーラビリティを改善するための想像力の余地が増えると考えられています。
参考元：
- DAG-Rider ペーパー: [PODC 2021]必要なのは DAG だけ
- イッカクと牙の論文：[2105.11827] イッカクと牙: DAG ベースの Mempool と効率的な BFT コンセンサス
- Bullshark 論文: [CCS 2022 に登場] Bullshark: DAG BFT
プロトコルが実用化 - DAG と BFT の出会い - 次世代の BFT コンセンサス
- Narwhal、Bullshark、および Tusk、Sui のコンセンサス エンジン | スイ・ドックス