eth2 にも MEV はありますか?バリデーター報酬はどのような影響を受けますか?

Ethereum 2.0 のトランザクション順序付けプロセスは現在の PoW Ethereum と同じになるため、MEV の機会は Ethereum 2.0 でも依然として存在すると信じる理由があります。

Ethereum はまもなく PoW から PoS コンセンサス プロトコルに移行します。開発者は数年にわたってこの移行に取り組んでおり、複数のステップで実行しています。最初のステップは、2020 年 12 月にビーコン チェーンを立ち上げることでした。ビーコン チェーンは現在稼働しています。この記事の執筆時点では、ビーコン チェーン上には 160,000 を超えるバリデーターが存在し、これは約 500 万 ETH のステークに相当します。

2 回目の「大規模合併」は 2022 年初頭に発生する可能性があります。このステップ以降にはまだ多くの詳細が詰められていますが、PoS Ethereum (eth2) については十分な詳細が詰められており、eth2 の最大抽出可能値 (MEV、以前は「マイナー抽出可能値」と呼ばれていました) がいくらであるかを推測することができます。

この記事では、 eth2 でのトランザクションの順序付けを研究し、 MEV 値の抽出によってもたらされるバリデータ収益の増加を分析します。 MEV はバリデーターが受け取る報酬を大幅に増加させますが、eth2 参加者間の不平等も拡大させる可能性があることがわかりました。また、取引所やバリデータプール（ステーキングプール）などの最大の利害関係者間の潜在的なダイナミクスなど、eth2 における MEV の定性的な側面についても説明します。

この記事は Alex Obadia と Taarush Vemulapalli によって執筆されました。完全な分析ドキュメントについては、https://github.com/flashbots/eth2-research をご覧ください。

01. eth2の概要

現在、Ethereum のコンセンサスは、PoW の課題をより適切に解決するために最適化されたマイニング ハードウェアを実行するマイナーによって達成されています。 PoW コンセンサスから PoS コンセンサスへの移行は、Ethereum ネットワークがマイナーではなくバリデーターによって保護されることを意味します。各バリデータノードは 32 ETH のデポジットをステークし、投票を通じてビーコン チェーンの状態について合意に達する必要があります。バリデーターがこれを行うには経済的なインセンティブがあり、つまりバリデーターの善良な行動は報われ、オフラインまたは悪意のある行動は罰せられる（削減される）ことになります。

現在、ビーコンチェーンはeth1チェーンと並行して動作しており、2020年12月からビーコンチェーンは正常に動作しています。「big merge」では、ビーコンチェーンを現在のeth1チェーンとマージします。この記事では、ブロックとトランザクションを含む Ethereum 実行エンジンを「 eth1 」と呼びます。 「ビーコン チェーン」は、eth2 の新しい基盤となる PoS コンセンサス メカニズムを指します。 「 eth2 」は、 eth1 実行エンジンとコンセンサスを達成するために使用されるビーコン チェーンを含む、統合された Ethereum 標準チェーンを指します。

eth2 は 6.4 分ごとにコンセンサスに達します (エポックと呼ばれます)。各エポックには 32 個のスロットが含まれ、各スロットは 12 秒間続き、各スロットはビーコン チェーンにブロックが追加される機会を表します。通常の状況では、各スロットはブロックを生成しますが、バリデータがオフラインであるなどの理由により、一部のスロットが 0 ブロックを生成する場合があります。

各エポックでは、すべてのバリデーターは、ブロックを提案するか、他のバリデーターによって提案されたブロックを証明するために疑似ランダムに割り当てられます。ブロックを提案する検証者は「提案者」と呼ばれ、ブロックを証明する検証者は「認証者」と呼ばれます。各スロットでは、提案者は 1 人だけ、認証者は複数存在し、eth1 のデータやビーコン チェーンのデータを含むブロック内のすべての情報を証明する責任を負います。証明者は、ビーコン チェーンの 3 つの側面、つまりブロックチェーンのヘッド (つまり、最上位のブロック)、証明されたチェックポイント、および確定されたチェックポイントの現在の値に正しく投票することで報酬を得ます。

注: 各エポックの最後のスロットはチェックポイントと呼ばれます。連続する 2 つのエポックが正当化されると、前のエポックは確定したとみなすことができます。詳細については、「Ethereum 2.0: ファイナリティを実現するには？」を参照してください。

