原題：「Time, slots, and the ordering of events in Ethereum Proof-of-Stake》

原題：「

著者: Georgios Konstantopoulos、Mike Neuder、パラダイム

原文の編集: wesely

4 月 2 日、悪意のあるイーサリアム ネットワーク攻撃者が mev-boost-relay の脆弱性を悪用し、MEV 検索者から 2,000 万ドルを盗みました (Flashbot の事後検証を参照)。その後数日間、開発者は 5 つのパッチをリリースすることでバグに対処しました。これが既存のネットワーク遅延とバリデーター ポリシーと相まって、4 月 6 日にイーサリアム ネットワークで短期間の不安定性を引き起こしました。再編成はブロック生成率を低下させ、決済保証を低下させるため、ネットワークの健全性に悪影響を及ぼします。

この記事は、mev-boost とコンセンサスの相互作用を調査し、イーサリアムのプルーフ オブ ステーク メカニズムの微妙な点を明らかにし、今後の可能性のあるいくつかの方法を概説することを目的としています。私たちは、検索者に対する攻撃やネットワークが不安定になった瞬間からインスピレーションを受けてきました。

mev-boostとは何ですか?どうしてそれが重要ですか？

mev-boost は、最大抽出可能価値 (MEV) によるイーサリアム ネットワークへの悪影響を軽減するために、Flashbot とコミュニティによって設計されたプロトコルです。

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

• リレー - 提案者とブロック構築者を結び付ける相互信頼の競売人。

• プロポーザー - イーサリアムの Proof-of-Stake バリデーター。

各ブロックのイベントのおおよそのシーケンスは次のとおりです。

• 各ブロックのイベントのおおよそのシーケンスは次のとおりです。

• ビルダーは、ユーザー、検索者、またはその他の (プライベートまたはパブリック) 注文ストリームからトランザクションを受信することによってブロックを作成します。

• ビルダーはブロックを Relay に送信します。

• Relays はブロックが有効であることを確認し、提案者に支払う金額を計算します。

• リレーは、「ブラインド」ヘッダーと支払い値を現在のスロットの提案者に送信します。

提案者は受け取ったすべての入札を評価し、最高額の支払いに関連付けられたブラインドヘッダーに署名します。

プロポーザーは、この署名付きヘッダーを中継サイトに送り返します。

ブロックは、リレーラーによってローカル ビーコン ノードを使用して公開され、プロポーザーに返されます。報酬は、そのブロック内でトランザクションを実行し、ブロック報酬を実行することによって、構築者と提案者に分配されます。

Relay は、プロポーザーからのブロック スペースの公平な交換と、ビルダーからの MEV 抽出のトランザクション シーケンスを容易にする、相互に信頼できるサード パーティです。 Relay はビルダーを MEV の盗難から保護します。提案者は、MEV を発見した検索者/ビルダーに割り当てるのではなく、ビルダーのトランザクションを複製して MEV を取得します。リレーは、ビルダー ブロックを検証し、プロポーザーに代わってスロットごとに数百のブロックを処理し、プロポーザーの支払いの正確性を確保することによってプロポーザーを保護します。

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

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

攻撃と対応について詳しく説明する前に、イーサリアムのプルーフ オブ ステーク (PoS) メカニズムとそれに関連するフォーク選択ルールを見てみましょう。フォーク選択ルールにより、ネットワークはチェーンヘッドに関して合意に達することができます。合併後のイーサリアム再構築によると:

フォーク選択ルールは、クライアントによって評価される関数で、見たブロックやその他の情報を入力として受け取り、「公式チェーン」が何であるかをクライアントに出力します。選択できる有効なチェーンが複数ある可能性があるため、フォーク選択ルールが必要です (たとえば、同じ親を持つ 2 つの競合するブロックが同時にパブリッシュされる場合)。

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

スロットとサブスロットのサイクル

イーサリアム PoS では、時間がスロットと呼ばれる 12 秒単位に分割されます。 PoS アルゴリズムは、ブロックを提案するためのスロットを取得するバリデーターをランダムに割り当てます。このバリデーターはプロポーザーと呼ばれます。同じスロット内で、他のバリデータには、フォーク選択ルールを適用することによって、ローカル ビュー内のチェーン ヘッドの位置にあるブロックの最新バージョンに投票するタスクが割り当てられます。 12 秒間隔は 3 つのフェーズに分割されており、各フェーズには 4 秒かかります。

スロット内で発生するイベントは次のとおりです。t=0 はスロットの開始を示します。

スロットで最も重要な瞬間は、t=4 の認証期限です。認証バリデーターが認証期限までにブロックを確認できなかった場合、(ブランチ選択ルールに従って) 以前に承認されたチェーンのヘッドに投票します。ブロックが早く提案されるほど、伝播に時間がかかるため、より多くの証人が蓄積されます (認証期限前にブロックを確認したバリデーターが増えるため)。

ネットワークの健全性の観点から見ると、ブロック解放の最適な時間は t=0 です (仕様で指定されているとおり)。ただし、ブロック値は時間の経過とともに単調に増加するため、提案者には、より多くの MEV が蓄積できるようにブロックの公開を遅らせるインセンティブがあります。詳細については、プルーフ オブ ステークの時間制限ゲームとこのディスカッションを参照してください。

歴史的には、次のバリデーターが後続のスロット ブロックを構築する前にブロックを観察している限り、プロポーザーは検証期間の後、またはスロットの終わり近くであってもブロックを公開できます。ここでは、親ブロックが重みを継承し、分岐選択ルールがリーフ ノードで終了するため、ブロックのパブリッシュの遅延による悪影響は発生しません。合理的な行動 (ブロックのリリースの遅延) を誠実な行動 (予定通りの公開) に向けて促進するために、「誠実な再編成」が実装されました。

