ブロックチェーンの核心は、厳密なグローバルコンセンサス（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は効率を向上させるためにパイプラインバージョン（パイプラインHotStuff）にさらにアップグレードすることもできます。オリジナルのHotStuffでは、同じバリデーターが多くのラウンドでリーダーを連続して務め、1つのブロックが完全に確認されるまで続きます。このプロセスは「1ラウンドで1つのブロックを処理する」であり、すべてのエネルギーが現在の1つを進めることに集中しています。そして、パイプラインHotStuffでは、メカニズムがさらに柔軟になりました：毎ラウンドで新しいリーダーが選ばれ、各リーダーのタスクは2つあります：前のラウンドの投票をクォーラム証明書（QC）としてパッケージ化し、全ネットワークにブロードキャストする；新しいブロックを提案し、次のラウンドを開始する準備をします。つまり、「1つを確認してから次を処理する」というのではなく、生産ラインのように、異なるリーダーが各段階を順番に担当するということです。前のリーダーがブロックを提案し、次のリーダーがそれを確認して新しいブロックを提案し、チェーン上のコンセンサスはリレーのように引き継がれていきます。これが「パイプライン」という比喩の由来です：現在のブロックは確認プロセスを進行中で、次のブロックはすでに準備されています。複数のステップが並行して行われ、スループット効率が向上します。まとめると、HotStuff のようなプロトコルは、従来の BFT に比べて二つの次元で大きな改善をもたらしました：一つは通信がより軽量で、各バリデーターはリーダーとだけ通信する必要があります。二つ目は、処理効率がさらに高く、複数のブロック確認プロセスを並行して行うことができるということです。これにより、HotStuffは多くの現代のPoSブロックチェーンコンセンサスメカニズムの設計テンプレートとなりました。しかし、すべてのことには利点と欠点があります——パイプライン構造は性能が優れていますが、静かに発見しにくい構造的リスクを引き込んでしまいます。次に、私たちはこの核心的な問題について深く話し合う必要があります：テールフォーク（Tail Forking）。テールコーリングHotStuff、特にそのパイプライン版は、コンセンサスプロトコルのスケーラビリティの問題を解決しましたが、新たな課題もいくつか引き起こしました。その中で最も重要で、見落とされがちなものがいわゆる「テイルフォーク」（Tail Forking）問題です。尾分岐とは何ですか？簡単に言うと、ブロックチェーンの「チェーンの尾」で予期しないブロック再編成が発生したことを指します(reorg)。具体的には、有るブロックが有効で、すでに大多数のバリデーターに成功裏に伝播され、十分な投票支持を受けているので、理論的にはすぐに確認され、メインチェーンに書き込まれるべきです。しかし最終的には、「スキップ」され、捨てられ（orphaned）、その代わりに同じ高さの新しいブロックが置き換わりました。これはバグでも攻撃でもなく、プロトコル自体の設計構造に、この「チェーンの切断」が発生する可能性が存在するからです。これって少し不公平に聞こえませんか？では、これは一体どうやって起こるのでしょうか？私たちは前に、パイプライン HotStuff の各リーダーには二つの任務があると言いました：A. 新しいブロックを提案する（例えば Bₙ₊₁）B. 前のリーダーのブロックに投票を集め、QCを生成する（例えばBₙの最終確認を完了するため）この二つのタスクは並行して行われ、交代でリレーします。しかし、問題はここにあります。例を挙げると、アリスがリーダーであると仮定します。彼女は第 n 高さでブロック Bₙ を提案し、このブロックはスーパー多数の投票を得て「ほぼ確認済み」です。次にボブがリーダーとなり、チェーンの次のブロック Bₙ₊₁ を進めるべきですが、同時に Bₙ の QC（法定多数証明）を彼の提案にパッケージ化し、Bₙ の最終確認を完了させる必要があります。しかし、もしこの時 Bob がオフラインであるか、意図的に Bₙ の QC を提出しなければ、問題が発生します。アリスのブロックのQCパッケージを完了する人がいなかったため、Bₙの投票記録は広がらず、本来確認されるべきブロックはこのように「冷遇」され、最終的にネットワーク全体に無視されました。これがフォークの本質です：前のリーダーのブロックが次のリーダーの怠慢または悪意によってスキップされる。尾部分岐はなぜ深刻なのですか？尾部分岐の問題は主に2つの側面に集中しています：1）インセンティブメカニズムが破壊されること、2）システムの活性が脅かされること。第一、報酬が飲み込まれる：1つのブロックが廃棄されると、そのブロックを提案したリーダーは、いかなる報酬も得られません。出ブロック報酬や取引手数料を問わずです。例えば、アリスが合法的なブロックを提案し、スーパー多数の投票支持を得た場合でも、ボブのミスや悪意のある操作により、このブロックが確認されなかった場合、アリスは最終的に一銭も得られません。これは誤ったインセンティブ構造をもたらします：ボブのような悪意のあるノードは、対戦相手のブロックをスキップすることで、彼らの報酬源を「遮断」することができます。このような行動は技術的攻撃を必要とせず、故意に「協力をしない」だけで競争相手の利益を削減することができます。このような事が繰り返されると、長い目で見れば、システム全体の参加度と公平性が低下し、さらにはノード間の共謀を引き起こす可能性があります。次に、MEVの攻撃空間が拡大します:テールフォークもまた、より狡猾ですが深刻な問題を引き起こします:MEV(Maximum Extractable Value)は、悪意を持って操作される余地があります。 例を挙げると、アリスが自分のブロックに貴重なアービトラージ取引を持っているとします。 ボブが問題を起こしたいと思ったら、次のリーダーであるキャロルと共謀し、わざとアリスのブロックを広げないようにすることができます。 その後、キャロルは同じ高さで新しいブロックを再構築し、アリスの元のアービトラージ取引を「盗み」、MEVが自分のものを得るようにします。 この「チェーンヘッドの組み換え+共謀と横領」という行為は、表面的にはルールからするとまだブロックですが、実は巧妙に仕組まれた略奪なのです。 さらに悪いことに、それはリーダー間の「共謀」を誘発し、ブロックの確認を公共サービスではなく利益分配ゲームに変えます。第三に、ファイナリティの保証を破り、ユーザーエクスペリエンスに影響を与えます:BFTがNakamotoのようなプロトコルに対する主な利点の1つは、決定論的なファイナリティです:ブロックがコミットされると、ロールバックすることはできません。 しかし、テールフォークは、特に「投票されたが公式に確認されていない」ブロックでは、この保証を損ないます。 高スループットのDAppsの中には、通常、レイテンシを短縮するためにブロックが投票された直後にデータを読み取れるようにしたいと考えており、ブロックが突然破棄されると、異常なアカウント残高、完了したばかりの高レバレッジ取引が理由もなく消える、ゲーム状態が突然リセットされるなど、ユーザーの状態がロールバックする可能性があります。第四、連鎖的故障を引き起こす可能性：一般的に、末尾の分岐はあるブロックの確認を一巡遅らせるだけで、影響は大きくない。しかし、いくつかの限界状況では、連続して数人のリーダーが前のブロックをスキップすることを選択すると、システムは停滞状態に陥り、誰も前のブロックを「受け取ろう」としなくなる。全体のチェーンの進行はそこで止まり、「責任を引き受ける」リーダーが現れるまで、ネットワークは進み続けることができない。以前にも BeeGees プロトコルが提案した末尾分岐回避メカニズムなどのいくつかの解決策がありましたが、しばしばパフォーマンスを犠牲にする必要がありました。たとえば、二次通信の複雑さを再導入することは、得られるものに対して代償が大きすぎます。MonadBFTとは何ですか？MonadBFTは、尾部分岐問題を解決するために設計された新しい世代のコンセンサスプロトコルです。その優れた点は、構造的なリスクを解決しながら、パイプラインHotStuffによる性能の利点を犠牲にしていないことです。言い換えれば、MonadBFTはゼロからやり直すのではなく、HotStuffのコアフレームワークに基づいて最適化を続けています。これにより、3つの重要な特性を保持しています：リーダーのローテーション（rotating leader）：各ラウンドで新しいリーダーを選出してチェーンを推進します；パイプラインコミット：複数のブロック確認プロセスを重ねて行うことができます；線形通信（linear messaging）：各検証者はリーダーとだけ通信すればよく、大量のネットワークオーバーヘッドを節約できます。しかし、この3つだけでは十分な安全性はありません。尾部分岐という構造的な脆弱性を塞ぐために、MonadBFTは2つの重要なメカニズムを追加しました：再提案ノーエンドースメント証明書(NEC)再提案BFT プロトコルでは、時間は一つ一つのラウンド（ビューと呼ばれる）に分けられ、各ラウンドには新しいブロックを提案する責任を持つリーダーがいます。もしリーダーが失敗した場合（例えば、時間通りにブロックを提案しなかったり、提案が無効だったりする場合）、システムは次のラウンドに切り替わり、新しいリーダーが選出されます。MonadBFTは、viewの切り替えプロセスにおいて、誠実に提案されたブロックがリーダーの交代によって「落ちる」ことがないようにするメカニズムを追加しました。現在のラウンドのリーダーが失敗した場合、バリデーターは現在のラウンドがタイムアウトしたことを示す署名付きのラウンド切り替えメッセージ（view change）を発信します。特に、このメッセージは「タイムアウトしました」とだけ表示されるのではなく、その検証者の最近の投票のブロック情報も含む必要があります。これは、「私は合法的な提案を受け取っていません。これが私が現在見ている最新のブロックです」と言っているのと同じです。新しいリーダーは、スーパー多数（2f+1）のバリデーターからこれらのタイムアウトメッセージを収集し、それをタイムアウト証明（Timeout Certificate, TC）に統合します。このTCは、前のラウンドが失敗したときに、全ネットワークが「チェーンヘッドブロック」に対する統一認識のスナップショットを表しています。新しいリーダーは、その中から最高の高さ（または最新のビュー番号）のブロック、いわゆるhigh\_tipを選び出します。MonadBFT の要件：新しいリーダーの提案には、合法的な TC が含まれている必要があり、TC の中で最も高い保留ブロックを再提案し、そのブロックが再び確認される機会を得る必要があります。なぜでしょうか？先ほど述べたように、私たちは確認に近いブロックがこのまま消えてしまうことを望んでいません。例を挙げると、アリスがビュー5のリーダーで、有效なブロックを提案し、過半数の票を得たとします。その後、ビュー6のリーダーであるボブがオフラインになり、チェーンの進行を進められませんでした。キャロルがビュー7のリーダーになったとき、MonadBFTのルールに従って、彼女はTCを含め、アリスのブロックを再提案しなければなりません。こうすることで、アリスの誠実な労働が無駄にならないのです。もしキャロルがアリスのブロックを持っていない場合、彼女は他のノードにリクエストできます。ノードは：そのブロックを提供するか、署名された「無背書メッセージ」（No-Endorsement, NE）を返し、自分がこのブロックを持っていないことを示します（後でそのメカニズムについて説明します）。（最大 f 個のビザンチンノードが要求を無視し、応答しないことを選択する可能性があります。）キャロルがアリスのブロックを再提案した場合、彼女は追加の提案の機会を得ることになり、前のラウンドのリーダーの失敗のために「連座」されることがないようにします。この再提案メカニズムの役割は明確です：チェーンの進行が公平であることを保証し、どんな有効な作業も運が悪かったり、誰かが妨害したりして静かに捨てられることがないようにします。ノーエンドースメント証明書(NEC)続けて先ほどの例：Bobのターンがタイムアウトした後、Carolは他のバリデーターにhigh\_tipブロック（つまり、Aliceのブロック）を要求します。この時、少なくとも2f+1のバリデーターが応答します：要するに、Alice のブロックを提供してください。Aliceのブロックを受け取っていないことを示す署名されたNEメッセージを送信するか、Carol が Alice のブロックを受け取ったら、彼女はルールに従ってそれを再提案しなければならない。少なくとも f+1 のバリデーターが NE メッセージに署名している場合にのみ、Carol はそのブロックをスキップして新しいものを提案することができる。なぜ f+1 なのか？3f+1 のバリデーターで構成される BFT システムでは、最大で f 個の作悪者が存在する可能性があります。もしアリスのブロックが本当にスーパー多数の投票を得たのであれば、少なくとも 2f+1 の誠実なノードがそれを受け取ったことになります。したがって、Carol が「私は Alice のブロックを受け取れなかった」と主張する場合、彼女は f+1 の検証者の署名を提出しなければならず、これらの人々が受け取っていないことを証明する必要があります。これは無背書証明書（No-Endorsement Certificate, NEC）を構成します。NECはリーダーの「免責」の証明書です：それは前のブロックが確認される準備ができていないことを示す検証可能な証拠であり、悪意を持ってスキップしたのではなく、合理的に「放棄」したのです。再提案+承認証明書なし=テールフォークの解像度MonadBFTは、Re-ProposalメカニズムとNo-Endorsement Certificate(NEC)を導入することにより、ヘッダーの取り扱いに関する厳格で明確なルールを確立しました。「確認に近い」ブロックを最終的に提交するか、またはそのブロックが確認される条件を満たしていないことを証明する十分な証拠を提供しなければなりません。さもなければ、前のブロックをスキップまたは置き換えることは許可されません。このメカニズムは、法定多数の投票を得たブロックは、リーダーの誤りや故意の回避によって放棄されないことを保証します。尾の部分の分岐の構造的リスクは体系的に解消され、プロトコルは不適切なスキップ行為に対して明確な制約を形成することができます。もしあるリーダーが理由もなく前のブロックをスキップしようとし、NECの証拠を提供できなかった場合、プロトコルは直ちにその行為を認識し拒否します。暗号証拠のないスキップ行為は違法と見なされ、ネットワークのコンセンサスの支持を得ることはありません。経済的インセンティブの観点から見ると、この設計はバリデーターに明確な保護を提供します：誠実に提案され、投票の支持を得たブロックは、その後の段階での障害によって報酬が剥奪されることはありません；極端な状況、例えばあるノードが故意に自分の提案のラウンドをスキップし、他者が前のブロックの MEVを奪うのを助けようとした場合でも、プロトコルは後続のリーダーに元のブロックを再提案させることを強制し、攻撃者がプロセスをスキップして経済的利益を得ることを不可能にします。さらに重要なのは、MonadBFTはプロトコルのパフォーマンスを犠牲にして安全性を向上させたわけではないということです。これまでの一部のテール分岐に対処する設計（例えば、BeeGeesプロトコル）は一定の防護能力を備えているものの、しばしば高い通信の複雑さ（n²）に依存していたり、各ラウンドで再通信プロセスを有効にする必要があり、実際にはシステムの負担を大幅に増加させることになります。MonadBFTのデザイン戦略はもっと繊細です。ビューが失敗したり異常が発生した場合にのみ、追加の通信（タイムアウトメッセージやブロックの再提案など）を開始します。ほとんどの誠実なリーダーが連続してブロックを生成する通常のパスでは、プロトコルは依然として軽量かつ効率的な動作状態を維持します。この性能と安全性の間の動的バランスこそが、MonadBFTが前世代のプロトコルに対して持つ核心的な利点の一つです。まとめ本稿では、従来のPBFTコンセンサスの基本メカニズムを振り返り、HotStuffプロトコルの発展経路を整理し、MonadBFTがプロトコル層の構造から、パイプラインHotStuffに内在する尾部分岐問題をどのように解決するかに重点を置いて説明します。尾部分岐はブロック提案者の経済的インセンティブを歪め、ネットワークの活性に潜在的な脅威をもたらします。MonadBFTは再提案メカニズムと無背書証明書（NEC）を導入することで、誠実なリーダーによって提案され、法定多数の投票を得たブロックが放棄されたりスキップされたりしないことを保障します。次の記事では、MonadBFTのもう2つのコア特性について引き続き探討します：投機的な最終性楽観的な応答性これらのメカニズムがバリデーターと開発者にとって実際に意味することをさらに分析します。つづく。
MonadBFT 解析（上）：いかにして尾部フォーク問題を解決するか
ブロックチェーンの核心は、厳密なグローバルコンセンサス（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は効率を向上させるためにパイプラインバージョン（パイプラインHotStuff）にさらにアップグレードすることもできます。
オリジナルのHotStuffでは、同じバリデーターが多くのラウンドでリーダーを連続して務め、1つのブロックが完全に確認されるまで続きます。このプロセスは「1ラウンドで1つのブロックを処理する」であり、すべてのエネルギーが現在の1つを進めることに集中しています。
そして、パイプラインHotStuffでは、メカニズムがさらに柔軟になりました：毎ラウンドで新しいリーダーが選ばれ、各リーダーのタスクは2つあります：
前のラウンドの投票をクォーラム証明書（QC）としてパッケージ化し、全ネットワークにブロードキャストする；
新しいブロックを提案し、次のラウンドを開始する準備をします。
つまり、「1つを確認してから次を処理する」というのではなく、生産ラインのように、異なるリーダーが各段階を順番に担当するということです。前のリーダーがブロックを提案し、次のリーダーがそれを確認して新しいブロックを提案し、チェーン上のコンセンサスはリレーのように引き継がれていきます。
これが「パイプライン」という比喩の由来です：現在のブロックは確認プロセスを進行中で、次のブロックはすでに準備されています。複数のステップが並行して行われ、スループット効率が向上します。
まとめると、HotStuff のようなプロトコルは、従来の BFT に比べて二つの次元で大きな改善をもたらしました：
一つは通信がより軽量で、各バリデーターはリーダーとだけ通信する必要があります。
二つ目は、処理効率がさらに高く、複数のブロック確認プロセスを並行して行うことができるということです。
これにより、HotStuffは多くの現代のPoSブロックチェーンコンセンサスメカニズムの設計テンプレートとなりました。しかし、すべてのことには利点と欠点があります——パイプライン構造は性能が優れていますが、静かに発見しにくい構造的リスクを引き込んでしまいます。
次に、私たちはこの核心的な問題について深く話し合う必要があります：テールフォーク（Tail Forking）。
テールコーリング
HotStuff、特にそのパイプライン版は、コンセンサスプロトコルのスケーラビリティの問題を解決しましたが、新たな課題もいくつか引き起こしました。その中で最も重要で、見落とされがちなものがいわゆる「テイルフォーク」（Tail Forking）問題です。
尾分岐とは何ですか？簡単に言うと、ブロックチェーンの「チェーンの尾」で予期しないブロック再編成が発生したことを指します(reorg)。
具体的には、有るブロックが有効で、すでに大多数のバリデーターに成功裏に伝播され、十分な投票支持を受けているので、理論的にはすぐに確認され、メインチェーンに書き込まれるべきです。しかし最終的には、「スキップ」され、捨てられ（orphaned）、その代わりに同じ高さの新しいブロックが置き換わりました。
これはバグでも攻撃でもなく、プロトコル自体の設計構造に、この「チェーンの切断」が発生する可能性が存在するからです。これって少し不公平に聞こえませんか？では、これは一体どうやって起こるのでしょうか？
私たちは前に、パイプライン HotStuff の各リーダーには二つの任務があると言いました：
A. 新しいブロックを提案する（例えば Bₙ₊₁）
B. 前のリーダーのブロックに投票を集め、QCを生成する（例えばBₙの最終確認を完了するため）
この二つのタスクは並行して行われ、交代でリレーします。しかし、問題はここにあります。
例を挙げると、アリスがリーダーであると仮定します。彼女は第 n 高さでブロック Bₙ を提案し、このブロックはスーパー多数の投票を得て「ほぼ確認済み」です。次にボブがリーダーとなり、チェーンの次のブロック Bₙ₊₁ を進めるべきですが、同時に Bₙ の QC（法定多数証明）を彼の提案にパッケージ化し、Bₙ の最終確認を完了させる必要があります。
しかし、もしこの時 Bob がオフラインであるか、意図的に Bₙ の QC を提出しなければ、問題が発生します。
アリスのブロックのQCパッケージを完了する人がいなかったため、Bₙの投票記録は広がらず、本来確認されるべきブロックはこのように「冷遇」され、最終的にネットワーク全体に無視されました。
これがフォークの本質です：前のリーダーのブロックが次のリーダーの怠慢または悪意によってスキップされる。
尾部分岐はなぜ深刻なのですか？
尾部分岐の問題は主に2つの側面に集中しています：1）インセンティブメカニズムが破壊されること、2）システムの活性が脅かされること。
第一、報酬が飲み込まれる：1つのブロックが廃棄されると、そのブロックを提案したリーダーは、いかなる報酬も得られません。出ブロック報酬や取引手数料を問わずです。例えば、アリスが合法的なブロックを提案し、スーパー多数の投票支持を得た場合でも、ボブのミスや悪意のある操作により、このブロックが確認されなかった場合、アリスは最終的に一銭も得られません。これは誤ったインセンティブ構造をもたらします：ボブのような悪意のあるノードは、対戦相手のブロックをスキップすることで、彼らの報酬源を「遮断」することができます。このような行動は技術的攻撃を必要とせず、故意に「協力をしない」だけで競争相手の利益を削減することができます。このような事が繰り返されると、長い目で見れば、システム全体の参加度と公平性が低下し、さらにはノード間の共謀を引き起こす可能性があります。
次に、MEVの攻撃空間が拡大します:テールフォークもまた、より狡猾ですが深刻な問題を引き起こします:MEV(Maximum Extractable Value)は、悪意を持って操作される余地があります。 例を挙げると、アリスが自分のブロックに貴重なアービトラージ取引を持っているとします。 ボブが問題を起こしたいと思ったら、次のリーダーであるキャロルと共謀し、わざとアリスのブロックを広げないようにすることができます。 その後、キャロルは同じ高さで新しいブロックを再構築し、アリスの元のアービトラージ取引を「盗み」、MEVが自分のものを得るようにします。 この「チェーンヘッドの組み換え+共謀と横領」という行為は、表面的にはルールからするとまだブロックですが、実は巧妙に仕組まれた略奪なのです。 さらに悪いことに、それはリーダー間の「共謀」を誘発し、ブロックの確認を公共サービスではなく利益分配ゲームに変えます。
第三に、ファイナリティの保証を破り、ユーザーエクスペリエンスに影響を与えます:BFTがNakamotoのようなプロトコルに対する主な利点の1つは、決定論的なファイナリティです:ブロックがコミットされると、ロールバックすることはできません。 しかし、テールフォークは、特に「投票されたが公式に確認されていない」ブロックでは、この保証を損ないます。 高スループットのDAppsの中には、通常、レイテンシを短縮するためにブロックが投票された直後にデータを読み取れるようにしたいと考えており、ブロックが突然破棄されると、異常なアカウント残高、完了したばかりの高レバレッジ取引が理由もなく消える、ゲーム状態が突然リセットされるなど、ユーザーの状態がロールバックする可能性があります。
第四、連鎖的故障を引き起こす可能性：一般的に、末尾の分岐はあるブロックの確認を一巡遅らせるだけで、影響は大きくない。しかし、いくつかの限界状況では、連続して数人のリーダーが前のブロックをスキップすることを選択すると、システムは停滞状態に陥り、誰も前のブロックを「受け取ろう」としなくなる。全体のチェーンの進行はそこで止まり、「責任を引き受ける」リーダーが現れるまで、ネットワークは進み続けることができない。
以前にも BeeGees プロトコルが提案した末尾分岐回避メカニズムなどのいくつかの解決策がありましたが、しばしばパフォーマンスを犠牲にする必要がありました。たとえば、二次通信の複雑さを再導入することは、得られるものに対して代償が大きすぎます。
MonadBFTとは何ですか？
MonadBFTは、尾部分岐問題を解決するために設計された新しい世代のコンセンサスプロトコルです。その優れた点は、構造的なリスクを解決しながら、パイプラインHotStuffによる性能の利点を犠牲にしていないことです。言い換えれば、MonadBFTはゼロからやり直すのではなく、HotStuffのコアフレームワークに基づいて最適化を続けています。これにより、3つの重要な特性を保持しています：
リーダーのローテーション（rotating leader）：各ラウンドで新しいリーダーを選出してチェーンを推進します；
パイプラインコミット：複数のブロック確認プロセスを重ねて行うことができます；
線形通信（linear messaging）：各検証者はリーダーとだけ通信すればよく、大量のネットワークオーバーヘッドを節約できます。
しかし、この3つだけでは十分な安全性はありません。尾部分岐という構造的な脆弱性を塞ぐために、MonadBFTは2つの重要なメカニズムを追加しました：
再提案
ノーエンドースメント証明書(NEC)
再提案
BFT プロトコルでは、時間は一つ一つのラウンド（ビューと呼ばれる）に分けられ、各ラウンドには新しいブロックを提案する責任を持つリーダーがいます。もしリーダーが失敗した場合（例えば、時間通りにブロックを提案しなかったり、提案が無効だったりする場合）、システムは次のラウンドに切り替わり、新しいリーダーが選出されます。
MonadBFTは、viewの切り替えプロセスにおいて、誠実に提案されたブロックがリーダーの交代によって「落ちる」ことがないようにするメカニズムを追加しました。
現在のラウンドのリーダーが失敗した場合、バリデーターは現在のラウンドがタイムアウトしたことを示す署名付きのラウンド切り替えメッセージ（view change）を発信します。
特に、このメッセージは「タイムアウトしました」とだけ表示されるのではなく、その検証者の最近の投票のブロック情報も含む必要があります。これは、「私は合法的な提案を受け取っていません。これが私が現在見ている最新のブロックです」と言っているのと同じです。
新しいリーダーは、スーパー多数（2f+1）のバリデーターからこれらのタイムアウトメッセージを収集し、それをタイムアウト証明（Timeout Certificate, TC）に統合します。このTCは、前のラウンドが失敗したときに、全ネットワークが「チェーンヘッドブロック」に対する統一認識のスナップショットを表しています。新しいリーダーは、その中から最高の高さ（または最新のビュー番号）のブロック、いわゆるhigh_tipを選び出します。
MonadBFT の要件：新しいリーダーの提案には、合法的な TC が含まれている必要があり、TC の中で最も高い保留ブロックを再提案し、そのブロックが再び確認される機会を得る必要があります。
なぜでしょうか？先ほど述べたように、私たちは確認に近いブロックがこのまま消えてしまうことを望んでいません。
例を挙げると、アリスがビュー5のリーダーで、有效なブロックを提案し、過半数の票を得たとします。その後、ビュー6のリーダーであるボブがオフラインになり、チェーンの進行を進められませんでした。キャロルがビュー7のリーダーになったとき、MonadBFTのルールに従って、彼女はTCを含め、アリスのブロックを再提案しなければなりません。こうすることで、アリスの誠実な労働が無駄にならないのです。
もしキャロルがアリスのブロックを持っていない場合、彼女は他のノードにリクエストできます。ノードは：
そのブロックを提供するか、
署名された「無背書メッセージ」（No-Endorsement, NE）を返し、自分がこのブロックを持っていないことを示します（後でそのメカニズムについて説明します）。（最大 f 個のビザンチンノードが要求を無視し、応答しないことを選択する可能性があります。）
キャロルがアリスのブロックを再提案した場合、彼女は追加の提案の機会を得ることになり、前のラウンドのリーダーの失敗のために「連座」されることがないようにします。
この再提案メカニズムの役割は明確です：チェーンの進行が公平であることを保証し、どんな有効な作業も運が悪かったり、誰かが妨害したりして静かに捨てられることがないようにします。
ノーエンドースメント証明書(NEC)
続けて先ほどの例：Bobのターンがタイムアウトした後、Carolは他のバリデーターにhigh_tipブロック（つまり、Aliceのブロック）を要求します。この時、少なくとも2f+1のバリデーターが応答します：
要するに、Alice のブロックを提供してください。
Aliceのブロックを受け取っていないことを示す署名されたNEメッセージを送信するか、
Carol が Alice のブロックを受け取ったら、彼女はルールに従ってそれを再提案しなければならない。少なくとも f+1 のバリデーターが NE メッセージに署名している場合にのみ、Carol はそのブロックをスキップして新しいものを提案することができる。
なぜ f+1 なのか？3f+1 のバリデーターで構成される BFT システムでは、最大で f 個の作悪者が存在する可能性があります。もしアリスのブロックが本当にスーパー多数の投票を得たのであれば、少なくとも 2f+1 の誠実なノードがそれを受け取ったことになります。
したがって、Carol が「私は Alice のブロックを受け取れなかった」と主張する場合、彼女は f+1 の検証者の署名を提出しなければならず、これらの人々が受け取っていないことを証明する必要があります。これは無背書証明書（No-Endorsement Certificate, NEC）を構成します。
NECはリーダーの「免責」の証明書です：それは前のブロックが確認される準備ができていないことを示す検証可能な証拠であり、悪意を持ってスキップしたのではなく、合理的に「放棄」したのです。
再提案+承認証明書なし=テールフォークの解像度
MonadBFTは、Re-ProposalメカニズムとNo-Endorsement Certificate(NEC)を導入することにより、ヘッダーの取り扱いに関する厳格で明確なルールを確立しました。
「確認に近い」ブロックを最終的に提交するか、またはそのブロックが確認される条件を満たしていないことを証明する十分な証拠を提供しなければなりません。さもなければ、前のブロックをスキップまたは置き換えることは許可されません。
このメカニズムは、法定多数の投票を得たブロックは、リーダーの誤りや故意の回避によって放棄されないことを保証します。尾の部分の分岐の構造的リスクは体系的に解消され、プロトコルは不適切なスキップ行為に対して明確な制約を形成することができます。
もしあるリーダーが理由もなく前のブロックをスキップしようとし、NECの証拠を提供できなかった場合、プロトコルは直ちにその行為を認識し拒否します。暗号証拠のないスキップ行為は違法と見なされ、ネットワークのコンセンサスの支持を得ることはありません。
経済的インセンティブの観点から見ると、この設計はバリデーターに明確な保護を提供します：
誠実に提案され、投票の支持を得たブロックは、その後の段階での障害によって報酬が剥奪されることはありません；
極端な状況、例えばあるノードが故意に自分の提案のラウンドをスキップし、他者が前のブロックの MEVを奪うのを助けようとした場合でも、プロトコルは後続のリーダーに元のブロックを再提案させることを強制し、攻撃者がプロセスをスキップして経済的利益を得ることを不可能にします。
さらに重要なのは、MonadBFTはプロトコルのパフォーマンスを犠牲にして安全性を向上させたわけではないということです。
これまでの一部のテール分岐に対処する設計（例えば、BeeGeesプロトコル）は一定の防護能力を備えているものの、しばしば高い通信の複雑さ（n²）に依存していたり、各ラウンドで再通信プロセスを有効にする必要があり、実際にはシステムの負担を大幅に増加させることになります。
MonadBFTのデザイン戦略はもっと繊細です。
ビューが失敗したり異常が発生した場合にのみ、追加の通信（タイムアウトメッセージやブロックの再提案など）を開始します。ほとんどの誠実なリーダーが連続してブロックを生成する通常のパスでは、プロトコルは依然として軽量かつ効率的な動作状態を維持します。
この性能と安全性の間の動的バランスこそが、MonadBFTが前世代のプロトコルに対して持つ核心的な利点の一つです。
まとめ
本稿では、従来のPBFTコンセンサスの基本メカニズムを振り返り、HotStuffプロトコルの発展経路を整理し、MonadBFTがプロトコル層の構造から、パイプラインHotStuffに内在する尾部分岐問題をどのように解決するかに重点を置いて説明します。
尾部分岐はブロック提案者の経済的インセンティブを歪め、ネットワークの活性に潜在的な脅威をもたらします。MonadBFTは再提案メカニズムと無背書証明書（NEC）を導入することで、誠実なリーダーによって提案され、法定多数の投票を得たブロックが放棄されたりスキップされたりしないことを保障します。
次の記事では、MonadBFTのもう2つのコア特性について引き続き探討します：
投機的な最終性
楽観的な応答性
これらのメカニズムがバリデーターと開発者にとって実際に意味することをさらに分析します。
つづく。