Paradigm：MEV-Boost とコンセンサスメカニズムの関係を探る

原文标题：《Time, slots, and the ordering of events in Ethereum Proof-of-Stake》

原文作者：Georgios Konstantopoulos、Mike Neuder，Paradigm

原文编译：wesely，GWEI Research

4月2日、悪意のあるイーサリアムネットワークの参加者がmev-boost-relayの脆弱性を利用して、1人のMEV検索者から2000万ドルを盗みました（Flashbotsの事後分析を参照）。その後数日間、開発者は5つのパッチを公開してこのバグを修正し、既存のネットワーク遅延とバリデータ戦略を組み合わせて、4月6日にイーサリアムネットワークに短期間の不安定期を引き起こしました。再編成はネットワークの健全性にとって不利であり、ブロックの生産性を低下させ、決済保証を減少させます。

この記事は、mev-boostとコンセンサスの相互作用を探求し、イーサリアムのプルーフ・オブ・ステークメカニズムの微妙な点を明らかにし、いくつかの進むべき方向を挙げることを目的としています。私たちは、検索者が攻撃を受けたこととネットワークの一時的な不安定事件からインスパイアを受けました。

mev-boostとは何か？なぜ重要なのか？

mev-boostは、Flashbotsとコミュニティによって設計されたプロトコルで、最大抽出可能価値（MEV）がイーサリアムネットワークに与える悪影響を軽減することを目的としています。

mev-boostには3つの役割があります：

• Relays - 相互に信頼するオークショニアが提案者をブロックビルダーに接続します。
• Builders - 自分自身と提案者のMEVを最大化するためにブロックを構築する複雑な実体。
• Proposers - イーサリアムプルーフ・オブ・ステークのバリデータ。

各ブロックの大まかなイベントシーケンスは次のとおりです：

• Buildersは、ユーザー、検索者、または他の（プライベートまたはパブリック）オーダーフローから取引を受け取ることによってブロックを作成します。
• BuildersはそのブロックをRelayに提出します。
• Relaysはそのブロックが有効であるかどうかを証明し、提案者に支払うべき手数料を計算します。
• Relayは現在のスロットの提案者に「blinded」ヘッダーと支払い価値を送信します。
• 提案者は受け取ったすべての入札を評価し、最高の支払いに関連付けられたblindedヘッダーに署名します。

提案者はこの署名済みヘッダーを中継サイトに送り返します。

そのブロックは中継によってそのローカルビーコーンノードを使用して発行され、提案者に返されます。報酬はそのブロック内での取引とブロック報酬を通じてビルダーと提案者に配分されます。

Relayは、提案者からのブロックスペースの公平な交換と、ビルダーからのMEV抽出のためのトランザクションシーケンシングを促進する相互信頼の第三者です。Relayは、提案者がビルダーのトランザクションをコピーしてMEVを取得するのではなく、発見したsearcher/builderに配分されるMEVからビルダーを保護します。Relayは、提案者がビルダーのブロックの有効性を確認し、提案者が各スロットで数百のブロックを処理し、提案者の支払いの正確性を確保します。

mev-boostは重要なプロトコルインフラストラクチャであり、すべての提案者がビルダーや検索者との信頼関係を築くことなくMEVに民主的にアクセスできるようにし、イーサリアムの長期的な分散化に寄与します。

イーサリアムのフォーク選択ルールとmev-boost

攻撃と応答に深く入る前に、イーサリアムのプルーフ・オブ・ステーク（PoS）メカニズムとその関連するフォーク選択ルールを見てみましょう。フォーク選択ルールは、ネットワークがチェーンヘッドに合意することを可能にします。『合併後のイーサリアム再編成』によれば：

フォーク選択ルールは、クライアントが評価する関数であり、既に見たブロックと他のメッセージを入力として受け取り、クライアントに「正式なチェーン」が何であるかを出力します。フォーク選択ルールが必要なのは、同じ親を持つ2つの競合ブロックが同時に発表されるなど、選択可能な複数の有効なチェーンが存在する可能性があるためです。

フォーク選択ルールに関してあまり知られていない側面の1つは、時間との関係であり、これはブロック生産に重大な影響を与えます。

スロットとサブスロット周期

イーサリアムPoSでは、時間は12秒の増分に分割され、これをスロットと呼びます。PoSアルゴリズムは、バリデータにそのスロットでブロックを提案するようランダムに指定します。このバリデータは提案者と呼ばれます。同じスロット内で、他のバリデータには次のタスクが割り当てられます：フォーク選択ルールを適用して、彼らのローカルビューでチェーンヘッドがある位置に最新のバージョンのブロックを支持するために投票します。12秒の間隔は3つの段階に分けられ、各段階は4秒を消費します。

スロット内で発生するイベントは次のようになります。ここでt=0はスロットの開始を示します。

