ブロックチェーンの核心は厳格なグローバルコンセンサスを実現することです。つまり、ネットワークノードがどの国やタイムゾーンに分散しているかに関係なく、すべての参加者は最終的に客観的な結果について合意しなければなりません。

しかし、分散ネットワークの現実は理想的ではありません: ノードがオフラインになる、ノードが嘘をつく、そして中には意図的に妨害するノードもいます。この場合、システムはどのようにして「一つの声で話す」ことができ、一貫性を維持するのでしょうか？

これは、コンセンサスプロトコルが解決しようとする問題です。それは基本的に、独立した、そして部分的に信頼されていないノードのグループが、各トランザクションの順序と内容について一致した意思決定をどのように行うかを指示する一連のルールです。

そして、この「厳格なコンセンサス」が確立されると、ブロックチェーンはデジタル資産権の保護、インフレ防止通貨モデル、スケーラブルな社会連携構造など、多くの重要な機能を解除できます。しかし、前提条件は、コンセンサスプロトコル自体が同時に2つの基本的な側面を確保する必要があります。

• 相反する2つのブロックは両方とも確認されることはできません;
• ネットワークは前に進み続け、立ち往生したり停止したりすることはできません。

MonadBFTはこの方向性での最新の技術的なブレークスルーです。

コンセンサスプロトコルの進化に関する簡単なレビュー

コンセンサスメカニズムの分野では、実際に数十年にわたって研究されてきました。PBFT（Practical Byzantine Fault Tolerance）などの最初のプロトコルのバッチは、すでに非常に現実的な状況を処理できます。ネットワーク内の一部のノードがチェーンをドロップしたり、悪意を持ったり、ナンセンスを話したりしても、合計数の三分の一を超えない限り、システムは依然としてコンセンサスに到達できます。

これらの初期プロトコルの設計はより「伝統的」です：各ラウンドでリーダーが選択され、提案を開始し、他の検証者は複数のラウンドでこの提案に投票してトランザクションの順序を徐々に確認します。

投票プロセス全体は通常、事前準備、準備、確定、応答などの段階を経て進行します。各段階で、すべての検証者がお互いに通信する必要があります。言い換えれば、誰もが他の誰かに伝えなければならず、メッセージのボリュームは「メッシュ」パターンで爆発的に増加します。

この通信構造の複雑さはn²です。つまり、ネットワークに100人の検証者がいる場合、各合意ラウンドで約10,000通りのメッセージを送信する必要があるかもしれません。

小規模なネットワークでは、これは問題ではありませんが、検証者の数が増えると、システムの通信負荷がすぐに耐えられなくなり、効率に直接影響します。

情報の出所:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

‘みんながみんなと話す’二次通信構造は実際には非常に効率が悪いです。 例えば、100人の検証者を持つネットワークでは、各コンセンサスラウンドで何万ものメッセージを処理する必要があるかもしれません。

これはまだ小さな円で管理することができますが、グローバルでオープンなチェーンネットワークに配置すると、通信負荷はすぐに受け入れられないものになります。そのため、PBFTやTendermintなどの初期のBFTプロトコルは、通常、許可されたネットワークまたはほとんどのバリデータがほとんど機能しないシステムでのみ使用されます。

BFTプロトコルが許可なしのパブリックチェーン環境に適応するために、次世代の設計の一部は、より軽量な通信方法に移行しています。各バリデータがすべてのメンバーと通信するのではなく、リーダーとのみ通信を許可します。

これにより、元のn²からnへのメッセージの複雑さが最適化され、システムの負荷が大幅に軽減されます。

2018年に提案されたHotStuffプロトコルは、このスケーラビリティの問題に対処するために提案されました。その設計思想は非常に明確であり、PBFTの複雑な投票プロセスをより簡潔でリーダー主導の通信構造に置き換えることです。

HotStuffの重要な機能の1つは、いわゆる線形通信です。そのメカニズムでは、各検証者は現在のリーダーにのみ彼らの投票を送信する必要があり、その後、リーダーはこれらの投票をパッケージ化してクォーラム証明書（QC）を生成します。

このQCは基本的に集団署名であり、全ネットワークに証明します：『ほとんどのノードがこの提案に同意しています。』

