著者: michaellwyブロックチェーンの核心は、厳密なグローバルコンセンサス（strict global consensus）を実現することにあります。つまり、ネットワークノードがどの国やタイムゾーンに分布していても、すべての参加者が最終的に一連の客観的結果に合意しなければならないということです。しかし、現実の分散ネットワークは理想的ではありません：ノードがダウンしたり、ノードが嘘をついたり、さらには故意に破壊する人もいます。このような状況では、システムはどのように「一致」を保つのでしょうか？これがコンセンサスプロトコルが解決しようとしている問題です。本質的には、互いに独立し、完全に信頼できないノードのグループが、各取引の順序と内容についてどのように合意に達するかを導くための一連のルールです。そしてこの「厳密なコンセンサス」が確立されると、ブロックチェーンはデジタル所有権の保障、インフレに強い通貨モデル、そしてスケーラブルな社会協力構造など、多くの重要な特性を解放できる。しかし条件として、コンセンサスプロトコル自体が同時に二つの基本的な面を保証しなければならない。相互に矛盾する2つのブロックが確認されることはできません；ネットワークは継続的に推進されなければならず、停止したり止まったりしてはいけません。MonadBFTは、この方向における最新の技術的突破口です。コンセンサスプロトコルの簡単な進化の振り返りコンセンサスメカニズムのこの分野は、実際には数十年にわたって研究されてきました。最初の一群のプロトコル、例えばPBFT（実用的バイザンチンフォールトトレランス）は、非常に現実的な状況に対処できるようになっています。つまり、ネットワーク内の一部のノードが故障したり、悪意を持ったり、無意味なことを言ったりしても、それらが総数の1/3を超えなければ、システムは合意に達することができます。これらの初期プロトコルの設計方式は比較的「伝統的」である：毎回リーダーを選出し、彼が提案を開始し、他の検証者がこの提案に対して複数回投票を行い、取引の順序を段階的に確認する。投票プロセスは通常、pre-prepare、prepare、commit、replyなどのいくつかの段階を経る必要があります。各段階で、すべてのバリデーターは互いに通信しなければなりません。言い換えれば、全員が全員に一度は話さなければならず、メッセージの量は「ネットワーク状」に爆発的に増加します。この通信構造の複雑さは n² です。つまり、ネットワークに 100 のバリデーターがいる場合、各ラウンドのコンセンサスでは約 1 万件のメッセージを送信する必要があるかもしれません。これが小規模なネットワークでは問題ありませんが、バリデーターの数が増えると、システムの通信負担は急速に耐え難くなり、効率が直接的に著しく低下します。ソース：このような「みんながみんなをフォローしてコミュニケーションをとる」という二次的なコミュニケーション構造は、実はとても非効率的です。 例えば、100人のバリデーターのネットワークでは、コンセンサスのラウンドごとに数万のメッセージが処理されることがあります。これは小さなサークル内では何とか対応できますが、もしグローバル規模のオープンなブロックチェーンネットワークに置かれると、通信負荷はすぐに受け入れられなくなります。そのため、PBFTやTendermintのような初期のBFTプロトコルは、通常、許可制のシナリオ（permissioned network）や検証者の数が非常に少ないシステムでのみ使用され、何とか動作します。BFTプロトコルをパーミッションレスのパブリックチェーン環境に適応させるために、一部の次世代設計では、各バリデーターがチームのすべてのメンバーではなく、リーダーとのみ通信する、より軽いコミュニケーション方法に移行し始めています。これにより、メッセージの複雑度が元の n² から n に最適化され、システムの負担が大幅に軽減されました。HotStuffプロトコルは2018年に提案され、まさにこのスケーラビリティの問題を解決するために作られました。その設計理念は非常に明確で、よりシンプルでリーダー主導の通信構造でPBFTの複雑な投票プロセスを置き換えることです。HotStuffの重要な特性は、いわゆる線形通信（linear communication）です。そのメカニズムでは、各検証者は自分の投票を現在のリーダーに送信するだけで、リーダーはこれらの投票をパッケージ化してQuorum Certificate（QC、法定多数証明）を生成します。このQCは本質的に集合署名であり、ネットワーク全体に「大多数のノードがこの提案に同意した」と証明するものです。対照的に、PBFTの通信モードは「全員ブロードキャスト」で、皆がグループ内で話しているため、場面は非常に混乱しています。HotStuffのモードは「一人が収集し、一度にパッケージ化する」ようなもので、ネットワークに何人いても、高効率で運営を維持できます。上の図は、HotStuffのファンアウト型通信構造とPBFTの全ネットワーク相互接続モデルを比較しています。ソース：線形通信に加えて、HotStuffは効率を向上させるためにパイプライン版（パイプラインHotStuff）にさらにアップグレードできます。オリジナルのHotStuffでは、同じ検証者が複数回連続してリーダーを務め、ブロックが完全に確認されるまで続きます。このプロセスは「1ラウンドで1ブロックを処理する」であり、すべてのエネルギーが現在の1つのブロックの推進に集中しています。そして、HotStuffのパイプラインでは、メカニズムがさらに柔軟になります：各ラウンドごとに新しいリーダーが選出され、各リーダーのタスクは2つあります：一方では、前回の投票は定足数証明書(QC)にパッケージ化され、ネットワーク全体にブロードキャストされます。新しいブロックを提案し、次のラウンドを開始する準備をします。つまり、「一つを確認してから次を処理する」というわけではなく、生産ラインのように異なるリーダーが各段階を順番に担当します。前の人がブロックを提案し、次の人がそれを確認して新しいブロックを提案し、チェーン上のコンセンサスがリレーのように引き継がれていきます。これが「ライン」という比喩の由来です：現在のブロックは確認プロセスを進行中で、次のブロックはすでに準備されています。複数のステップを並行して行うことで、スループット効率が向上します。要約すると、HotStuffのようなプロトコルは、2つの次元で従来のBFTよりも大幅に改善されています。一つは通信がより軽量であり、各バリデーターはリーダーとだけ通信する必要があります。二つ目は、処理効率がさらに高く、複数のブロック確認プロセスを並行して行えることです。これにより、HotStuffは多くの現代のPoSブロックチェーンコンセンサスメカニズムの設計テンプレートとなりました。しかし、良いことには悪いこともある——パイプライン構造は性能が強力ですが、見つけにくい構造的リスクを静かに引き入れています。次に、私たちはこの核心的な問題について深く話し合う必要があります：テールフォーク（Tail Forking）。テールコールHotStuffは、特にそのパイプライン版がコンセンサスプロトコルのスケーラビリティの問題を解決しましたが、新たな課題もいくつか引き起こしました。その中で最も重要で、見落とされがちなものは「テールフォーク」（Tail Forking）問題です。テール分岐とは何ですか？簡単に言えば、ブロックチェーンの「チェーンの尾」で予期しないブロック再編成が発生したことを意味します(reorg)。具体的には、有効なブロックがあり、それがほとんどの検証者の手に成功裏に広まっており、十分な投票支持を得ています。理論的には、それはすぐに確認され、メインチェーンに書き込まれるべきです。しかし最終的には、それは「スキップされ」、破棄（オーファン）され、同じ高さの別の新しいブロックに置き換えられました。これはバグでも攻撃でもなく、プロトコル自体の設計構造にこの「チェーン切れ」の可能性が存在するためです。これは少し不公平に聞こえますか？では、これは一体どのように発生するのでしょうか？私たちが前に言ったように、HotStuff の各リーダーには二つの任務があります：A. 新しいブロックを提案する（例えば Bₙ₊₁）B. 前のリーダーのブロックに投票を集めて、QCを生成します（例えば、Bₙの最終確認を完了するため）。この2つのタスクは並行して行われ、交代で実行されます。しかし、問題はここにあります。例えば：アリスがリーダーであると仮定します。彼女は高さ n でブロック Bₙ を提案し、このブロックはスーパー過半数の票を得て、「ほぼ確認されました」。次に、ボブがリーダーとして、チェーンの次のブロック Bₙ₊₁ を推進し続けるべきであり、同時に Bₙ の QC（法定多数証明）を彼の提案に組み込んで、Bₙ の最終確認を完了させる必要があります。しかし、もしボブがこの時オフラインであったり、故意にBₙのQCを提出しなかった場合、問題が発生します。アリスのブロックのQCパッキングを代わりに行う人がいなかったため、Bₙの投票記録は広がらず、本来確認されるべきブロックはこうして「冷却処理」され、最終的にはネットワーク全体に無視されてしまった。これが尾部分岐の本質です：前のリーダーのブロックが次のリーダーの不作為や悪意によってスキップされることです。なぜテールが深刻に分岐しているのですか？尾部分岐の問題は主に二つの側面に集中しています：1）インセンティブメカニズムが破壊されること、2）システムの活性が脅かされること。第一、報酬が飲み込まれた：ブロックが破棄された場合、それを提案したリーダーは報酬を受け取りません。 ブロック報酬であろうと取引手数料であろうと。 たとえば、アリスが正当なブロックを提案し、圧倒的多数の票を獲得したが、ボブのミスや悪意のある行動により、ブロックは確認されず、アリスは最終的にペニーをもらえませんでした。 これは間違ったインセンティブ構造につながり、ボブのような悪意のあるノードは、対戦相手のブロックをスキップすることで報酬源を「雑用」することができます。 この種の行動は技術的な攻撃を必要とせず、競合他社の収益を弱めるための意図的な「非協力」のみを必要とします。 このようなことが繰り返されると、時間の経過とともに、システム全体の参加と公平性が低下し、ノード間の共謀を誘発することさえあります。第二、MEV攻撃のスペースが拡大する：また、テールフォークは、MEV(Maximum Extractable Value)が悪意を持って操作される余地があるという、より狡猾ではあるが深刻な問題を引き起こします。 例えば、アリスが自分のブロックで貴重なアービトラージ取引をしているとします。 ボブがトラブルを起こしたい場合は、次のリーダーであるキャロルと共謀し、アリスのブロックを意図的に広めないようにすることができます。 その後、キャロルは同じ高さに新しいブロックを再構築し、アリスの元の裁定取引を「盗み」、MEVを自分のものにします。 この「チェーンヘッドの再配置+共謀と横領」の慣行は、表面上のルールに従ったブロックですが、実際には巧妙に設計された略奪です。 さらに悪いことに、それはリーダー間の「共謀」を誘発し、ブロック確認を公共サービスではなく利益分配ゲームに変えてしまいます。第三に、最終的な保証を破壊し、ユーザー体験に影響を与える：Nakamoto 型プロトコルと比較して、BFT の大きな利点は決定的な最終性です：一度ブロックがコミットされると、ロールバックできません。しかし、末尾のフォークはこの保証を破壊します。特に「投票は得られたが正式には確認されていない」ブロックについてです。特定の高スループット DApp は、ブロック投票が通過した後にすぐにデータを読み取ることを望むことが多く、遅延を低減しますが、そのブロックが突然破棄されると、ユーザーの状態がロールバックする可能性があります。たとえば、アカウントの残高の異常、最近完了した高レバレッジ取引の無断消失、ゲームの状態が突然リセットされるなどです。第四、連鎖的な障害を引き起こす可能性がある：一般的に、尾部の分岐は特定のブロックの確認を1ラウンド遅らせるだけで、大きな影響はありません。しかし、一部の限界なシナリオでは、連続して何人かのリーダーが前のブロックをスキップすることを選ぶと、システムは停滞状態に陥る可能性があります。誰も前のブロックを「受け取る」ことを望まないのです。全体のチェーンの進行はそこで停止し、最終的に「責任を引き受ける」リーダーが現れるまで、ネットワークは進み続けることができません。以前にも BeeGees プロトコルが提案した尾部分岐回避メカニズムのような解決策がいくつかありましたが、しばしばパフォーマンスを犠牲にする必要があり、例えば二次通信の複雑さを再導入することが必要であり、割に合わないことが多いです。MonadBFTとは何ですか？MonadBFT は、テールフォークの問題を解決するために特別に設計された次世代のコンセンサスプロトコルです。 これが素晴らしい点です:組立ラインHotStuffのパフォーマンス上の利点を犠牲にすることなく、構造上の問題を解決します。 言い換えれば、MonadBFT は車輪の再発明ではなく、HotStuff のコア フレームワークに基づいており、最適化を続けています。 次の 3 つの主要な機能を保持しています。1）リーダーのローテーション（rotating leader）：各ラウンドで新しいリーダーを選出してチェーンを推進します；2）パイプラインコミット：複数のブロック確認プロセスが重複して行うことができます；3）線形通信（linear messaging）：各バリデーターはリーダーとだけ通信すればよく、大量のネットワークオーバーヘッドを節約できます。しかし、これらの3点だけでは十分な安全性とは言えません。尾部分岐という構造的な脆弱性を塞ぐために、MonadBFTは2つの重要なメカニズムを追加しました：1)再提案2)ノーエンドースメント証明書(NEC)再提案BFTプロトコルでは、時間が1つずつのラウンド（ビューと呼ばれる）に分けられ、各ラウンドには新しいブロックを提案するリーダーがいます。リーダーが失敗した場合（例えば、時間通りにブロックを提案しない、または提案が無効である場合）、システムは次のラウンドに切り替わり、新しいリーダーが選出されます。MonadBFTは、view切り替えの過程で、誠実に提案されたブロックがリーダーのローテーションによって「落ちる」ことがないことを保証するメカニズムを追加しました。現在のラウンドのリーダーが失敗した場合、バリデーターは現在のラウンドがタイムアウトしたことを示す署名付きのラウンド変更メッセージ（view change）を発行します。特に、このメッセージは「タイムアウトした」というだけでなく、そのバリデーターが最近投票したブロックの情報も含む必要があり、「私は有効な提案を受け取っていません。これが私が現在見ている最新のブロックです。」と言っているようなものです。新しいリーダーは、スーパー多数（2f+1）のバリデーターからこれらのタイムアウトメッセージを収集し、タイムアウト証明書（Timeout Certificate, TC）として統合します。この TC は、前のラウンドが失敗した際に、ネットワーク全体が「チェインのヘッドブロック」に対する統一された認識のスナップショットを表しています。新しいリーダーは、その中から最高の高さ（または最新のビュー番号）のブロック、いわゆる high\_tip を選びます。MonadBFT の要件：新しいリーダーの提案は、合法的な TC を含む必要があり、TC 内の最も高い保留ブロックを再提案し、そのブロックが再度確認される機会を得る必要があります。なぜですか？前述のように、確認される直前のブロックが消えてしまうことを望んでいません。例えば、Aliceがview 5のリーダーで、有効なブロックを提案し、大多数の投票を得たとしましょう。次に、view 6のリーダーBobがオフラインになり、チェーンの進行を進められませんでした。Carolがview 7のリーダーを務めるとき、MonadBFTのルールに従い、彼女はTCを含め、Aliceのブロックを再提案しなければなりません。こうすることで、Aliceの誠実な労働は無駄になりません。もしキャロルがアリスのブロックを持っていない場合、他のノードからリクエストできます。ノードは:そのブロックを提供するか、または署名された「無背書メッセージ」（No-Endorsement, NE）を返し、自分がこのブロックを持っていないことを示します（そのメカニズムは後で説明します）。（最大 f 個のビザンチンノードがリクエストを無視することを選択し、応答しない可能性があります。）キャロルがアリスのブロックを再提案すると、彼女は追加の提案の機会を得ます。前回のリーダーの失敗のために「連座」されないことが保証されます。この再提案メカニズムの役割は明確です：チェーンの進行が公平であることを保証し、どんな有効な作業も運が悪かったり、誰かの妨害によって静かに捨てられることがないようにします。ノーエンベロープ証明書（NEC）前の例を続けます：Bob のラウンドがタイムアウトした後、Carol は他のバリデーターに high\_tip ブロック（すなわち Alice のブロック）を要求します。この時、少なくとも 2f+1 のバリデーターが応答します：アリスのブロックを提供するかAliceのブロックを受け取っていないことを示す署名付きNEメッセージを送信するか、キャロルがアリスのブロックを受け取ったら、彼女はルールに従ってそれを再提案しなければなりません。少なくともf+1人の検証者がNEメッセージに署名している場合にのみ、キャロルはそのブロックをスキップして新しいものを提案することができます。なぜ f+1 なのか？3f+1 の検証者で構成される BFT システムでは、最大で f つの悪事を働く可能性があります。もしアリスのブロックが実際にスーパー過半数の投票を得た場合、少なくとも 2f+1 の誠実なノードがそれを受け取ったことになります。したがって、Carol が「私は Alice のブロックを受け取れない」と主張する場合、彼女は f+1 個の検証者の署名を提示しなければならず、これらの人々が受け取っていないことを証明する必要があります。これは無背書証明書（No-Endorsement Certificate, NEC）を構成します。NECはリーダーの「免責」の証明書です：それは、前のブロックが確認される準備ができていないことを示す検証可能な証拠であり、悪意を持ってスキップしたのではなく、正当な理由で「放棄」したことを示しています。再提案 + エンドースメント証明書なし = テールフォークの解決MonadBFT は、再提案メカニズムと No-Endorsement Certificate (NEC) を導入することにより、ヘッダーを処理するための厳格で明確なルールセットを確立しました。「確認される近く」のブロックを最終的に提出するか、十分な証拠を提供して、そのブロックが確認される条件を満たしていないことを証明する必要があります。そうでなければ、前のブロックをスキップしたり置き換えたりすることは許可されません。このメカニズムは、法定多数の投票を得たブロックは、リーダーの失敗や故意の回避によって放棄されないことを保証します。尾部分岐の構造的リスクは体系的に解消され、プロトコルは不当なスキップ行為に対して明確な制約を形成することができる。もしあるリーダーが理由もなく前のブロックをスキップしようとし、NECの証拠を提供できなかった場合、プロトコルは直ちにその行為を認識し拒否します。暗号証拠のないスキップ行為は違法と見なされ、ネットワークの合意の支持を得ることはありません。経済的インセンティブの観点から見ると、この設計はバリデーターに明確な保護を提供します。誠実に提案され、投票の支持を得たブロックの報酬は、その後のプロセスの障害によって奪われることはありません；極端な状況下でも、例えばあるノードが自分の提案ラウンドを故意にスキップして他の人が前のブロックのMEVを奪うのを助けようとする場合、プロトコルは後続のリーダーに元のブロックを再提案することを優先させるため、攻撃者はプロセスをスキップして経済的利益を得ることができません。さらに重要なのは、MonadBFTはプロトコルの性能を犠牲にして安全性を向上させていないということです。これまでのいくつかの末尾分岐に対処するための設計（例えばBeeGeesプロトコル）は、一定の防護能力を持っているものの、しばしば高い通信の複雑性（n²）に依存していたり、各ラウンドで再通信プロセスを有効にする必要があり、実際にはシステムの負担を著しく増加させる。MonadBFT の設計戦略はもっと微妙だ。ビューが失敗したり異常が発生した場合にのみ、追加の通信（タイムアウトメッセージ、ブロックの再提案など）を開始します。ほとんどの誠実なリーダーが連続してブロックを生成する通常のパスでは、プロトコルは依然として軽量で効率的な運用状態を維持します。この性能と安全性の間の動的なバランスこそが、MonadBFTが前世代のプロトコルに対して持つ核心的な利点の一つです。まとめこの記事では、従来のPBFTコンセンサスの基本メカニズムを振り返り、HotStuffプロトコルの発展経路を整理し、MonadBFTがプロトコル層の構造から、パイプラインHotStuffに内在する末尾分岐問題をどのように解決するかに重点を置いて説明します。末尾の分岐はブロック提案者の経済的インセンティブを歪め、ネットワークの活性に潜在的な脅威をもたらす。MonadBFTは再提案メカニズムと非裏付け証明書（NEC）を導入することによって、誠実なリーダーによって提案され、法定多数の投票を得たブロックが放棄されたりスキップされたりしないことを保証する。次の記事では、MonadBFTのもう2つのコア機能について引き続き探討します：1)投機的ファイナリティ2)楽観的な応答性これらのメカニズムがバリデーターと開発者にとって実際に意味することをさらに分析します。未完の続き。
MonadBFT：ブロックチェーンコンセンサスの安全性を再定義し、尾部フォークリスクに別れを告げる
著者: michaellwy
ブロックチェーンの核心は、厳密なグローバルコンセンサス（strict global consensus）を実現することにあります。つまり、ネットワークノードがどの国やタイムゾーンに分布していても、すべての参加者が最終的に一連の客観的結果に合意しなければならないということです。
しかし、現実の分散ネットワークは理想的ではありません：ノードがダウンしたり、ノードが嘘をついたり、さらには故意に破壊する人もいます。このような状況では、システムはどのように「一致」を保つのでしょうか？
これがコンセンサスプロトコルが解決しようとしている問題です。本質的には、互いに独立し、完全に信頼できないノードのグループが、各取引の順序と内容についてどのように合意に達するかを導くための一連のルールです。
そしてこの「厳密なコンセンサス」が確立されると、ブロックチェーンはデジタル所有権の保障、インフレに強い通貨モデル、そしてスケーラブルな社会協力構造など、多くの重要な特性を解放できる。しかし条件として、コンセンサスプロトコル自体が同時に二つの基本的な面を保証しなければならない。
相互に矛盾する2つのブロックが確認されることはできません；
ネットワークは継続的に推進されなければならず、停止したり止まったりしてはいけません。
MonadBFTは、この方向における最新の技術的突破口です。
コンセンサスプロトコルの簡単な進化の振り返り
コンセンサスメカニズムのこの分野は、実際には数十年にわたって研究されてきました。最初の一群のプロトコル、例えばPBFT（実用的バイザンチンフォールトトレランス）は、非常に現実的な状況に対処できるようになっています。つまり、ネットワーク内の一部のノードが故障したり、悪意を持ったり、無意味なことを言ったりしても、それらが総数の1/3を超えなければ、システムは合意に達することができます。
これらの初期プロトコルの設計方式は比較的「伝統的」である：毎回リーダーを選出し、彼が提案を開始し、他の検証者がこの提案に対して複数回投票を行い、取引の順序を段階的に確認する。
投票プロセスは通常、pre-prepare、prepare、commit、replyなどのいくつかの段階を経る必要があります。各段階で、すべてのバリデーターは互いに通信しなければなりません。言い換えれば、全員が全員に一度は話さなければならず、メッセージの量は「ネットワーク状」に爆発的に増加します。
この通信構造の複雑さは n² です。つまり、ネットワークに 100 のバリデーターがいる場合、各ラウンドのコンセンサスでは約 1 万件のメッセージを送信する必要があるかもしれません。
これが小規模なネットワークでは問題ありませんが、バリデーターの数が増えると、システムの通信負担は急速に耐え難くなり、効率が直接的に著しく低下します。
ソース：
このような「みんながみんなをフォローしてコミュニケーションをとる」という二次的なコミュニケーション構造は、実はとても非効率的です。 例えば、100人のバリデーターのネットワークでは、コンセンサスのラウンドごとに数万のメッセージが処理されることがあります。
これは小さなサークル内では何とか対応できますが、もしグローバル規模のオープンなブロックチェーンネットワークに置かれると、通信負荷はすぐに受け入れられなくなります。そのため、PBFTやTendermintのような初期のBFTプロトコルは、通常、許可制のシナリオ（permissioned network）や検証者の数が非常に少ないシステムでのみ使用され、何とか動作します。
BFTプロトコルをパーミッションレスのパブリックチェーン環境に適応させるために、一部の次世代設計では、各バリデーターがチームのすべてのメンバーではなく、リーダーとのみ通信する、より軽いコミュニケーション方法に移行し始めています。
これにより、メッセージの複雑度が元の n² から n に最適化され、システムの負担が大幅に軽減されました。
HotStuffプロトコルは2018年に提案され、まさにこのスケーラビリティの問題を解決するために作られました。その設計理念は非常に明確で、よりシンプルでリーダー主導の通信構造でPBFTの複雑な投票プロセスを置き換えることです。
HotStuffの重要な特性は、いわゆる線形通信（linear communication）です。そのメカニズムでは、各検証者は自分の投票を現在のリーダーに送信するだけで、リーダーはこれらの投票をパッケージ化してQuorum Certificate（QC、法定多数証明）を生成します。
このQCは本質的に集合署名であり、ネットワーク全体に「大多数のノードがこの提案に同意した」と証明するものです。
対照的に、PBFTの通信モードは「全員ブロードキャスト」で、皆がグループ内で話しているため、場面は非常に混乱しています。HotStuffのモードは「一人が収集し、一度にパッケージ化する」ようなもので、ネットワークに何人いても、高効率で運営を維持できます。
上の図は、HotStuffのファンアウト型通信構造とPBFTの全ネットワーク相互接続モデルを比較しています。
ソース：
線形通信に加えて、HotStuffは効率を向上させるためにパイプライン版（パイプラインHotStuff）にさらにアップグレードできます。
オリジナルのHotStuffでは、同じ検証者が複数回連続してリーダーを務め、ブロックが完全に確認されるまで続きます。このプロセスは「1ラウンドで1ブロックを処理する」であり、すべてのエネルギーが現在の1つのブロックの推進に集中しています。
そして、HotStuffのパイプラインでは、メカニズムがさらに柔軟になります：各ラウンドごとに新しいリーダーが選出され、各リーダーのタスクは2つあります：
一方では、前回の投票は定足数証明書(QC)にパッケージ化され、ネットワーク全体にブロードキャストされます。
新しいブロックを提案し、次のラウンドを開始する準備をします。
つまり、「一つを確認してから次を処理する」というわけではなく、生産ラインのように異なるリーダーが各段階を順番に担当します。前の人がブロックを提案し、次の人がそれを確認して新しいブロックを提案し、チェーン上のコンセンサスがリレーのように引き継がれていきます。
これが「ライン」という比喩の由来です：現在のブロックは確認プロセスを進行中で、次のブロックはすでに準備されています。複数のステップを並行して行うことで、スループット効率が向上します。
要約すると、HotStuffのようなプロトコルは、2つの次元で従来のBFTよりも大幅に改善されています。
一つは通信がより軽量であり、各バリデーターはリーダーとだけ通信する必要があります。
二つ目は、処理効率がさらに高く、複数のブロック確認プロセスを並行して行えることです。
これにより、HotStuffは多くの現代のPoSブロックチェーンコンセンサスメカニズムの設計テンプレートとなりました。しかし、良いことには悪いこともある——パイプライン構造は性能が強力ですが、見つけにくい構造的リスクを静かに引き入れています。
次に、私たちはこの核心的な問題について深く話し合う必要があります：テールフォーク（Tail Forking）。
テールコール
HotStuffは、特にそのパイプライン版がコンセンサスプロトコルのスケーラビリティの問題を解決しましたが、新たな課題もいくつか引き起こしました。その中で最も重要で、見落とされがちなものは「テールフォーク」（Tail Forking）問題です。
テール分岐とは何ですか？簡単に言えば、ブロックチェーンの「チェーンの尾」で予期しないブロック再編成が発生したことを意味します(reorg)。
具体的には、有効なブロックがあり、それがほとんどの検証者の手に成功裏に広まっており、十分な投票支持を得ています。理論的には、それはすぐに確認され、メインチェーンに書き込まれるべきです。しかし最終的には、それは「スキップされ」、破棄（オーファン）され、同じ高さの別の新しいブロックに置き換えられました。
これはバグでも攻撃でもなく、プロトコル自体の設計構造にこの「チェーン切れ」の可能性が存在するためです。これは少し不公平に聞こえますか？では、これは一体どのように発生するのでしょうか？
私たちが前に言ったように、HotStuff の各リーダーには二つの任務があります：
A. 新しいブロックを提案する（例えば Bₙ₊₁）
B. 前のリーダーのブロックに投票を集めて、QCを生成します（例えば、Bₙの最終確認を完了するため）。
この2つのタスクは並行して行われ、交代で実行されます。しかし、問題はここにあります。
例えば：アリスがリーダーであると仮定します。彼女は高さ n でブロック Bₙ を提案し、このブロックはスーパー過半数の票を得て、「ほぼ確認されました」。
次に、ボブがリーダーとして、チェーンの次のブロック Bₙ₊₁ を推進し続けるべきであり、同時に Bₙ の QC（法定多数証明）を彼の提案に組み込んで、Bₙ の最終確認を完了させる必要があります。
しかし、もしボブがこの時オフラインであったり、故意にBₙのQCを提出しなかった場合、問題が発生します。
アリスのブロックのQCパッキングを代わりに行う人がいなかったため、Bₙの投票記録は広がらず、本来確認されるべきブロックはこうして「冷却処理」され、最終的にはネットワーク全体に無視されてしまった。
これが尾部分岐の本質です：前のリーダーのブロックが次のリーダーの不作為や悪意によってスキップされることです。
なぜテールが深刻に分岐しているのですか？
尾部分岐の問題は主に二つの側面に集中しています：1）インセンティブメカニズムが破壊されること、2）システムの活性が脅かされること。
第一、報酬が飲み込まれた：
ブロックが破棄された場合、それを提案したリーダーは報酬を受け取りません。 ブロック報酬であろうと取引手数料であろうと。 たとえば、アリスが正当なブロックを提案し、圧倒的多数の票を獲得したが、ボブのミスや悪意のある行動により、ブロックは確認されず、アリスは最終的にペニーをもらえませんでした。 これは間違ったインセンティブ構造につながり、ボブのような悪意のあるノードは、対戦相手のブロックをスキップすることで報酬源を「雑用」することができます。 この種の行動は技術的な攻撃を必要とせず、競合他社の収益を弱めるための意図的な「非協力」のみを必要とします。 このようなことが繰り返されると、時間の経過とともに、システム全体の参加と公平性が低下し、ノード間の共謀を誘発することさえあります。
第二、MEV攻撃のスペースが拡大する：
また、テールフォークは、MEV(Maximum Extractable Value)が悪意を持って操作される余地があるという、より狡猾ではあるが深刻な問題を引き起こします。 例えば、アリスが自分のブロックで貴重なアービトラージ取引をしているとします。 ボブがトラブルを起こしたい場合は、次のリーダーであるキャロルと共謀し、アリスのブロックを意図的に広めないようにすることができます。 その後、キャロルは同じ高さに新しいブロックを再構築し、アリスの元の裁定取引を「盗み」、MEVを自分のものにします。 この「チェーンヘッドの再配置+共謀と横領」の慣行は、表面上のルールに従ったブロックですが、実際には巧妙に設計された略奪です。 さらに悪いことに、それはリーダー間の「共謀」を誘発し、ブロック確認を公共サービスではなく利益分配ゲームに変えてしまいます。
第三に、最終的な保証を破壊し、ユーザー体験に影響を与える：
Nakamoto 型プロトコルと比較して、BFT の大きな利点は決定的な最終性です：一度ブロックがコミットされると、ロールバックできません。しかし、末尾のフォークはこの保証を破壊します。特に「投票は得られたが正式には確認されていない」ブロックについてです。特定の高スループット DApp は、ブロック投票が通過した後にすぐにデータを読み取ることを望むことが多く、遅延を低減しますが、そのブロックが突然破棄されると、ユーザーの状態がロールバックする可能性があります。たとえば、アカウントの残高の異常、最近完了した高レバレッジ取引の無断消失、ゲームの状態が突然リセットされるなどです。
第四、連鎖的な障害を引き起こす可能性がある：
一般的に、尾部の分岐は特定のブロックの確認を1ラウンド遅らせるだけで、大きな影響はありません。しかし、一部の限界なシナリオでは、連続して何人かのリーダーが前のブロックをスキップすることを選ぶと、システムは停滞状態に陥る可能性があります。誰も前のブロックを「受け取る」ことを望まないのです。全体のチェーンの進行はそこで停止し、最終的に「責任を引き受ける」リーダーが現れるまで、ネットワークは進み続けることができません。
以前にも BeeGees プロトコルが提案した尾部分岐回避メカニズムのような解決策がいくつかありましたが、しばしばパフォーマンスを犠牲にする必要があり、例えば二次通信の複雑さを再導入することが必要であり、割に合わないことが多いです。
MonadBFTとは何ですか？
MonadBFT は、テールフォークの問題を解決するために特別に設計された次世代のコンセンサスプロトコルです。 これが素晴らしい点です:組立ラインHotStuffのパフォーマンス上の利点を犠牲にすることなく、構造上の問題を解決します。 言い換えれば、MonadBFT は車輪の再発明ではなく、HotStuff のコア フレームワークに基づいており、最適化を続けています。 次の 3 つの主要な機能を保持しています。
1）リーダーのローテーション（rotating leader）：各ラウンドで新しいリーダーを選出してチェーンを推進します；
2）パイプラインコミット：複数のブロック確認プロセスが重複して行うことができます；
3）線形通信（linear messaging）：各バリデーターはリーダーとだけ通信すればよく、大量のネットワークオーバーヘッドを節約できます。
しかし、これらの3点だけでは十分な安全性とは言えません。尾部分岐という構造的な脆弱性を塞ぐために、MonadBFTは2つの重要なメカニズムを追加しました：
1)再提案
2)ノーエンドースメント証明書(NEC)
再提案
BFTプロトコルでは、時間が1つずつのラウンド（ビューと呼ばれる）に分けられ、各ラウンドには新しいブロックを提案するリーダーがいます。リーダーが失敗した場合（例えば、時間通りにブロックを提案しない、または提案が無効である場合）、システムは次のラウンドに切り替わり、新しいリーダーが選出されます。
MonadBFTは、view切り替えの過程で、誠実に提案されたブロックがリーダーのローテーションによって「落ちる」ことがないことを保証するメカニズムを追加しました。
現在のラウンドのリーダーが失敗した場合、バリデーターは現在のラウンドがタイムアウトしたことを示す署名付きのラウンド変更メッセージ（view change）を発行します。
特に、このメッセージは「タイムアウトした」というだけでなく、そのバリデーターが最近投票したブロックの情報も含む必要があり、「私は有効な提案を受け取っていません。これが私が現在見ている最新のブロックです。」と言っているようなものです。
新しいリーダーは、スーパー多数（2f+1）のバリデーターからこれらのタイムアウトメッセージを収集し、タイムアウト証明書（Timeout Certificate, TC）として統合します。この TC は、前のラウンドが失敗した際に、ネットワーク全体が「チェインのヘッドブロック」に対する統一された認識のスナップショットを表しています。新しいリーダーは、その中から最高の高さ（または最新のビュー番号）のブロック、いわゆる high_tip を選びます。
MonadBFT の要件：新しいリーダーの提案は、合法的な TC を含む必要があり、TC 内の最も高い保留ブロックを再提案し、そのブロックが再度確認される機会を得る必要があります。
なぜですか？前述のように、確認される直前のブロックが消えてしまうことを望んでいません。
例えば、Aliceがview 5のリーダーで、有効なブロックを提案し、大多数の投票を得たとしましょう。次に、view 6のリーダーBobがオフラインになり、チェーンの進行を進められませんでした。Carolがview 7のリーダーを務めるとき、MonadBFTのルールに従い、彼女はTCを含め、Aliceのブロックを再提案しなければなりません。こうすることで、Aliceの誠実な労働は無駄になりません。
もしキャロルがアリスのブロックを持っていない場合、他のノードからリクエストできます。ノードは:
そのブロックを提供するか、または
署名された「無背書メッセージ」（No-Endorsement, NE）を返し、自分がこのブロックを持っていないことを示します（そのメカニズムは後で説明します）。（最大 f 個のビザンチンノードがリクエストを無視することを選択し、応答しない可能性があります。）
キャロルがアリスのブロックを再提案すると、彼女は追加の提案の機会を得ます。前回のリーダーの失敗のために「連座」されないことが保証されます。
この再提案メカニズムの役割は明確です：チェーンの進行が公平であることを保証し、どんな有効な作業も運が悪かったり、誰かの妨害によって静かに捨てられることがないようにします。
ノーエンベロープ証明書（NEC）
前の例を続けます：Bob のラウンドがタイムアウトした後、Carol は他のバリデーターに high_tip ブロック（すなわち Alice のブロック）を要求します。この時、少なくとも 2f+1 のバリデーターが応答します：
アリスのブロックを提供するか
Aliceのブロックを受け取っていないことを示す署名付きNEメッセージを送信するか、
キャロルがアリスのブロックを受け取ったら、彼女はルールに従ってそれを再提案しなければなりません。少なくともf+1人の検証者がNEメッセージに署名している場合にのみ、キャロルはそのブロックをスキップして新しいものを提案することができます。
なぜ f+1 なのか？3f+1 の検証者で構成される BFT システムでは、最大で f つの悪事を働く可能性があります。もしアリスのブロックが実際にスーパー過半数の投票を得た場合、少なくとも 2f+1 の誠実なノードがそれを受け取ったことになります。
したがって、Carol が「私は Alice のブロックを受け取れない」と主張する場合、彼女は f+1 個の検証者の署名を提示しなければならず、これらの人々が受け取っていないことを証明する必要があります。これは無背書証明書（No-Endorsement Certificate, NEC）を構成します。
NECはリーダーの「免責」の証明書です：それは、前のブロックが確認される準備ができていないことを示す検証可能な証拠であり、悪意を持ってスキップしたのではなく、正当な理由で「放棄」したことを示しています。
再提案 + エンドースメント証明書なし = テールフォークの解決
MonadBFT は、再提案メカニズムと No-Endorsement Certificate (NEC) を導入することにより、ヘッダーを処理するための厳格で明確なルールセットを確立しました。
「確認される近く」のブロックを最終的に提出するか、
十分な証拠を提供して、そのブロックが確認される条件を満たしていないことを証明する必要があります。
そうでなければ、前のブロックをスキップしたり置き換えたりすることは許可されません。
このメカニズムは、法定多数の投票を得たブロックは、リーダーの失敗や故意の回避によって放棄されないことを保証します。
尾部分岐の構造的リスクは体系的に解消され、プロトコルは不当なスキップ行為に対して明確な制約を形成することができる。
もしあるリーダーが理由もなく前のブロックをスキップしようとし、NECの証拠を提供できなかった場合、プロトコルは直ちにその行為を認識し拒否します。暗号証拠のないスキップ行為は違法と見なされ、ネットワークの合意の支持を得ることはありません。
経済的インセンティブの観点から見ると、この設計はバリデーターに明確な保護を提供します。
誠実に提案され、投票の支持を得たブロックの報酬は、その後のプロセスの障害によって奪われることはありません；
極端な状況下でも、例えばあるノードが自分の提案ラウンドを故意にスキップして他の人が前のブロックのMEVを奪うのを助けようとする場合、プロトコルは後続のリーダーに元のブロックを再提案することを優先させるため、攻撃者はプロセスをスキップして経済的利益を得ることができません。
さらに重要なのは、MonadBFTはプロトコルの性能を犠牲にして安全性を向上させていないということです。
これまでのいくつかの末尾分岐に対処するための設計（例えばBeeGeesプロトコル）は、一定の防護能力を持っているものの、しばしば高い通信の複雑性（n²）に依存していたり、各ラウンドで再通信プロセスを有効にする必要があり、実際にはシステムの負担を著しく増加させる。
MonadBFT の設計戦略はもっと微妙だ。
ビューが失敗したり異常が発生した場合にのみ、追加の通信（タイムアウトメッセージ、ブロックの再提案など）を開始します。ほとんどの誠実なリーダーが連続してブロックを生成する通常のパスでは、プロトコルは依然として軽量で効率的な運用状態を維持します。
この性能と安全性の間の動的なバランスこそが、MonadBFTが前世代のプロトコルに対して持つ核心的な利点の一つです。
まとめ
この記事では、従来のPBFTコンセンサスの基本メカニズムを振り返り、HotStuffプロトコルの発展経路を整理し、MonadBFTがプロトコル層の構造から、パイプラインHotStuffに内在する末尾分岐問題をどのように解決するかに重点を置いて説明します。
末尾の分岐はブロック提案者の経済的インセンティブを歪め、ネットワークの活性に潜在的な脅威をもたらす。MonadBFTは再提案メカニズムと非裏付け証明書（NEC）を導入することによって、誠実なリーダーによって提案され、法定多数の投票を得たブロックが放棄されたりスキップされたりしないことを保証する。
次の記事では、MonadBFTのもう2つのコア機能について引き続き探討します：
1)投機的ファイナリティ
2)楽観的な応答性
これらのメカニズムがバリデーターと開発者にとって実際に意味することをさらに分析します。
未完の続き。