MonadBFT 解析（下）：開発者とユーザーにとっての意味
TechFlow厳選深潮セレクト
MonadBFT 解析（下）：開発者とユーザーにとっての意味
MonadBFTは、パイプライン化されたHotStuffスタイルのコンセンサスに、フォークの末尾に対する耐性、1ラウンドでの投機的ファイナリティ、楽観的レスポンシブネス、および線形通信という4つの主要な革新を導入しています。
Web3業界の深掘り報道に専念し潮流を洞察第1部では、クラシックPBFT（Practical Byzantine Fault Tolerance）コンセンサスの仕組みと初期のHotStuffの動作について検討しました。また、MonadBFTがどのようにしてHotStuffのテールフォーク問題（パイプラインシステムにおいて有効なブロックが破棄されることがある問題）を解決するかも学びました。
このテールフォーク問題は主に2つの問題を引き起こします：1） 誠実なブロック構築者の報酬が乱れる、2） ネットワークが停止する可能性がある。
MonadBFTは再提案ルールと背書なし投票（NEC）メカニズムを導入することでテールフォーク問題を排除し、誠実なプロポーザからの適切に承認されたブロックがすべてチェーンに取り込まれることを保証します。
第2部では、MonadBFTの他の2つの特徴：1） 投機的ファイナリティ、および 2） 楽観的レスポンシブネスについて探ります。また、MonadBFTが開発者に与える影響についても考察します。
一回のラウンドでの投機的ファイナリティ
テールフォークへの耐性に加えて、MonadBFTのもう一つの主要な特徴は一回のラウンドでの投機的ファイナリティです。
実際には、これはクライアントやユーザーがブロックが大多数の投票を得た直後にトランザクションの確定を受け取ることができ、次のラウンドが完了する前でも可能であることを意味します。
基本的なHotStuffプロトコルでは、ブロックが最終的に確定（不可逆）と見なされるには、通常少なくとも2段階（Fast-HotstuffやDiem-BFTなど）が必要であることを思い出してください。1段階目は法定人数証明（QC）（≥2f+1票でブロックをロック）を得ること、2段階目は次のリーダーがその法定人数証明（QC）に基づいてブロックを構築しコミットすることです。
この二段階コミットは安全性を確保するために必要です。十分な数の正直なノードがブロックをロックすると、それと競合するブロックは法定人数を得られず、次のラウンドでのコミットによりそれが永続化されます。したがって、クライアントは通常、前のトランザクションが確定したかどうかを知るために、次のブロックまたは次のラウンドの生成を待つ必要があります。
MonadBFTは基本的に、一回の投票ラウンド後だけでトランザクションを十分に最終的（安全に操作可能）と見なすことを可能にします。これが投機的ファイナリティと呼ばれるものです。
リーダーがブロックを提案し、バリデータがそのブロックに対するQCを形成して投票すると、そのブロックは投票済み状態（法定人数によりロック済み）になります。MonadBFTでは、バリデータがQCを形成するとすぐに、そのブロックのトランザクションを実行し、クライアントにそのブロックが（投機的に）受け入れられたという初步的な確認を送信します。これは「このブロックに対して大多数が同意しています。非常に予期せぬ事態が起きない限り、このブロックは確定したと考えてよいでしょう。」と言うようなものです。
このような即時確認は楽観的です。ブロックはまだレッジャーにコミットされていません。それは次のプロポーザが現れ、それを最確認（QC-on-QC）することでコミットされますが、正常な状況下ではそれを巻き戻すものは何もありません。投機的に実行されたブロックが取り消される唯一のケースは、リーダーが等価攻撃を行う場合（同一高さで異なる2つのブロックを提案して投票を分散させる）です。
投機的ファイナリティは、テールフォーク耐性の優れた副産物と見なすことができます。 テールフォークへの耐性により、次期リーダーがクラッシュしても現在の提案が破棄されないことが保証されます（これは再提案とNECルールによるものです）。投機的に実行されたブロックが取り消される唯一のケースは、元のプロポーザが等価攻撃を行う（証明可能な悪意のある二重署名違反）場合であり、これは1） 競合するQCによって検出可能、2） 罰則対象、3） 極めて稀です。
以前のプロトコルでは、次期リーダーが前のブロックを再提案することを保証しないため、テールフォークが可能になり、投機的仮定が崩れます。
楽観的レスポンシブネス
ほとんどのコンセンサスプロトコルでは、各ラウンドの後にバッファ期間やタイムアウトといった組み込みの待ち時間があります。これはすべてのメッセージが次に進む前に到着していることを保証するためのもので、リーダーのクラッシュやまったく情報が送信されないなどの最悪のケースに対処する保護機構です。
これらのタイムアウトは通常過剰に保守的です。ネットワークが正常に機能し、すべてのバリデータが正しく動作している場合、固定された待ち時間は不要なオーバーヘッドとなります。ブロックはもっと速く完了できるのに、プロトコルは念のため遅延させます。
MonadBFTは楽観的レスポンシブネスを導入しており、これはネットワークの情報を基に即座に進行でき、常に固定タイマーに依存しないことを意味します。ここでの設計原則は「速くなれるなら速く、忍耐が必要なときだけ待つ」と要約できます。
MonadBFTは、正常時や障害回復時においても、必要なければ予定されたタイムアウトを待って停止しないように設計されています。
- ハッピーパス（つまり、誠実なリーダーがいる場合）： 提案や投票に組み込みの遅延はありません。リーダーのターンになるとすぐにブロックを提案します。バリデータは有効な提案を受信すると直ちに投票します。リーダー（正確には、パイプライン型HotStuffでは次のプロポーザ）が2f+1票を集めるとQCが形成され、伝播できます。楽観的レスポンシブネス設計では、これにより直ちに次の段階がトリガーされます。
実際には、ノード間のネットワーク遅延が100ミリ秒であれば、コンセンサスは計算・集約オーバーヘッドを加えても数百ミリ秒で1ラウンドを完了できる可能性があることを意味します。
必要なければ、例えば1秒という「スロット時間」をまるごと待つことはしません。これは、slot-and-epoch modelを採用しているイーサリアムメインネットとは異なります。イーサリアムでは、ブロック生成の間隔は固定で12秒です。誰もが事前に準備できていたとしても、プロトコルは待機します。
MonadBFTのアプローチは不要な遅延を排除します。パイプライン型HotStuffの構造を維持しつつ、正常時に「Δ秒待たなければならない」という硬直した規定を削除しています。これにより、安全性を犠牲にすることなく、時間制約システムよりもレスポンス面で優越できるのです。
- アンハッピーパス（リーダー失敗時）： 多くのコンセンサスプロトコルでは、リーダーがブロックを提出できなかった場合、他のノードはタイムアウトΔが経過するまでそれに気づきません。例えばΔが1秒であれば、その時間は基本的に無駄になります。MonadBFTはこれとは異なります。バリデータが提案の欠落を検出すると、直ちにタイムアウトメッセージ（TCまたはタイムアウト証明）をブロードキャストします。2f+1回のタイムアウトが発生すると、次のリーダーが引き継ぎます。ビューの移行は時計ではなく、法定人数に基づく証拠によってトリガーされます。
hotstuff-family コンセンサスとの比較
MonadBFTはHotStuffファミリーのコンセンサスプロトコルに基づいていますが、一連の理想的な特性を実現することで他と差別化されています。 早期のプロトコルはパイプラインスループットや線形通信など特定の次元を最適化することが多く、他の側面を犠牲にしていました。一方、MonadBFTは線形メッセージ複雑性、パイプラインコミット、強力なテールフォーク耐性、固定遅延のない即時レスポンス性、効率的な回復メカニズムを同時に備えながら、迅速なファイナリティと高可用性の保証を維持しています。以下の表は、MonadBFTがこれらの主要な次元において、他のリーダー交代型BFTプロトコルとどう比較されるかをまとめたものです。
開発者とユーザーにとっての意味
開発者にとって、MonadBFTは以下を意味します：
- シンプルなファイナリティモデル： MonadBFTを使用すると、QC（大多数の投票）を持つブロックを事実上最終的に確定したものと見なすことができ、プロトコルがこれを確定するか、あるいは違反者を罰するからです。開発者は1ブロック確認で高い確信を持って安全に操作できます。
- アプリケーションのUX改善： 高スループットのアプリケーション（取引所、ゲームなど）を構築している場合、MonadBFTの低遅延とフォーク耐性がよりスムーズなユーザーエクスペリエンスにつながります。ユーザーはほぼ即座に自分の操作が確認されたことを認識でき、混乱するような再編成やロールバックに頻繁に遭遇しません。これにより、ファイナリティと高速更新を備えたアプリを設計できます。
- 決定論的挙動： MonadBFTは再提案要求などより厳格なルールにより、ブロック包含の不確実性を減らします。投票またはタイムアウトがリーダーに先に届くかどうかといった微妙なタイミング要因によって、ブロックが含まれたりスキップされたりする「エッジケース」が少なくなります。MonadBFTはこうした時間に敏感な曖昧さを、明確なルールと検証可能な証拠で置き換えます。これにより、プロトコルの正当性の推論やテストが容易になります。また、故障ノードを特定する明確な根拠も提供します（例えば、誰かが再提案しなかったり、競合するブロックを提案した場合は、プロトコル違反であることがわかります）。
- スケーラビリティの余地： スケーラビリティに関心のある開発者にとって、MonadBFTはボトルネックに達するまでより多くの余地を提供します。二次プロトコルと比較して、ブロックサイズやバリデータ数をより簡単に増やすことができます。また、消去符号化ブロック伝播などの機能により、個々のノードを過度に負荷することなく大量のデータをネットワーク上で送信できます。これにより、より高いスループットを狙うことが可能になり、より野心的なオンチェーンアプリの設計空間が広がります。
エンドユーザー向け： 一般のユーザーはここで議論している内容を理解しないかもしれませんが、その恩恵は感じ取ることができます。MonadBFTがMonadチェーンの基盤として採用されることで、非中央集権性や検閲耐性を損なうことなく、以下の良い特性を期待できます。
- より速い確認： トークン送信、資産交換、NFT鋳造、取引実行などのトランザクションが素早く確認されます。
- 例外の減少： テールフォークのような本質的に再編成となる現象が排除されるため、チェーンの状態の一貫性が高まります。
- 公平性と透明性： コンセンサスの改善は間接的に、チェーンの運営がより公平になることを意味します。単一のバリデータが容易にトランザクションを検閲したり、ブロック内の順序を操作したりできなくなります。
結論
まとめると、MonadBFTはパイプライン型HotStuffスタイルのコンセンサスに以下の4つのコア革新を導入しています：
テールフォーク耐性： MonadBFTは、テールフォーク攻撃を排除した最初のパイプライン型BFTプロトコルです。これは、次期リーダーが前リーダーが失敗した場合に、直前の投票済みブロックを再提案するか、そのブロックが支持を欠いていることを示す背書なし証明（NEC）を提示することで実現します。これにより、大多数の支持を得たブロックが破棄されないことが保証され、誠実なリーダーの報酬が保護され、悪意ある再編成やクロスブロックMEV抽出が防止されます。
一回のラウンドでの投機的ファイナリティ： バリデータは1回の通信ラウンド（リーダーの提案と投票）後にブロックを確定でき、クライアントに即時の包含保証を提供します。この投機的確定は、リーダーの等価攻撃（証明可能かつ罰則対象となる行為）の場合にのみ取り消され、実用上は安全な仮定となります。
楽
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
