第1部では、クラシックPBFT（実用ビザンチン耐障害性）コンセンサスの仕組みと、初期バージョンのHotStuffの動作方法を研究しました。また、MonadBFTがHotStuffの末端フォーク問題、つまりパイプラインシステムにおいて有効なブロックが時々廃棄される問題をどのように解決するかについても理解しました。この尾叉問題は、2つの主要な問題を引き起こします：1）それは誠実なブロック構築者の報酬を混乱させる、2）ネットワークの停滞を引き起こす可能性があります。MonadBFTは、再提案ルールと無背書投票メカニズムを導入して、尾部フォーク問題を排除し、誠実な提案者からの適切に承認されたブロックがチェーンに入ることを保証します。第2部では、MonadBFTのもう2つの特性について探ります：1）投機的最終性と2）楽観的応答性。また、MonadBFTが開発者に与える影響についても探ります。単一ラウンド投機の最終性尾部フォークに抵抗することに加えて、MonadBFTのもう一つの主要な特性は、単一ラウンドの投機的最終性です。実際のアプリケーションでは、これによりクライアントとユーザーはブロックがほとんどの投票を得た後、次のラウンドが完了する前に即座に取引確認を受け取ることができます。思い出してみてください。ベースラインHotStuffプロトコルでは、1つのブロックは通常、最終的に確定（不可逆）と見なされるために、少なくとも2つのステージ（Fast-HotstuffやDiem-BFTなど）を経なければなりません。1つのステージでは法定人数証明（QC）を取得し（≥2f+1票でブロックをロック）、次のステージでは次のリーダーがその法定人数証明（QC）に基づいてブロックを構築し、提出します。この二段階コミットは、安全性を確保するために必要です：十分な数の誠実なノードが1つのブロックをロックすると、それに対立するブロックは法定人数を得ることができず、次のラウンドのコミットによってそれは永続化されます。したがって、クライアントは通常、前のトランザクションが最終的に確定したかどうかを知るために、次のブロックまたは次のラウンドが生成されるのを待つ必要があります。MonadBFTは基本的に、取引が一度の投票で十分に最終的と見なされることを許可します（安全に操作できます）。これがいわゆる投機的最終性です。リーダーがブロックを提案し、バリデーターがそのブロックのQCを投票して形成した時、そのブロックは投票状態（法定人数によってロックされている）になります。MonadBFTでは、バリデーターがQCを形成すると、すぐにそのブロックの取引を実行し、クライアントに初期確認を送信することさえあります。これは、ブロックが（投機的に）受け入れられたことを示しています。「私たちは大多数がこのブロックに同意しています。非常に予期しない事態が発生しない限り、このブロックは確認されたと見なせます。」この即時確認は楽観的です。ブロックはまだ帳簿に提出されていません。これは次の提案が現れ、それを最も確認する（QC-on QC）まで続きますが、通常、これを撤回するものはありません。投機的に実行されたブロックを撤回できる唯一の状況は、リーダーが同等攻撃を行う場合です（つまり、同じ高さで異なる2つのブロックを提案して投票を分散させること）。投機的最終性を尾部フォークに対する抵抗の優れた副産物と見ることができます。 尾部フォークに対する抵抗は、次のリーダーが崩壊しても現在の提案が捨てられないことを保証します（これは再提案とNECルールのおかげです）。投機的な実行ブロックが捨てられる唯一のケースは、元の提案者が同等攻撃を受けた場合（悪意のある二重署名エラーを証明できる）であり、この状況は：1）対立するQCによって検出可能；2）罰せられる；3）極めてまれです。以前のプロトコルでは、次のリーダーが前のブロックを再提出することが保証されていなかったため、尾部フォークが発生する可能性があり、投機的な仮定が破られました。楽観的な応答性ほとんどのコンセンサスプロトコルでは、各ラウンドの後にバッファ期間やタイムアウトなどの組み込まれた待機時間があります。これは、すべてのメッセージが進行する前に到達していることを確認するためです。これは、リーダーがクラッシュしたり、まったく情報を送信しなかったりするなどの最悪の事態に対処するための保護メカニズムです。これらのタイムアウトは通常過度に保守的です。ネットワークが正常に動作し、すべてのバリデーターの行動が正しい場合、固定の待機時間は不必要なコストになります。ブロックはもっと早く完了できたはずですが、プロトコルは念のために遅延させました。MonadBFTは楽観的応答性を導入しており、これはプロトコルがネットワーク情報に基づいて即座に前進できることを意味し、常に固定されたタイマーに依存するわけではありません。ここでの設計原則は「できるだけ早く、忍耐が必要なときだけ忍耐する」と要約できます。MonadBFTの設計は、通常時だけでなく、障害復旧時にも、必要がない限り、予定されたタイムアウトを待つために一時停止しないことを可能にします。楽しいパス上で（誠実なリーダーがいることを意味します）： 提案や投票に内蔵の遅延はありません。リーダーの番になったら、ブロックを提案します。検証者は、有効な提案を受け取るとすぐに投票します。リーダー（あるいはより正確には次のリーダー、なぜならパイプラインHotStuffでは、投票は次の提案者に送信されるからです）が2f+1票を集めると、QCが形成され、広がることができます。楽観的応答性設計では、これは次の段階を即座に引き起こします。実際には、これはノード間のネットワーク遅延が100ミリ秒である場合、コンセンサスが数百ミリ秒で1ラウンドを完了できることを意味します（計算および集約のオーバーヘッドを加えて）。必要がない場合、1秒の「スロット時間」を待つことはありません。これは、イーサリアムのメインネットで採用されているスロットとエポックのモデルとは異なります。イーサリアムでは、ブロック生成の時間間隔は12秒に固定されています。全員が事前に準備をしていても、プロトコルは待機します。MonadBFTの方法は不必要な遅延を排除します。これはパイプラインHotStuff構造を保持していますが、通常「Δ秒待たなければならない」という厳しい規定を削除しました。これは、安全性を損なうことなく、応答性の面で時間制約システムよりも優れていることを意味します。不幸な経路において（リーダーの失敗）： 多くのコンセンサスプロトコルでは、リーダーがブロックを提出できなかった場合、他のノードはタイムアウト Δ の後にのみそのことに気付くことになります。たとえば、Δ が 1 秒の場合、この時間は基本的に無駄になります。MonadBFT の処理方法はこれとは異なります。検証者が提案の喪失を検出すると、すぐにタイムアウトメッセージ（TC またはタイムアウト証明書）をブロードキャストします。2f+1 回のタイムアウトが発生すると、次のリーダーが引き継ぎます。新しい視点への移行は、時計によってではなく、法定人数に基づく証拠によって引き起こされます。hotstuff-familyのコンセンサスとの比較MonadBFTは、HotStuffファミリーのコンセンサスプロトコルの上に構築されていますが、望ましい機能の組み合わせを実装していることで際立っています。 以前のプロトコルは、パイプラインのスループットや線形通信など、特定の次元に最適化されることが多かったのですが、他の次元を犠牲にしなければなりませんでした。 MonadBFTは、直線的なメッセージの複雑さ、パイプライン化された送信、強力なテールスプリット耐性、固定遅延のない即時応答性、効率的なリカバリメカニズムを独自に組み合わせながら、迅速なファイナライゼーションと高可用性の保証を維持します。 次の表は、MonadBFTが他のローテーションリーダーBFTプロトコルとどのように比較されるかを、これらの主要な次元でまとめたものです。これは開発者とユーザーにとって何を意味しますか？開発者にとって、MonadBFT はいくつかの意味があります：よりシンプルな最終確定性モデル：MonadBFTを使用すると、QC（過半数の投票）を持つブロックを実際に最終確定されたものと見なすことができます。なぜなら、プロトコルはそれを最終確定するか、罰を行うからです。開発者は1ブロックの確認を安全に操作することに高度の自信を持つことができます。アプリケーションのユーザーエクスペリエンスの改善：もし高スループットのアプリケーション（取引所、ゲームなど）を構築している場合、MonadBFTの低遅延とフォーク抵抗特性は、よりスムーズなユーザーエクスペリエンスに変換されます。ユーザーはほぼ即座に自分の操作が確認されたことを実感でき、混乱を招く再構成やロールバックに頻繁に遭遇することはありません。このように、最終確定性と迅速な更新を持つアプリを設計することができます。決定論的な振る舞い: MonadBFTのより厳格なルール、例えば再提案要件は、ブロック包含の不確実性を減らします。 投票やタイムアウトが最初にリーダーに到達するかどうかなどの微妙な時間的要因により、ブロックが含まれたりスキップされたりする「エッジケース」は少なくなります。 MonadBFTは、この一刻を争う曖昧さを、明確なルールと検証可能な証拠に置き換えます。 これにより、プロトコルの正確性を推論してテストしやすくなります。 また、障害のあるノードを特定するための明確な基盤も提供します(たとえば、誰かが再提案に失敗したり、競合するブロックを提案したりした場合、プロトコルに違反していることがわかります)。スケーラビリティの余地：もしあなたがスケーラビリティに注目している開発者であれば、MonadBFTはボトルネックに達する前に、より多くの余地を提供します。二次プロトコルと比較して、ブロックサイズやバリデーターの数をより簡単に増やすことができます。また、エラーディレクテッドブロック伝播などの機能により、ネットワークを通じて大量のデータをプッシュすることができ、単一のノードを過度に消耗させることはありません。これにより、より高いスループットを目指すことが可能になり、より野心的なオンチェーンアプリケーションの設計スペースが開かれます。最終ユーザー向け：一般のユーザーは、ここで議論している内容を理解することはありませんが、その影響を感じるでしょう。MonadBFTをMonadチェーンの基盤として利用することで、ユーザーは非中央集権性と検閲抵抗を犠牲にすることなく、以下のすべての良い特性を期待することができます。より迅速な確認： 取引（トークンの送信、資産の交換、NFTのミント、取引の実行など）は迅速に確認されます。偶発的な減少：チェーン状態の一貫性が高まります。なぜなら、尾部フォークのような本質的に再構成に属するものが排除されるからです。公平と透明性：コンセンサスの改善は、チェーンの運用がより公平であることを間接的に意味します。どの単一のバリデーターも、取引を容易に審査したり、ブロック間の順序に手を加えたりすることはできません。結論まとめると、MonadBFTはパイプラインHotStuffスタイルのコンセンサスに基づいて4つの核心的な革新を導入しました：尾部フォークに対する抵抗：MonadBFTは、尾部フォーク攻撃を排除する最初のパイプラインBFTプロトコルです。これは、次のリーダーが前のリーダーが失敗した場合に前回の投票のブロックを再提示するか、無背書証明書（NEC）を提示して、そのブロックが支持を欠いていることを証明することによって実現されます。これにより、圧倒的な支持を受けたブロックが捨てられることはなくなり、誠実なリーダーの報酬が保護され、悪意のある再構成やクロスブロックMEVの抽出が防止されます。単一ラウンドの投機的最終性：バリデーターは単一ラウンドの通信（リーダーが提案し投票する）後にブロックを確認し、クライアントに即座の包含保証を提供できます。この投機的確認は、リーダーが同等攻撃（証明可能で罰則がある行為）を行った場合にのみ回復されるため、実際には安全な仮定となります。楽観的応答性：プロトコルはネットワーク速度で動作し、固有の遅延はありません。リーダーは必要な投票を受け取った後、すぐにコンセンサスを進め、視点の変更は法定人数のタイムアウトを観察した後に即座に発生します。固定のタイムインターバルを待つのではありません。このような楽観的応答性の設計は、待機時間を最小限に抑え、スループットを最大化し、非同期や障害が発生した場合でも堅牢に処理することを可能にします。線形通信：幸せなパス上（つまり、リーダーが誠実である場合）、メッセージと検証の複雑さは検証者の数に線形関係を持ちます。MonadBFTは、HotStuffの効率的な通信モデルを保持し、集約署名とシンプルなリーダーによる検証者へのブロードキャストを使用して、プロトコルが数百の検証者にスケールできるようにし、パフォーマンスのボトルネックが発生しないようにします。
MonadBFTの解析（下）：開発者とユーザーにとって何を意味するか
第1部では、クラシックPBFT（実用ビザンチン耐障害性）コンセンサスの仕組みと、初期バージョンのHotStuffの動作方法を研究しました。また、MonadBFTがHotStuffの末端フォーク問題、つまりパイプラインシステムにおいて有効なブロックが時々廃棄される問題をどのように解決するかについても理解しました。
この尾叉問題は、2つの主要な問題を引き起こします：1）それは誠実なブロック構築者の報酬を混乱させる、2）ネットワークの停滞を引き起こす可能性があります。
MonadBFTは、再提案ルールと無背書投票メカニズムを導入して、尾部フォーク問題を排除し、誠実な提案者からの適切に承認されたブロックがチェーンに入ることを保証します。
第2部では、MonadBFTのもう2つの特性について探ります：1）投機的最終性と2）楽観的応答性。また、MonadBFTが開発者に与える影響についても探ります。
単一ラウンド投機の最終性
尾部フォークに抵抗することに加えて、MonadBFTのもう一つの主要な特性は、単一ラウンドの投機的最終性です。
実際のアプリケーションでは、これによりクライアントとユーザーはブロックがほとんどの投票を得た後、次のラウンドが完了する前に即座に取引確認を受け取ることができます。
思い出してみてください。ベースラインHotStuffプロトコルでは、1つのブロックは通常、最終的に確定（不可逆）と見なされるために、少なくとも2つのステージ（Fast-HotstuffやDiem-BFTなど）を経なければなりません。1つのステージでは法定人数証明（QC）を取得し（≥2f+1票でブロックをロック）、次のステージでは次のリーダーがその法定人数証明（QC）に基づいてブロックを構築し、提出します。
この二段階コミットは、安全性を確保するために必要です：十分な数の誠実なノードが1つのブロックをロックすると、それに対立するブロックは法定人数を得ることができず、次のラウンドのコミットによってそれは永続化されます。したがって、クライアントは通常、前のトランザクションが最終的に確定したかどうかを知るために、次のブロックまたは次のラウンドが生成されるのを待つ必要があります。
MonadBFTは基本的に、取引が一度の投票で十分に最終的と見なされることを許可します（安全に操作できます）。これがいわゆる投機的最終性です。
リーダーがブロックを提案し、バリデーターがそのブロックのQCを投票して形成した時、そのブロックは投票状態（法定人数によってロックされている）になります。MonadBFTでは、バリデーターがQCを形成すると、すぐにそのブロックの取引を実行し、クライアントに初期確認を送信することさえあります。これは、ブロックが（投機的に）受け入れられたことを示しています。「私たちは大多数がこのブロックに同意しています。非常に予期しない事態が発生しない限り、このブロックは確認されたと見なせます。」
この即時確認は楽観的です。ブロックはまだ帳簿に提出されていません。これは次の提案が現れ、それを最も確認する（QC-on QC）まで続きますが、通常、これを撤回するものはありません。投機的に実行されたブロックを撤回できる唯一の状況は、リーダーが同等攻撃を行う場合です（つまり、同じ高さで異なる2つのブロックを提案して投票を分散させること）。
投機的最終性を尾部フォークに対する抵抗の優れた副産物と見ることができます。 尾部フォークに対する抵抗は、次のリーダーが崩壊しても現在の提案が捨てられないことを保証します（これは再提案とNECルールのおかげです）。投機的な実行ブロックが捨てられる唯一のケースは、元の提案者が同等攻撃を受けた場合（悪意のある二重署名エラーを証明できる）であり、この状況は：1）対立するQCによって検出可能；2）罰せられる；3）極めてまれです。
以前のプロトコルでは、次のリーダーが前のブロックを再提出することが保証されていなかったため、尾部フォークが発生する可能性があり、投機的な仮定が破られました。
楽観的な応答性
ほとんどのコンセンサスプロトコルでは、各ラウンドの後にバッファ期間やタイムアウトなどの組み込まれた待機時間があります。これは、すべてのメッセージが進行する前に到達していることを確認するためです。これは、リーダーがクラッシュしたり、まったく情報を送信しなかったりするなどの最悪の事態に対処するための保護メカニズムです。
これらのタイムアウトは通常過度に保守的です。ネットワークが正常に動作し、すべてのバリデーターの行動が正しい場合、固定の待機時間は不必要なコストになります。ブロックはもっと早く完了できたはずですが、プロトコルは念のために遅延させました。
MonadBFTは楽観的応答性を導入しており、これはプロトコルがネットワーク情報に基づいて即座に前進できることを意味し、常に固定されたタイマーに依存するわけではありません。ここでの設計原則は「できるだけ早く、忍耐が必要なときだけ忍耐する」と要約できます。
MonadBFTの設計は、通常時だけでなく、障害復旧時にも、必要がない限り、予定されたタイムアウトを待つために一時停止しないことを可能にします。
楽しいパス上で（誠実なリーダーがいることを意味します）： 提案や投票に内蔵の遅延はありません。リーダーの番になったら、ブロックを提案します。検証者は、有効な提案を受け取るとすぐに投票します。リーダー（あるいはより正確には次のリーダー、なぜならパイプラインHotStuffでは、投票は次の提案者に送信されるからです）が2f+1票を集めると、QCが形成され、広がることができます。楽観的応答性設計では、これは次の段階を即座に引き起こします。
実際には、これはノード間のネットワーク遅延が100ミリ秒である場合、コンセンサスが数百ミリ秒で1ラウンドを完了できることを意味します（計算および集約のオーバーヘッドを加えて）。
必要がない場合、1秒の「スロット時間」を待つことはありません。これは、イーサリアムのメインネットで採用されているスロットとエポックのモデルとは異なります。イーサリアムでは、ブロック生成の時間間隔は12秒に固定されています。全員が事前に準備をしていても、プロトコルは待機します。
MonadBFTの方法は不必要な遅延を排除します。これはパイプラインHotStuff構造を保持していますが、通常「Δ秒待たなければならない」という厳しい規定を削除しました。これは、安全性を損なうことなく、応答性の面で時間制約システムよりも優れていることを意味します。
不幸な経路において（リーダーの失敗）： 多くのコンセンサスプロトコルでは、リーダーがブロックを提出できなかった場合、他のノードはタイムアウト Δ の後にのみそのことに気付くことになります。たとえば、Δ が 1 秒の場合、この時間は基本的に無駄になります。MonadBFT の処理方法はこれとは異なります。検証者が提案の喪失を検出すると、すぐにタイムアウトメッセージ（TC またはタイムアウト証明書）をブロードキャストします。2f+1 回のタイムアウトが発生すると、次のリーダーが引き継ぎます。新しい視点への移行は、時計によってではなく、法定人数に基づく証拠によって引き起こされます。
hotstuff-familyのコンセンサスとの比較
MonadBFTは、HotStuffファミリーのコンセンサスプロトコルの上に構築されていますが、望ましい機能の組み合わせを実装していることで際立っています。 以前のプロトコルは、パイプラインのスループットや線形通信など、特定の次元に最適化されることが多かったのですが、他の次元を犠牲にしなければなりませんでした。 MonadBFTは、直線的なメッセージの複雑さ、パイプライン化された送信、強力なテールスプリット耐性、固定遅延のない即時応答性、効率的なリカバリメカニズムを独自に組み合わせながら、迅速なファイナライゼーションと高可用性の保証を維持します。 次の表は、MonadBFTが他のローテーションリーダーBFTプロトコルとどのように比較されるかを、これらの主要な次元でまとめたものです。
これは開発者とユーザーにとって何を意味しますか？
開発者にとって、MonadBFT はいくつかの意味があります：
よりシンプルな最終確定性モデル：MonadBFTを使用すると、QC（過半数の投票）を持つブロックを実際に最終確定されたものと見なすことができます。なぜなら、プロトコルはそれを最終確定するか、罰を行うからです。開発者は1ブロックの確認を安全に操作することに高度の自信を持つことができます。
アプリケーションのユーザーエクスペリエンスの改善：もし高スループットのアプリケーション（取引所、ゲームなど）を構築している場合、MonadBFTの低遅延とフォーク抵抗特性は、よりスムーズなユーザーエクスペリエンスに変換されます。ユーザーはほぼ即座に自分の操作が確認されたことを実感でき、混乱を招く再構成やロールバックに頻繁に遭遇することはありません。このように、最終確定性と迅速な更新を持つアプリを設計することができます。
決定論的な振る舞い: MonadBFTのより厳格なルール、例えば再提案要件は、ブロック包含の不確実性を減らします。 投票やタイムアウトが最初にリーダーに到達するかどうかなどの微妙な時間的要因により、ブロックが含まれたりスキップされたりする「エッジケース」は少なくなります。 MonadBFTは、この一刻を争う曖昧さを、明確なルールと検証可能な証拠に置き換えます。 これにより、プロトコルの正確性を推論してテストしやすくなります。 また、障害のあるノードを特定するための明確な基盤も提供します(たとえば、誰かが再提案に失敗したり、競合するブロックを提案したりした場合、プロトコルに違反していることがわかります)。
スケーラビリティの余地：もしあなたがスケーラビリティに注目している開発者であれば、MonadBFTはボトルネックに達する前に、より多くの余地を提供します。二次プロトコルと比較して、ブロックサイズやバリデーターの数をより簡単に増やすことができます。また、エラーディレクテッドブロック伝播などの機能により、ネットワークを通じて大量のデータをプッシュすることができ、単一のノードを過度に消耗させることはありません。これにより、より高いスループットを目指すことが可能になり、より野心的なオンチェーンアプリケーションの設計スペースが開かれます。
最終ユーザー向け：一般のユーザーは、ここで議論している内容を理解することはありませんが、その影響を感じるでしょう。MonadBFTをMonadチェーンの基盤として利用することで、ユーザーは非中央集権性と検閲抵抗を犠牲にすることなく、以下のすべての良い特性を期待することができます。
より迅速な確認： 取引（トークンの送信、資産の交換、NFTのミント、取引の実行など）は迅速に確認されます。
偶発的な減少：チェーン状態の一貫性が高まります。なぜなら、尾部フォークのような本質的に再構成に属するものが排除されるからです。
公平と透明性：コンセンサスの改善は、チェーンの運用がより公平であることを間接的に意味します。どの単一のバリデーターも、取引を容易に審査したり、ブロック間の順序に手を加えたりすることはできません。
結論
まとめると、MonadBFTはパイプラインHotStuffスタイルのコンセンサスに基づいて4つの核心的な革新を導入しました：
尾部フォークに対する抵抗：MonadBFTは、尾部フォーク攻撃を排除する最初のパイプラインBFTプロトコルです。これは、次のリーダーが前のリーダーが失敗した場合に前回の投票のブロックを再提示するか、無背書証明書（NEC）を提示して、そのブロックが支持を欠いていることを証明することによって実現されます。これにより、圧倒的な支持を受けたブロックが捨てられることはなくなり、誠実なリーダーの報酬が保護され、悪意のある再構成やクロスブロックMEVの抽出が防止されます。
単一ラウンドの投機的最終性：バリデーターは単一ラウンドの通信（リーダーが提案し投票する）後にブロックを確認し、クライアントに即座の包含保証を提供できます。この投機的確認は、リーダーが同等攻撃（証明可能で罰則がある行為）を行った場合にのみ回復されるため、実際には安全な仮定となります。
楽観的応答性：プロトコルはネットワーク速度で動作し、固有の遅延はありません。リーダーは必要な投票を受け取った後、すぐにコンセンサスを進め、視点の変更は法定人数のタイムアウトを観察した後に即座に発生します。固定のタイムインターバルを待つのではありません。このような楽観的応答性の設計は、待機時間を最小限に抑え、スループットを最大化し、非同期や障害が発生した場合でも堅牢に処理することを可能にします。
線形通信：幸せなパス上（つまり、リーダーが誠実である場合）、メッセージと検証の複雑さは検証者の数に線形関係を持ちます。MonadBFTは、HotStuffの効率的な通信モデルを保持し、集約署名とシンプルなリーダーによる検証者へのブロードキャストを使用して、プロトコルが数百の検証者にスケールできるようにし、パフォーマンスのボトルネックが発生しないようにします。