一方、PBFTの通信モードは「すべてにブロードキャスト」であり、グループ内の誰もが話すことになり、時には混沌とした状況になります。一方、HotStuffのモードは、「1人がまとめ、1度に1つのパッケージを処理する」ようであり、ネットワークに何人いても効率的な運用を維持できます。

その図は、HotStuffのファンアウト通信構造とPBFTの完全に相互接続されたモードを比較しています。出典:

https://www.mdpi.com/1424-8220/24/16/5417

線形通信に加えて、HotStuffは効率を向上させるためにパイプライン化バージョンにさらにアップグレードすることができます。

元のHotStuffでは、同じバリデータが複数の連続したラウンドでリーダーとして機能し、ブロックが完全に確認されるまで続きます。このプロセスは「ラウンドごとに1つのブロックを処理する」もので、すべての取り組みが現在のものを前に進めることに集中しています。

HotStuffパイプラインでは、メカニズムはさらに柔軟であり、各ラウンドで新しいリーダーが選ばれ、各リーダーには2つのタスクがあります。

• 最後の投票ラウンドを一方向にクォーラム証明書（QC）に詰め込んで、ネットワーク全体にブロードキャストします;
• 一方で、新しいブロックを提案し、次のラウンドを開始する準備が整っています。

言い換えれば、「次の処理を行う前に1つを確認する」のではなく、生産ラインのように、異なるリーダーが交代で各ステップに責任を持つようになりました。前の人がブロックを提案し、次の人がそれを確認して新しいブロックを提案し続け、チェーン上の合意はリレーレースのように受け渡されます。

これが「組み立てライン」の比喩の起源です：現在のブロックはまだ確認プロセス中ですが、次のブロックはすでに準備中で、複数のステップが並行して進行し、スループット効率が向上しています。

要約すると、HotStuffなどのプロトコルは、従来のBFTに比べて、2つの側面で大幅な改善を遂げています:

• 最初、通信は軽く、各検証者はリーダーとだけ通信すればよいです；
• 第二に、処理効率が高く、複数のブロック確認プロセスを並行して実行できます。

これにより、HotStuffは多くの現代のPoSブロックチェーンコンセンサスメカニズムの設計テンプレートとなっています。ただし、すべてには長所と短所があります。パイプライン構造はパフォーマンスで強力ですが、見つけにくい構造リスクも静かに導入されています。

次に、この核心問題、テールフォーキングについて詳しく調査していきます。

末尾でのテールフォーキング問題

HotStuff、特にそのパイプライン化されたバージョンは、合意プロトコルのスケーラビリティ問題を解決しますが、いくつかの新しい課題も導入します。最も重要で見落されやすいのは、いわゆる「テールフォーキング」問題です。

テールフォークとは何ですか？それは単純に理解することができます：ブロックチェーンがチェーンの「末尾」で偶発的なブロックの再編成を経験します。

具体的には、有効なブロックがあり、ほとんどの検証者に正常に伝播され、十分な投票を受けています。理論上は、すぐに確認され、メインチェーンに書き込まれるはずです。しかし、最終的には「スキップされ」、孤立して、同じ高さで別の新しいブロックに置き換えられます。

これはバグでも攻撃でもありませんが、プロトコル自体の設計構造上、この「チェーンテイリング」の可能性があるためです。これはやや不公平に聞こえますか？では、これはどのように起こるのでしょうか？

前述の通り、HotStuffパイプラインの各リーダーには2つのタスクがあります。

• A. 新しいブロックを提案する（例：Bₙ₊₁）
• 前任リーダーのブロックの投票を集めてQCを生成します（例：最終的にBₙを確認するために）

これらの2つのタスクは並行しており、交代で中継されます。しかし、問題はここで発生します。

例えば、Alice がリーダーであり、彼女が高さ n でブロック Bₙ を提案し、それが多数決を得て「ほぼ確定」となったとします。

次に、リーダーの役割を担うのはボブの番です。チェーンの次のブロック Bₙ₊₁ に進み、さらに、Bₙ の QC（資格付きコミットメント）も提案に含めて、Bₙ の最終確認を完了させるべきです。

しかし、この時点でBobがオフラインの場合、または意図的にBₙのQCを提出しない場合、問題が発生します。

