InPart 1,私たちは、クラシックなPBFTコンセンサスがどのように機能するか、およびHotStuffの以前のバージョンがどのように動作するかを調査しました。また、MonadBFTがHotStuffのテイルフォーキングの問題を解決する方法についても見てきました。これは、有効なブロックが時々パイプラインシステムで取り残される問題です。

このテールフォーキングの問題は2つの大きな問題を引き起こします：1）正直なブロックビルダーの報酬を台無しにし、2）ネットワークを停滞させる可能性があります。

MonadBFTは、尾部分岐問題を排除し、正当な提案者からの適切に承認されたブロックが常にチェーンに取り込まれることを保証するために、ReproposalルールとNo-Endorsement投票メカニズムを導入しています。

第2部では、MonadBFTのもう2つの特性である1)仮定的確定性および2)楽観的応答性について探求します。また、MonadBFTの開発者への影響についても探求します。

ワンラウンドの投機的最終性

テールフォーク耐性に加えて、MonadBFTのもう1つの主要な特徴は、1つのラウンド内での仮想確定性です。

実際的な意味では、これはクライアントやユーザーが、次のラウンドが完了する前に、ブロックが過半数の投票を受けるとすぐにトランザクションの確認を受け取ることができることを意味します。

プロトコルベースラインHotStuffにおいて、ブロックは通常、少なくとも2つのフェーズ（例：Fast-Hotstuff＆Diem-BFT）を経るまで、最終的（不可逆的）とは見なされません。1つ目のフェーズではクォーラム証明書を取得し（ブロックを≥2f+1票でロック）、2つ目のフェーズでは次のリーダーがそのQCに基づいてブロックを確定します。

この2段階のコミットは安全性を確保するために必要です: 十分な正直なノードがブロックをロックした後、競合するブロックがクォーラムを集めることはできず、次のラウンドでのコミットにより永続化されます。したがって、通常、クライアントは前のトランザクションが最終的であることを知る前に、次のブロックまたは次のラウンドが生成されるのを待たなければならないかもしれません。

MonadBFTは、投票ラウンドが1回だけ行われた後に取引を十分に最終的（実行可能な安全性）と見なすことを可能にします。これを仮最終性と呼びます。

リーダーがブロックを提案し、検証者がそのブロックのためのQCを形成するために投票すると、そのブロックは現在Voted状態になります（クォーラムによってロックされています）。MonadBFTでは、検証者はQCを形成するとすぐにブロックのトランザクションを実行し、クライアントにそのブロックが（仮に）受け入れられたことを示す予備的な確認さえ送信します。これは次のように言うのと同じです。「このブロックについて合意する超過多数がいます。非常に予期しないことがない限り、このブロックを確認されたものと考えてください。」

この直ちに確認されることは楽観的です。ブロックはまだ台帳に確定されていません。次の提案が来てそれを最終決定する（QC-on QC）際に確定されますが、通常の条件下では何も取り消されません。仮に実行されたブロックを元に戻す唯一のシナリオは、リーダーが曖昧な態度をとった場合（つまり、同じ高さで2つの異なるブロックを提案して投票を分割した場合）です。

投機的な最終性を、テールフォーク耐性の素敵な副産物と考えることができます。 テールフォークの耐性は、次のリーダーがクラッシュしても、現在の提案が放棄されないことを保証します（再提案とNECルールのおかげで）。したがって、投機的に実行されたブロックが破棄される唯一の場合は、元の提案者が二重署名の過失（証明可能に悪意がある）をした場合であり、これは次の通りです：1）競合するQCを検出でき、2）スラッシュ可能であり、3）非常にまれです。

以前のプロトコルでは、次のリーダーが前のブロックを再提案することを保証していなかったため、テールフォーキングが可能であり、仮説の前提を破ることができました。

楽観的なレスポンシブ

ほとんどの合意プロトコルでは、各ラウンドの後にバッファ期間やタイムアウトのような組み込みの待ち時間があります。これは、前に進む前にすべてのメッセージが到着していることを確認するためです。これは、リーダーがクラッシュしたり何も送信しなかった場合など、最悪のシナリオを処理するための保護メカニズムです。

