これは大きなマイルストーンです:MonadBFT、RaptorCast、blocksync、statesync、mempoolなどを実装するコードベースの半分はオープンソースです! このコードベースは、パフォーマンスの高いシステムエンジニアリング作業の宝庫です。これがこの分野を実質的に前進させることを願っています。 ステップバイステップ。
James (May 26 arc)
James (May 26 arc)2025年8月4日
Monad consensus client is now open source (link below). This is the result of thousands of hours of effort by the team at @category_xyz. Enjoy
MonadBFTは、パイプライン[つまりパフォーマンス]とテールフォーク抵抗を初めて統合しました。これだけでも、BFTコンセンサスのフロンティアの進歩です。 現在オープンソース化されたコンセンサス クライアントには、testnet-2 でライブ配信される最初の実装が含まれています。 続きを読む:
Keone Hon 🎟️
Keone Hon 🎟️2025年4月3日
MonadBFTのブレークスルーをまとめる 昨日、Category LabsはMonadBFTの論文を発表し、メインネットでMonadを動かすコンセンサスメカニズムについて説明しました。 MonadBFTは、Pipelined HotStuffがテールフォークに耐性を持つようになった初めての事例であるため、コンセンサス研究における重要な発展です。 テールフォークは、スロットが欠落したために前の提案が破棄され、再マイニングされる場合に発生します。これは、コンセンサスを不安定にするマルチブロックMEV攻撃を開くため、以前のPipelined HotStuffの定式化では深刻な問題です。 この問題を軽減することは、Pipelined HotStuffのすべての利点(頻繁なブロック、低遅延、大規模なバリデーターセット)を提供しながら、最大の欠点を回避するため、非常に大きな問題です。 MonadBFTは、ファイナリティのための大幅なアップグレードも提供します。シングルスロット (500 ms) の投機的ファイナリティと 2 スロット (1s) のハード ファイナリティを特長としています。 「投機的ファイナリティ」とは、「大多数のバリデーターによる曖昧さ(二重署名)の場合にのみ元に戻されるファイナリティ」を意味します。曖昧さはほとんどのブロックチェーンシステムで重大な違反であり、一般的にスラッシュで罰せられます。曖昧さに対するペナルティが大きければ大きいほど、「投機的終局性」を終局性に近づけると考えることができます。 1スロットの投機的ファイナリティは、次のブロックが受信された直後にワールドの更新された状態を自信を持って表示できる高性能アプリケーションにとって大きなロック解除です。 これらの特性により、MonadBFTはコンセンサスにおける大きな進歩となり、非同期実行、楽観的並列実行、MonadDbなど、Monadの他の複合的な改善を補完する価値があります。 この記事の残りの部分では、MonadBFTが解決する問題を説明するために、HotStuffの連続的な改善がどのように積み重なってきたかをまとめる役割を果たします。 要約すると、次のようになります。 1. HotStuffは、大規模なバリデーターセットを持つことができるように、直線的な通信の複雑さを提供しますが、あまり効率的ではありません 2. Pipelined HotStuffは、スロットごとにブロックを提案することで効率と低遅延を実現しますが、テールフォークの問題に悩まされています 3. MonadBFTは、テールフォーク耐性と1スロットの投機的ファイナリティを提供します --- HotStuff:線形通信の複雑さにより、大量のノード数が可能に HotStuffのアルゴリズムは、数回のコミュニケーションの過程で完了し、一般的には、リーダーからバリデーター、そしてリーダーへの直接の「ファンアウト、ファンイン」のコミュニケーションの形をとります。 各ラウンドは、リーダーが他のバリデータに直接メッセージを送信することから始まり、バリデーターはメッセージを受信したことを証明する署名入りのメッセージを送り返します。 バリデータの過半数(2/3)が証明を送り返すと、各ラウンドはリーダーが署名された証明をクォーラム証明書(QC)に集約することで終了します。これは、圧倒的多数が前のメッセージを証明したことを証明する役割を果たします。 HotStuffのアルゴリズムは、このように複数のラウンドの通信を行います。 - リーダーからの最初のメッセージはブロック提案です - 2番目のメッセージは、そのブロック提案のQCです - 3 番目のメッセージは、前の QC に関する QC です (つまり、QC-on-QC) -などなど ファイナリティの前にプロシージャが中断された場合、ブロックはファイナライズに失敗し、破棄されます。そのブロックからのトランザクションは、次のブロックに再含める必要があります。 元のHotStuffプロトコルにはパイプラインがなく、ファイナリティまでに3ラウンドの通信があります。同じバリデーターが各ラウンドでリーダーの役割を果たします。 --- パイプライン化されたホットスタッフ:スロットごとに新しいブロックが効率を高めます パイプライン化とは、洗濯物が2つあるときに、私たち全員が直感的に行うことです。負荷1が全サイクルを終了するのを待ってから負荷2を開始するのではなく、パイプラインでは、負荷2が洗濯機に入るのと同時に負荷1を乾燥機に入れます。 オリジナルのHotStuffは、洗濯をするための素朴なアプローチ(ロード1が完全に完了するまでロード2から開始しない)と考えることができますが、Pipelined HotStuffは、複数の洗濯物をずらして進行させる直感的な動作を行っています。 Pipelined HotStuffでは、各ラウンドで新しいブロックが提案され、新しいブロックが前のブロックのQCを運ぶメッセージの上にピギーバックされるように、提案をずらします。 ブロック提案は、複数のラウンドを通じて最終段階に向かって進みます。 パイプライン化の利点は大きいです。パイプライン化は、ブロック提案がすべてのスロットで行われるため、ブロック提案の密度を高め、スループットを向上させ、ファイナリティまでの時間を短縮します。 ただし、パイプラインには大きな欠点が 1 つあり、例を挙げて説明します。ブロック N、N+1、N+2 のリーダーが Alice、Bob、Charlie であると仮定します。 ボブが彼のスロットを逃した場合、ボブのメッセージには彼の提案とアリスの提案のQCの両方が含まれているため、アリスの提案も無効になります。 これが起こると、チャーリーは、アリスの提案が存在しなかったかのようにブロックを作成するように求められることになります。 この動作を「テールフォーク」と呼び、深さ1のミニ再編成と考えることができます。 テールフォークの可能性は、スロットの見逃しが必ずしも偶然ではないため、重大な影響を及ぼします。 一部のトランザクションを再注文または省略しながら、アリスのブロックを再マイニングすることで価値を引き出す機会がある場合、ボブとチャーリーは共謀してボブが意図的にスロットを逃すように仕向けることができ、チャーリーがアリスのブロックを再マイニングする機会をトリガーできます。 これは、Pipelined HotStuffプロトコルの重大な欠点でした(その一部は今日のメインネットにあります)。 --- MonadBFTはこれを変更します MonadBFTは、アルゴリズムのテールフォーク耐性を高めながらパイプライン化を可能にした最初のプロトコルです。 このテールフォークの抵抗は、ボブがスロットを逃したときのフォールバック手順に由来し、バリデーターはアリスの提案に関する集合的な知識とバリデーターセット内のコンセンサスレベルをつなぎ合わせることができます。 特に、MonadBFTでは、ボブがスロットを逃した場合、フォールバック手順では、バリデーターがアリスのブロックを見たかどうかを示す署名入りの証明で互いに通信します。 圧倒的多数がアリスのブロックを証明した場合、チャーリーはアリスのブロックを再提案することを余儀なくされます。チャーリーが別のブロックを提案したい場合は、アリスのブロックが時間通りに見られないことを証明する大多数のバリデーターからの署名入りの証明を提供する必要があります。 チャーリーがアリスのブロックを再提案する典型的なケースでは、彼は次のラウンドで彼のブロックを提案することができます。 その結果、テールフォーク抵抗と投機的なシングルスロットファイナリティという2つの重要な特性が得られます。テールフォーク耐性についてはすでに説明しましたが、ファイナリティへの影響を理解しましょう。 前回と同様に、ブロック N、N+1、N+2 のリーダーが Alice、Bob、Charlie であると仮定します。 Pipelined 2-Phase HotStuff では、つまり MonadBFT の前 - バリデーター (またはフルノード) として、Charlie のブロック提案を見るまで Alice のブロック提案を確定することはできません。なぜでしょうか。なぜなら、ボブのプロポーズを見てすぐに確定すると、ボブが自分のプロポーズをあなたに転送するだけであなたをいじっている可能性があり、実際には彼はプロポーズを他の人に送るのに失敗し、自分の枠を逃すつもりだからです。 しかし、MonadBFTでは、ボブの提案を見るとすぐに、ボブの提案にはアリスの提案に対するQCが含まれているため、アリスの提案を「推測的に」確定することができます。 ボブが彼の提案をあなたに転送するだけであなたをいじり、彼のスロットを逃すことになったとしても、ネットワークの圧倒的多数がアリスの提案を見て、フォールバック手順に参加すると、再びアリスの提案に署名することを知っています。 アリスのブロックが確定しない唯一の方法は、バリデーターが曖昧にし、アリスのメッセージを見ていないと結論付けた場合です。この欠点は簡単に証明できます - 私たちは彼らからの矛盾するメッセージに署名しました。曖昧さに対するペナルティが相当なものであるならば、そしてそうあるべきなのに、この「思弁的」な最終性は、実際にはそれほど思弁的ではない。 --- テイクアウト MonadBFTは、コンセンサスのための非常にエキサイティングな開発であり、非同期実行、楽観的並列実行、MonadDbなど、Monadの他の複合的な改善を補完する価値があります。 この重要なブレークスルーについて、@MohammadMJalal1さんと@KushalBabelさんに心からおめでとうございます。 MonadBFTは、現在Pipelined 2-Phase HotStuffを実装しているMonad Testnetにまもなく実装されます。 詳細については、次のツイートでリンク先のブログ記事と論文を参照してください。
RaptorCastは、BFTプロパティを維持しながら、帯域幅要件を最小限に抑えながら、巨大なブロックの効率的なブロードキャストを可能にします。 現在もオープンソース化されています。 続きを読む:
Keone Hon 🎟️
Keone Hon 🎟️2025年5月1日
RaptorCastについての@category_xyzからのこのめちゃくちゃ良いブログ記事を読んでください - フォールトトレランスを維持しながら、帯域幅の要件を最小限に抑えながら、巨大なブロックの効率的なブロードキャストを可能にします あなたはたくさん学ぶでしょう!
91.02K