誰もがアリスのブロックをQCでパッケージ化しなかったため、Bₙの投票記録は広がりませんでした。確認されるはずだったこのブロックはしたがって「コールド処理」され、最終的にはネットワーク全体に無視されました。

これがテールフォークの本質です: 前のリーダーのブロックが次のリーダーの怠慢または悪意によってスキップされます。

なぜ尾のフォークがそんなに厳しいのですか？

テールフォークの問題は主に2つの側面に焦点を当てています。1)インセンティブメカニズムが崩れる、2)システムの活動が脅かされる。

最初、報酬は吸収されます：

ブロックが放棄されると、それを提案したリーダーは、ブロック報酬や取引手数料のいずれも受け取ることはありません。たとえば、アリスが有効なブロックを提案し、投票で圧倒的な支持を受けたとしても、ボブの過失や悪意のある操作により、ブロックが確認されなかった場合、最終的にはアリスは一銭も受け取れません。これは欠陥のあるインセンティブ構造につながります：ボブのような悪意のあるノードは、相手のブロックをスキップすることで報酬源を‘切り捨て’ることができます。この行動には技術的な攻撃は必要ありません。競合他社の利益を弱めるために故意の‘非協力’だけで十分です。これが繰り返されると、時間の経過とともに、システム全体の参加と公平性が低下し、ノード間の共謀さえ引き起こす可能性があります。

セカンド、MEV攻撃面積が拡大します：

テールフォークには、より悪質で深刻な問題も存在します：MEV（最大採取可能価値）が悪意を持って操作される余地が増えるということです。例を挙げましょう：たとえば、アリスが彼女のブロックに貴重な裁定取引を持っているとします。ボブがトラブルを起こしたいと思った場合、次のリーダーであるキャロルと共謀し、アリスのブロックを故意に広めないことにします。その後、キャロルは同じ高さで新しいブロックを再構築し、アリスの元の裁定取引を「盗み」、MEVの利益を自分のものとします。この「チェーンヘッドの再配置+共謀と横領」という慣行は、表面上はルールに従ったブロックですが、実際にはよく計画された略奪です。さらに悪いことに、これはリーダー間の「共謀」を誘発し、ブロック確認を公共サービスではなく利益分配のゲームに変えてしまいます。

第三に、最終性の保証を損ない、ユーザーエクスペリエンスに影響を与えます:

Nakamotoのようなプロトコルと比較すると、BFTの主な利点の1つは確定的な最終性です：ブロックが確定されると、それを巻き戻すことはできません。ただし、テールフォークは、特に「事前に確認されたが形式的に確認されていない」ブロックに影響を与え、この保証を乱します。一部の高スループットのdappは、レイテンシを減らすためにブロックの投票直後にデータをすぐに読み取りたい場合があり、ブロックが突然破棄されると、ユーザーステートのロールバックが発生する可能性があります-異常な口座残高、理由なく消えた高レバレッジ取引、突然のゲームステートリセットなど。

第四に、連鎖反応の故障を引き起こす可能性があります:

一般的に、テールフォークはラウンドのブロック確認を遅らせるだけであり、大きな影響はありません。ただし、いくつかの例外的なケースでは、連続していくつかのリーダーが前のブロックをスキップすることを選択した場合、システムが停滞する可能性があり、誰もが前のブロックを「引き継ぐ」ことを望んでいません。リーダーが最終的に責任を負うことを望む場合まで、全体のチェーンが停滞し、ネットワークは前に進むことができません。

以前には、BeeGeesプロトコルによって提案されたテールフォーク回避メカニズムなど、いくつかの解決策がありましたが、それらはしばしばパフォーマンスを犠牲にする必要があり、二次通信の複雑さを再導入するなどの問題があり、それは損失に値するものではありません。

MonadBFTとは何ですか？

MonadBFTは、テールフォーク問題に特に対処するように設計された新世代のコンセンサスプロトコルです。その強みは、構造上の脆弱性に対処しながらも、HotStuffパイプラインによってもたらされるパフォーマンスの利点を犠牲にしません。言い換えれば、MonadBFTは最初からやり直すのではなく、HotStuffのコアフレームワークに基づいて最適化を続けています。それは3つの主要な特性を維持しています。