02. eth2 の MEV

MEV (最大抽出可能値) は、ブロック提案者が提案したブロック内のトランザクションを並べ替え、検閲、または妨害することによって取得できる可能性のある合計値です。 eth2 でのトランザクションの順序を理解するには、まずトランザクションの順序付けに使用されるソフトウェア (つまり、eth2 クライアント) の内部の仕組みを見てみましょう。

1. eth2クライアント

eth2 は本質的に 2 つのチェーン (eth1 チェーンとビーコン チェーン) が結合されたものなので、eth2 クライアントが 2 つの「サブクライアント」で構成されていることは驚くことではありません。1 つは実行エンジン クライアントで、もう 1 つはコンセンサス クライアントです。現在の PoW Ethereum クライアント(つまりeth1 クライアント)は eth2 に存在し続け、異なる分業でビーコン クライアントと一緒に実行されることに留意してください。

このうち、eth2 の eth1 クライアントは、コンセンサスの責任を取り除かれた現在の PoW Ethereum クライアントであり、eth1 チェーンのトランザクション プール、eth1 実行、および EVM のみに焦点を当てています。一方、ビーコン クライアントはコンセンサスとバリデーターの責任の割り当て (ビーコン ブロックの証明や提案など) を担当します。 2 つのクライアントは並行して実行され、それぞれが独自の p2p ネットワーク スタックを維持します (ビーコン クライアントは libp2p を維持し、eth1 クライアントは devp2p を維持します)。

eth2クライアントは、この修正された図のようになります（Danny Ryanの記事[1]より）。

図1

2. eth1のブロック提案

現在の PoW Ethereum と同様に、eth2 の eth1 クライアントは、P2P ネットワークから受信したトランザクションを含むローカル トランザクション プール (mempool) を維持します。 Rayonism仕様[2]に記載されているように、ビーコンクライアントはeth1クライアントと対話してeth1ブロックを形成します。仕様の通信経路 (2 つのクライアント間) の詳細は運用時に変更される可能性がありますが、一般的なアプローチはおそらく同じままです。

• 多数のラウンドトリップの後、ビーコン クライアントは eth1 トランザクション プールを通じて形成された特定のeth1 ブロックについて eth1 クライアントに照会し、そのブロックがさまざまな有効条件を満たしているかどうかを確認します。

• この eth1 ブロックがビーコン クライアントによって受信され、さまざまな有効性チェックに合格すると、 eth1 ブロックは提案者によって現在のビーコン ブロックにパッケージ化され、認証者が投票するデータの一部になります。

• 次に、ビーコン クライアントは eth1 クライアントに、eth1 チェーンの先頭(つまり、最上位のブロック) を最新のパッケージ化された eth1 ブロックに更新するように要求します。

• しばらくすると、ビーコン ブロックを含むエポックが確定され、ビーコン クライアントは eth2 ブロックがコンセンサス レイヤーで確定されたことを eth1 クライアントに通知します。

図2

eth2 でコンセンサスに達する方法は変更されましたが、 eth2 の各 eth1 ブロック内のトランザクションの順序は現在と同じであり、トランザクションを順序付けるソフトウェア (PoW Ethereum クライアント Geth など) と p2p トランザクション ネットワークに実装されています。

3. eth2 に MEV は存在しますか?

eth2 のトランザクション順序付けプロセスは現在の PoW Ethereum と同じであるため、現在の PoW Ethereum と同様に、 eth2 でも MEV の機会が存在するのは当然です。違いは、順序付けを最終的に制御できるのは誰かという点にあります。つまり、 eth2 では、バリデーター (マイナーではない) がトランザクションの順序付けを制御します。バリデータは、eth1 クライアントからクエリされた新しい eth1 ブロックを含むビーコン ブロックを提案するために選択されます。

図3

つまり、eth1 トランザクションの送信者がブロック提案者 (およびトランザクション ソーター) にチップを支払うことで、希望するトランザクション順序を実現できるようにする Flashbots の MEV-geth (MEV 抽出を最適化するように設計された修正された eth1 クライアント ソフトウェア) などのテクノロジは、今後も存在することになります。この主張を念頭に置いて、バリデーターが Flashbots のようなソフトウェアを実行することでどれだけの収益を得ることができるか考えてみましょう。

