著者: ゲオルギオス・コンスタントプロス、マイク・ニューダーコンピレーション：Kxp、BlockBeats＃＃＃ 序章4 月 2 日、悪意のあるイーサリアム ネットワーク攻撃者が MEV-Boost リレーの脆弱性を悪用し、MEV シーカーから 2,000 万ドルを盗みました (Flashbots レポートを参照)。その後数日間にわたって、開発者は 5 つのパッチをリリースしてこの脆弱性に対処しました。これらのパッチは、ネットワークの遅延や検証ポリシーと相まって、4 月 6 日にイーサリアム ネットワークに短期間の変動を引き起こしました。ブロックを再編成すると、ブロックの生成速度が低下し、決済の保証が低下するため、ネットワークの健全性に悪影響を与える可能性があります。この投稿では、シーカーが攻撃を受け、ネットワークが一時的に不安定になっている状況で、MEV-Boost とコンセンサスの相互作用を調査し、イーサリアムのプルーフ オブ ステーク メカニズムの微妙な点を分析し、今後の可能性のあるいくつかの方法を列挙します。### MEV-Boost とそれが重要な理由MEV-Boost は、イーサリアム ネットワークに対する最大抽出可能値 (MEV) の悪影響を軽減するために、Flashbot とコミュニティによって設計されたプロトコルです。MEV-Boost には 3 人のアクターがいます。1.リレー - ブロックプロデューサーとブロックビルダーを結びつける、お互いを信頼する競売人2. コンストラクター - 自分自身とブロック作成者の MEV を最大化するためにブロックを構築する複雑なエンティティ3. ブロックプロデューサー - イーサリアムのプルーフ・オブ・ステーク検証者各ブロックのイベントのおおよそのシーケンスは次のとおりです。1. ビルダーは、ユーザー、検索者、またはその他の (プライベートまたはパブリック) 注文ストリームからトランザクションを受信してブロックを作成します。2. ビルダーはブロックをリレーに送信します3. リレーはブロックの正当性を検証し、ブロック作成者に支払う金額を計算します。4. リレーラーは、空白のタイトルと支払い値を現在のスロットのブロックプロデューサーに送信します。5. ブロックプロデューサーは受け取ったすべての入札を評価し、最高額の支払いに関連付けられた空白のヘッダーに署名します。6. ブロックプロデューサーは、この署名付きヘッダーをリレーに送り返します。7. リレーは、ネイティブ ビーコン ノードを使用してブロックを公開し、ブロック提供者に返します。報酬は、ブロック内のトランザクションおよびブロック報酬を通じて構築者と提案者に分配されます。リレーは、ブロックプロデューサーによるブロックスペースの公正な交換と、MEV 抽出のためのビルダーによるトランザクション順序付けを促進する、信頼できるサードパーティです。リレーは、ビルダーを MEV の盗難から保護することでビルダーを保護し、ブロックプロデューサーがビルダーのトランザクションをコピーして、MEV を見つけたシーカー/ビルダーに配布せずに MEV を持ち去ることを防ぎます。リレーは、ブロックの有効性を確認し、ブロック プロデューサーに代わってスロットごとに数百のブロックを処理し、ブロック プロデューサーの支払いの正確性を保証することで、ブロック プロデューサーを保護します。MEV-Boost は重要なプロトコル インフラストラクチャであり、すべてのブロック プロデューサーがビルダーやサーチャーとの信頼関係を必要とせずに民主的に MEV にアクセスできるようになり、イーサリアムの長期的な分散化に貢献します。### イーサリアムのフォーク選択ルールと MEV-Boost攻撃と対応について説明する前に、イーサリアムのプルーフ オブ ステーク メカニズムと関連するフォーク選択ルールを見てみましょう。記事「イーサリアムの合併後の再編成」で定義されているように、フォーク選択ルールにより、ネットワークはチェーン ヘッドに関する合意に達することができます。「フォーク選択ルールは、クライアントによって評価される関数であり、表示されたブロックおよびその他の情報を入力として受け取り、「標準チェーン」をクライアントに出力します。選択できる有効なチェーンが複数ある可能性があるため、フォーク選択ルールは重要です (たとえば、同じ親ブロックを持つ 2 つの競合するブロックが同時にパブリッシュされる場合)。 」フォーク選択ルールも時間に依存するため、ブロック生成に大きな影響を与えます。#### スロットとサブスロットのサイクルイーサリアムのプルーフ オブ ステーク メカニズムでは、時間が 12 秒ごとのスロットに分割されます。プルーフ・オブ・ステーク アルゴリズムは、そのスロット内のブロックを提案するためのライセンスをバリデーターにランダムに割り当てます。このバリデーターはブロックプロデューサーと呼ばれます。同じスロット内で、他のバリデータには、ローカル ビューに従ってフォーク選択ルールを適用するチェーンヘッドを検証 (投票) するタスクが割り当てられます。この 12 秒のスロットは 3 つのフェーズに分割されており、各フェーズのコストは 4 秒です。スロット内で発生するイベントは次のとおりです。t=0 はスロットの始まりを示します。!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/e38ba3da350c386059383272cb713cc3.)スロット中、最も重要な瞬間は t=4 の認証期限です。認証バリデーターが認証期限までにブロックを確認できなかった場合、以前に受け入れられたチェーンの先頭に投票します (フォーク選択ルールに従って)。ブロックが早く提案されるほど、そのブロックが伝播されるまでの時間が長くなり、より多くの承認が蓄積されます (承認期限前にブロックを確認するバリデーターが増えるため)。ネットワークの健全性の観点から見ると、ブロック解放の最適な時間は t=0 です (仕様に従って)。ただし、ブロックの値は時間の経過とともに単調に増加するため、ブロックの作成者には、より多くの MEV を蓄積できるようにブロックのリリースを遅らせるインセンティブがあります。詳細については、Proof-of-Stake のタイミング ゲームとこのディスカッションを参照してください。以前は、次のバリデーターが後続のスロットのブロックを確立する前にブロックを監視していれば、ブロック プロデューサーは認証期限後 (スロットの終わり近くでも) ブロックを公開できました。これは、子ブロックが親ブロックの重みを継承し、フォーク選択ルールがリーフ ノードで終了するためです。したがって、ブロックのリリースを延期しても副作用はありません。合理的な行動 (ブロックのリリースの延期) を誠実な行動 (予定通りの公開) に移行するために、「正直な再編成」が実装されました。#### ブロックプロデューサーの報酬メカニズムと正直な再編成認証期限に重大な影響を与える 2 つの新しい概念がコンセンサス クライアントに導入されました。1. ブロック プロデューサーの報酬メカニズム - ブロック プロデューサーに全認証重みの 40% に相当するフォーク選択の「報酬」を与えることで、リバランス攻撃を最小限に抑えることを目的としています。重要なのは、この報酬はスロット全体でのみ持続することです。2. 正直な再編成 - ブロック プロデューサーの高速化を利用して、正直なブロック プロデューサーが認証の重みが 20% 未満のブロックの再編成を強制できるようにします。これはすでに Lighthouse と Prysm (v4.0 - Capella リリース以降) に実装されています。この変更はブロックプロデューサーによって決定されるものであり、認証バリデーターの動作には影響しないため、オプションです。したがって、すべてのクライアントに同時に適用することはなく、特定のハード フォークに関連付けられることもありません。次のような特殊な場合には、正直な再編成が回避されることに注意してください。1. エポック境界ブロック中2. チェーンがファイナライズされていない場合3. チェーンの先頭が再編成前のスロットの先頭ではない場合ケース 3 では、正直な再編成によってチェーンから 1 つのブロックのみが削除されることが保証され、これがサーキット ブレーカーとして機能し、ネットワーク レイテンシが極端に長い間もチェーンがブロックを生成し続けることができます。また、提案者が提案した拡張ブロックが標準とみなされるかどうか確信が持てないため、ネットワークの認識にあまり自信がないことも反映しています。以下の図は、再構築戦略を実行するために誠実な行動をどのように変えることができるかを示しています。!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/0bc90dde27603fd264d41dc184ed18a9.)この場合、ｂ１は後期ブロックを表すものとする。遅延により、b1 は n 番目のスロットの耐荷重の 19% しか持ちません。多くの証明者が証明期限までに b1 を確認できなかったため、証明重みの残りの 81% が親ブロック HEAD に割り当てられます。正直な再構成がない場合、スロット n+1 の提案者は b1 をチェーンの先頭とみなし、サブブロック b2 を構築します。提案者は、b1 のプルーフウェイトが 19% しかないにもかかわらず、b1 を再構成する努力をしませんでした。スロット n+1 では、b2 に提案者の強化があり、予定どおりに配信されると仮定すると、そのスロットの証明の大部分を蓄積することで b2 が標準になります。Honest Reorganization では、状況は大きく異なります。ここで、スロット n+1 の提案者は、b1 のプルーフ ウェイトの 19% が再構成のしきい値を下回っていることに気づき、HEAD を親としてブロックを構築し、b1 に再構成を強制します。スロット n+1 の証明期限に達すると、正直な証明者は b1 (19%) と b2 (提案者のブーストからの 40%) の相対的な重みを比較します。すべてのクライアントはプロポーザー拡張機能を実装しているため、b2 がチェーンの先頭とみなされ、スロット n+1 の証明が蓄積されます。#### アンバンドリング攻撃に対するリレーおよびビーコン ノードの修正4 月 2 日のアンバンドリング攻撃では、提案者はリレーの脆弱性を悪用し、無効な署名ヘッダーをリレーに送信しました。その後数日間、リレー チームとコア開発チームは、繰り返される攻撃のリスクを軽減するために多数のソフトウェア パッチをリリースしました。主な変更点は以下の5つです。リレーの変更: 既知の悪意のあるプロポーザーがないかデータベースを確認します (実稼働環境では Ultrasonic Relay のみで使用され、削除されています)。リレーが完全なブロックを P2P ネットワークのスロットに配信したかどうかを確認します。ブロックが発行される (すべてのリレーから削除される) 前に、0 ～ 500 ミリ秒の範囲で均一なランダムな遅延が発生します。ビーコン ノードの変更 (リレー ビーコン ノードのみ): ブロードキャスト前にビーコン ブロックを検証します。ブロックを公開する前に、ネットワークに誤った確認がないか確認してください。これらの変更の組み合わせによりコンセンサスが不安定になり、バリデーターの大多数が現在上記の誠実な再編成戦略を使用しているという事実によって問題が悪化しました。＃＃＃＃ 意図しない結果上記の 5 つの変更はすべて、リレー ブロック発行のホット パスに遅延をもたらし、確認期限後にリレー ブロックがブロードキャストされる可能性が高くなります。以下の図は、これら 5 つのチェックのシーケンスと、遅延が発生してブロック パブリケーションがどのように確認期限を超過するかを示しています。t = 0 のラグ (例: t = 3) を持つ多数の署名付きヘッダーは、通常、これらのチェックが実装されるまで問題を引き起こしません。リレーのオーバーヘッドは非常に低いため、確認期限を待たずに t = 4 より前にブロックを公開します。ただし、これら 5 つのパッチの導入が遅れたため、ブロードキャストの遅れの原因の一部は中継局にある可能性があります。以下の仮想のブロック パブリッシュ プロセスを見てみましょう。!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/75c78cd64c084e204f322a05865b1339。)リレーは、t = 3 でブロックプロデューサーから署名付きヘッダーを受信します。 t = 4 の時点では、リレーはまだチェックを実行しているため、ブロードキャストは確認期限の後に行われます。この場合、ブロックプロデューサーによって送信された遅延署名付きヘッダーと、リレーによって導入された追加の遅延の組み合わせにより、確認期限前のブロードキャストが失敗しました。誠実な再編が行われていなかったら、これらのブロックはおそらくチェーン上に載っていたでしょう。図 2 に示すように、次のスロットの正直なブロック プロデューサーは、これらのブロックが遅れているため、意図的に再編成することはありません。ただし、確認期限を過ぎた場合、ブロックは次のブロックプロデューサーによって再編成されます。その結果、攻撃後の数日間でフォークされたブロックの数が劇的に増加しました。!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/43719fc8ff5a07765c2275deb1e5afff.)Metrika の 2 週間のデータによると、最悪のシナリオでは 1 時間で 13 ブロック (4.3%) が再編成される可能性があり、これは通常の速度の約 5 倍です。リレーラーがさまざまな変更を展開するにつれて、フォークされたブロックの数が劇的に増加したことが明らかになりました。リレー オペレーターとコア開発者によるコミュニティの多大な努力のおかげで、影響が判明すると、多くの変更がロールバックされ、ネットワークは健全な状態に復元されました。現在のところ、最も有用な変更は、発行前のビーコン ノード ブロックの検証と拒否チェックです。悪意のあるブロックプロデューサーは、無効なヘッダーをリレーに送信し、拒否されたブロックを公開する前にリレービーコンノードが認識しないようにすることで、攻撃を実行できなくなります。それにもかかわらず、リレーは依然として、MEV-Boost と ePBS で提案されているより一般的な攻撃拒否に直面しています。### 次のアクションこの投稿では、MEV-Boost がどのように機能するか、そしてそれがイーサリアムのコンセンサスにとってどれほど重要であるかを強調します。また、タイミング関連のイーサリアムフォーク選択ルールのあまり知られていない側面の詳細な分析も提供します。ケーススタディとして「アンバンドリング」攻撃と開発者の対応を使用して、フォーク選択ルールのタイミング関連の側面の潜在的な脆弱性とネットワークの安定性に対するその影響を強調します。これを念頭に置いて、研究コミュニティは、拒否攻撃のより一般的な露出を考慮して、再組織化の「許容可能な」数がどれくらいかを評価し、緩和策を実装する必要があるかどうかを決定する必要があります。さらに、現在、いくつかの将来の方向性が積極的に検討されています。1. MEV-boost を等価性エラー攻撃から保護するヘッドロック メカニズムを実装します。これには、コンセンサス クライアント ソフトウェアへの変更も必要となり、場合によっては校正刷りの提出期限を延長するための仕様変更も必要になります。2. MEV-Boost ソフトウェアのバグ報奨金プログラムの数と配布を増やします。3. シミュレーション ソフトウェアを拡張して、サブスロットのタイミングがネットワークの安定性にどのような影響を与えるかを調査します。これを使用して、再編成を削減するためにプルーフの提出期限を調整する方法を評価できます。4. リレー上のブロック解放パスを最適化して、不要な遅延を削減します。これはすでに検討されています。5. MEV ブーストをコア プロトコル機能として認識し、それをコンセンサス クライアント、つまり「enshrined-PBS (ePBS)」に組み込みます。 2 スロット ePBS は明らかな攻撃に対して脆弱であるため、「ヘッドロック メカニズム」の実装が依然としてオプションです。6. レイテンシや認証期限に関する問題に関するハイブ テストや仕様テストを追加する。7. リレー仕様の追加実装を構築することで、リレー クライアントの多様性を促進します。8. 明らかな攻撃に対してペナルティを調整することを検討しますが、極度の MEV 機会が存在する場合には、32 ETH 全額のペナルティであっても悪意のある行為を阻止できない可能性があることに留意してください。9. サブスロットのタイミングを再考し、ブロック伝播フェーズの調整を検討します (たとえば、認証期限を t=4 から t=6 に調整するなど)。全体として、私たちは MEV と mev-boost エコシステムの復活に興奮しています。私たちは、アンバンドリング攻撃と緩和策を通じて、レイテンシー、MEV ブースト、コンセンサス メカニズムの間の重要な関係について学びました。私たちは、プロトコルがこれに対処できるよう強化され続けることを望んでいます。
MEV-Boostの動作原理とイーサリアムフォークの選択ルールの詳細な説明
著者: ゲオルギオス・コンスタントプロス、マイク・ニューダー
コンピレーション：Kxp、BlockBeats
＃＃＃ 序章
4 月 2 日、悪意のあるイーサリアム ネットワーク攻撃者が MEV-Boost リレーの脆弱性を悪用し、MEV シーカーから 2,000 万ドルを盗みました (Flashbots レポートを参照)。その後数日間にわたって、開発者は 5 つのパッチをリリースしてこの脆弱性に対処しました。これらのパッチは、ネットワークの遅延や検証ポリシーと相まって、4 月 6 日にイーサリアム ネットワークに短期間の変動を引き起こしました。ブロックを再編成すると、ブロックの生成速度が低下し、決済の保証が低下するため、ネットワークの健全性に悪影響を与える可能性があります。
この投稿では、シーカーが攻撃を受け、ネットワークが一時的に不安定になっている状況で、MEV-Boost とコンセンサスの相互作用を調査し、イーサリアムのプルーフ オブ ステーク メカニズムの微妙な点を分析し、今後の可能性のあるいくつかの方法を列挙します。
MEV-Boost とそれが重要な理由
MEV-Boost は、イーサリアム ネットワークに対する最大抽出可能値 (MEV) の悪影響を軽減するために、Flashbot とコミュニティによって設計されたプロトコルです。
MEV-Boost には 3 人のアクターがいます。
1.リレー - ブロックプロデューサーとブロックビルダーを結びつける、お互いを信頼する競売人
コンストラクター - 自分自身とブロック作成者の MEV を最大化するためにブロックを構築する複雑なエンティティ
ブロックプロデューサー - イーサリアムのプルーフ・オブ・ステーク検証者
各ブロックのイベントのおおよそのシーケンスは次のとおりです。
ビルダーは、ユーザー、検索者、またはその他の (プライベートまたはパブリック) 注文ストリームからトランザクションを受信してブロックを作成します。
ビルダーはブロックをリレーに送信します
リレーはブロックの正当性を検証し、ブロック作成者に支払う金額を計算します。
リレーラーは、空白のタイトルと支払い値を現在のスロットのブロックプロデューサーに送信します。
ブロックプロデューサーは受け取ったすべての入札を評価し、最高額の支払いに関連付けられた空白のヘッダーに署名します。
ブロックプロデューサーは、この署名付きヘッダーをリレーに送り返します。
リレーは、ネイティブ ビーコン ノードを使用してブロックを公開し、ブロック提供者に返します。報酬は、ブロック内のトランザクションおよびブロック報酬を通じて構築者と提案者に分配されます。
リレーは、ブロックプロデューサーによるブロックスペースの公正な交換と、MEV 抽出のためのビルダーによるトランザクション順序付けを促進する、信頼できるサードパーティです。リレーは、ビルダーを MEV の盗難から保護することでビルダーを保護し、ブロックプロデューサーがビルダーのトランザクションをコピーして、MEV を見つけたシーカー/ビルダーに配布せずに MEV を持ち去ることを防ぎます。リレーは、ブロックの有効性を確認し、ブロック プロデューサーに代わってスロットごとに数百のブロックを処理し、ブロック プロデューサーの支払いの正確性を保証することで、ブロック プロデューサーを保護します。
MEV-Boost は重要なプロトコル インフラストラクチャであり、すべてのブロック プロデューサーがビルダーやサーチャーとの信頼関係を必要とせずに民主的に MEV にアクセスできるようになり、イーサリアムの長期的な分散化に貢献します。
イーサリアムのフォーク選択ルールと MEV-Boost
攻撃と対応について説明する前に、イーサリアムのプルーフ オブ ステーク メカニズムと関連するフォーク選択ルールを見てみましょう。記事「イーサリアムの合併後の再編成」で定義されているように、フォーク選択ルールにより、ネットワークはチェーン ヘッドに関する合意に達することができます。
「フォーク選択ルールは、クライアントによって評価される関数であり、表示されたブロックおよびその他の情報を入力として受け取り、「標準チェーン」をクライアントに出力します。選択できる有効なチェーンが複数ある可能性があるため、フォーク選択ルールは重要です (たとえば、同じ親ブロックを持つ 2 つの競合するブロックが同時にパブリッシュされる場合)。 」
フォーク選択ルールも時間に依存するため、ブロック生成に大きな影響を与えます。
スロットとサブスロットのサイクル
イーサリアムのプルーフ オブ ステーク メカニズムでは、時間が 12 秒ごとのスロットに分割されます。プルーフ・オブ・ステーク アルゴリズムは、そのスロット内のブロックを提案するためのライセンスをバリデーターにランダムに割り当てます。このバリデーターはブロックプロデューサーと呼ばれます。同じスロット内で、他のバリデータには、ローカル ビューに従ってフォーク選択ルールを適用するチェーンヘッドを検証 (投票) するタスクが割り当てられます。この 12 秒のスロットは 3 つのフェーズに分割されており、各フェーズのコストは 4 秒です。
スロット内で発生するイベントは次のとおりです。t=0 はスロットの始まりを示します。
!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/e38ba3da350c386059383272cb713cc3.)
スロット中、最も重要な瞬間は t=4 の認証期限です。認証バリデーターが認証期限までにブロックを確認できなかった場合、以前に受け入れられたチェーンの先頭に投票します (フォーク選択ルールに従って)。ブロックが早く提案されるほど、そのブロックが伝播されるまでの時間が長くなり、より多くの承認が蓄積されます (承認期限前にブロックを確認するバリデーターが増えるため)。
ネットワークの健全性の観点から見ると、ブロック解放の最適な時間は t=0 です (仕様に従って)。ただし、ブロックの値は時間の経過とともに単調に増加するため、ブロックの作成者には、より多くの MEV を蓄積できるようにブロックのリリースを遅らせるインセンティブがあります。詳細については、Proof-of-Stake のタイミング ゲームとこのディスカッションを参照してください。
以前は、次のバリデーターが後続のスロットのブロックを確立する前にブロックを監視していれば、ブロック プロデューサーは認証期限後 (スロットの終わり近くでも) ブロックを公開できました。これは、子ブロックが親ブロックの重みを継承し、フォーク選択ルールがリーフ ノードで終了するためです。したがって、ブロックのリリースを延期しても副作用はありません。合理的な行動 (ブロックのリリースの延期) を誠実な行動 (予定通りの公開) に移行するために、「正直な再編成」が実装されました。
ブロックプロデューサーの報酬メカニズムと正直な再編成
認証期限に重大な影響を与える 2 つの新しい概念がコンセンサス クライアントに導入されました。
ブロック プロデューサーの報酬メカニズム - ブロック プロデューサーに全認証重みの 40% に相当するフォーク選択の「報酬」を与えることで、リバランス攻撃を最小限に抑えることを目的としています。重要なのは、この報酬はスロット全体でのみ持続することです。
正直な再編成 - ブロック プロデューサーの高速化を利用して、正直なブロック プロデューサーが認証の重みが 20% 未満のブロックの再編成を強制できるようにします。これはすでに Lighthouse と Prysm (v4.0 - Capella リリース以降) に実装されています。この変更はブロックプロデューサーによって決定されるものであり、認証バリデーターの動作には影響しないため、オプションです。したがって、すべてのクライアントに同時に適用することはなく、特定のハード フォークに関連付けられることもありません。
次のような特殊な場合には、正直な再編成が回避されることに注意してください。
エポック境界ブロック中
チェーンがファイナライズされていない場合
チェーンの先頭が再編成前のスロットの先頭ではない場合
ケース 3 では、正直な再編成によってチェーンから 1 つのブロックのみが削除されることが保証され、これがサーキット ブレーカーとして機能し、ネットワーク レイテンシが極端に長い間もチェーンがブロックを生成し続けることができます。また、提案者が提案した拡張ブロックが標準とみなされるかどうか確信が持てないため、ネットワークの認識にあまり自信がないことも反映しています。
以下の図は、再構築戦略を実行するために誠実な行動をどのように変えることができるかを示しています。
!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/0bc90dde27603fd264d41dc184ed18a9.)
この場合、ｂ１は後期ブロックを表すものとする。遅延により、b1 は n 番目のスロットの耐荷重の 19% しか持ちません。多くの証明者が証明期限までに b1 を確認できなかったため、証明重みの残りの 81% が親ブロック HEAD に割り当てられます。
正直な再構成がない場合、スロット n+1 の提案者は b1 をチェーンの先頭とみなし、サブブロック b2 を構築します。提案者は、b1 のプルーフウェイトが 19% しかないにもかかわらず、b1 を再構成する努力をしませんでした。スロット n+1 では、b2 に提案者の強化があり、予定どおりに配信されると仮定すると、そのスロットの証明の大部分を蓄積することで b2 が標準になります。
Honest Reorganization では、状況は大きく異なります。ここで、スロット n+1 の提案者は、b1 のプルーフ ウェイトの 19% が再構成のしきい値を下回っていることに気づき、HEAD を親としてブロックを構築し、b1 に再構成を強制します。スロット n+1 の証明期限に達すると、正直な証明者は b1 (19%) と b2 (提案者のブーストからの 40%) の相対的な重みを比較します。すべてのクライアントはプロポーザー拡張機能を実装しているため、b2 がチェーンの先頭とみなされ、スロット n+1 の証明が蓄積されます。
アンバンドリング攻撃に対するリレーおよびビーコン ノードの修正
4 月 2 日のアンバンドリング攻撃では、提案者はリレーの脆弱性を悪用し、無効な署名ヘッダーをリレーに送信しました。その後数日間、リレー チームとコア開発チームは、繰り返される攻撃のリスクを軽減するために多数のソフトウェア パッチをリリースしました。主な変更点は以下の5つです。
リレーの変更: 既知の悪意のあるプロポーザーがないかデータベースを確認します (実稼働環境では Ultrasonic Relay のみで使用され、削除されています)。リレーが完全なブロックを P2P ネットワークのスロットに配信したかどうかを確認します。ブロックが発行される (すべてのリレーから削除される) 前に、0 ～ 500 ミリ秒の範囲で均一なランダムな遅延が発生します。
ビーコン ノードの変更 (リレー ビーコン ノードのみ): ブロードキャスト前にビーコン ブロックを検証します。ブロックを公開する前に、ネットワークに誤った確認がないか確認してください。これらの変更の組み合わせによりコンセンサスが不安定になり、バリデーターの大多数が現在上記の誠実な再編成戦略を使用しているという事実によって問題が悪化しました。
＃＃＃＃ 意図しない結果
上記の 5 つの変更はすべて、リレー ブロック発行のホット パスに遅延をもたらし、確認期限後にリレー ブロックがブロードキャストされる可能性が高くなります。以下の図は、これら 5 つのチェックのシーケンスと、遅延が発生してブロック パブリケーションがどのように確認期限を超過するかを示しています。
t = 0 のラグ (例: t = 3) を持つ多数の署名付きヘッダーは、通常、これらのチェックが実装されるまで問題を引き起こしません。リレーのオーバーヘッドは非常に低いため、確認期限を待たずに t = 4 より前にブロックを公開します。
ただし、これら 5 つのパッチの導入が遅れたため、ブロードキャストの遅れの原因の一部は中継局にある可能性があります。以下の仮想のブロック パブリッシュ プロセスを見てみましょう。
!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/75c78cd64c084e204f322a05865b1339。)
リレーは、t = 3 でブロックプロデューサーから署名付きヘッダーを受信します。 t = 4 の時点では、リレーはまだチェックを実行しているため、ブロードキャストは確認期限の後に行われます。この場合、ブロックプロデューサーによって送信された遅延署名付きヘッダーと、リレーによって導入された追加の遅延の組み合わせにより、確認期限前のブロードキャストが失敗しました。誠実な再編が行われていなかったら、これらのブロックはおそらくチェーン上に載っていたでしょう。図 2 に示すように、次のスロットの正直なブロック プロデューサーは、これらのブロックが遅れているため、意図的に再編成することはありません。ただし、確認期限を過ぎた場合、ブロックは次のブロックプロデューサーによって再編成されます。
その結果、攻撃後の数日間でフォークされたブロックの数が劇的に増加しました。
!【MEV-Boostの動作原理とイーサリアムフォーク選択ルールの詳細説明】(https://img.gateio.im/social/https://cdn-img.panewslab.com//panews/2022/5/13/)画像/43719fc8ff5a07765c2275deb1e5afff.)
Metrika の 2 週間のデータによると、最悪のシナリオでは 1 時間で 13 ブロック (4.3%) が再編成される可能性があり、これは通常の速度の約 5 倍です。リレーラーがさまざまな変更を展開するにつれて、フォークされたブロックの数が劇的に増加したことが明らかになりました。リレー オペレーターとコア開発者によるコミュニティの多大な努力のおかげで、影響が判明すると、多くの変更がロールバックされ、ネットワークは健全な状態に復元されました。
現在のところ、最も有用な変更は、発行前のビーコン ノード ブロックの検証と拒否チェックです。悪意のあるブロックプロデューサーは、無効なヘッダーをリレーに送信し、拒否されたブロックを公開する前にリレービーコンノードが認識しないようにすることで、攻撃を実行できなくなります。それにもかかわらず、リレーは依然として、MEV-Boost と ePBS で提案されているより一般的な攻撃拒否に直面しています。
次のアクション
この投稿では、MEV-Boost がどのように機能するか、そしてそれがイーサリアムのコンセンサスにとってどれほど重要であるかを強調します。また、タイミング関連のイーサリアムフォーク選択ルールのあまり知られていない側面の詳細な分析も提供します。ケーススタディとして「アンバンドリング」攻撃と開発者の対応を使用して、フォーク選択ルールのタイミング関連の側面の潜在的な脆弱性とネットワークの安定性に対するその影響を強調します。
これを念頭に置いて、研究コミュニティは、拒否攻撃のより一般的な露出を考慮して、再組織化の「許容可能な」数がどれくらいかを評価し、緩和策を実装する必要があるかどうかを決定する必要があります。
さらに、現在、いくつかの将来の方向性が積極的に検討されています。
MEV-boost を等価性エラー攻撃から保護するヘッドロック メカニズムを実装します。これには、コンセンサス クライアント ソフトウェアへの変更も必要となり、場合によっては校正刷りの提出期限を延長するための仕様変更も必要になります。
MEV-Boost ソフトウェアのバグ報奨金プログラムの数と配布を増やします。
シミュレーション ソフトウェアを拡張して、サブスロットのタイミングがネットワークの安定性にどのような影響を与えるかを調査します。これを使用して、再編成を削減するためにプルーフの提出期限を調整する方法を評価できます。
リレー上のブロック解放パスを最適化して、不要な遅延を削減します。これはすでに検討されています。
MEV ブーストをコア プロトコル機能として認識し、それをコンセンサス クライアント、つまり「enshrined-PBS (ePBS)」に組み込みます。 2 スロット ePBS は明らかな攻撃に対して脆弱であるため、「ヘッドロック メカニズム」の実装が依然としてオプションです。
レイテンシや認証期限に関する問題に関するハイブ テストや仕様テストを追加する。
リレー仕様の追加実装を構築することで、リレー クライアントの多様性を促進します。
明らかな攻撃に対してペナルティを調整することを検討しますが、極度の MEV 機会が存在する場合には、32 ETH 全額のペナルティであっても悪意のある行為を阻止できない可能性があることに留意してください。
サブスロットのタイミングを再考し、ブロック伝播フェーズの調整を検討します (たとえば、認証期限を t=4 から t=6 に調整するなど)。
全体として、私たちは MEV と mev-boost エコシステムの復活に興奮しています。私たちは、アンバンドリング攻撃と緩和策を通じて、レイテンシー、MEV ブースト、コンセンサス メカニズムの間の重要な関係について学びました。私たちは、プロトコルがこれに対処できるよう強化され続けることを望んでいます。