MonadBFT 解析（上）：末尾フォーク問題の解決方法

2025.05.05

共有先

TechFlow厳選深潮セレクト

MonadBFT 解析（上）：末尾フォーク問題の解決方法

尾部分叉はブロック提案者の経済的インセンティブを歪め、ネットワークの活性に潜在的な脅威を与える可能性がある。MonadBFT は再提案メカニズムと背書なし証明書（NEC）を導入することで、正直なリーダーによって提案され、法定多数の投票を得たすべてのブロックが放棄またはスキップされることのないよう保証する。

2025.05.05 - 03:16:07

MonadMonadBFT

Web3業界の深掘り報道に専念し潮流を洞察

ブロックチェーンの核心は、厳密なグローバルコンセンサス（strict global consensus）を実現することにある。つまり、ネットワークノードがどの国やタイムゾーンに分散していようとも、すべての参加者が最終的に一組の客観的な結果について一致しなければならないということだ。

しかし現実の分散ネットワークは理想的ではない：ノードが切断されたり、嘘をついたり、悪意を持って妨害する者さえいる。このような状況下で、システムはいかにして「全員一致」を保ち、整合性を維持しているのか？

これがコンセンサスプロトコルが解決すべき問題である。本質的には、互いに独立しており、完全に信頼できないノードたちが、各取引の順序と内容について統一された決定をどうやって下すかという一連のルールのことだ。

そして一旦この「厳密なコンセンサス」が確立されれば、ブロックチェーンはデジタル所有権の保証、インフレに強いマネーモデル、拡張可能な社会的協働構造など、多くの重要な特性を解き放つことができる。ただし前提として、コンセンサスプロトコル自体が以下の二つの基本要件を同時に満たさなければならない：

相互に矛盾する二つのブロックが確認されることはないこと；
ネットワークは停止したり固まったりせず、継続的に進行し続けること。

TechFlowはまさにこの方向における最新の技術的飛躍である。

コンセンサスプロトコルの簡潔な進化史

コンセンサスメカニズムという分野は、実は数十年にわたり研究されてきた。初期のプロトコル、例えばPBFT（Practical Byzantine Fault Tolerance：実用的ビザンチンフォールトトレランス）はすでに非常に現実的な状況に対処できていた。つまり、ネットワーク内に一部のノードが脱落したり、悪意を持ったり、誤った情報を流したとしても、それらが全体の1/3を超えない限り、システムは依然として合意に達できるのである。

こうした初期プロトコルの設計は比較的「伝統的」だった。各ラウンドでリーダーを選出し、そのリーダーが提案を行い、他のバリデータがその提案に対して複数回の投票を行い、段階的に取引の順序を確定していく。

投票プロセス全体は通常いくつかのフェーズを経る。pre-prepare、prepare、commit、replyなどだ。各フェーズにおいて、すべてのバリデータは互いに通信を行う必要がある。つまり、誰もが他の全員に一度ずつメッセージを送る必要があり、メッセージ量は「網目状」に爆発的に増加する。

この通信構造の複雑度はn²である。つまり、ネットワークに100人のバリデータがいれば、一回のコンセンサスラウンドで約1万通のメッセージが送られる可能性がある。

これは小規模ネットワークでは大きな問題ではないが、バリデータ数が増えれば、システムの通信負荷は急速に耐え難くなり、効率は大きく低下する。

monadbft_2

この「全員が全員と通信する」という二次的な通信構造は、実に非効率的である。例えば、100人のバリデータからなるネットワークでは、一回のコンセンサスごとに数万通のメッセージを処理しなければならない。

これは小規模なグループ内ではまだ対応可能だが、グローバルかつオープンなブロックチェーンネットワークでは、通信負荷はすぐに受け入れがたいものとなる。そのため、PBFTやTendermintのような初期のBFTプロトコルは、通常、許可制ネットワーク（permissioned network）やバリデータ数が非常に少ないシステムでのみ実用可能であった。

BFTプロトコルを許可不要型、パブリックチェーン環境にも適応させるため、次世代の設計ではより軽量な通信方式へと向かうようになった。つまり、各バリデータがリーダーのみと通信すればよく、全員が互いに通信する必要はない。

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

HotStuffプロトコルは2018年に登場し、まさにこのスケーラビリティ問題を解決するために提唱された。その設計理念は明確である：PBFTの複雑な投票プロセスに代えて、よりシンプルでリーダー主導の通信構造を採用すること。