これらのタイムアウトはしばしば過剰に保守的です。ネットワークが正常に機能し、すべてのバリデータが正しく動作している場合、その固定待ちが必要なオーバーヘッドになります。ブロックはより速く最終化されていたかもしれませんが、プロトコルは念のために引き留められていました。

MonadBFTは、プロトコルが常に固定タイマーに依存するのではなく、ネットワークメッセージに基づいてすぐに前進できるという楽観的な応答性を導入しています。ここでの設計原則は、「できるときは速く、しなければ我慢する」と要約できます。

MonadBFTは、通常のケースや障害からの回復においても、必要がなければ所定のタイムアウトを待たずに設計されています。

• 幸せなパス（つまり、正直なリーダーがいる場合）：提案や投票には組み込みの遅延がありません。リーダーが順番を持つとすぐに、ブロックを提案します。検証者が有効な提案を受け取るとすぐに、投票します。リーダー（むしろ、次のリーダー、なぜなら、投票はパイプライン化されたHotStuffの次の提案者に送られるため）が2f+1票を集めると、QCが形成され、伝播されます。楽観的に応答性のある設計では、これにより次の段階が直ちに開始されます。

実際には、これはネットワークノード間の遅延が100msである場合、合意は潜在的にわずか数百ミリ秒でラウンドを終了することができます（計算と集計のオーバーヘッドを加えると）。

必要がない場合、たとえば1秒の「スロット時間」を待つことはありません。これは、必要がない場合にEthereumメインネットとは対照的ですスロットとエポックモデルイーサリアムでは、ブロックの生成は12秒間隔で固定されています。誰もが早く準備ができても、プロトコルは待機します。

MonadBFTの手法は不要な遅延を排除します。パイプライン化されたHotStuff構造を維持しつつ、通常の場合における厳格な「Δ秒待たなければならない」というルールを削除します。これにより、応答性において時間制約システムを凌駕することができ、安全性を犠牲にすることなく性能を向上させることができます。

• 不幸なパス（リーダーの失敗）：多くの合意プロトコルでは、リーダーがブロックの提案に失敗した場合、他のノードはタイムアウトΔが経過した後に初めて気付きます。たとえば、Δが1秒の場合、その時間は実質的に失われます。MonadBFTはこれを異なる方法で処理します。検証者が提案の欠落を検出すると、すぐにタイムアウトメッセージ（TCまたはタイムアウト証明書）をブロードキャストします。これらのタイムアウトが2f+1個見られると、次のリーダーが引き継ぎます。新しいビューへの移行は、クォーラムに基づく証拠によってトリガーされ、時計によってではありません。

hotstuff-familyコンセンサスとの比較

MonadBFTは、HotStuffファミリーの合意プロトコルの系譜を継承して構築されていますが、従来の設計ではトレードオフなしに完全に統合することができなかった望ましい特性の組み合わせを実現しています。以前のプロトコルは、通信システムや直線的な通信などの特定の次元に最適化されている場合がありますが、他の次元を犠牲にする必要がありました。MonadBFTは、直線的なメッセージ複雑さ、パイプライン化されたコミット、強力なテイル・フォーキング・レジスタンス、固定遅延なしでの即時応答、効率的な回復メカニズムを組み合わせることに成功し、高速な確定性と高いライブネスの保証を維持しながら、他の回転リーダーBFTプロトコルと比較してどのように優れているかをまとめた表は以下の通りです。

開発者やユーザーにとって、これはどういう意味ですか？

開発者にとって、MonadBFTとはいくつかの意味を持ちます。