03. バリデータ報酬メカニズム

MEVを測定することは非常に難しいことで有名ですが、eth2ブロック提案者がMEVを通じて獲得できる最低限の追加収益の下限としてFlashbotsデータ[3]を使用します。 MEV アクティビティのごく一部のみが Flashbots で発生するため、これはリターンの下限値となります。

この分析の注意点の 1 つは、この記事では eth2 プロトコルによって提供されるステーキング リターンに基づいて MEV を検討していますが、ブロック提案者が受け取ることができるトランザクション手数料の報酬は含まれていないことです。これらの取引手数料を含めない主な理由は、EIP-1559 以降、提案者が取引手数料からどれだけの利益を得ることができるかを予測することが難しいためです (EIP-1559 では、基本取引手数料 basefee の破壊メカニズムが導入されます)。

1. 理想的な状況

まず、すべてのバリデーターが完全に参加して最大のプロトコル報酬を受け取る（つまり、大規模なスラッシングがない）理想的なケースを考えてみましょう。また、すべてのバリデーターが無限の時間スケールで同じ数のブロックを提案するため、すべてのステーキング報酬が均等に分配されます。

図 4: Y 軸は収益率を表し、X 軸はバリデーターの数を表します。青い線は、MEV を考慮しないバリデーターの理想的な年間収益率を表しています。黄色の線は、 MEV を考慮したバリデーターの理想的な年間収益率を表しています。青い縦の破線は、執筆時点でのバリデーターの数（約 160,000 バリデーター）を表しています。

現在のバリデーター数（160,000バリデーター）に基づくと、MEVはバリデーター報酬を75.3%増加させる、つまり12.83%のAPR（年率）を提供できることがわかりました。これは、MEVを考慮した場合、ETHをステーキングすることで得られる7.35%のAPRよりも高い値です。このことから導き出される結論の 1 つは、バリデーターの報酬が高くなるということは、より多くの ETH 保有者がバリデーターになることに惹かれることを意味し、バリデーターの数が増えると Ethereum がより安全になることを意味します。

近い将来、より多くのバリデーターがオンラインになるにつれて、MEV に基づくバリデーターのリターンの増加はそれほど大きくはなくなるでしょう。たとえば、250,000 人のバリデーター（つまり、800 万 ETH のステーク）に対する報酬は 60% しか増加しません。前述のように、この分析では、バリデーターが獲得する取引手数料の額は考慮されていません。考慮すると、MEV が収益に与える相対的な影響が減ってしまうためです。ただし、これらの数字は、現在の PoW マイナーが Flashbots を通じて獲得する追加の MEV 報酬 (現在約 5.6%) と比較すると、依然として有用です。この大きな違いは、PoS 発行率の大幅な低下から生じています。これは、MEV 抽出が eth1 よりも eth2 でより報酬が高くなり、ステーカーが MEV を通じて達成されるステーキング リターンを強く求める可能性があることを示唆しています。

2. 時間と収益の配分を考慮する

有限の時間スケールでは、ブロックを提案するためのプロトコル固有の報酬があり、一部のバリデータは平均よりも多くのブロックを提案できるほど幸運である一方で、それほど幸運ではないバリデータはより少ないブロックを提案するため、バリデータ報酬は変動します。

たとえば、ネットワーク内に 100,000 人のバリデーターがいる場合、各バリデーターが 1 年に提案するブロックの平均数は26 ブロックですが、最も運の悪い1% のバリデーターは最大 15 ブロックを提案する可能性があり、最も運の良い1% のバリデーターは少なくとも 39 ブロックを提案する可能性があります。下の図を参照してください。

図5

このロジックに基づいて、ブロック提案の「運」の 3 つの異なるレベル (つまり、最も幸運なバリデーターの 1%、最も不運なバリデーターの 1%、および平均的なバリデーター) に基づいて、バリデーターのステーキング報酬の変動性 (MEV の影響は考慮しない) をプロットできます。