HotStuffのキーフィーチャーはいわゆる線形通信（linear communication）である。このメカニズムでは、各バリデータは自分の投票を現在のリーダーに送るだけでよい。リーダーはそれらの投票を集約し、Quorum Certificate（QC、法定多数証明）を生成する。

このQCは本質的に集団署名であり、「大多数のノードがこの提案に同意した」とネットワーク全体に証明する役割を持つ。

対照的に、PBFTの通信モードは「全員へのブロードキャスト」であり、誰もが群れの中で発言するため、非常に混乱した状態になりやすい。一方、HotStuffのモードは「一人が収集し、一括でパッケージングする」ようなものであり、ネットワークにどれだけ多くの人がいても、依然として高効率で動作できる。

monadbft_3

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

オリジナルのHotStuffでは、同じバリデータが複数ラウンドにわたって連続してリーダーを務め、一つのブロックが完全に確定するまで続く。このプロセスは「一ブロックずつ処理」であり、すべてのリソースが現在のブロックの推進に集中する。

一方、パイプライン化HotStuffでは、メカニズムがより柔軟になる。各ラウンドで新しいリーダーが選ばれ、各リーダーには二つの任務がある：

前ラウンドの投票を集約してQuorum Certificate（QC）を作成し、全ネットワークにブロードキャストする；
新しいブロックを提案し、次のラウンドの準備をする。

つまり、「一つを完全に確認してから次を処理する」のではなく、生産ラインのように、異なるリーダーが各工程を担当する。前の者がブロックを提出し、次の者がそれを確認しつつ新たなブロックを提案し、コンセンサスがリレー競争のように引き継がれていく。

これが「パイプライン」という比喩の由来である。現在のブロックが確認プロセスを進める一方で、次のブロックの準備も並行して行われる。複数のステップを同時進行させることで、スループット効率が向上する。

まとめると、HotStuffのようなプロトコルは、従来のBFTと比べて二つの面で大きな改善を遂げている：

通信がより軽量になり、各バリデータはリーダーとのみ通信すればよい；
処理効率が高く、複数のブロック確認プロセスを並列化できる。

これにより、HotStuffは現代の多くのPoSブロックチェーンコンセンサスの設計テンプレートとなった。しかし、何事も利点があれば欠点もある――パイプライン構造は性能を高める一方で、気づかれにくい構造的リスクを静かに導入してしまう。

次からは、この核心的な問題、「テイルフォーク（Tail Forking）」について深く考察する。

テイルフォーク問題（Tail-Forking）

HotStuff――特にそのパイプライン版――はコンセンサスプロトコルのスケーラビリティ問題を解決したが、同時に新たな課題も生じさせた。その中でも最も重要かつ見過ごされがちなのが、「テイルフォーク（Tail Forking）」と呼ばれる問題である。

テイルフォークとは何か？簡単に言えば、ブロックチェーンの「チェーン末尾」で予期せぬブロック再編（reorg）が発生することを指す。

具体的には、あるブロックが有効であり、大多数のバリデータに配布され、十分な投票を得ており、理論上はすぐ確認され、メインチェーンに書き込まれるはずだった。しかし最後にそれが「スキップ」され、孤立化（orphaned）され、同じ高さの別の新しいブロックに置き換えられてしまう。

これはバグでも攻撃でもなく、プロトコル自体の設計構造に、このような「末尾が外れる」可能性が内在しているためである。これは不公平に聞こえるだろうか？では、一体どのようにして起こるのだろうか？

前述の通り、パイプラインHotStuffの各リーダーには二つのタスクがある：

A. 新しいブロック（例：Bₙ₊₁）を提案する
B. 前のリーダーのブロックに対する投票を集約し、QCを生成する（例：Bₙの最終確定）

これら二つのタスクは並行的・交替的に実行される。しかし、ここに問題がある。

例として、Aliceがリーダーとなり、n番目の高さでブロックBₙを提案し、超多数の投票を得て「ほぼ確定寸前」になったとする。次にBobがリーダーとなり、次のブロックBₙ₊₁を推進すると同時に、BₙのQC（法定多数証明）を自身の提案に含め、Bₙの最終確定を完了すべきである。

しかし、もしBobがオフラインになっていたり、意図的にBₙのQCを提出しなかった場合、問題が発生する。

誰もAliceのブロックのQCをパッケージングしないため、Bₙの投票記録は広まらず、本来確認されるはずだったブロックが「無視」され、最終的にネットワーク全体によって無視されてしまう。

これがテイルフォークの本質である：前のリーダーのブロックが、次のリーダーの不履行または悪意によってスキップされること。