1) リーダーの交代：各ラウンドごとに新しいリーダーを選出してチェーンを前進させます；
2) パイプライン化されたコミット：複数のブロック確認プロセスが重なる可能性があります；
3) リニア通信（リニアメッセージング）：各検証者はリーダーとだけ通信すればよく、多くのネットワークオーバーヘッドを節約できます。

ただ、これらの3つの点だけに頼るのは十分に安全ではありません。テールフォークの構造上の脆弱性を抑制するために、MonadBFTは2つの主要なメカニズムを追加しました。

1) 強制再提案メカニズム（再提案）
2) 承認なし証明書（NEC）

再提案メカニズム

BFTプロトコルでは、時間はラウンド（ビューとも呼ばれる）に分割され、各ラウンドには新しいブロックを提案するリーダーがいます。リーダーが失敗した場合（例えば、時間通りにブロックを提案しないか、無効な提案をする場合など）、システムは次のラウンドに切り替わり、新しいリーダーを選択します。

MonadBFTは、ビュースイッチプロセス中に正直に提案されたブロックがリーダーの交代によって 'チェーンをドロップ' しないようにするメカニズムを追加しました。

現在のリーダーが失敗した場合、検証者は署名付きメッセージを送信し、ラウンドの切り替え（ビューの変更）を示すことで、現在のラウンドがタイムアウトしました。

特に、このメッセージは、単に「タイムアウト」を示すだけでなく、バリデータの最近の投票のブロック情報も含める必要があります。これはつまり、「有効な提案を受信していないことを示し、これが現在私が見ている最新のブロックです」と言っているのと同等です。

新しいラウンドのリーダーは、超過半数（2f+1）のバリデータからこれらのタイムアウトメッセージを収集し、タイムアウト証明書（TC）にマージします。このTCは、前のラウンドが失敗したときの全ネットワークの『チェーンヘッドブロック』の統一された認知スナップショットを表します。新しいリーダーは、その中から最も高い高さ（または最新のビューナンバー）であるハイティップとして知られるブロックを選択します。

MonadBFTは次を要求します: 新しいリーダーの提案には有効なTCが含まれている必要があり、そのTC内で最も保留中のブロックを再提案して、このブロックに再確認の機会を与える必要があります。

なぜ？前述のように、確認されそうなブロックが消えるのは避けたいのです。

例えば、Alice がビュー 5 のリーダーであり、有効なブロックを提案し、過半数の投票を受け取ったとします。次に、ビュー 6 のリーダーである Bob がオフラインでチェーンのプロセスを進められない場合、Carol がビュー 7 のリーダーとして引き継ぐ時に、MonadBFT のルールに従い、TC を含めて Alice のブロックを再提案しなければなりません。このようにして、Alice の正直な作業が無駄にならないようにします。

もしキャロルがアリスのブロックを持っていない場合、他のノードからそれをリクエストすることができます。ノードは次のことができます:

• ブロックを提供する、または
• 送信者がこのブロックを持っていないことを示す署名付きの「非承認（NE）」メッセージを返します（そのメカニズムは後で説明されます）。 （最大fビザンティンノードは、リクエストを無視して応答しないことを選択することができます。）

キャロルがアリスのブロックを再提案すると、前のリーダーの失敗のために '関与' されないようにするため、追加の提案の機会を得ます。

この再提案メカニズムの役割は明確です：チェーンの進歩が公平であり、悪運や誰かの妨害によって有効な作業が静かに廃棄されることがないようにすることです。

非承認可能証明書（NEC）

前の例を続ける：Bobのターンがタイムアウトした後、Carolは他のバリデータに高いチップブロック（つまり、Aliceのブロック）を提供するように要求します。この時点で、少なくとも2f+1人のバリデータが応答します：

• アリスのブロックを提供するか
• Aliceのブロックを受信していないことを示す署名付きのNEメッセージを送信するか、

キャロルがアリスのブロックを受け取る限り、彼女はルールに従ってそれを再提案しなければなりません。 キャロルは、少なくともf+1人の検証者がNEメッセージに署名した場合にのみ、ブロックをスキップして新しいブロックを提案できます。

なぜf+1なのか？ 3f+1のバリデータで構成されるBFTシステムでは、最大でもfのみが悪意を持っている可能性があります。もしアリスのブロックが過半数の投票を受けたのであれば、少なくとも2f+1の正直なノードがそれを受け取りました。