スロット内で最も重要な瞬間は、t=4の認証締切です。認証バリデータが認証締切前にブロックを見なければ、彼らはチェーン上で以前に受け入れられたヘッダーに投票します（フォーク選択ルールに基づいて）。ブロックが早く提案されるほど、それはより多くの時間を持って広がり、したがってより多くの証人を蓄積します（より多くのバリデータが認証締切前にそれを見ました）。

ネットワークの健全性の観点から、ブロック発行の最適なタイミングはt=0です（規範で指定されています）。しかし、時間の経過とともにブロックの価値が単調に増加するため、提案者はMEVの蓄積を許可するためにブロックの発行を遅らせる動機があります。詳細については、プルーフ・オブ・ステークにおけるタイミングゲームとこの議論を参照してください。

歴史的に、認証期限後やスロットの終了に近い時点で提案者はブロックを発行することができました。次のバリデータがその後のスロットブロックを構築する前にそのブロックを観察すればよいのです。これは親ブロックが重みを継承し、フォーク選択ルールが葉ノードで終了することにより、遅延発表ブロックに悪影響を及ぼさないことを意味します。合理的な行動（ブロック発行の遅延）を誠実な行動（時間通りの発行）に向けて促進するために、「誠実な再編成」が実施されました。

提案者の強化と誠実な再編成

2つの新しい概念がコンセンサスクライアントに導入され、証明締切に重要な影響を与えます。

• 提案者の強化（PR） - 提案者に対して完全な証明重みの40％に相当するフォーク選択「強化」を付与することで再編成バランス攻撃を最小化しようとします。重要なのは、この強化は1つのスロットの間だけ持続することです。
• 誠実な再編成（PR） - 提案者の強化を採用し、誠実な提案者がそれを使用して20％未満の認証重みを持つブロックの再編成を強制することを許可します。これはLighthouseとPrysmで実装されています（v4.0-Capellaのリリース以降）。この変更はオプションであり、提案者が行うローカルな決定によるもので、バリデータの行動には影響を与えません。したがって、すべてのクライアントに同時に導入するための調整努力はなく、特定のハードフォークに関連付けられることもありません。

特定の特殊な状況では誠実な再編成を避けることに注意してください：

• 紀元境界ブロックの期間中
• チェーンが完了していない場合
• チェーンヘッドが再編成ブロックの前のスロットから取得されていない場合

条件3は、誠実な再編成がチェーンから単一のブロックを削除するだけであることを保証し、これはブレーカーとして機能し、チェーンが極端なネットワーク遅延の間にブロックを生成し続けることを可能にします。これはまた、提案者がそのネットワークビューに対する信頼を低下させることを反映しています。なぜなら、彼らはもはや提案者の強化ブロックが規範として見なされるかどうかを確信できないからです。

以下の図は、誠実な行動が再編成戦略を実施する方法を示しています。

この場合、b1を遅れて到着したブロックとします。遅延のため、b1はスロットnの19％の証明重みしか持っていません。残りの81％の証明重みは親ブロックHEADに割り当てられます。なぜなら、多くのバリデータが認証締切前にb1を見なかったからです。

誠実な再編成がなければ、スロットn+1で提案者はb1をチェーンヘッドと見なし、サブブロックb2を構築します。たとえそれが19％の証明重みしか持っていなくても、提案者はb1を再編成しようとはしません。スロットn+1の期間中、b2は提案者の強化機能を持ち、時間通りに配信されれば、そのスロットの大部分の認証を蓄積し、規範となります。

誠実に再編成することで、状況は大きく異なります。今、スロットn+1の提案者はb1の19％の認証重みが再編成閾値を下回っていることを発見し、したがって彼らはHEADをb2の親として構築し、b1を強制的に再編成します。スロットn+1の認証締切に達すると、誠実なバリデータはb2（提案者の強化からの40％）とb1（19％）の相対重みを比較します。すべてのクライアントが提案者の強化を実行するため、b2はチェーンヘッドと見なされ、スロットn+1の認証を蓄積します。

アンバインド攻撃に対する中継とビーコーンノードの修正

4月2日のアンバインド攻撃では、提案者が中継の脆弱性を利用し、中継に無効な署名ヘッダーを送信することで攻撃を行いました。その後数日間、中継とコア開発チームは、再発攻撃のリスクを軽減するために多くのソフトウェアパッチを公開しました。5つの主要な変更は次のとおりです：

1. Relayの変更：

• 知られている悪意のある提案者がデータベースに存在するかどうかを確認します（これは超音波中継によって生産環境で使用され、削除されました）。
• この期間内に完全なブロックがP2Pネットワークに渡されたかどうかを確認します。
• ブロックを発行する前に、0-500msの範囲内で統一されたランダム遅延を導入します（すべてのリレーから削除）。

1. ビーコーンチェーンノードの変更（リレーのビーコーンチェーンノードのみに適用）：

• ビーコーンブロックをブロードキャストする前にその有効性を検証します。
• ブロックを発行する前に、ネットワーク上に同等物が存在するかどうかを確認します。

これらの変更の組み合わせは、コンセンサスの不安定性を引き起こし、現在ほとんどのバリデータが上記の誠実な再編成戦略を使用しているため、この状況をさらに悪化させました。