図 6: Y 軸は収益率を表し、X 軸はバリデーターの数を表します。緑の線は、MEV を考慮せずに最も幸運な 1% のバリデーターが得られる年間ステーキング収益率を表しています。赤い線は、MEV を考慮せずに、最も不運な 1% のバリデーターが得られる年間ステーキング収益率を表しています。黄色の線は、MEV を考慮せずにバリデーターが得られる平均年間ステーキング収益率を表しています。青い縦の破線は、執筆時点でのバリデーターの数（約 160,000 バリデーター）を表しています。

ここで、Flashbots [4]に記録されたブロックごとの平均抽出値（ REV 、または実現抽出値）を追加することで、MEV値を考慮した場合と考慮しない場合の、ブロック提案の「幸運」の3つの異なるレベルに対するバリデーターのリターンを比較することができます。

図 7: 緑の線は、MEV 値の抽出を含めた場合に最も幸運な 1% のバリデーターが得られる年間収益率を表しています。赤い線は、MEV 値の抽出を含めた場合に、最も不運な 1% のバリデーターが得られる年間収益率を表しています。黄色の線は、MEV 値の抽出が含まれる場合にバリデーターが得られる平均年間収益率を表します。下の太線は、MEV を考慮せずに 3 種類のブロック提案「運」の下でバリデーターが得られる年間ステーキング利回りですが、上図の 3 本の線の違いが小さすぎるため、3 本の線が重なっています。

上図（図 7）の 3 つの曲線は、MEV の値を考慮せずに 3 つのレベルの「運」によってもたらされるバリデータの年間ステーキング収益を表すために使用されますが、ほぼ重なり合っていて区別が困難です。これは、MEV値の抽出により、ブロック提案の「運」によって引き起こされるバリデータ間の利益の不平等が拡大することを示唆しています。

さらに、REV の分配は不均一であり、一部のブロックの MEV 報酬が他のブロックよりも大きいという「運」の 2 番目の側面として見ることができます。たとえば、Flashbots の MEV-Geth マイニングを使用してマイナーが過去 100,000 連続 Ethereum ブロック (ブロック高 11,600,000 から開始) で受け取った REV 報酬の (ロングテール) 分布は次のとおりです。

図8

上の図（図 8）では、X 軸（各ブロックでマイナーが実際に獲得した REV 値）を 3 ETH に切り捨てていますが、実際には、私たちのサンプルでは、​​マイナーが獲得できる最大の REV 値は 101 ETH です。この Flashbots マイナー報酬の分布を使用して REV の分布を表すことで、最も不運な 1% のバリデーター、平均的なバリデーター、最も幸運な 1% のバリデーターが MEV 報酬から獲得する金額に基づいて、3 つの幸運レベルの年間利回り曲線を定義してプロットできます。

図 9:緑の線は、 MEV 値の抽出を含めた場合に最も幸運な1% のバリデーターが得られる年間収益率を表しています。赤い線は、MEV 値の抽出を含めた場合に、最も不運な1% のバリデーターが得られる年間収益率を表しています。黄色の線は、 MEV 値の抽出が含まれる場合にバリデーターが得られる平均年間収益率を表します。青い縦の破線は、執筆時点でのバリデーターの数（約 160,000 バリデーター）を表しています。

前のグラフ (図 7) は、ブロック提案の「運」によってバリデーター間の利益の不平等が MEV によって拡大されたことを示しています。このグラフ (図 9)は、REV の不均等な分配がバリデーター間の利益の不平等の大きな原因であることを示しています。特に、このグラフ (図 9) の Y 軸が 600% に増加しているのに対し、図 7 の Y 軸は 80% に過ぎないことを考えると、そのことがよくわかります。

しかし、実際には、バリデーターはバリデータープール（ステーキングプールとも呼ばれます）にリソースをプールし、ブロック提案の運や REV の不均等な分配によるバリデーター報酬の差を排除します。しかし、これは、MEV がバリデーターの収益に与える影響によって、バリデーターノードを独立して実行する意欲が減退し、バリデータープールに参加することが経済的に魅力的になり、ネットワーク検証の集中化につながる可能性があることを意味します。

最終的に、最も多くの ETH をステークしたエンティティが、より少ない ETH をステークしたエンティティ (バリデータ プール) よりも速く成長するため、MEV によって eth2 の寡占ダイナミクスが悪化する可能性があることを懸念しています。これにより、コンセンサス投票権を分散化するために、eth2 での MEV 抽出の民主化が特に重要になります。

