MonadBFT：ブロックチェーン合意の安全性を再定義し、末尾のフォークリスクに終止符を打つ
TechFlow厳選深潮セレクト
MonadBFT：ブロックチェーン合意の安全性を再定義し、末尾のフォークリスクに終止符を打つ
MonadBFTは、テールフォーク問題を解決するために特別に設計された次世代コンセンサスプロトコルです。
Web3業界の深掘り報道に専念し潮流を洞察著者：michaellwy
ブロックチェーンの核となるのは、厳格なグローバル合意（strict global consensus）を実現することです。つまり、ネットワークノードがどの国に、どのタイムゾーンにあろうと、すべての参加者が最終的に一連の客観的な結果に対して一致する必要があります。
しかし現実の分散型ネットワークは完璧ではありません。ノードが切断されたり、嘘をついたり、意図的に妨害行為を行う場合さえあります。このような状況下で、システムはどうやって「全員が同じ結論に達する」ことができるのでしょうか？
これこそがコンセンサスプロトコルが解決すべき問題です。本質的には、互いに独立しており、完全に信頼できないノードたちが、各取引の順序と内容についてどのように統一された決定を下すかというためのルールセットです。
こうした「厳格な合意」が確立されれば、ブロックチェーンはデジタル所有権の保証、インフレに強い通貨モデル、拡張可能な社会的協働構造といった重要な機能を解放できます。ただし、その前提として、コンセンサスプロトコル自体が以下の2つの基本要件を同時に満たさなければなりません。
-
矛盾する2つのブロックが同時に確認されることはないこと
-
ネットワークは停止やフリーズなく、継続的に前進し続けること
MonadBFT は、まさにこの方向性においてなされた最新の技術的突破です。
コンセンサスプロトコルの簡単な進化史
コンセンサスメカニズムの研究は実は数十年の歴史があります。初期のプロトコルであるPBFT（Practical Byzantine Fault Tolerance）は、すでに非常に現実的な状況に対応できていました。ネットワーク内の一部のノードが故障したり、悪意を持ったり、虚偽の情報を流しても、それらが全体の1/3未満であれば、システムは依然として合意に達できるのです。
これらの初期プロトコルの設計は比較的「伝統的」でした。各ラウンドでリーダーを選出し、そのリーダーが提案を行い、他のバリデータがその提案に対して複数回の投票を行い、段階的に取引の順序を確定します。
投票プロセス全体は通常、pre-prepare、prepare、commit、replyといったいくつかのフェーズを経ます。各フェーズにおいて、すべてのバリデータが相互に通信する必要があります。つまり、全員が全員にメッセージを送る形になり、メッセージ量は「網目状」に爆発的に増加します。
この通信構造の複雑度は n² です。つまり、ネットワークに100人のバリデータがいれば、1回のコンセンサスごとに約1万件のメッセージがやり取りされる可能性があります。
これは小規模ネットワークでは問題になりませんが、バリデータ数が増えると、通信負荷は急速に耐え難くなるため、効率は大きく低下します。
出典：
https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
この「全員が全員と通信する」二次的な通信構造は、極めて非効率的です。例えば、100人のバリデータからなるネットワークでは、1回のコンセンサスで数万件のメッセージを処理しなければならないことがあります。
これは閉じた小規模グループ内では対応可能ですが、世界規模のオープンなブロックチェーンネットワークでは、通信負荷はすぐに受け入れがたいものになります。そのため、PBFTやTendermintのような初期のBFTプロトコルは、許可制ネットワーク（permissioned network）やバリデータ数が非常に少ないシステムでのみ、なんとか動作可能です。
BFTプロトコルを無許可型、パブリックチェーン環境にも適用できるようにするため、次世代の設計ではより軽量な通信方式が採用されるようになりました。つまり、各バリデータがリーダーだけと通信し、全員間の通信を行わないようにするのです。
これにより、メッセージの複雑度はn²からnに最適化され、システム負荷が大幅に軽減されます。
HotStuff プロトコルは2018年に提案され、まさにこのスケーラビリティ問題を解決するために生まれました。その設計理念は明確です。PBFTの複雑な投票プロセスに代わって、より簡潔でリーダー主導の通信構造を採用するのです。
HotStuffの鍵となる特徴は、いわゆる線形通信（linear communication）です。このメカニズムでは、各バリデータは自分の投票を現在のリーダーに送信するだけでよく、リーダーがそれらを集約してQuorum Certificate（QC、法定多数証明）を生成します。
このQCは本質的に集団署名であり、「大多数のノードがこの提案に同意した」とネットワーク全体に証明するものです。
一方、PBFTの通信モードは「全員が群れで発言する」ようなもので、非常に混乱しがちです。HotStuffのモードはむしろ 「一人が集約し、一括でパッケージングする」 ようなもので、ネットワークの規模に関わらず効率的に動作し続けられます。
上図は、HotStuffの扇状通信構造とPBFTの全接続モードを比較しています
出典：
https://www.mdpi.com/1424-8220/24/16/5417
線形通信に加えて、HotStuffはさらにパイプライン化バージョン（pipelined HotStuff）へと進化させることができ、効率を高めます。
オリジナルのHotStuffでは、同一のバリデータが複数ラウンドにわたって連続してリーダーを務め、ブロックが完全に確定するまで続きます。このプロセスは 「1ラウンドで1ブロックを処理」 するもので、すべてのリソースが現在のブロックの推進に集中します。
一方、パイプライン化HotStuff では、仕組みがより柔軟になります。各ラウンドで新しいリーダーが選ばれ、それぞれのリーダーには2つの任務があります。
-
前のラウンドの投票を集約し、Quorum Certificate（QC）としてネットワーク全体にブロードキャストする
-
新しいブロックを提案し、次のラウンドの準備をする
つまり、「1つを完全に確認してから次に進む」のではなく、生産ラインのように、異なるリーダーがそれぞれの工程を担当します。前のリーダーがブロックを提出し、次のリーダーがそれを確認しながら新たなブロックを提案し、コンセンサスがリレー競争のように続いていくのです。
これが「パイプライン」という比喩の由来です。現在のブロックがまだ確認プロセス中でも、次のブロックの準備は既に始まっているのです。複数のステップを並列化することで、スループット効率が向上します。
まとめると、HotStuffのようなプロトコルは、従来のBFTと比べて2つの点で大きな進歩を遂げています。
-
通信がより軽量になる。各バリデータはリーダーとのみ通信すればよい
-
処理効率が向上する。複数のブロック確認プロセスを並行して実行できる
このため、HotStuffは多くの現代のPoSブロックチェーンのコンセンサス設計のテンプレートとなっています。しかし、良い面ばかりではありません。パイプライン構造は性能を高める一方で、見過ごされがちな構造的リスクを静かに導入しているのです。
次に、その核心的な問題——テールフォーク（Tail Forking）——について深掘りしていきます。
テールフォーク問題（Tail-Forking）
HotStuff、特にそのパイプライン化バージョンは、コンセンサスプロトコルのスケーラビリティ問題を解決しましたが、同時に新たな課題も引き起こしています。その中で最も重要かつ見過ごされがちなのが、「テールフォーク」（Tail Forking）問題です。
テールフォークとは何か？簡単に言えば、ブロックチェーンの「チェーン末尾」で予期せぬブロック再編成（reorg）が発生することです。
具体的には、あるブロックが有効であり、大多数のバリデータに正常に配布され、十分な票を得ているにもかかわらず、本来であればすぐ確認されてメインチェーンに記録されるはずなのに、最終的に「スキップ」され、孤立ブロック（orphaned）となり、同じ高さの別の新ブロックに置き換えられてしまう現象です。
これはバグでも攻撃でもなく、プロトコル自体の設計構造に、「末尾が切れる」可能性が内在しているためです。不公平に感じませんか？では、これは一体どうやって起きるのでしょうか？
先ほど述べた通り、パイプライン化HotStuffの各リーダーには2つのタスクがあります。
-
A. 新しいブロックを提案する（例：Bₙ₊₁）
-
B. 前のリーダーのブロックに対する投票を集約し、QCを生成する（例：Bₙの最終確定）
これら2つのタスクは並行的・継ぎ足し式に進行します。しかし、問題はここにあります。
例として、Aliceがリーダーであり、高さnでブロックBₙを提案し、超多数の投票を得て「ほぼ確定寸前」になったとします。
次にBobがリーダーとなり、次のブロックBₙ₊₁を推進すると同時に、BₙのQCを自身の提案に含めて最終確定させるべきです。
しかし、もしBobがオフラインになったり、意図的にBₙのQCを提出しない場合、問題が起きます。
誰もAliceのブロックのQCをパッケージングしないため、Bₙの投票記録は広まらず、本来確認されるべきブロックが「放置」され、最終的にネットワーク全体によって無視されてしまいます。
これがテールフォークの本質です。前のリーダーのブロックが、次のリーダーの不履行または悪意によってスキップされるのです。
なぜテールフォークは深刻なのか？
テールフォークの問題は主に2つの側面に影響します：1）インセンティブ機構の破壊、2）システムの活性への脅威です。
第一、報酬の消失：
ブロックが放棄されると、それを提案したリーダーは一切の報酬を受け取れません。ブロック報酬も、トランザクション手数料も得られません。例えば、Aliceが正当なブロックを提案し、超多数の投票を得たにもかかわらず、Bobのミスや悪意的な操作により確認されず、結果としてAliceは一銭も得られないのです。これは誤ったインセンティブ構造を生み出します。Bobのような悪意のあるノードは、ライバルのブロックをスキップすることで、彼らの報酬源を「遮断」できます。このような行為には技術的攻撃は不要で、単に「協力しない」ことで競争相手の収益を損なうことができるのです。これが繰り返されれば、長期的にはシステムへの参加意欲や公平性が低下し、ノード間の共謀を誘発する可能性さえあります。
第二、MEV攻撃の余地が拡大：
テールフォークは、より隠れた深刻な問題も引き起こします。それは、MEV（最大抽出可能価値）が悪用される空間が広がることです。例えば、Aliceのブロックに極めて高価値な裁定取引が含まれているとします。Bobが悪意を持っている場合、次のリーダーCarolと結託し、意図的にAliceのブロックを伝播しないようにできます。その後、Carolが同じ高さで新しいブロックを再構築し、Aliceの裁定取引を「盗んで」MEVの利益を自分たちのものにするのです。この「チェーンヘッドの再配置＋共謀による横領」は、表面上はルールに従ってブロックを生成しているように見えますが、実際には精巧に計画された略奪行為です。さらに悪いことに、これはリーダー同士の「共謀関係」を促進し、ブロック確認が公共サービスではなく、利益分配ゲームになってしまう危険性があります。
第三、最終性の保証が損なわれ、ユーザー体験に悪影響：
Nakamoto型プロトコルと比べ、BFTの大きな利点は確定的最終性（deterministic finality）にあります。一度ブロックがコミットされれば、ロールバックできません。しかし、テールフォークはこの保証を破壊します。特に「投票は得られたが正式確認されていない」ブロックにおいて顕著です。高スループットなdappは、ブロックの投票後すぐにデータを読み取り遅延を抑えることを望みますが、そのブロックが突然放棄されると、ユーザーステータスが巻き戻される可能性があります。例えば、アカウント残高の異常、完了したはずのハイレバレッジ取引が消える、ゲームの状態がリセットされるなどです。
第四、連鎖的障害を引き起こす可能性：
一般的に、テールフォークはせいぜい1ラウンド遅れる程度で、影響は限定的です。しかし、特殊な状況下で、複数のリーダーが連続して前のブロックをスキップしようとすれば、システムは停止状態に陥る可能性があります。誰も「前のブロックを受け継ぐ」ことを拒否するのです。チェーンの進行は、ついに「責任を負う」リーダーが現れるまで止まったままになります。
過去にも、BeeGeesプロトコルが提唱したテールフォーク回避メカニズムなどいくつかの解決策がありましたが、多くの場合、性能を犠牲にしており、二次的な通信複雑度を再導入する必要があり、得るものが少ないという問題がありました。
MonadBFTとは何か？
MonadBFTは、テールフォーク問題を解決するために設計された次世代コンセンサスプロトコルです。その優れた点は、構造的リスクを解消しつつ、パイプライン化HotStuffがもたらす性能劣化を一切伴わないことです。言い換えれば、MonadBFTはゼロベースからの再設計ではなく、HotStuffのコアフレームワークを踏襲しつつ、さらなる最適化を施したものです。以下の3つのキーポイントは維持されています。
1）リーダー交代（rotating leader）：各ラウンドで新しいリーダーを選出してチェーンを推進する
2）パイプラインコミット（pipelined commits）：複数のブロック確認プロセスを重ねて実行できる
3）線形通信（linear messaging）：各バリデータはリーダーとのみ通信し、ネットワークリソースを大幅に節約
しかし、これら3つだけでは安全ではありません。テールフォークという構造的脆弱性を塞ぐために、MonadBFTは以下の2つのキーメカニズムを追加しています。
1）強制的再提案メカニズム（Re-Proposal）
2）エンドースメントなし証明（NEC, No-Endorsement Certificate）
再提案メカニズム（Re-Proposal）
BFTプロトコルでは、時間が一連のラウンド（viewと呼ばれる）に分割され、各ラウンドで1人のリーダーが新区塊を提案します。リーダーが失敗した場合（例：タイムリーにブロックを提出しない、無効な提案をする）、システムは次のラウンドに移行し、新しいリーダーを選出します。
MonadBFTは、view切り替え中に、正直に提出されたブロックがリーダー交代によって「脱落」しないよう保証するメカニズムを追加しました。
現在のラウンドのリーダーが失敗すると、バリデータは署名付きのビュー切り替えメッセージ（view change）を発行し、「現在のラウンドがタイムアウトした」ことを示します。
特に重要なのは、このメッセージは「タイムアウトした」というだけでなく、バリデータが最後に投票したブロック情報を含まなければならない点です。つまり、「合法な提案を受け取れなかった。これが私が見た最新のブロックだ」と宣言するのです。
新しいラウンドのリーダーは、超多数（2f+1）のバリデータからこれらのタイムアウトメッセージを収集し、タイムアウト証明（Timeout Certificate, TC）としてまとめる必要があります。このTCは、前ラウンドが失敗した時点で、ネットワーク全体が共有していた「チェーンヘッドブロック」の認識スナップショットを表します。新リーダーはその中から最高高さ（または最新ビュー番号）のブロック、いわゆるhigh_tipを選び出します。
MonadBFTは、新リーダーの提案が有効なTCを含み、かつTC内の最高の保留中ブロックを再提案しなければならないと規定しています。これにより、そのブロックに再確認のチャンスを与えます。
なぜでしょうか？前述の通り、ほぼ確認されかけたブロックがそのまま消えるのを避けたいのです。
例として、Aliceがview 5のリーダーで、有効なブロックを提出し、多数の投票を得たとします。次にview 6のリーダーBobがオフラインになり、チェーンの進行が止まります。view 7のリーダーCarolが登場したとき、MonadBFTのルールにより、彼女はTCを含み、Aliceのブロックを再提案しなければなりません。これにより、Aliceの誠実な作業が無駄にならないのです。
もしCarolがAliceのブロックを持っていなくても、他のノードに要求できます。ノードは以下のように応答できます。
-
ブロックを提供する
-
署名付きの「エンドースメントなしメッセージ」（No-Endorsement, NE）を返し、自身はそのブロックを持っていないことを示す（詳細は後述）。（最大f個のビザンチンノードが要求を無視して応答しない可能性がある。）
一旦CarolがAliceのブロックを再提案すれば、彼女は追加の提案権限を得て、前のリーダーの失敗によって「連座処罰」されないように保護されます。
この再提案メカニズムの目的は明確です。チェーンの進行が公平であり、運が悪かったり他人が邪魔をしたとしても、有効な作業がこっそり捨てられることはないようにするのです。
エンドースメントなし証明（NEC）
先ほどの例を続けます。Bobのラウンドがタイムアウトした後、Carolは他のバリデータにhigh_tipブロック（Aliceのブロック）の提供を求めます。このとき、少なくとも2f+1のバリデータが応答します。
-
Aliceのブロックを提供する
-
署名付きのNEメッセージを送り、自身はAliceのブロックを受信していないことを示す
CarolがAliceのブロックを入手できた場合、ルールに従って再提案しなければなりません。ただし、f+1以上のバリデータがNEメッセージに署名した場合のみ、Carolはそのブロックをスキップし、新しいブロックを提案できます。
なぜf+1なのでしょうか？3f+1のバリデータからなるBFTシステムでは、最大f個の悪意ノードしか存在しません。もしAliceのブロックが本当に超多数の票を得ていたなら、少なくとも2f+1の正直なノードがそれを受信しているはずです。
したがって、Carolが「Aliceのブロックを取得できない」と主張する場合、f+1のバリデータが署名したNEメッセージを提示しなければなりません。これにより、エンドースメントなし証明（No-Endorsement Certificate, NEC）が形成されます。
NECはリーダーの「免責証明」です。前ブロックがまだ確認可能状態ではないことを証明する検証可能な証拠であり、「悪意でスキップした」のではなく、正当な理由で「放棄」したことを示します。
再提案 + エンドースメントなし証明 = テールフォークの解決
MonadBFTは、再提案メカニズム（Re-Proposal）とエンドースメントなし証明（NEC, No-Endorsement Certificate）を導入することで、チェーンヘッドの処理に関する厳密かつ明確なルールを確立しました。
「ほぼ確認されかけた」ブロックを最終コミットする
または、そのブロックがまだ確認条件を満たしていないことを証明する十分な証拠を提供する
それ以外の場合、前のブロックをスキップまたは置き換えることは許されません。
このメカニズムにより、法定多数の投票を得たブロックは、リーダーのミスや故意の回避によって放棄されることはないことが保証されます。
テールフォークの構造的リスクは体系的に解消され、不当なスキップ行為に対して明確な制約が課されます。
あるリーダーが正当な理由なく前のブロックをスキップしようとした場合、NECによる裏付けがなければ、プロトコルは直ちにその行為を識別して拒否します。暗号証拠のないスキップは違法と見なされ、ネットワークのコンセンサスは支持しません。
経済的インセンティブの観点から見ても、この設計はバリデータに対して明確な保護を提供します。
-
誠実に提出され、投票支持を得たブロックについては、後続のプロセスの障害によって報酬を剥奪されない
-
極端なケースでも、あるノードが自分の提案ラウンドを意図的にスキップして他人に前のブロックのMEVを奪わせようとしても、プロトコルは後続のリーダーに元のブロックを優先的に再提案させることで、攻撃者がスキップを通じて経済的利益を得ることを防ぐ
さらに重要なのは、MonadBFTが安全性向上のために性能を犠牲にしていない点です。
これまでのテールフォーク対策（例：BeeGeesプロトコル）は一定の防御能力を持ちつつも、多くの場合高通信複雑度（n²）や毎ラウンドの再通信プロセスに依存しており、実際にはシステム負荷を著しく増加させていました。
一方、MonadBFTの設計はより巧妙です。
ビュー失敗や異常が発生した場合にのみ、追加の通信（タイムアウトメッセージ、ブロックの再提案）を開始するのです。ほとんどの場合、正直なリーダーが連続してブロックを生成する通常パスでは、プロトコルは依然として軽量かつ効率的に動作し続けます。
この性能と安全性の動的バランスこそが、MonadBFTが前世代プロトコルに比べ持つ核心的優位性の一つです。
まとめ
本稿では、従来のPBFTコンセンサスの基本メカニズムを振り返り、HotStuffプロトコルの発展経路を整理した上で、特にMonadBFTがどのようにしてパイプライン化HotStuffに内在するテールフォーク問題をプロトコル層で解決するかを重点的に解説しました。
テールフォークはブロック提案者の経済的インセンティブを歪め、ネットワークの活性にも潜在的な脅威を及ぼします。MonadBFTは再提案メカニズムとエンドースメントなし証明（NEC）を導入することで、正直なリーダーが提出し、法定多数の投票を得たブロックが放棄またはスキップされることを防止しています。
次回は、MonadBFTの他の2つの主要特性について探ります。
1）仮の最終性（Speculative Finality）
2）楽観的応答性（Optimistic Responsiveness）
そして、これらのメカニズムがバリデータや開発者にとってどのような実際的意味を持つのかをさらに分析します。
続く。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