予期しない結果

上記の5つの変更はそれぞれ、リレーのブロック発行のホットパス上の遅延時間を増加させ、リレーのブロックが証明締切を超えてブロードキャストされる可能性を高めました。下の図は、これら5つのチェックの順序と、導入された遅延がブロック発行を証明締切を超える原因となる方法を示しています。

これらのチェックを実施する前は、署名ヘッダーの到着時間がt=0（例えばt=3）を大幅に超えても問題は発生しませんでした。リレーのオーバーヘッドは非常に低いため、t=4前にブロックが発行されます。

しかし、これら5つのパッチによって導入された遅延時間が増加するにつれて、リレーは遅延ブロードキャストの一因となる可能性があります。以下の仮定の下でのブロック発行を見てみましょう。

リレーはt=3で提案者から署名済みのヘッダーを受け取りました。t=4に達すると、リレーはまだチェックを実行しているため、ブロードキャストは証明締切の後に発生します。この場合、提案者が署名済みヘッダーを遅れて送信し、リレーがいくつかの追加の遅延を導入した結果、証明締切を逃すことになります。誠実な再編成がなければ、これらのブロックはチェーンに入る可能性が高いです。図2で見たように、その後のスロットの誠実な提案者は、時間が遅すぎて拒否されたブロックを意図的に再編成しません。しかし、誠実な再編成がある場合、証明締切を逃すことは、そのブロックが次の提案者によって再編成されることを意味します。

したがって、攻撃後数日間で、フォークブロックの数が急増しました。

Metrikaの2週間のデータは、最悪のシナリオでは、1時間内に13のブロック（4.3％）が再編成され、通常の約5倍であることを示しています。リレーがさまざまな変更を導入するにつれて、フォークブロックの数の急増が明らかになりました。リレーオペレーターとコア開発者がコミュニティの大きな努力を行い、影響を理解した後、多くの変更が撤回され、ネットワークは健康な状態に戻りました。

今日まで、最も有用な変更はビーコーンノードブロックの検証とブロードキャスト前の同等物チェックです。悪意のある提案者は、無効なヘッダーをリレーに送信し、リレーのビーコーンノードが発行前に同等のブロックを見ないようにすることで攻撃を実行できなくなりました。それでも、このリレーは、Mev-boostとePBSの仲介攻撃が提示するより一般的な同等攻撃の影響を受けやすいです。

では、私たちは何をすべきか？

この記事では、mev-boostの仕組みとそれがイーサリアムのコンセンサスにとって重要である理由を強調しました。また、時間に関連するイーサリアムのフォーク選択ルールのあまり知られていない側面についても詳しく説明しました。分割攻撃と開発者の応答をケーススタディとして使用することで、フォーク選択ルールにおける時間に関連する側面の潜在的な脆弱性とそれがネットワークの安定性に与える影響を強調しました。

これを考慮して、研究界は「受け入れ可能な」再編成の数を評価し、一般的な同等攻撃がもたらすリスクを考慮して、緩和策を実施する必要があるかどうかを判断するべきです。

さらに、現在、複数の将来の方向性が積極的に探求されています：

• mev-boostを同等攻撃から保護するために「headlock」を実装する。これにはコンセンサスクライアントソフトウェアの変更が必要であり、証明締切を延長するための規範変更が必要になる可能性があります。
• mev-boostソフトウェアの脆弱性報奨金プログラムの数と可視性を増加させる。
• サブスロットのタイミングがネットワークの安定性にどのように影響するかを探るためにシミュレーションソフトウェアを拡張する。これを使用して、証明締切を調整することで再編成を減少させる方法を評価できます。
• 不要な遅延を減らすためにリレー上のブロック発行パスを最適化する。これはすでに研究中です。
• mev-boostがコアプロトコル機能であることを認識し、それをコンセンサスクライアントに組み込む、すなわち、enshrined-PBS（ePBS）。2つのスロットのePBSは同等攻撃の影響を受けやすいため、「headlock」を実装することは依然として選択肢です。
• 遅延と証明締切の問題に基づくより多くのハイブや/または規範テストを増加させる。
• リレーの仕様の他の実装を構築することでリレークライアントの多様性を促進する。
• 同等罰則を調整することを検討するが、極端なMEV機会が存在する場合、32 ETHを完全に削減しても悪意のある行動を防ぐことができないことを忘れないでください。

全体として、私たちはMEVとmev-boostエコシステムの周りで再び活気づいているエネルギーに興奮しています。分割攻撃と緩和策を通じて、私たちは遅延、mev-boost、コンセンサスメカニズムの間の重要な関係を理解しました。私たちは、プロトコルが持続的に強化されることを期待しています。

Bert Miller、Danny Ryan、Alex Stokes、Francesco D'Amato、Michael Sproul、Terence Tsao、Frankie、Joachim Neu、Chris Hager、Matt Garnett、Charlie Noyes、samczsunのこの記事へのフィードバックに感謝します。