04. 新たなコンセンサス参加者

上記の定量分析は eth2 の MEV について考え始める上で重要ですが、eth2 コンセンサス参加者の定性分析がなければこの記事は不完全です。前述のように、eth2 では、マイナーとマイニング プールは、大量の ETH を管理するエンティティ (取引所、プロトコル トレジャリー、投資ファンド、バリデータ プールなど) に置き換えられます。これは、ビーコン チェーン ブラウザ beaconcha.in に表示される現在の eth2 バリデータの eth1 デポジット アドレスの分布を通じてすでに確認できます。

上記: すべての eth2 バリデーターの eth1 デポジット アドレスの分布。多数の eth2 バリデータが、複数の取引所やステーキングプールなどのエンティティのアドレスを通じてステーキングしていることがわかります。これは、これらのエンティティが eth2 の投票権の大部分を制御していることを意味します。

この円グラフでは、コンセンサス投票権を制御する最終的な主体と、それが実行されるインフラストラクチャを区別していないことに注意してください。 eth2 コンセンサス投票権の集中化は懸念されますが、インフラストラクチャの集中化はそうではない可能性があり、PoS の経済的インセンティブは、関連する削減リスクを最小限に抑えるためにインフラストラクチャの分散化を奨励します。

具体的には、大量の eth を管理する Kraken のような取引所は、この大規模なインフラストラクチャ運用タスクを社内で引き受けるのではなく、多くのインフラストラクチャ プロバイダーに預金を分散し、異なる地域の異なるハードウェアで eth2 ノードを実行することで、大幅な削減のリスクを軽減できる可能性があることを意味します。

1. 交換

eth2 における最も注目すべき変化は、取引所が最大の ETH 保有者となり、したがって最大のバリデーターとなったことです。 Coinbase、Binance、Kraken などの中央集権型企業が、最も多くのバリデータ スロットを管理することになると思われます。これらの参加者はマイニングプールとは異なるルールに縛られており、その評判には多くの影響を及ぼします。この違いは、マイナーの状況と比較してバリデーターの状況に新たな影響を及ぼす可能性があり、バリデーターが行う活動（見返りに獲得する MEV の種類など）に影響を及ぼす可能性があります。

興味深いことに、これらの組織は eth2 ステーキング以外にも複数の活動に関与しており、これらの取引所が提供する既存のサービスと MEV 価値抽出の間に相乗効果をもたらす新たな機会をもたらす可能性があります。これらの活動には、取引の加速、オンチェーンにパッケージ化される前のプライベート引き出しの提供、注文フローの暗号ネイティブ支払いによるオンチェーン取引手数料の削減などが含まれます。

このようなサービスは当初は最先端のものであったとしても、その利点によりユーザーはそのサービスを提供する取引所に移行する可能性があり、規制上の理由でそのサービスを提供しない、または提供できない取引所に損害を与える可能性があります。さらに、MEV ゲームにおける取引所の潜在的な垂直統合 (取引所が独自のボットを実行してトランザクションを独自のバリデータ ノードに送信するなど) は、さらに調査する必要がある懸念事項であると考えています。

2. バリデータプール

eth2 のもう 1 つの重要な変化は、バリデータ プール(「ステーキング プール」とも呼ばれる)の台頭です。これにより、eth2 ステーキングに参加するために必要な最小 ETH 量を引き下げる (ユーザーは、1 つのバリデータ ノードを自分で実行するために 32 ETH をステーキングする必要がありますが、バリデータ プールに参加すると、バリデータ プールがすべてのユーザーの ETH をステーキング用にプールするため、32 ETH 未満を提供できます)、顧客用のバリデータ ノードを構築する、ブロック提案の「運」による変数を排除する (MEV+ 取引手数料収入に影響します)、ステーキング デリバティブなどの追加サービスを提供する (管理する資金基盤のおかげです) などの利点があります。

興味深い現象として、Rocketpool や Lido などのメタプールの出現が挙げられます。これらのエンティティは多くのバリデータプールに接続されており、それらのバリデータプールの大きなステーク源となる可能性が高いため、参加する MEV 抽出の種類やステーカーに提供する利益分配に影響を与えるなど、バリデータプールの動作に影響を与えることができます。

