この号は非常に長いので、便宜上、カタログをプレビューできます。
復習：最大抽出可能値MEVとは何か
パート 1: イーサリアム POS の MEV
バリデータの一元化
ライセンスされたメモリ プール
文章
Proposer -Builder Separation
文章
Builder API
Builder API は MEV の影響をどのように軽減しますか?
パート 3: MEV はイーサリアム固有のものですか?
パート 4: MEV は複雑さに従う
文章
パート 5: MEV の修正が難しい理由
本文の冒頭では、まずMEVとは何かを例を挙げて復習しましょう。
たとえば、多数の取引により価格が下落した後、Uniswap には 10,000 ドルの裁定取引の機会があります。裁定取引ボットは機会に気づき、それを獲得するためのトランザクションを送信し、マイナーに 10 ドルのトランザクション手数料を提示します。次の 2 つのうちの 1 つが発生する可能性があります。
鉱山労働者は、自ら機会をつかむために、裁定取引者の取引をコピーし、検閲します。
10,他のボットはこれに気づき、より高い txfee を入札し、裁定権をめぐる入札合戦を開始します。このオークションは「プライオリティ・ガス・オークション」（PGA）と呼ばれます。
$000 の潜在的な利益は MEV です。マイナーがそれを取得せず、PGA が開始した場合、オークション価格と利用可能な合計 MEV の差が落札トレーダーの利益となります (たとえば、マイナーに手数料として 7,000 ドルが支払われた場合、残りの 3,000,000 はトレーダーに支払われます)。MEVシリーズでは、最初の記事
ここでは MEV の形式とその影響について詳しく紹介しました。その後、引き続き MEV がイーサリアムに与える影響について説明します。
Part.1 イーサリアムPoSにおけるMEV
ステーキング プールが大規模であれば、MEV の機会を獲得するために必要な最適化に投資できるリソースが増える可能性があります。これらのプールが抽出する MEV が多ければ多いほど、MEV 抽出能力を向上させる (そして全体的な収益が増加する) ために必要なリソースが増え、本質的に規模の経済が生まれます。独立したステーカーは、自由に使えるリソースが少ないため、MEV の機会から利益を得ることができない可能性があります。これにより、独立系バリデーターには、収益を増やすために強力なステーキングプールに参加するよう圧力がかかり、イーサリアムの断片化が軽減される可能性があります。
ライセンスされたメモリ プール
サンドイッチ攻撃やフロントランニング攻撃に対応して、トレーダーは取引のプライバシーを保護するためにバリデーターとのオフチェーン取引を開始する可能性があります。トレーダーは潜在的な MEV トランザクションを公開メモリプールに送信するのではなく、バリデーターに直接送信し、バリデーターはそれをブロックに含めてトレーダーと利益を共有します。
「ダーク プール」は、この取り決めの拡張バージョンであり、料金を支払う意思のあるユーザーに開かれた、許可されたアクセス専用のメモリ プールとして機能します。この傾向により、イーサリアムのパーミッションレスやトラストレス性が低下し、ブロックチェーンが最高入札者に有利な「ペイ・トゥ・プレイ」メカニズムに変わる可能性があります。許可された mempool は、前のセクションで説明した集中化のリスクも加速します。複数のバリデーターを実行している大規模なプールは、トレーダーやユーザーにトランザクションのプライバシーを提供することで利益を得ることができ、それによって MEV の収益が増加する可能性があります。
マージされたイーサリアムにおけるこれらの MEV 関連の問題に対処することは、研究の中核分野です。これまでのところ、合併後のイーサリアムの分散化とセキュリティに対する MEV の悪影響を軽減するために、提案者とビルダーの分離 (PBS) とビルダー API という 2 つのソリューションが提案されています。
Proposer-Builder Separation
副題
提案者と構築者の分離 (PBS) は、特にコンセンサス層における MEV の影響を軽減することを目的としています。 PBS の主な特徴は、ブロックプロデューサーとブロック提案者 (Proposer) ルールの分離です。バリデーターは引き続きブロックの提案と投票を担当しますが、ブロック ビルダー (ブロック ビルダー) はトランザクションの順序付けとブロックの構築を担当します。
PBS では、ブロック ビルダーはトランザクション バンドルを作成し、それが (「実行ペイロード」として) ビーコン チェーン ブロックに含まれるように入札します。次のブロックを提案するバリデーターが選択され、さまざまな入札をチェックして、最も高い手数料のトランザクション パッケージを選択します。 PBS は基本的に、建設業者がバリデーターと交渉してブロック スペースを販売するオークション市場を作成します。
現在の PBS 設計ではコミット公開スキームが使用されており、ビルダーはコンテンツ (ブロック ヘッダー) とその入札をブロックするための暗号化コミットメントのみを公開します。落札価格を承諾した後、提案者はブロック ヘッダーを含む署名付きブロック提案を作成します。ブロックビルダーは、署名されたブロック提案を確認した後、完全なブロック本体を公開する必要があり、最終決定する前にバリデーターから十分な証明書を受け取る必要もあります。
PBS は MEV の影響をどのように軽減しますか?
プロトコル内 PBS は、バリデーターの権限から MEV 抽出を削除することで、コンセンサスに対する MEV の影響を軽減します。代わりに、専用ハードウェア上で実行されるブロック ビルダーが将来の MEV の機会をつかむことになります。
ただし、ビルダーはバリデーターにブロックを受け入れてもらうためにプレミアムを支払わなければならないため、これでバリデーターの MEV 関連収入が完全に排除されるわけではありません。ただし、バリデーターは MEV 収益の最適化に直接焦点を当てなくなったため、タイムバンディット攻撃の脅威は軽減されます。
PBS は、MEV 集中化のリスクも軽減します。たとえば、コミット公開スキームを使用すると、ビルダーは、MEV の機会を盗んだり、他のビルダーに公開したりしないようにバリデータを信頼する必要がなくなります。これにより、独立系ステーカーが MEV の恩恵を受ける障壁が低くなります。そうでないと、ビルダーはオフチェーンの評判を持つ大規模なプールを好み、オフチェーンで取引する傾向があります。
Builder API
同様に、バリデーターは、支払いが無条件であるため、ビルダーがブロック本体を保留したり、無効なブロックを発行したりしないと信頼する必要はありません。提案されたブロックが利用できないか、他のバリデーターによって無効化された場合でも、バリデーター料金は引き続き処理されます。後者の場合、ブロックは単純に破棄され、ブロックビルダーはすべてのトランザクション手数料と MEV 収益を失うことになります。
PBS は MEV 撤退の影響を軽減すると述べていますが、それを実装するにはコンセンサスプロトコルの変更が必要です。具体的には、ビーコン チェーンのフォーク選択ルールを更新する必要があります。 Builder API は、より高い信頼性を前提としていますが、PBS の効率的な実装を提供することを目的とした暫定的なソリューションです。
ビルダー API はエンジン API の修正バージョンであり、コンセンサス層クライアントが実行層クライアントに実行負荷を要求するために使用します。 Honest Validators 仕様に概要が記載されているように、ブロック提案任務のために選択されたバリデーターは、接続された実行クライアントからトランザクション パッケージを要求し、提案されたビーコン チェーン ブロックに含めます。
ビルダー API は、バリデーターと実行層クライアントの間のミドルウェアとしても機能しますが、ビーコン チェーン上のバリデーターが (実行クライアントを使用してブロックをローカルに構築する代わりに) 外部エンティティからブロックを取得できるようにする点が異なります。
ビルダー API は次のように動作します。
ビルダー API は、実行層クライアントを実行するブロック ビルダーのネットワークにバリデータを接続します。 PBS と同様に、ビルダーはリソース集約型のブロック構築に専念し、さまざまな戦略を使用して MEV + 優先チップからの収益を最大化する専任のグループです。
バリデーター (コンセンサス層クライアントを実行) は、ビルダー ネットワークからの入札とともに実行ペイロードを要求します。ビルダーからの入札には、実行ペイロード ブロック ヘッダー (ペイロードの内容に対する暗号化コミットメント) とバリデーターに支払われる料金が含まれます。
バリデーターは受信した入札を検討し、最も高価な実行負荷を選択します。ビルダー API を使用して、バリデーターは署名と実行ペイロード ブロック ヘッダーのみを含む「ブラインド」ビーコン ブロック プロポーザルを作成し、それをビルダーに送信します。
Builder API を実行するビルダーは、ブラインド ブロックの提案を確認した後、完全な実行負荷で応答することが期待されます。これにより、バリデーターは「署名付き」ビーコン ブロックを作成し、ネットワーク全体に伝播できるようになります。
ビルダー API を使用するバリデーターは、ブロック ビルダーが時間内に応答しなかった場合に備えて、ブロック提案の報酬を逃さないようにローカルでブロックを構築する必要があります。ただし、バリデーターは、現在公開されているトランザクションまたは別のトランザクションのセットを使用して別のブロックを作成することはできません。これはあいまいさ (同じスロットで 2 つのブロックに署名する) になり、重大なエラーになります。
MEV-Boost は、BuilderAPI の実装例です (MEV-Boost については次号で別途紹介します)。これは、イーサリアム上の MEV の負の外部性を抑制することを目的とした Flashbots オークション メカニズムの改良です。 Flashbot オークションを利用すると、採掘者は収益性の高いブロックを構築する作業を、Proof-of-Work の検索者と呼ばれる専門グループに委託できます。
サーチャーは収益性の高い MEV の機会を探し、ブロックに含まれる封印された価格入札とともにマイナーのトランザクション パッケージを送信します。 go-ethereum (Geth) クライアントのフォーク バージョンである mev-geth を実行しているマイナーは、最も収益性の高いトランザクション パッケージを選択し、それを新しいブロックの一部としてマイニングするだけです。マイナーをスパムや無効なトランザクションから保護するために、トランザクション パケットはマイナーに到達する前にリレイヤーを通じて検証されます。
中継者は、トランザクション バンドルを提案者に渡す前に検証する責任を負います。ただし、MEV Boost では、ビルダーから送信されたブロック本体とバリデーターから送信されたブロック ヘッダーを保存することにより、データの可用性を提供するエスクローが導入されています。ここでは、リレーラーに接続されたバリデーターが利用可能な実行ペイロードをリクエストし、MEV Boost のランキング アルゴリズムを使用して、「最高入札額 + MEV 料金」を持つペイロード ヘッダーを選択します。
副題
Builder API は MEV の影響をどのように軽減しますか?
Builder API の中核的な強みは、MEV の機会へのアクセスを民主化できる可能性です。コミット公開スキームを使用すると、信頼の前提が取り除かれ、MEV からメリットを得ようとするバリデーターの参入障壁が低くなります。これにより、MEV の利益を向上させるために大規模なステーキングプールと統合するという独立系ステークに対するプレッシャーが軽減されるはずです。
Builder API の広範な実装により、ブロック ビルダー間の競争が激化し、検閲への耐性が高まります。バリデーターが複数のビルダーからの入札をレビューする場合、1 つ以上のユーザー トランザクションをレビューしようとするビルダーが成功するには、他のすべての非レビュー ビルダーよりも高い値を付ける必要があります。これにより、ユーザーを検閲するコストが大幅に増加し、検閲の実施が妨げられます。
MEV Boost などの一部のプロジェクトは、全体構造の一部として Builder API を使用し、フロントランニング/サンドイッチ攻撃を試みるトレーダーなどの特定の当事者にトランザクションのプライバシーを提供するように設計されています。これは、ユーザーとブロック ビルダーの間にプライベート通信チャネルを提供することによって実現されます。前に説明したライセンス付きメモリ プールとは異なり、このアプローチは次の理由で有益です。
Builder API ソフトウェアはオープンソースであり、誰でもブロック ビルダー サービスを提供できます。これは、ユーザーが特定のブロック ビルダーの使用を強制されず、イーサリアムの中立性とパーミッションレスの性質が高まることを意味します。さらに、MEV を求めるトレーダーは、プライベート取引チャネルを使用することで不用意に集中化に寄与することはありません。
文章
Part.3 MEVはイーサリアム特有のものですか？
MEV はイーサリアム固有のものですか? と尋ねずにはいられません。
いいえ、MEV がビットコインでも認識できると仮定します。ライトニング チャネルやトークンの二重支払いを検閲するインセンティブは、技術的には MEV です。ただし、私たちの仮説は、ビットコインは本質的にイーサリアムなどのブロックチェーンよりも MEV の影響を受けにくいというものです。
その理由は、それぞれのブロックチェーンの複雑さと「ステートフル性」です。
MEV が特定のブロックチェーン上に蓄積される速度は、通常、そのアプリケーション層の動作の複雑さに比例します。
イーサリアムなどの任意に柔軟なプロトコルはこの複雑さを制限できず、本質的に時間の経過とともに複雑さが増す傾向があります。
これが、イーサリアムの複雑さが呪いになる可能性があると言われる理由です。
文章
Part.4 MEV は複雑さを追求します
対照的に、主に DeFi アプリケーションを介した大きな価値の流れにより、イーサリアム上の MEV サーフェスの指数関数的な増加が観察されます。これらの一見有望に見える財務基盤は、イーサリアムの寄生虫とも見なすことができます。日々、より大きく複雑に成長する MEV の無限のネットワークを織り成しています。
最初のレベルのタイトル
Part.5 MEVは修理が難しい
最後に、イーサリアムが MEV のプロトコルへの参入を相殺するメカニズムを構築できるかどうかを尋ねるのは自然なことです。要するに、いいえ、少なくともイーサリアム上の開発者やユーザーのエクスペリエンスは変わりません。
マイナー/バリデーターが収益源を受け取ることを妨げようとするあらゆる試みは、オフプロトコル市場の創設に拍車をかける可能性があります。たとえば、すべてのトランザクションが 1 つの均一レートの支払いのみを許可されている場合、マイナー/バリデーターはトランザクションの優先順位を得るためにトランザクション業者と共謀して支払いを受け入れることが予想されます。同様に、すべての取引手数料がバーンされるか「パブリックポット」に支払われる場合、マイナー/バリデーターは手数料を個別に徴収するだけで済みます。
ブロックチェーンの知識と乾物について詳しく知りたい場合は、Tokenview.io をフォローしてください。
参考記事
https://research.paradigm.xyz/MEV
https://ethereum.org/en/developers/docs/mev/#mev-in-ethereum-proof-of-stake