• より単純な確定性モデル：MonadBFTを使用すると、QC（過半数投票）を持つブロックをほぼすべての目的で実質的に確定したものとして扱うことができます。なぜなら、プロトコルがそれを確定するか、そうでない場合はスラッシュするからです。開発者は、高い信頼を持って1ブロック確認に対応することができます。
• アプリの改善されたUX：高スループットのアプリケーション（取引所、ゲームなど）を構築している場合、MonadBFTの低レイテンシとフォーク耐性はスムーズなUXに繋がります。ユーザーはほぼ即座にアクションが確認され、混乱するリオルグやロールバックにはほとんど遭遇しません。これにより、最終性と迅速な更新を前提としたアプリケーションを設計できます。
• 決定論的な動作：MonadBFTの厳格なルール（再提案要件など）により、ブロックの含有における非決定性が減少します。投票またはタイムアウトが最初にリーダーに到達するかどうかなどの微妙なタイミングに依存してブロックが含まれたりスキップされたりする可能性のある「特異ケース」が少なくなります。 MonadBFTは、そのようなタイミングに敏感な曖昧さを明確なルールと検証可能な証拠で置き換えます。これにより、プロトコルの正確さについて推論しやすくなり、テストしやすくなります。また、誤ったノードを特定する明確な根拠も提供します（たとえば、再提案を怠るか、競合するブロックを提案する場合、プロトコルに違反したことがわかります）。
• スケーラビリティの余地：スケーリングに関心を持つ開発者の場合、MonadBFTはボトルネックに達する前により多くの余地を提供します。二次プロトコルよりもブロックサイズやバリデータ数をより快適に増やすことができます。また、イレースコード化されたブロックの伝播などの機能により、個々のノードを過度に負担することなく大量のデータをネットワークを介して送信できます。これにより、より高いスループットを目指すことが可能となり、それによりより野心的なオンチェーンアプリケーションのための設計空間が拡大します

エンドユーザー向け：ノーミー ユーザーは、ここで議論したものについては何も知らないかもしれませんが、その影響を感じています。Monadチェーンを支えるMonadBFTの下、ユーザーは、中央集権性や検閲耐性を犠牲にすることなく、以下に示すすべての素晴らしい特性を期待できます。

• より速い確認：トランザクション（トークンの送信、アセットの交換、NFTの発行、取引の実行など）が非常に迅速に確認されます。
• 少ない驚き：チェーンの状態の一貫性が高まり、再編成のようなものが排除されるため、尾部のフォーキングなどの驚きが少なくなります
• 公正さと透明性：コンセンサスの改善は、チェーンの運営がより公平になることを間接的に意味します。単一の検証者が簡単に取引を検閲したり、ブロック間の順序付けでゲームをしたりすることはできません。

結論

再度確認すると、MonadBFTは、パイプライン化されたHotStuffスタイルのコンセンサスの上に、4つのコアイノベーションを導入しています。

Tail-Forking Resistance: MonadBFTは、テイルフォーキング攻撃を排除するための最初のパイプライン方式のBFTプロトコルです。前のリーダーが失敗した場合、次のリーダーに前回の投票済みブロックを再提案するか、それ以外の場合はサポートが不足していることを証明するNo-Endorsement Certificate（NEC）を示すことによってこれを実現します。これにより、過半数によって支持されたブロックが放棄されることはなく、正直なリーダーの報酬が保護され、悪意のある再編成やクロスブロックMEV抽出が防止されます。

1ラウンドでの仮定確定性：バリデータは1ラウンドの通信（1つのリーダー提案と投票）の後にブロックを確認でき、クライアントに直ちに含まれることの保証を提供​​できます。この仮定確定性は、リーダーが二重に（証明および処罰できる行為）する場合にのみ元に戻り、実践的に安全な仮定となります。

楽観的な応答性：プロトコルは固有の遅延なしにネットワーク速度で動作します。リーダーは必要な投票が受信されるとすぐに合意を進め、ビューの変更は固定のタイムアウト間隔を待つのではなく、タイムアウトのクォーラムが観察されるとすぐに発生します。この楽観的な応答性設計は待ち時間を最小限に抑え、スループットを最大化し、発生時に非同期性と障害を堅牢に処理します。

リニア通信：ハッピーパス（リーダーが正直であることを意味する）で、メッセージと認証の複雑さはバリデータの数に比例しています。MonadBFTは、集約された署名とシンプルなリーダーからバリデータへのブロードキャストを使用した、効率的な通信パターンを保持し、プロトコルがパフォーマンスのボトルネックなしに数百のバリデータにスケーリングすることを可能にします。

免責事項：

1. この記事は[michael_lwy]から転載されました。すべての著作権は元の著者[michael_lwy]に帰属します。michael_lwy]. If there are objections to this reprint, please contact theGate Learnチームが promptly に対処します。
2. 責任の免責事項： この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームによって他言語への記事の翻訳が行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。