この記事は「必要なのは優先順位だけ」からのものです
原作者：ダン・ロビンソン、デイブ・ホワイト
コンパイラー：Odaily Planet Dailyの夫はどうですか？
パラダイムは6月4日、新しい仕組みのMEV税について詳しく紹介した記事「Priority Is All You Need」を掲載した。
MEV 税は、アプリケーションが生成した MEV をブロック プロポーザーに漏らすのではなくキャプチャできるようにする新しいメカニズムです (ブロック プロポーザーの詳細については、記事の最後にある脚注を参照してください)。このメカニズムは、ブロック構築プロセスにおける競合優先順位付けを利用します。このソート方法では、トランザクションを優先コストの降順に並べ、優先順位の高いトランザクションから順にブロック化します。 MEV 税は、取引の優先手数料に追加料金を加算することで機能します。アプリケーションは、トランザクションの優先料金に基づいて独自の料金を設定することで、MEV のほとんどまたはすべてを取得できます。これは、アプリケーションがブロック プロポーザーによって実行される単一の共有オークションに参加することで、オフチェーン インフラストラクチャを必要とせずに独自のカスタム MEV オークションを実行できることを意味します。
MEV 税制の誕生は、既存の DeFi エコシステムに影響を与える可能性があります。
従来の MEV の配布方法の変更: 従来、MEV は提案者をブロックすることがほとんどでしたが、MEV 税により、アプリケーションがこの値を取得してユーザーに再配布したり、他の目的に使用したりできるようになります。
アプリケーションの収益とユーザー エクスペリエンスの向上: ユーザーはトランザクション実行の効率が向上し、トランザクション価格が向上するため、より優れたユーザー エクスペリエンスを提供しながら、MEV 税を導入することでアプリケーションの収益を増やすことができます。
DEXルーティングの最適化、裁定取引でのAMM損失の削減、ウォレットユーザーのMEV漏洩の削減など、DeFi:Mのいくつかの問題を解決しました。 MEV税を導入することで、アプリケーションは製品やサービスを向上させることができ、それによってDeFiエコシステムの効率と持続可能性が向上します。
引用
この記事では、あらゆるアプリケーションが独自の MEV (最大抽出可能値) を取得できるメカニズムである MEV 税について紹介します。
このメカニズムは、OP Mainnet、Base、Blast などの OP Stack L2 チェーンですぐに利用できます。これらのチェーンのブロック提案者は、競合優先順位付けと呼ばれる一連のルールに従うためです。
これらのチェーンに MEV 税を導入するために、スマート コントラクトはトランザクションの優先料金に基づいて料金を請求します。アプリケーションが、検索者が支払った優先権 1 ドルごとに 99 ドルの MEV 税を課した場合、そのトランザクションの競争力のある MEV の 99% を取得できることを示します。
MEV 税は、広大な設計領域を開くシンプルな手法です。これは、チェーン上の任意のアプリケーションが、独自のオフチェーン インフラストラクチャを必要とせずに、ブロック プロポーザーによって実行される共有オークションに接続するだけで、独自のカスタム MEV オークションを実行できるようにすると考えることができます。
MEV 研究における 3 つの主要な問題に対処するために MEV 税をどのように使用できるかを示します。
取引所が受け取る価格を最適化する分散型取引所 (DEX) ルーター
リバランス（LVR）によって流動性プロバイダーが被る損失を最小限に抑える自動マーケットメーカー（AMM）
ユーザーがトランザクションによって生成された「ロールバック」MEV をキャプチャできるウォレット
しかし、問題があります。 MEV税は、ブロックの提案者が、検閲、覗き見、遅延なしに優先料によるトランザクションの注文を含む競争優先ルールを厳格に遵守している場合にのみ有効です。ブロックの提案者がこれらのルールから逸脱すると、MEV 税を回避して価値を獲得できる可能性があります。したがって、今日の MEV 税は信頼できる L2 シーケンサーに依存しており、イーサリアム L1 ではまったく機能しない可能性があります。イーサリアム メインネットでは、ブロック構築は提案者の収入を最大化するために競争力のあるビルダー オークションによって主に支配されているためです。
それにもかかわらず、MEV 税の機能と柔軟性は、現在優先順位を提供できるプラットフォームにとって優先順位付けが正しい選択である可能性があることを示唆しています。そして、競合優先順位付けの比較的単純さは、単一のシーケンサーを信頼せずに、分散型の方法で競合優先順位付けを強制する実行可能な方法がある可能性があることを示唆しています。この記事がこの問題に関するさらなる研究を促進することを願っています。
優先順位
誰かがイーサリアムメインネットまたはL2でトランザクションを送信するとき、ブロック提案者に支払われる優先料金を指定します。これは、builderPriorityFee (ETH で支払われる合計金額) を取得するためにトランザクションで使用されるガスを乗算した数値である priorityFeePerGas によって指定されると想像できます。
イーサリアム プロトコルでは、ブロック内のトランザクションを priorityFeePerGas の降順で貪欲に並べ替える必要はありません。ただし、これはブロックを構築する一般的な方法です。たとえば、これは OP スタック チェーンのシーケンサーと geth および reth で使用されるデフォルトのアルゴリズムです。優先順位付けにより、トレーダーは取引の緊急性を効果的に表現できるだけでなく、特定の種類の MEV が提案者をブロックするように自然に指示されます。
これは、優先順位付けにより MEV の競争が優先ガスオークションに変わるために起こります。 AMM と集中型取引所の間の裁定など、チェーンとのやり取りから利益を得る機会がある場合、検索者はその機会を最初に掴むために競争します。チェーンが優先順位付けを使用してトランザクションのパッケージ化と順序を決定する場合、検索者はトランザクションに高い優先順位の料金を設定することで競争することになります。
リスクのない利益が競争によってゼロに圧縮される競争シナリオでは、勝った検索者は最終的に優先料として MEV の全額を支払う必要があります。したがって、コントラクトの操作によって 100 ETH の利益が得られた場合、その機会をつかむための最初の取引には 100 ETH の優先手数料が設定されます。 (これに関するいくつかの考慮事項については、「制限事項」セクションで説明します)。
MEV税
スマート コントラクトが、対話するトランザクションで MEV をキャプチャしたいとします。スマート コントラクトが独自の MEV をキャプチャしようとする、アプリケーション固有のさまざまな方法に関する広範な研究文献があります。
しかし実際には、アプリケーションについて具体的なことを知る必要は必ずしもありません。ブロックが競合的な優先順位付けによって構築されることがわかっている場合、トランザクション内の MEV の量に関する統一されたシグナル、つまり優先料が得られます。
私たちは、スマートコントラクトがトランザクションの優先手数料を調べ、それに基づいて独自の手数料を請求できることを提案します。この手数料は優先手数料の増加関数です。たとえば、コントラクトでは、呼び出す人が applicationPriorityFee = 99 *proposerPriorityFee の ETH をコントラクトに転送することが要求される場合があります。
この新しい料金はトランザクションを送信した検索者によって支払われるため、その検索者の行動に影響します。オポチュニティの MEV が 100 ETH の場合、勝ち取ったトランザクションは優先手数料 1 ETH のみを設定します。これにより、合計支払い額は 100 ETH になります (ブロック提案者に 1 ETH、スマート コントラクトに 99 ETH)。 。優先料が高くなると取引は不採算になり、優先料が低くなると、より高い料金を設定する競合他社に機会を奪われてしまいます。これは、スマート コントラクトがトランザクション内の MEV の 99% をキャプチャすることを意味します。
スマート コントラクトによって課されるこの追加料金を MEV 税と呼びます。 MEV 税により、アプリケーションは自らの利益のために優先順位を乗っ取ることができ、提案者をブロックするために MEV が漏洩するのではなく、ユーザーのために MEV を取り戻すことができるようになります。
料金が priorityFeePerGas の関数として十分な速さで増加する場合、提案者に発生するのはごくわずかな MEV だけです。 priorityFeePerGas の価格はウェイ (ETH の 10 億分の 1) で設定されているため、多くの精度を活用できます。たとえば、MEV の税感応度が十分に高く、priorityFeePerGas が 50,000 だと法外に高い税金が発生する場合、提案者に支払われる合計金額は 0.01 ドル未満になります。
ただし、重要な注意点があります。制限セクションで説明したように、MEV 税は、ブロック提案者が特定のルール (これを「競争的優先順位付け」と呼びます) に従い、自らの収益を最大化するためにこれらのルールから逸脱しない場合にのみ機能します。これらのルールをトラストレスな方法で強制するかどうかは未解決の問題です。
単一アプリケーションの MEV キャプチャ
競争的な優先順位付けを使用してブロックが構築されることが保証されているチェーンでは、MEV 税を使用して MEV の 3 つの重要な問題を軽減できます。DEX インターフェイスによる取引執行の改善を可能にし、AMM が LP での裁定損失を削減できるようにします。 pass ユーザーの MEV 漏洩を減らすためにユーザーをランバックする権利を販売します。
DEXルーターサーチャー
UniswapX や 1inch Fusion などのインテントベースの DEX ルーティング プロトコルでは、ユーザー (Alice) が交換インテントに署名し、サーチャーがそのインテントを最良の価格でルーティングまたは設定するために競い合います。
現在のバージョンの UniswapX は、この競争を実行するために 2 つのメカニズムを使用しています。1 つは、アリスの指値価格が検索者によって満たされるまで時間の経過とともに変化するダッチ オークションで、もう 1 つは開始価格を設定する最初のオフチェーン見積依頼 (RFQ) オークションです。オランダのオークション。
競争上の優先順位付けを保証するプラットフォーム上で、UniswapX はこれらを MEV 税というメカニズムに置き換えることができます。これは、誰でも即座に約定できる注文にユーザーが署名できるようにすることで機能しますが、約定価格は取引の優先手数料の関数です。
たとえば、Alice が 1 ETH を販売する UniswapX 注文を持っている場合、その注文の約定価格を minimumPrice + ($ 0.01 * priorityFeePerGas) として定義できます。minimumPrice は、現在より大幅に低いと予想される固定値にすることができます。価格。
検索者は、トランザクションを送信してアリスの注文を満たすために競い合います。最も優先度の高い手数料とフォールバックのない取引は注文を約定するため、トレーダーは検索者が見つけられる最高の価格を確実に得ることができます。 (これに対するいくつかの例外については、「制限事項」セクションで説明します。)
アリスの最低価格が 3,000 ドルで、現在の ETH 価格が 3,500 ドルの場合、勝利したトランザクションの priorityFeePerGas は約 50,000 です。 (200,000 ガスの費用がかかるトランザクションでは、ブロック提案者に支払われるのは ~100 億ウェイ (~0.000035 ドル) だけになることに注意してください。
これには、UniswapX で使用されている既存のメカニズムに比べて、潜在的な利点がいくつかあります。
MEV 税を使用した注文は、ダッチ オークションを使用した注文よりも迅速かつ有利な価格で注文を処理できます。この記事で説明したように、オンチェーン ダッチ オークションでは、ブロック間の価格変動により一部の価値が MEV に漏洩し、完了するまでに複数のブロックが必要になる場合があります。対照的に、MEV 税を使用する注文は、多くの場合、MEV の大部分を取得しながら次のブロックで履行できます。
オフチェーンの RFQ とは異なり、MEV 税を使用して注文を満たすオークションは、オンチェーンのトランザクションが実行されるとアトミックに発生します。これは、落札者は、オンチェーントランザクションが成功した場合にのみ注文が約定されることが保証されることを意味します。これにより、オンチェーンの流動性 (AMM など) がオフチェーンの流動性と競合しやすくなります。つまり、UniswapX がマルチプール サブシステム (Uniswap v4 など) のより効率的なルーターとして機能できるようになります。
自動マーケットメーカー (AMM)
論文「損失対リバランス」で説明されているように、裁定取引者がブロックの最上部で古い価格で取引することにより、AMM から価値が漏洩することがよくあります。 MEV 税を使用して、AMM にこれらの MEV をキャプチャさせることができます。わかりやすくするために、集中流動性を持たない AMM でこれを実装する方法について説明します。 (この種の問題を一元的な流動性で解決する方法に興味がある場合は、Sorella がすぐにソリューションをリリースする予定です。)
AMM は、トランザクションの優先順位に基づいて追加料金を請求することで MEV を獲得し、ブロック内のトランザクションに優先順位を付ける権利を競売にかけることを可能にします。この料金を計算して評価するにはさまざまな方法があります。プール流動性単位 sqrt(xy) で表現される、おそらく中立的なアプローチについて説明します。勝利するトレードは、プールの流動性を最も高めるトレードになります。
ブロック内のプールで最初のトランザクションを実行するとき、x_end * y_end > x_start * y_start プールは条件を (何らかの定数として) 強制できます。
x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^ 2 この式は、裁定取引トレーダーに真の価格まで取引するよう促します。その後、プールの中間価格が真の価格になるはずです。
最初のトランザクションの後は、固定の交換手数料を使用して、トランザクションは Uniswap v2 と同様に機能します。追加の MEV 税を支払わずに取引を希望する知識のないトレーダーには、優先手数料が低く設定されます。
AMM に MEV 税を導入する方法は他にもたくさんあり、さまざまな効果が得られます。たとえば、MEV 税は取引所の入力トークンまたは出力トークンで表すことができ、プールによって適用される取引所手数料の割合に影響を与えたり、ユーザー トランザクションの最低価格を決定したりすることができます。私たちは、これは探求する価値のある興味深いデザイン空間だと考えています。
バックランニングオークション
上記の説明は、MEV の漏洩を回避するために特定のアプリケーションをどのように設計できるかを示しています。しかし、ウォレットが、ユーザーがトランザクションを通じてアプリケーションと対話するときに生成する MEV を取得できるようにしたい場合は、それらのアプリケーションに MEV 税が含まれていない場合でもどうでしょうか?
たとえば、アリスが AMM で大規模な取引を行うとき、価格を通常に戻すために「バックランナー」に裁定取引の機会を作り出すことがあります。通常、これらの機会は、Alice が所有するのではなく、MEV に漏洩されます。
MEV-ShareとMEVBlockerは、ユーザーがトランザクションから MEV を取得できるようにする 2 つのプロトコルですが、複雑なオフチェーン オークション システムに依存しています。 「 Orderflow オークション デザイン スペース」では、その他のソリューションについて説明しています。
MEV 税をインテントベースのスマート コントラクト ウォレットと組み合わせると、アリスの追跡 MEV を取得する代替システムを構築できます。アリスは、AMM で取引されるトランザクションを作成するのではなく、そのアクションを実行させるために誰でもアリスのスマート コントラクト ウォレットに送信できるインテントに署名するとします。アリスのスマート コントラクト ウォレットは、トランザクションを送信した人に MEV 税を請求し、税金はアリスに支払われます。
アリスの意図を送信した検索者は、同じトランザクション内でアトミックに彼女をフォローできるため、彼女をフォローする排他的な権利を持ちます。したがって、検索の競争が激しい場合、アリスの追跡から得られるすべての利益は、MEV 税を介してアリスに支払われるはずです。
フロントランニングはユーザーへの MEV 税の支払いを回避できる可能性があるため、このシステムはフロントランニング攻撃からユーザーを完全に保護できない可能性があることに注意することが重要です。この問題 (およびその考えられる緩和策の一部) については、以下の「制限事項」セクションで詳しく説明します。それでも、これは少なくとも、何の緩和策も講じていないパブリック メモリ プール システムよりも改善されています。
その他の使用例
これらの例に加えて、MEV 税のその他の潜在的な用途には、オフチェーンまたはダッチ オークションが現在使用されているほぼすべてのシナリオが含まれます。
Oval のようなプロトコルは、作成したオラクルをキャプチャすることで抽出可能な価値 (OEV) を可能にします。
BlendのようなNFT担保融資プロトコルでのオークションの借り換え。
貸付契約の清算では、ダッチオークションよりも価値が流出しません。
クロスアプリケーション MEV キャプチャ
上記のソリューションは、単一のアプリケーションと対話するときに生成される MEV をキャプチャするように設計されています。ただし、検索者が同じトランザクションで複数のアプリを操作することで、より多くの価値を獲得できる場合があります。
これらのアプリケーションのうち 1 つだけが MEV 税を使用する場合、MEV 税が高いか低いかに関係なく、トランザクションからのすべての MEV は MEV 税を使用するアプリケーションに帰属する必要があります。
しかし、検索者のトランザクションが MEV 税を使用する 2 つのアプリケーションと対話する場合はどうなるでしょうか?たとえば、特定の MEV が、MEV 課税の AMM に対して MEV 課税の UniswapX 注文を約定することによってのみ取得できる場合です。
この場合、各アプリケーションによって取得される超過 MEV の相対量は、それらのアプリケーションによって設定された MEV 税によって決まります。 MEV 税としての app_i の値が関数 Tax_i(priority) で与えられる場合、勝利トランザクションの優先度は、次の優先度の方程式を解くことによって決定できます。合計MEV
(技術的には、ブロック提案者に支払われる優先料を説明するために、第 3 項 priorityPerGas * Gas Used を追加することもできますが、付録 A で説明したように、通常の状況では、優先コストはおそらく無視できるため、これは無視します)。
priorityPerGas の線形 MEV 税 (つまり、tax_ 1(priorityPerGas) = a_ 1 * priorityPerGas ) の単純なケースでは、各アプリケーションが受け取る MEV シェアを求めることができます。
a_ 1 * 優先ガス当たりの優先度 + a_ 2 * 優先ガス当たりの優先度 = MEV
ガスあたりの優先順位 = MEV/(a_ 1 + a_ 2)
Tax_ 1(ガスあたりの優先度) =(a_ 1/(a_ 1+a_ 2))*MEV
Tax_ 2(ガスあたりの優先度) = (a_ 2/(a_ 1+a_ 2))*MEV
アプリケーションは、独自の MEV 税を設定する際にトレードオフに直面します。税率が高いほど、クロスアプリケーション MEV が発生したときに、より多くのシェアを獲得できますが、競合するアプリケーションが存在する場合、一部のクロスアプリケーション MEV を逃す可能性があります。 Appmevの抽出方法。たとえば、すべての取引に MEV 税を請求する AMM が 1 つある場合、MEV 税の UniswapX 注文は別の AMM またはオフチェーン フィラーによって約定される可能性があります。
多くの場合、2 つのアプリケーションがそれぞれの福祉を最大化する方法で MEV を共有するように MEV 税を設計するという均衡が存在する可能性があります。たとえば、MEV Tax AMM は、ブロックの先頭付近にある情報に基づいた 1 人のトレーダーから価値を取得したいが、その価値を他のトレーダーやアプリケーション (MEV Tax を使用するものを含む) がより低い固定手数料の流動性で利用できるようにしたい場合があります。この場合、AMM は比較的低い MEV 税 (例: $0.00001 * priorityFeePerGas ) を設定して、裁定取引 (存在する場合) がブロックの早い段階で発生し、その後ブロック内の後続の取引で MEV 税が請求されないようにします。 AMM と対話したい UniswapX のようなアプリケーションは、プールがすでに裁定取引された後にトランザクションが確実に含まれるように、より高い MEV 税 ($0.01 * priorityFeePerGas など) を設定できます。これらの相対的な税金により、UniswapX の注文が 1 ドルの MEV と 50,000 ドルの MEV だけであっても、AMM が最初に裁定取引されることになります。
私たちは、これは将来の研究に値する幅広い設計空間であると信じています。
制限
MEV 税にはいくつかの複雑さと落とし穴があります。これらは将来の研究にとって興味深い分野であると私たちは信じています。
インセンティブの非互換性
MEV 税は独占ブロック提案者に対するインセンティブと両立しません。これらは、トランザクションの包含に関して公正な競争が存在する場合にのみ機能します。これは、ブロックの提案者が自らの収益を最大化するのではなく、私たちが「競争的優先順位付け」と呼ぶルールに従う場合にのみ発生します。これらのルールには以下を含めることをお勧めします。
優先順位付け: ブロック内のトランザクションは、priorityFeePerGas の降順で並べ替える必要があります。
検閲への抵抗: ブロックの構築時にブロック提案者がトランザクション t 1 を受け取り、そのブロックがフルではないか、トランザクション t 2 を含み、かつ t 2.priorityFeePerGas < t 1.priorityFeePerGas である場合、ブロックにはトランザクション t 1 が含まれている必要があります。
トランザクション前のプライバシー: ブロックの提案者は、プライベート エンドポイントを通じてトランザクションを受け入れる必要があり、ブロックを送信する前にこれらのトランザクションを誰とも共有してはならず、また、これらのトランザクションの内容を使用して独自のトランザクションを構築することもできません。
時期はまだ決まっていない。ブロック提案者は、明確な時間 (blockTime) を設定し、その前は誰からもトランザクションを受け入れ、その後は誰からもトランザクションを受け入れないようにする必要があります。
これらの属性の 1 つ以上が違反されると、MEV 税の有効性が低下する可能性があります。検閲抵抗に違反するブロック提案者は、競合するトランザクションを除外し、優先度ゼロのトランザクションを提出することで、自らその機会を利用して、ほとんどの MEV 税を回避できます。トランザクション前のプライバシーを侵害するブロック提案者は、他のトランザクションから MEV を盗んだり、優先料金を覗き見して、他のトランザクションを上回るために優先料金をどのくらい高く設定する必要があるかを知ることができますが、他のトランザクションよりも遅くトランザクションを送信できるプロポーザーは、他の人よりも入札するかどうかを「最終的に決定する」自由は、最終的に競争を阻害する逆選択の問題を引き起こします。
残念ながら、最初のプロパティはプロトコル層で簡単に強制できますが、トラストレスな方法で他のプロパティを強制することは未解決の問題です。
プロトコル レベルでの強制がない場合、提案者がブロックの構築を競争収益最大化オークション (イーサリアム メインネットの MEV-Boost など) に委託する場合、これらのルールに準拠するシーケンサーは、これらのルールから逸脱しないと信頼される必要があります。彼らに従わないかもしれない。
これらの問題は、競争的な優先順位付けを使用してブロックを構築することを約束する単一の信頼できる発注者によって「解決」できます。また、コンセンサス、暗号化、および/または Sorella の Angstrom、Flashbots の SUAVE、Leaderless Auctions、Multiplicity などの信頼できる実行環境を組み合わせて使用することにより、分散型メカニズムで解決することもできます。
完全なブロック
ブロックが完全にいっぱいの場合、MEV 税の通常の動作には例外があります。この場合、ブロックの提案者は、優先度の低いトランザクションをブロックの後半に含めるだけでなく、除外する必要がある場合があります。 MEV 税を使用するアプリケーションと対話するトランザクションの優先料金は非常に低い可能性が高いため、これらのアプリケーションは、MEV 税を使用しないアプリケーションまたは非常に低い MEV 税を使用するアプリケーションによって混雑する可能性があります。ただし、EIP-1559 のようなメカニズムを使用して個別の基本料金を設定するチェーンでは、ブロックが完全にいっぱいになることは比較的まれです。さらに、ブロックがいっぱいになったときに一部のトランザクションを遅らせる必要があることを考慮すると、より高い MEV 税を設定して緊急性の低いトランザクションを遅らせるのが合理的な結果になる可能性があります。
トランザクションのロールバック
MEV 税は基本的に単一ブロックのオークションに依存しており、各「入札」が取引となります。このタイプのオークションの欠点の 1 つは、入札が失敗するとロールバック トランザクションがオンチェーンに含まれることが多く、基本料金が支払われ、チェーンが混雑することです。
シーケンサーが失敗したトランザクションを完全に除外できれば、この問題は軽減されますが、これは集中型シーケンサーでも達成するのは困難です。 (これも、上で説明した検閲耐性の特性に完全に準拠しているわけではありませんが、その定義は調整可能です。) より洗練されたシーケンサーは、トランザクションが参加する紛争オークションを指定できるようにすることで、このプロセスを最適化できる可能性があります。シーケンサーは、後続のトランザクションが失敗することがわかっているので、紛争オークションをスキップします。
ユーザーの意図を明らかにする
MEV 税は、検索者間で競争がある場合にのみ機能します。つまり、機会がある程度わかっている必要があります。 AMM のような、オンチェーンでチャンスが見えるアプリケーションの場合、これは自然に起こるはずです。ただし、インテントベースのルーティングやトレーリング入札などのアプリケーションの場合、これは、アプリケーションがユーザーのインテントを検索者と共有する必要がある可能性があることを意味します。
場合によっては、実装前にユーザーの意図をブロードキャストすることによって失われた一時的なプライバシーが、MEV 税では回復できない形で価値を漏洩する可能性があります。
たとえば、アリスが上記のトレーリング オークション プロトコルを使用して流動性の低いトークンを購入したいとします。彼女は、AMM でトークンを購入するために署名されたインテントをスマート コントラクト ウォレットにポストし、ある程度のスリッページ許容値を設定します。検索者は、ユーザーの注文に応じることなく、優先度の高い取引で競争して、そのトークンの価格をスリッページ許容範囲まで押し上げることができます。勝者のボブは、優先度の低いトランザクションにアリスの意図を含めてロールバックすることで、非競争的にアリスの意図を満たすことができます。これにより、アリスのトランザクションが挟まれ、MEV 税を逃れながら、より悪い価格を彼女に与えることができます。 NFTを購入する際にも同様の問題が発生する可能性があります。
ボブはトークンの購入とアリスへの販売の間のアトミック性を保証できないため、このような攻撃はボブにとって危険であることに注意してください。ナイーブなボブは、アリスが自分から価値のないトークンを購入する意図を公開し、自分の取引を挟むことを期待してボブにそのトークンを購入させる「サンドイッチ引き裂き」の罠の犠牲になる可能性がありますが、ボブがトークンを完了する前に、アリスはその意図を取り消します。サンドイッチ。
多くの既存の注文フロー オークションの場合と同様に、アプリケーションは、インテントを共有する検索者のセットを制限し、その動作を監視することでこれを軽減することもできます。
MEV 税と、Flashbots の SUAVE 設計で想定されているようなプライバシーを意識したビルダー機能を組み合わせることも可能です。
最後に、アリスが自分の意図を共有するコストが競合検索の利点を上回ると判断した場合は、自分でトランザクションを構築し、それをブロックに直接送信できます。前述したように、競合優先順位付けの理想的な実装では、ブロック提案者にトランザクション前のプライバシーが提供されます。
ディスカッションと準備作業
優先ガスオークション。 「マイナー抽出可能価値」という用語を生み出したFlash Boys 2.0の論文では、分散型ブロックチェーンにおける優先順位付けのダイナミクスの一部を調査しています。この論文は、イーサリアムマイナーが（ネットワークがプルーフ・オブ・ワークを使用していたとき）すでにトランザクションに優先順位を付けており、裁定取引者はこの行動を利用して「優先ガスオークション」に参加し、そこでブロックに含まれる権利を入札していたと観察している。まず、分散型取引所の裁定取引からの MEV のほとんどがマイナーに蓄積されます。
早い者勝ち。 ThemisやArbitrum One の現在のシーケンサーなどのトランザクション順序付けルール経由) を緩和するために、MEV は、ブロックの提案者がトランザクションを見た順序で順序付けする必要がある、別の順序付けルール (「公平な順序付け」と呼ばれることもあります) を適用することに重点を置いています。
優先順位付けには別のアプローチが採用されます。指定された期間内に到着するトランザクションは平等に扱われ、宣言された優先順位に従って並べ替えられます。
「公平な順序付け」は、複数のバリデータがある実際のネットワーク環境で強制したり、定義したりすることさえ困難です。また、信頼できるシーケンサーが 1 つであっても、無駄なレイテンシー レースやスパムが発生する可能性があります。最後に、MEV 税は、資産価格の個別の「急騰」による裁定利益など、特定の「先着順」の MEV を排除できる可能性があります。先着順に対する優先順位の潜在的な利点は、 Budish、Cramton、Shim (2015)で議論されている連続時間交換に対する離散時間交換の利点に部分的に関連しています。
また、優先順位付けはデフォルトで MEV に値を漏洩するように見えますが、この投稿ではそれを取り戻すためのアプリケーションを設計する方法を示します。
費用分担。 Blast はイーサリアム L2 であり、トランザクションでアクセスされるスマート コントラクトと一部の優先料金と基本料金を共有します。
MEV 税では、同様のことが (少なくとも優先料金に関しては) 許可されていますが、料金共有のための特別なサポートを必要とせずに、競争的な優先順位付けを使用して、任意のチェーンのアプリケーション層で実装できます。また、アプリケーションが独自の税金を優先料金のカスタム関数として定義できるため、柔軟性が向上し、MEV 対応アプリケーションの構成可能性が向上する可能性があります。
トラストレスなソリューション。この記事では、トラストレスに競争優先順位付けを強制する方法について説明するのではなく、プラットフォームが競争優先順位付けを使用する動機と、競争優先順位付けプラットフォームを活用する方法に焦点を当てます。
競争上の優先順位付けに必要なその他の各属性については、これまでに詳しく説明しました。たとえば、 Fox、Pai、Resnick (2023)では、著者らは検閲耐性のないオンチェーン オークションの脆弱性について議論し、複数の同時提案者を使用した検閲耐性オークションの設計について説明しています。ただし、特定のトランザクション順序を推奨するものではありません。
他にも、FlashbotsのSUAVE、SorellaのAngstrom、Leaderless Auctions、EspressoとOffchain Labsの分散型Timeboost、Péter Szilágiの強制パブリックトランザクションパッケージングなど、信頼を最小限に抑えたブロック構築メカニズムの構築に関する研究があります。
結論は
この記事が L2 に優先順位付け (OP スタックによってデフォルトでサポートされている) の使用を検討するよう促し、サポートされている場合にはアプリケーションが MEV タックスを試す動機になることを願っています。
また、このことが、L1 および L2 における信頼を最小限に抑える競合優先順位付けプロトコルに関するさらなる研究のきっかけとなることを期待しています。
脚注
この記事では、特定のブロックにどのトランザクションが含まれるかを決定するアクターまたはプロセスを指すために「プロポーザー」を使用します。イーサリアム L2 では、この役割は通常「シーケンサー」によって行われます。イーサリアム L1 では、プロポーザーと呼ばれる特定のイーサリアム検証者によってデータが設定されますが、プロポーザーは通常、ブロックを構築するタスクを「中継者」と「ビルダー」が参加する競争オークションに委託します。これらの責任がどのように分担されるかについての詳細は、この記事の範囲を超えています。
実際には、ガスごとの優先料金はトランザクションで明示的に指定されていませんが、トランザクションで計算できます。トランザクションではガス価格が指定されますが、イーサリアムはガス価格から差し引かれて燃やされる基本料金も請求します。 MEV 税に関する限り、基本料金はディーラーの管理外であるため、無視する必要があります。 Gas ごとの優先手数料 (つまり、ブロック提案者に支払われるトランザクション手数料の部分の価格) は、Solidity で priorityGasPrice = tx.gasprice - block.basefee として計算できます。
「MEV」を定義するだけで、検索者の利益を除外し、バリデーターに流れる値のみを参照できます。
最終的にトランザクションで使用されるガスの量を知る方法がないため、proposerPriorityFee は、契約中にトランザクションで使用された合計ガス priorityFeePerGas 量 (トランザクションで使用された合計ガスに等しい) の倍数を実際には計算できないことに注意してください。ただし、必要なのは上限だけであるため、通常はこれは問題になりません。安全を期すために、priorityFeePerGas に 3,000 万を掛けることができます。これは、イーサリアム ブロック内の現在の最大ガスです。この値を過大評価すると、MEV に占める MEV の割合が大きくなるだけになります。
トランザクションが 3,000 万 Gas を超えることができないと仮定すると、priorityFeePerGas が 50,000 の場合、Gas の支払いは 1500 グウェイ (ETH 価格 4000 ドルで約 0.006 ドル) になります。
裁定取引者の利益がゼロになるように priorityFeePerGas が設定されている場合、利益を最大化する裁定取引は、AMM を最大化する関数上の同じ取引に対応する必要があります。
Arbitrum では、これを Timeboost と呼ばれる優先順位付けの形式に置き換えることについて議論していますが、この記事の執筆時点ではまだ運用されていません。
