この記事では、MEV がイーサリアムにもたらす集中化の問題について説明します。改善方法？
著者: サイモン・ブラウン
元の編集: 0x11、ForesightNews
MEV はどのようにして PoS イーサリアムの集中力となったのでしょうか?この記事は、この質問についての考察の第 2 部です。最初の部分は、MEV の影響によりイーサリアムがどのように集中化されるかを推測するために合併前に書かれました。 2 番目の記事は合併後に書かれており、合併後の数か月で実際に何が起こったのか、現在のエコシステムの状態、そして将来どこへ向かうのかを考察しています。
バリデータの一元化
バリデータの一元化
MEV-Boost の背後にある元々の理論的根拠は、必然的に集中化につながる、MEV の出金に対する大規模なステーキング プールの規模への影響を軽減する試みであったことを思い出してください。 MEV-Boost は、バリデーターが提案したブロックからできるだけ多くの MEV を獲得できるように設計されています。これは、独立したステーカーが大規模なステーキング プールと同じ MEV を獲得するチャンスを持ち、したがって平等な競争条件を維持できることを意味します。
画像の説明
ビーコン チェーン デポジットの詳細、出典: Etherscan
リドは株式の29.8％を占めており、これはコンセンサス基準に近い数字であり、懸念材料となっている。
ただし、Lido 自体が DAO であり、定義上分散化されていることを意味するため、誤解があります。 Lido は、ノード オペレーターの分散に関して透明性のあるポリシーを持っています。これについては、分散化に関する投稿で詳しく読むことができます。
画像の説明
エンティティ別の預金者 (Lido 分割ノードを含む)、出典: Etherscan
特にコインベースとクラーケン（米国登録企業2社）が合わせて21％以上の株式を保有していることを考えると、状況は依然として厳しい。さらに、ダニー・ライアン氏は、流動性ステーキングのデリバティブ契約にはリスクがあり、契約自体が分散化されている場合でも、コンセンサス閾値を超えるバリデーターシェアを取得するリスクがあると考えています。彼の記事でそれを見つけることができますThe Risks of LSD — HackMD詳細については、 を参照してください。
しかし、この一元化のどの程度が MEV によって推進されているのでしょうか? MEV-Boost がすべてのバリデーターにすべての MEV への公平なアクセスを提供していることを考えると、この集中化は他の要因によるものであるはずです。バリデーターが多ければ多いほど、プロポーザーとしてバリデーターを選択する頻度が高くなることに注意してください。現在、少なくとも週に 1 回提案者として選出される確率は 10% です。
slots_per_week = seconds_per_week / seconds_per_slot = ( 60* 60* 24* 7) / 12
( 1 / number_validators) * slots_per_week = ( 1 / 479652) * 50400 = 0.1
こここここの現象に関する Flashbots の分析を確認してください。
画像の説明
ビーコンチェーンデポジットの変更
これは、MEV-Boost が機能し、アンサンブル内のすべてのバリデーターに MEV を均等に分散していることを示しています。もちろん、合併以来バリデーターのシェアが変化していないのは、MEV-Boost の採用率が低いため、またはバリデーターに支払われる MEV の金額が非常に低いためであると主張することもできます。これら 2 つの指標を詳しく見てみると、これらが理由ではないことがわかります。
画像の説明
MEV-Boost の採用変更、出典: https://dune.com/queries/1279670/2192739
画像の説明
バリデーターに支払われる報酬、出典: https://dune.com/queries/1279670/2192739
もちろん、実行層の報酬には、ブロック内のすべてのトランザクションとそれに加えてキャプチャされた MEV の優先手数料が含まれます。合併後にバリデーター濃度に変化がないのが MEV の数が少ないためかどうかを判断するには、優先料金とは別に MEV を検討する必要があります。幸いなことに、Flashbots の良き友人たちすでに完了しました。彼らのデータ分析は、MEV がバリデーターへのすべての支払い報酬の 73% を占めていることを示しています。
これらのメトリクスをすべてまとめると、MEV がバリデータ セット全体にかなり均等に分散され、集中化が緩和されるという図が得られます。
出金は賭け金の分配にどのような影響を及ぼしますか?
これは興味深い質問です。ステーカーがあるステーキングプロバイダーから別のステーキングプロバイダーに移動することになるでしょうか?現在、すべてのステーカーがロックされています。引き出しが可能になると、ステーキングプール間の競争が激化します。この時点で、保有株式の自発的な再分配が見られる可能性があります。
これが起こるかどうか、またどのように起こるかは単なる推測ですが、おそらく多くの人がAPRのみに基づいて資金を移動することになるか、流動性担保デリバティブ契約によってより多くの市場シェアが引き寄せられることになるかもしれません。イーサリアムで出金が有効になった場合、分散型バリデーター技術が稼働する可能性があります。を参照してください。ObolまたはSSV通信網。
リピーターの集中化
画像の説明
リレーラーによって処理されるブロック配布、出典: https://www.mevboost.org
これは、イーサリアム インフラストラクチャの非常に重要なコンポーネントが高度に集中していることを明確に示しています。これは理想的とは言えず、このレベルの集中化に伴う潜在的な問題は、米国財務省 (特に OFAC) が Tornado Cash に制裁を課した 8 月に焦点が当てられました。彼らは、Tornado Cash 関連のスマート コントラクト アドレスを SDN リストに多数追加しました。これは萎縮効果をもたらし、多くの組織が dapp UI、GitHub リポジトリ、そしてもちろん RPC エンドポイント プロバイダーを削除して、Tornado Cash に送信されるトランザクションを検閲することになりました。
実際に Tornado Cash へのアクセスをブロックできないことを OFAC が実際に認識していたかどうかは不明ですが (ネタバレ注意: 現在も活発に使用されています)、これらのコントラクト アドレスを SDN リストに掲載することにより、予想通りの萎縮効果がありました。多くの MEV-Boost リレー担当者は (刑務所に行くリスクや巨額の罰金を支払うリスクを回避して) Tornado トランザクションを精査し始めましたが、その 1 つが Flashbots リレーでした。これは、この記事の執筆時点で、イーサリアム上の全ブロックの 75% がレビューされていることを意味します。
この検閲は、Tornado Cash (またはたまたま検閲される他の契約) へのアクセスを妨げるものではなく、Tornado Cash へのルーティングを数ブロック遅らせるだけであることに注意することが重要です。ジャスティン・ドレイクはこれを「弱い検閲アクセスを完全にブロックする「強力な検閲」とは対照的です。しかし、現時点で Tornado Cash を使用することは実際には問題ではありません。問題は、イーサリアムが権威主義政府の法令を強制した場合、信頼できる中立的なプラットフォームであると主張できないことです。このため、MEV-Boost リレーの集中化が問題になります。
では、何が MEV-Boost リレーの一元化につながったのでしょうか?
パート 1 で、mev 非表示の現象と、それがステーキング プールとリレーラーの間の信頼関係にどのようにつながるかについて説明したことを思い出してください。ステーキングプールは通常、バリデーターに支払われた MEV の量を追跡できるように、ノードオペレーターが特定のリレーに接続することを好みます。これは、バリデーターに渡されなかったノードオペレーターへの潜在的な支払いを特定するためです。もちろん、これはリレーの集中化に寄与する要因です。つまり、ビルダーが価値のあるブロックを作成すると、確立された信頼できるリレーを使用することが容易になります。
ブロックビルダーの一元化
驚くべきことに、サードパーティのブロック ビルダーによってネットワークに提案されたブロックの分布は、実際にはかなり均等です。私は、ネットワーク効果によって少数の主要なブロック ビルダーが出現するだけだと予測していましたが、実際、単一のブロック ビルダーの出現を完全に排除することさえできませんでした。
画像の説明
11月21日から28日までのブロックビルダーの配布。出典: https://www.relayscan.io/
これはまだ改善の余地がありますが、ブロックの大部分を生成する 2 つの主要なプール オペレーターが存在する PoW の集中化よりもそれほど悪いことではありません。
画像の説明
ネットワークに提案されたブロック共有の配布、出典: https://dune.com/queries/1306635/2237247
ご覧のとおり、ある時点では Flashbot が MEV-Boost ブロックの 60% 以上を構築していました。これらの数字をバリデーターによる MEV-Boost の総採用数と組み合わせると、ある時点で、Flashbot がイーサリアム上のブロックの約 30% を生成したことがわかります。当時はこの傾向が続くように見えたので、それはある程度予想されていましたが、心配でもありました。
画像の説明
画像の説明
出典: https://dune.com/queries/1306635/2237247
画像の説明
ブロックビルダーの数の変化、出典: mevboost.org
イーサリアムの将来はどうなるでしょうか？
MEV-Boost が単なるソフトウェアではなく、イーサリアム インフラストラクチャの重要な部分であることは明らかです。 Flashbot が作成したものは、Web の設計方法を根本的に変えました。今後、Flashbots は、MEV-Boost の管理とガバナンスがコミュニティの責任になることを望んでいます。
10月初旬、Flashbots地域社会へのさらなる参加を呼びかける、肯定的な反応を受け取りました。多くの組織が MEV-Boost の継続的な管理と開発に貢献するために名乗り出ています。
将来的には、部分ブロック オークション、トランザクション包含リスト、新しいトランザクション タイプなどの実装方法について決定される予定です。より多くの人がこのプロセスに参加し、貢献してくれることを願っています。
画像の説明
イーサリアムのロードマップ、出典: https://twitter.com/vitalikbuterin/status/1588669782471368704
プロトコル内 PBS (提案者と構築者の分離)
PBS は設計哲学であり、PBS を実装するにはさまざまな方法があり、それを研究する理由はたくさんあります。
PBS はもともと、MEV の集中化の影響を軽減する方法として提案されました。その考えは、MEV 抽出を経験豊富な専門家にアウトソーシングし、すべてのバリデーターにアウトソーシングされたサービスへの平等なアクセスを与えると、ステーキングプールが規模の経済の恩恵を受けてセット内のバリデーターのシェアをますます大きくすることができなくなるというものです。
PBS はスケーラビリティ、つまりダンクシャーディングにも影響します。ダンクシャーディングの大きなブロックを作成することは、バリデーター全員ができることではありません。 PBS がなければ、ネットワーク上のバリデータの数が大幅に減少する可能性があるため、PBS はダークシャーディングを可能にする鍵と見なされています。
MEV-Boost は、「プロト PBS」、つまりプロトコルの外側に存在する PBS と考えることができます。ある意味、これはアイデアの良いテストであると見ることができます。ただし、このアプローチの問題は、MEV-Boost 中継者が信頼できる立場に置かれ、ブロックの構築者や提案者から信頼されることです。何らかの保護された PBS がなければ、提案者がビルダーのブロックが解放されて支払いを受け取ることを確認するトラストレスな方法はありません。また、ビルダーがブロックしていることを確認するトラストレスな方法もありません。ブロック内の MEV は、盗まれていない。
そのため、何らかの形でPBSが協定に盛り込まれる可能性が高いと思われるが、現時点ではそうするための提案が多数あるため、どうなるかは不透明だ。
プロトコルに PBS を実装する方法に関する現在のアイデアの詳細については、次のスレッドで説明されているアイデアを参照してください。
その他の方向: 部分ブロックオークション
これまで見てきたように、ブロックのコンテンツ構築全体をサードパーティのブロック ビルダーにアウトソーシングすると、ブロック コンテンツに対する好みの不一致が生じる可能性があります。たとえば、ビルダーは米国政府による特定の取引の検閲に関する潜在的な問題を回避しようとします。
解決策は、ブロック コンテンツの一部のみの構築を外部委託することであるようで、これは部分ブロック オークションと呼ばれることが多いアイデアです。
この問題を解決するには多くの方法がありますが、それらはすべてアイデアを中心に展開しているようです。提案者はトランザクションを含むブロックのプレフィックスまたはサフィックスを作成し、ブロック内の残りのトランザクションはブロック ビルダーから取得されます。現時点では、複数のブロック ビルダーが単一のブロックにトランザクションを提供できるようにする提案は確認されていません。
アイゲンレイヤーは人気を集めていると思われるアプローチを提案しており、再ステーキングメカニズムを使用しています。
リモーゲージによる部分ブロックオークション
リモーゲージの考え方は非常にシンプルです。バリデーターがプロトコルに登録すると、デポジットコントラクトに 32 ETH をデポジットし、出金認証情報を提供して、バリデーターがステークを解除したい場合に備えて出金用のアドレスを指定します。
再仮説は、スマート コントラクト アドレスを引き出しアドレスとして提供するというアイデアに基づいています。バリデーターがステークを解除すると、残高をこの再ステークスマートコントラクトに引き出します。その後、ステークとバリデーターの報酬を受け取るために終了する必要があります。
これにより、スマートコントラクトはバリデーターに追加のペナルティを課すことができるため、自分の賭け金とバリデーターの報酬を全額受け取るためには、バリデーターとしての約束を果たす必要があります。実際、Eigenlayer では、「ミドルウェア」と呼ばれるさまざまな再ステーク コントラクトの作成が可能です。このように、Eigenlayer は「プログラム可能なクリッピング プロトコル」と考えることができます。
バリデーターが署名できるコミットメントの例は、部分ブロック オークションです。このオークションでは、バリデーターがブロック自体の一部を作成し、ブロック ビルダーによる別の部分の作成を許可できます。バリデーターを使用すると、ブロックビルダーがブロックの任意のサイズの部分を作成し、残りを自分で提案できるようになります。
この設定では、MEV-Boost リレーはトランザクションのビルダー部分を保存し、トランザクションのマークル ルートをバリデーターに転送します。説明されているセットアップは依然として中央の信頼できるリレーに依存していますが、バリデーターは何か問題が発生した場合に提案できるバックアップ ブロックを維持しています。さらに、Eigenlayer は、データ可用性レイヤーとして設計された別のミドルウェアを使用して、信頼できるリレーラーを完全に排除できます。
このデータ可用性ミドルウェアを使用して、ビルダーはブロック部分を「データ可用性アービター」に送信します。これは、単一のノードがブロックに関する情報にアクセスできないように、DA クォーラム内のノードにブロックを秘密裏に共有することによって行われます。クォーラム ノードは、受け取った秘密ブロックに署名してビルダーに返します。ビルダーは集約署名の形式で「証明書」を作成し、提案者への入札に含めます。提案者は、有効な証明書を持つすべての入札の中から最も高い入札を選択し、その入札に含まれるブロック ヘッダーに署名します。次に、プロポーザーはこの署名付きブロック ヘッダーを DA アービトレータに送信します。DA アービトレータはそれぞれの秘密ブロックをプロポーザーに公開し、プロポーザーはブロックのビルダー部分を再構築できるようになります。
このアプローチは 2 つの理由で興味深いものです。1 つは、提案者がいくつかのブロックを自分で構築できることを意味し、現在イーサリアムに影響を与えている検閲の問題を軽減するのに役立ちます。また、MEV-Boost インフラストラクチャの分散化にも役立ち、集中中継者への依存が不要になります。
PEPCによる部分ブロックオークション
バルナベ・モノノットも指揮したことに注意してください。探検、プロトコルレベルでの再ステーキングの形式を具体化します。これにより、バリデーターはサードパーティとあらゆる種類の一般的なコミットメントを行うことができ、Eigenlayers にコントラクト/ミドルウェアの再ステークを要求することなく、証明委員会によってこのコミットメントをプロトコル レベルで強制することができます。この考え方は、Protocol Enforced Proposer Commitment (PEPC) として知られています。このアプローチの背後にある主な理論的根拠は、Barnabé 氏が言うように、プロトコルが事実上リスクにさらされているバリデーターの数を認識できなくなった場合、最終的にコンセンサスを不安定にする可能性があるということです (ただし、Eigenlayer には、バリデーターの終了をプログラムでトリガーするなど、このシナリオに対して別の緩和策があると私は信じています) 。
PEPC は、再ステークとほぼ同じ方法で部分ブロック オークションを容易にします。ただし、プロトコルがどのバリデーターがどの程度スラッシュされているかを追跡できる点が異なります。もちろん、これは、バリデーターやサードパーティにとって、スマートコントラクトを再締結するよりも、プロトコルに強制された提案者のコミットメントの方が魅力的であると仮定しています。
プロトコルレベルの部分ブロックオークション
この形式のフラクショナル ブロック オークションは、PBS の crList (検閲耐性リスト) の代替として提案されていますが、これについては後で詳しく説明します。このスキームでは、部分ブロック オークションがプロトコル自体によって促進されます。このアイデアでは、プロポーザーはプレフィックスまたはサフィックスを提供できます。これは基本的に、ビルダーがブロックの一部を提供し、プロポーザーが残りを提供することを意味します。ヴィタリック話しました2 つのアプローチ間のトレードオフ、たとえば、提案者に追加の負担を課し、最終的に無国籍に向けた進歩を妨げる可能性があります。
トランザクション包含リスト/crLists/ハイブリッド PBS
トランザクション包含リスト (crList) は、提案者自身がブロックの一部を実際に提供する必要なく、ブロック ビルダーによるトランザクションの検閲を容易にする方法です。
大まかに言えば、提案者が有効なトランザクション (つまり、有効な nonce、署名、残高、maxFeePerGas など) ブロックのリストを作成できるようにするという考えです。
これは見た目ほど単純ではなく、この方法にはさまざまなバリエーションがあります。 crLists アプローチのすべてのバリアントは、プロトコルがビルダーに完全なブロック、またはリストを含むプロポーザーを受け入れるブロックの生成を強制するという中心原則に収束しているように見えます。
この理論的根拠は、メモリプール内にそれを含む可能性のあるトランザクションが存在するにもかかわらず、利用可能なブロック領域をすべて使用しないブロックをビルダーが作成した場合、合理的なビルダーが何らかの理由でトランザクションを検閲していると仮定できるということです。 、利用可能な取引をすべて除外すると、テーブルにお金が残るだけであり、不合理だからです。ブロック ビルダーによって生成されたブロックが利用可能なスペースをすべて使用していない場合、ブロック ビルダーが生成するブロックに crList 内のトランザクションが含まれない理由はありません。
このスキームでは、crList からのトランザクションを含むトランザクションの検閲を回避するために、ビルダーはブロックが提案者とネットワークによって受け入れられるように、ガス制限までブロックを埋める必要があります。これを行うには、ブロックを自分自身でランダムなトランザクションで埋める必要があります。これは、1 つまたは 2 つのブロックでは経済的に実行可能かもしれませんが、覚えておいてください。EIP-1559 では、ブロック制限に達すると基本料金が増加します。つまり、ビルダーは crList を含める必要がないようにトランザクションに対して支払う必要があり、追加のガスを支払う必要があります。時間の経過とともに、基本料金の増加は、ほとんどの通常のトランザクションがブロックに含まれなくなることを意味し、その結果、建設業者はより多くのスペースを「埋める」必要が生じます。
より可能性の高いシナリオは、crList に認可されたトランザクションが含まれなくなるまで、ブロック ビルダーがブロックの生成を控えることです。これにより、ブロック ビルダーの状況が再調整され、検閲を受けないビルダーが優先されることになります。
このアプローチはすべて利他主義に依存しているように見えます。 crList のさまざまな設計により、提案者が crList を作成するのに費用がかからないことが保証されるため、理論的には費用がかかりませんが、提案者が crList を作成する明確なインセンティブもありません。
現在のスロットの提案者がそのスロットの crList を作成する責任がある場合、空のリストを作成するインセンティブが生じます。これにより、ブロック ビルダーが最も収益性の高いブロックを構築し続けることが保証されます。これは、主要なブロック ビルダー (通常は最も価値の高いブロックを構築する) がすべて検閲されている場合に特に当てはまります。
そこで、将来のスロット用に crList を作成することを想像してください。たとえば、現在のスロット 2 n の提案者は 2 n + 2 の crList を作成します。これを「前方インクルードリスト」と呼びます。このようにして、現在のスロットの提案者は crList を作成することによって経済的に不利益を被るリスクを負いません。これには、単一秘密のリーダー選挙または SSLE と互換性があるという優れた特性もあります。これは、提案者が自分の立場より先に crList を公開することで自分自身をだますことがないためです。
書類書類crLists スキーム設計の概要を説明するバリアントの非網羅的なリスト。
未解決の質問
上記のアイデアはすべて活発に議論されており、そのうちのいくつかは非常に有望であることがわかりました。ただし、いくつか疑問があります。なぜバリデーターはブロックの 100% をビルダーに委託しないのですか?私たちは利他主義に頼っているだけでしょうか？提案者が部分ブロックを提供するために何らかの作業を行うインセンティブは何ですか?なぜバリデーターはわざわざ crList を作成するのでしょうか?イーサリアムクライアントがデフォルトでこれを行うためである場合、バリデーターにはそれを無効にするオプションがありますか?一部のステーキングプールのノードオペレーターは、crList を公開したり、認可されたトランザクションを含むプレフィックス/サフィックスをブロックしたりすることに消極的であることが想像できます。
不整合なインセンティブについてはどうですか?プロポーザーがブロックの一部を提供した場合、ビルダーが MEV をフォークするために使用できる貴重なブロック スペースが奪われますか?ブロックを満たすのに十分なトランザクションがない場合でも、提案者はビルダーのバンドルと衝突しないトランザクションを選択するように注意する必要があります。
crList に関する限り、提案者が crList を P2P ネットワーク上に公開しない場合はどうなりますか?これは合意によって強制できるのでしょうか？これには、複雑さを増す強力な同期の前提があり、これについては、私がリンクした元の資料の一部ですでに言及されています。
結論は
結論は
これらは、この記事を書いているときに頭に浮かんだ質問のほんの一部であり、私よりも賢い人々からのより挑戦的な質問があります。したがって、ご覧のとおり、特定の方向性やアプローチを設定する前に、対処する必要がある未解決の疑問や潜在的な懸念がまだ多くあります。この点に関して、効果的なソリューションが現れるまでには数年かかる可能性があり、その頃には MEV 全体の状況は大きく変わっているかもしれません。
元のリンク