これらのメタプールは通常、ステーキングデリバティブを提供します。一例として、ロックされた ETH 担保預金の流動性のあるトークン化されたバージョンをユーザーに提供し、ユーザーがそれをネットワーク内で使うための派生商品として利用できるようにするというものがあります。ユーザーがデリバティブの形で DeFi でロックされた ETH を再利用できるようにすることで、バリデーターの利益は MEV 値を超えてさらに増加し​​ます。

05. 自由回答形式の質問

eth2 の MEV の調査により、多くの未回答の質問が明らかになりました。今後数か月にわたって調査する予定です。そのうちの 4 つを以下に示します。

1. eth1ブロック提案者市場

eth2 には実際に実行するクライアントが 2 つ (eth1 クライアント + ビーコン クライアント) あるため、eth1 ノード自体を実行するオーバーヘッドが非常に高いため、独立したバリデーターは eth1 ノードを Infura などのサービス プロバイダーにデフォルト設定することを選択する可能性があります。これは、eth1 ノード オペレーターと eth2 ノード オペレーターの分離の始まりを示唆している可能性があります。このようなダイナミクスが出現すると仮定すると、eth2 ブロック提案者のニーズを満たす高性能ハードウェアと MEV シミュレーション ソフトウェアを実行する eth1 ノード オペレーターの市場が出現すると想像できます。

2. MEV検索の最適化における新たな制限

価格裁定や清算などの MEV の機会は eth2 にまだ存在しますが、この MEV 値を抽出するシステムには、MEV 抽出に対する制約を変更または導入する可能性のある新しいパラメーターがあります。

たとえば、eth2 のブロック時間は、現在の eth1 の可変ブロック時間ではなく 12 秒に固定されており、ブロック提案者のスロットは各エポックの開始時に割り当てられます。つまり、提案者は最大 6.4 分間タスクを計算することになります (もちろん、エポックの開始時にスロットを割り当てられた提案者には、それほど多くの時間はありません)。これにより、バリデーターが eth1 クライアント トランザクション プールで計算を実行して最適な MEV 抽出を行うための時間が長くなる可能性があるだけでなく、ブロック時間の予測可能性によりシミュレーションと実行も容易になります。

つまり、MEV 抽出戦略を計算して実行するための時間間隔がより長く、より予測可能になり、より複雑で計算集約的な MEV 抽出が可能になります。

3. リーダー選出メカニズムの変更

バリデーターは、ブロックを提案する必要があるかどうかを事前に認識します (新しいエポックの最初のスロットでない限り)。低い確率ではあるが、単一のエポック内で複数のブロックを提案することもできます。ブロック提案者の識別によって、MEV 値抽出のダイナミクスはどのように変化するのでしょうか?また、1 つのブロック内に複数のブロックが提案されることが決定された場合、これは MEV 抽出のダイナミクスにどのような影響を与えるでしょうか?特に、大規模なバリデータプール/取引所は、同じエポック内で複数の連続したスロットを所有する（割り当てられる）可能性が最も高くなります。

4. L2とシャーディング

この記事の大部分は、eth1 のブロック コンテンツが現在のまま残ることを前提としています。ただし、実際には、多くのトランザクション フローが L2 に転送され、Ethereum L1 がデータ可用性レイヤーとして使用され、zk-rollups と optimistic rollups がバッチ トランザクション データを L1 に送信する役割を担います。

これにより、バリデーターが MEV から受け取る利益が直感的に減少することになります。ただし、複数の L2 の世界では複雑さが増し、新しい形式の MEV (L2 間トランザクション、L1-L2 間トランザクションなど) が生まれる可能性があるため、これを予測するのは困難です。同様に、eth2が進化し続け、シャーディングが実用化されるにつれて、ビーコンブロック内のシャードの順序が重要になる可能性があり、MEVは「シャードブロックをずらしてブロック時間を短縮する」というVitalikの提案を実装するためのインセンティブメカニズムになる可能性があります[5]。

本稿の編集にご協力いただいた Terence Tsao、Raul Jordan、Alejo Salles、Luke Youngblood、Tomasz Stanczak、Lakshman Sankar、Barnabe Monnot、Caspar S、および Viktor Bunin の皆様に感謝申し上げます。議論に協力してくれた Flashbots チームの他のメンバーにも感謝します。