monadbft_4

なぜテイルフォークは深刻なのか？

テイルフォークの問題は主に二つの側面に集中している：1）インセンティブメカニズムの破壊、2）システムの活性（liveness）への脅威。

第一に、報酬の消失：ブロックが破棄されれば、それを提案したリーダーは報酬を得られない。ブロック報酬もトランザクション手数料も得られない。例えば、Aliceが正当なブロックを提案し、超多数の投票を得たにもかかわらず、Bobのミスや悪意的操作により確認されず、結果としてAliceは一銭も得られない。これは誤ったインセンティブ構造を生む：Bobのような悪意あるノードは、ライバルのブロックをスキップすることで、彼らの報酬源を「遮断」できる。このような行為には技術的攻撃は不要で、単に「協力しない」故意の行動だけで、競争相手の利益を損なうことができる。このようなことが繰り返されれば、長期的にシステムの参加意欲と公平性が低下し、さらにはノード間の共謀を誘発する可能性すらある。

第二に、MEV攻撃の余地が拡大：テイルフォークは、より隠蔽された深刻な問題も引き起こす：MEV（最大抽出可能価値）の悪用空間が広がること。例として、Aliceのブロックに極めて高価値な裁定取引が含まれているとする。Bobが悪意を持てば、次のリーダーCarolと結託し、意図的にAliceのブロックを広めない。その後、Carolが同じ高さで新しいブロックを再構築し、Aliceの裁定取引を「盗用」して、MEVの利益を自分たちのものにする。このような「チェーン先頭の再配置＋共謀による横取り」は、表面上はルールに従ってブロックを作成しているように見えるが、実際には精巧に設計された略奪行為である。さらに悪いことに、これはリーダーたちの間に「共謀関係」を形成させ、ブロック確認を公共サービスではなく、利益分配ゲームにしてしまう。

第三に、最終性の保証が損なわれ、ユーザーエクスペリエンスに影響： Nakamoto型プロトコルと比較して、BFTの大きな利点は決定的最終性（deterministic finality）にある。一度ブロックが確定すれば、取り消せない。しかしテイルフォークはこの保証を損なう。特に「投票は獲得したが正式に確定していない」ブロックに対して顕著である。高スループットのdappは、遅延を減らすためにブロックの投票通過直後にデータを読み取りたいことが多いが、もしそのブロックが突然破棄された場合、ユーザーの状態が巻き戻される可能性がある――例えば口座残高の異常、完了したはずの高レバレッジ取引が突然消える、ゲームの状態がリセットされるなど。

第四に、連鎖的障害を引き起こす可能性：一般に、テイルフォークは特定のブロックの確認が一ラウンド遅れる程度の影響しか及ぼさない。しかし、エッジケースでは、連続して複数のリーダーが前のブロックをスキップしようとすれば、システムは停滞状態に陥る可能性がある。誰も「前のブロックを受け継ぐ」ことを望まなくなるのだ。チェーンの進行が完全に止まり、ついに「責任を引き受ける」リーダーが現れるまで、ネットワークは前進できない。

monadbft_5

これまでにも、BeeGeesプロトコルが提案したテイルフォーク回避メカニズムなどの解決策が存在したが、しばしば性能を犠牲にしており、二次的な通信複雑度を再導入するなど、得るよりも失うものが大きかった。

TechFlowとは何か？

TechFlowは、テイルフォーク問題を解決するために設計された次世代コンセンサスプロトコルである。その優れた点は、構造的リスクを解決しつつ、パイプラインHotStuffがもたらす性能優位性を犠牲にしないことにある。言い換えると、TechFlowはゼロから作り直すのではなく、HotStuffのコアフレームワークを基にさらに最適化したものである。以下の三つの重要な特徴を維持している：

リーダー交代制（rotating leader）：各ラウンドで新しいリーダーを選出してチェーンを推進；
パイプラインコミット（pipelined commits）：複数のブロック確認プロセスを重ねて実行可能；
線形通信（linear messaging）：各バリデータはリーダーとのみ通信すればよく、ネットワーク負荷を大幅に削減。

しかし、この三点だけでは安全ではない。テイルフォークという構造的脆弱性を塞ぐために、TechFlowは以下の二つの重要なメカニズムを追加している：

強制再提案メカニズム（Re-Proposal）
無背書証明（NEC, No-Endorsement Certificate）

再提案メカニズム（Re-Proposal）