従って、Carolが「私はAliceのブロックを取得できない」と主張する場合、それらのいずれもそれを受け取っていないことを証明するために、f+1のバリデータ署名を生成する必要があります。これはエンドースメントなし証明書（NEC）を構成します。

NECはリーダーの「免責事項」資格証明書です：これは、前のブロックが確認の準備ができていないこと、悪意を持ってスキップされていないことを検証できる証拠ですが、「理由付きで放棄されています」。

再提案+未承認証明書=テールフォークの解決

MonadBFTは、再提案メカニズムと非承認証明書（NEC）を導入することにより、厳密で明確なチェーンヘッド処理ルールを導入しています。

いずれにしても、最終的には「確認されることに近い」ブロックにコミットするか。

ブロックがまだ確認する準備ができていないことを証明する十分な証拠を提供するか、

それ以外の場合、前のブロックをスキップまたは置き換えることは許可されていません。

このメカニズムにより、合法的な過半数の投票を受けたブロックは、リーダーのミスや意図的な回避によって放棄されることはありません。

テイルフォークの構造的リスクは体系的に解決され、プロトコルは明確に不適切なスキップ動作を制約できます。

リーダーが前のブロックをスキップしようとした場合、NECの証拠を提供しない場合、プロトコルはすぐにその行動を認識し、拒否します。暗号証拠なしでのジャンプ行動は違法と見なされ、ネットワークのコンセンサスサポートを受けません。

経済的インセンティブの観点から、この設計はバリデーターに明確な保護を提供します:

• ブロックが正直に提案され、投票支持を受ける限り、後続の失敗によって報酬が剥奪されることはありません。
• 極端な状況でも、例えばノードが故意に自分の提案ラウンドをスキップし、前のブロックからMEVを奪おうとするような場合でも、プロトコルは後続のリーダーにオリジナルのブロックを再提案することを優先させ、攻撃者がプロセスをスキップして経済的利益を得るのを防ぎます。

より重要なことに、MonadBFTはセキュリティを向上させるためにプロトコルのパフォーマンスを犠牲にしませんでした。

過去には、BeeGeesプロトコルなどのテールフォークを対象とするいくつかの設計が特定の保護機能を持っていましたが、しばしば高い通信複雑性（n²）に依存するか、各ラウンドで重い通信プロセスを可能にすることが多く、実際にはシステムの負担を大幅に増加させていました。

MonadBFTの設計戦略はより洗練されています:

ビューが失敗したり異常が存在する場合にのみ、追加の通信（タイムアウトメッセージ、ブロック再提案など）が開始されます。ほとんどの誠実なリーダーが継続的にブロックを生成する通常の経路では、プロトコルは軽量かつ効率的な動作状態を維持します。

MonadBFTの前身プロトコルに比べて、パフォーマンスとセキュリティの間の動的なバランスが正確にその中心的な利点の1つです。

概要

本文では、従来のPBFTコンセンサスの基本的なメカニズムについて検討し、HotStuffプロトコルの開発経路を整理し、MonadBFTがプロトコルレイヤー構造でHotStuffパイプラインの固有のテイルフォーク問題をどのように解決するかに焦点を当てています。

リアフォークは、ブロック提案者の経済的インセンティブを歪め、ネットワーク活動に潜在的な脅威をもたらす可能性があります。MonadBFTは、誠実なリーダーによって提案されたブロックが法定多数の投票で承認されることを保証し、再提案メカニズムと非承認証明書（NEC）を導入することで、そのブロックが放棄されることはありません。

次の記事では、MonadBFTのもう2つのコア機能を引き続き探求します:

1）スペキュラティブファイナリティ
2）楽観的なレスポンシブ

バリデーターと開発者にとってのこれらのメカニズムとその実用的な意義のさらなる分析。

ステートメント:

1. この記事は[michael_lwy]から転載されたもので、著作権は元の著者に帰属します[michael_lwy]，再版に異議がある場合は、お問い合わせくださいGate Learn Team）,チームは関連プロセスに従ってできるだけ早く対処します。
2. 免責事項：この記事で表現されている意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の他の言語バージョンは、Gate Learnチームによって翻訳されていますが、言及されていませんGate許可なく翻訳された記事をコピー、配布、または盗用しないでください。