提案者の昇天と誠実な組織再編

• 校正期限に重要な影響を与える 2 つの新しい概念がコンセンサス クライアントに導入されました。

• Proposer Boost (PR) - 提案者に全証明重量の 40% に相当するフォーク選択「ブースト」を与えることで、リバランス攻撃を最小限に抑えようとします。重要なのは、この強化は 1 つのスロットにのみ持続することです。

正直な再編成 (PR) - プロポーザー拡張を採用し、正直なプロポーザーがそれを使用して認証の重みが 20% 未満のブロックを強制的に再編成できるようにします。これは Lighthouse と Prysm (v 4.0-Capella のリリース以降) に実装されています。この変更は提案者によって行われるローカルな決定であり、バリデーターの動作には影響しないため、オプションです。そのため、すべてのクライアントに同時に展開するための調整された取り組みはなく、特定のハード フォークに結び付けられることもありませんでした。

• 一部の特殊な場合には、正直さの並べ替えが回避されることに注意してください。

• エポック境界ブロック中

• チェーンが完了していない場合

並べ替えられたブロックの前のスロットからチェーン ヘッドが取り出されなかった場合

条件 3 では、正直な再順序付けによってチェーンから 1 つのブロックのみが削除されることが保証され、これが回路ブレーカーとして機能し、ネットワーク遅延が極端に長い期間でもチェーンがブロックを生成し続けることができるようにします。これは、提案者の拡張ブロックが規範的であるとみなされるかどうか確信が持てなくなったため、ネットワークに対する提案者の自信の低下も反映しています。

以下の図は、再編戦略を実行するために誠実な行動がどのように変化するかを示しています。

この場合、ｂ １ が遅れて到着するブロックを表すものとする。遅延により、b1 は n 番目のスロットの耐荷重の 19% しか持ちません。多くの検証者が認証期限までに b1 を確認できなかったため、プルーフ ウェイトの残りの 81% が親ブロック HEAD に割り当てられます。

正直な再構成がない場合、スロット n+1 で提案者は b 1 をチェーンの先頭とみなし、サブブロック b 2 を構築します。プルーフウェイトが 19% しかないにもかかわらず、提案者は b1 を再構成する努力をしていません。スロット n+1 の間、b 2 には提案者ブーストがあり、予定通りに提出すると仮定すると、そのスロットの認証の大部分を蓄積することで標準になります。

正直に組織を再構築すると、状況はまったく異なります。ここで、エポック n+1 の提案者は、b 1 の 19% の認証重みが再構成のしきい値を下回っていることがわかり、b 2 の親として HEAD を持つ新しいブロックを構築し、b 1 の再構成を強制します。 n+1 エポックの認証期限では、誠実なバリデーターが b 2 (プロポーザー拡張からの 40%) と b 1 (19%) の相対的な重みを比較します。すべてのクライアントはプロポーザー拡張を実行するため、b2 がチェーンのヘッドとみなされ、スロット n+1 の証明書が蓄積されます。

アンバンドリング攻撃に対するリレーおよびビーコンノードの修正

4 月 2 日のアンバンドリング攻撃では、提案者は無効な署名ヘッダーをリレーに送信することでリレーの脆弱性を悪用しました。翌日、リレー開発チームとコア開発チームは、繰り返される攻撃のリスクを軽減するために多数のソフトウェア パッチをリリースしました。主な変更点は以下の5つです。

• 1. リレーの変更:

• 既知の悪意のあるプロポーザーがないかデータベースを確認します (超音波リレーによって運用環境でのみ使用され、削除されています)。

• その期間内に完全なブロックが P2P ネットワークに配信されたかどうかを確認します。

ブロックを公開する前に、0 ～ 500 ミリ秒の範囲で均一にランダムな遅延を導入します (すべてのリレーから削除されます)。

• 2. ビーコン チェーン ノードの変更 (リレー ビーコン チェーン ノードにのみ適用):

• ビーコン ブロックをブロードキャストする前に、その有効性を検証してください。

ブロックを公開する前に、ネットワーク上に同等のものがあるかどうかを確認してください。

これらの変更の組み合わせはコンセンサスの不安定性につながりますが、バリデーターの大多数が現在上記の誠実な再編成戦略を使用していることによってさらに悪化します。

意図しない結果

上記の 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 ソフトウェアのバグ報奨金プログラムの数と可視性を高めます。

• シミュレーション ソフトウェアを拡張して、サブスロットのタイミングがネットワークの安定性にどのような影響を与えるかを調査します。これは、校正期限を調整することで再組織をどのように削減できるかを評価するために使用できます。

• リレー上のブロック パブリッシュ パスを最適化して、不要な遅延を削減します。これはすでに研究中です。

• mev-boost をコア プロトコル機能として認識し、それをコンセンサス クライアントである enshrined-PBS (ePBS) に吸収します。 2 スロット ePBS は等価攻撃に対して脆弱であるため、「ヘッドロック」の実装が依然としてオプションです。

• レイテンシや証明期限の問題に基づいて、ハイブ テストや仕様テ​​ストを追加します。

• リレー仕様の追加実装を構築することで、リレー クライアントの多様性を促進します。

等価ペナルティの調整を検討しますが、極端な MEV 機会が存在する場合、32 ETH を完全にカットしても悪意のある行為を阻止できない可能性があることに留意してください。

全体として、私たちは MEV および mev-boost エコシステムを中心とした新たなエネルギーに興奮しています。攻撃と軽減策を分割することで、レイテンシ、mev-boost、およびコンセンサス メカニズムの間の重要な関係を学びました。私たちは、プロトコルが強化され続けることを望んでいます。