BFTプロトコルでは、時間は一連のラウンド（viewと呼ぶ）に分割され、各ラウンドでリーダーが新しいブロックを提案する責任を持つ。リーダーが失敗した場合（例：タイムリーにブロックを提出しない、または無効な提案）、システムは次のラウンドに切り替わり、新しいリーダーを選ぶ。

TechFlowは、view切り替えの過程で、誠実に提出されたブロックがリーダー交代により「脱落」しないよう、新たなメカニズムを追加した。

現在のラウンドのリーダーが機能しなくなると、バリデータは署名付きのview変更メッセージ（view change）を発行し、そのラウンドがタイムアウトしたことを示す。

特に重要なのは、このメッセージは単に「タイムアウトした」という意味だけでなく、そのバリデータが最近投票したブロック情報を含まなければならない点である。つまり、「合法な提案を受けていない。これが私が認識している最新のブロックだ」と表明している。

新しいラウンドのリーダーは、スーパーマジョリティ（2f+1）のバリデータからこれらのタイムアウトメッセージを収集し、タイムアウト証明（Timeout Certificate, TC）として統合する。このTCは、前のラウンドが失敗した時点で、ネットワーク全体が共有していた「チェーンヘッダブロック」のスナップショットを表す。新リーダーはその中から最も高い高さ（または最新のview番号）のブロック、いわゆるhigh_tipを選び出す。

TechFlowでは、新リーダーの提案は有効なTCを含んでいなければならず、またTC内の最高の保留ブロックを再提案しなければならない。これにより、そのブロックが再び確認される機会を得る。

なぜか？先ほど述べたように、ほぼ確認されかけたブロックがそのまま消えることを望まないからである。

例として、Aliceがview 5のリーダーとして有効なブロックを提出し、多数の投票を得たとする。次に、view 6のリーダーBobがオフラインになり、チェーンの進行を進められなかった。そしてview 7のリーダーCarolが就任したとき、TechFlowのルールに従えば、彼女は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のバリデータの署名を提示しなければならない。これが無背書証明（No-Endorsement Certificate, NEC）となる。

NECはリーダーの「免責証明」である。前ブロックがまだ確認可能になっていないことを証明する検証可能な証拠であり、悪意でスキップしたのではなく、正当な理由で「放棄」したことを示す。

再提案＋無背書証明＝テイルフォークの解決

TechFlowは、再提案メカニズム（Re-Proposal）と無背書証明（NEC, No-Endorsement Certificate）を導入することで、チェーンヘッドの処理に関する厳密かつ明確なルールを確立した：

「ほぼ確認されかけた」ブロックを最終的にコミットするか、あるいはそのブロックがまだ確認条件を満たしていないことを証明する十分な証拠を提供する。それ以外の場合は、前のブロックをスキップまたは置き換えてはならない。

このメカニズムにより、法定多数の投票を得たブロックは、リーダーのミスや意図的な回避によって放棄されることがなくなる。テイルフォークの構造的リスクは体系的に解消され、プロトコルは不適切なスキップ行為に対して明確な制約を設けることができる。

あるリーダーが理由なく前のブロックをスキップしようとしたが、NECによる裏付けを提供できなければ、プロトコルは直ちにその行為を識別し拒否する。暗号的証拠のないスキップは違法と見なされ、ネットワークコンセンサスの支持を得られない。

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

誠実に提出され、投票支持を得たブロックについては、後続の工程の故障によって報酬が剥奪されることはない；
極端な状況下でも、あるノードが自らの提案ラウンドを意図的にスキップし、他人が前のブロックのMEVを先行取得するのを支援しようとしても、プロトコルは後続のリーダーに元のブロックを優先して再提案させるため、攻撃者はスキッププロセスを通じて経済的利益を得ることができない。

さらに重要なのは、TechFlowが安全性向上のためにプロトコルのパフォーマンスを犠牲にしていない点である。

これまでのテイルフォーク対策（例：BeeGeesプロトコル）は一定の防御能力を持つものの、しばしば高通信複雑度（n²）に依存したり、毎ラウンドで再通信プロセスを起動したりするため、実際にはシステム負荷を著しく増加させていた。

TechFlowの設計戦略はさらに巧妙である：

ビューの失敗や異常が発生した場合にのみ、追加の通信（タイムアウトメッセージ、ブロックの再提案など）を開始する。ほとんどの場合、誠実なリーダーが連続してブロックを出力する正常なパスでは、プロトコルは依然として軽量かつ高効率に動作し続ける。

この性能と安全性の間の動的バランスこそが、TechFlowが従来のプロトコルに比べ持つ核心的優位性の一つなのである。

monadbft_6