Paradigm 新文：MEV 税と優先順位

パラダイム

2024-06-05 14:49:42

コレクション

MEV税メカニズムは、任意のアプリケーションがそのMEVをキャッチし、コンポーザビリティを維持することを可能にします。

共有する

WeChatでQRコードをスキャン

著者：Dan Robinson, Dave White

編纂：Joyce，BlockBeats

イントロダクション

この記事では、任意のアプリケーションが自らの MEV をキャッチするために使用できるメカニズムである MEV 税について紹介します。このメカニズムは、OP Mainnet、Base、Blast などの OP Stack L2 で利用可能であり、これらのチェーンのブロック提案者は、競争優先順位付けと呼ばれる一連のルールに従っています。

特定のチェーンに MEV 税を課すために、スマートコントラクトは取引優先費用の関数として手数料を徴収します。アプリケーションが検索者に対して 1 ドルの優先費用ごとに 99 ドルの MEV 税を課す場合、その取引の 99% の競争的 MEV をキャッチすることができます。

MEV 税はシンプルな技術であり、広範な設計空間を開くことができます。これを、チェーン上の任意のアプリケーションが独自のカスタム MEV オークションを実行できるようにするものと考えることができ、独自のオフチェーンインフラストラクチャを持つことなく、ブロック提案者が運営する単一の共有オークションに接続するだけで済みます。

私たちは、MEV 税を利用して MEV 研究における 3 つの主要な問題を解決する方法を説明します：

分散型取引所 (DEX) ルーターは、交換者が受け取る価格を最適化します；
自動マーケットメーカー (AMM) は、流動性提供者が経験する損失と再バランス (LVR) を最小限に抑えます；
ユーザーが取引によって生成された「バックラン」MEV をキャッチできるようにするウォレット；

しかし、問題があります。MEV 税は、ブロック提案者が取引を優先費用に基づいて順序付けし、取引を検閲、覗き見、または遅延させないという競争的優先順位付けルールを厳守する場合にのみ機能します。ブロック提案者がこれらのルールから逸脱すると、MEV 税を回避し、自らの利益を得ることができます。したがって、現在、MEV 税は信頼された L2 ソーターに依存しており、イーサリアム L1 では機能しない可能性があります。イーサリアム L1 では、ブロック構築が競争的なビルダーオークションによって主導され、提案者の収入を最大化します。

それにもかかわらず、MEV 税の力と柔軟性は、現在このサービスを提供できるプラットフォームにとって、優先順位付けが正しい選択である可能性を示しています。競争的優先順位付けの相対的な単純さは、単一のソーターを信頼することなく、分散型で強制する実行可能な方法が存在する可能性を示唆しています。この記事がこの問題に対するさらなる研究を刺激することを願っています。

優先順位付け

誰かがイーサリアム L1 または L2 で取引を送信するとき、彼らは優先費用を指定し、それをブロック提案者に支払います。これを priorityFeePerGas（優先順位費用）として指定され、取引で使用されるガスに掛け算して builderPriorityFee---ETH で表される総支払いを得ることができます。

イーサリアムプロトコルでは、ブロック内の取引が priorityFeePerGas に基づいて降順で貪欲に順序付けられる必要はありません。しかし、これはブロックを構築する人気のある方法であり、たとえば OP Stack チェーンのソーターや geth、reth が使用するデフォルトのアルゴリズムです。優先順位付けは、トレーダーが取引の緊急性を効果的に表現できるだけでなく、特定のタイプの MEV を自然にブロック提案者に渡すことを可能にします。

このようなことが起こるのは、優先順位付けが MEV の競争を優先ガスオークションに変えるからです。チェーンとの相互作用から利益を得る機会がある場合、たとえば AMM と中央集権型取引所との間でアービトラージを行う場合、検索者は先手を取るために競争します。チェーンが取引を含めて順序付けるために優先順位付けを使用する場合、検索者は自らの取引に高い優先費用を設定することで競争します。

リスクのない利益競争がゼロの競争シナリオでは、勝利した検索者は最終的に全額の MEV 優先費用を支払うべきです。したがって、契約との相互作用を通じて 100 ETH の利益を得ることができる場合、その利益を最初に請求する取引は 100 ETH の優先費用を設定します。（制限のセクションでいくつかの注意点について議論します）。

MEV 税

スマートコントラクトが相互作用する任意の取引から MEV をキャッチしたいと仮定します。スマートコントラクトが自らの MEV をキャッチするために試みることができるさまざまな特定のアプローチについての研究が豊富にあります。

しかし、実際には、アプリケーションに関する情報を必ずしも理解する必要はありません。ブロックが競争的優先順位付けによって構築されたことがわかれば、取引中の MEV の量に関する一般的な信号があります：優先費用です。

私たちは、スマートコントラクトが取引の優先費用を確認し、特定の増加関数として自らの費用を徴収できると提案します。たとえば、契約は呼び出し元に対して ETH の中で applicationPriorityFee = 99 * proposerPriorityFee を契約に転送するよう要求することができます。

この新しい費用は、取引を送信する検索者によって支払われるため、その検索者の行動に影響を与えます。機会に 100 MEV がある場合、勝利した取引は現在 1 ETH の優先費用を設定するだけで済みます。なぜなら、これにより合計で 100 ETH（1 ETH がブロック提案者に支払われ、99 ETH がスマートコントラクトに支払われる）を支払うことになるからです。より高い優先費用は取引を無利にし、より低い優先費用は高い費用を設定した競争相手に機会を失わせます。これにより、スマートコントラクトは取引中の 99% の MEV をキャッチしたことになります。

私たちは、スマートコントラクトが徴収するこの追加費用を MEV 税と呼びます。MEV 税は、アプリケーションが自らの利益のために優先順位付けをハイジャックし、ユーザーのために MEV を再キャッチすることを可能にします。これは、ブロック提案者に漏洩するのではなく、ユーザーのために再キャッチすることを可能にします。

この費用が priorityFeePerGas の関数として十分に早く増加する場合、提案者は微々たる MEV しか得られません。priorityFeePerGas は wei（1 ETH の 10 億分の 1）で価格が設定されるため、多くの精度を扱う必要があります。たとえば、MEV 税が十分に敏感であれば、50,000 の priorityFeePerGas は過剰な税金を引き起こし、提案者に支払われる総額は 0.01 ドル未満になります。(5)

しかし、重要な警告があります。「制限」セクションで議論されているように、MEV 税は、ブロック提案者が収入を最大化するためにこれらのルールから逸脱するのではなく、特定のルール（私たちが「競争的優先順位」と呼ぶ）に従う場合にのみ機能します。これらのルールを信頼できない方法で実行することは未解決の問題です。

単一アプリケーション MEV キャッチ

ここでは、競争的優先順位付けを使用してブロックを構築するチェーン上で、MEV 税が MEV における 3 つの重要な問題を緩和するためにどのように使用できるかを概説します：DEX インターフェースが交換者の取引実行を改善し、AMM が流動性提供者のアービトラージ損失を減少させ、ウォレットがユーザーの MEV 漏洩を減少させるためにユーザーのバックラン権を販売することを可能にします。

分散型取引所ルーター

UniswapX や 1inch Fusion などの意図に基づく DEX ルーティングプロトコルでは、ユーザー（アリス）は交換の意図を署名し、検索者はアリスのために最良の価格でその意図をルーティングまたは埋めるために競争します。

UniswapX の現在のバージョンは、競争を行うために 2 つのメカニズムを使用しています：オランダ式オークションで、アリスのリミット価格は時間とともに変化し、検索者が埋めるまで変化します；およびオランダ式オークションの開始価格を設定するための初期オフチェーン見積もり (RFQ) オークション。

競争的優先順位付けが保証されたプラットフォーム上で、UniswapX はこれらのメカニズムを単一のメカニズムで置き換えることができます：MEV 税。これは、ユーザーが誰でも即座に埋めることができる注文を署名させることによって実現できますが、実行価格は取引優先順位の関数として設定されます。

たとえば、アリスが 1 ETH を売却する UniswapX 注文を持っている場合、彼女は注文の実行価格を minimumPrice + ($0.01 * priorityFeePerGas) と定義できます。minimumPrice は特定の固定値であり、彼女はその値が現在の価格を明らかに下回ると予想しています。

検索者は取引を提出することでアリスの注文を埋めるために競争します。どの取引が最も高い優先費用を持ち、かつ復元されないかに応じて、その注文が完了します。これにより、交換者は検索者が見つけることができる最良の価格を得ることが保証されるはずです。（「制限」セクションではいくつかの例外について議論します。）

アリスの最低価格が 3,000 ドルで、ETH の現在の価格が 3,500 ドルの場合、勝利した取引の priorityFeePerGas は約 50,000 になります。（200,000 ガスを費やす取引では、ブロック提案者に約 100 億 wei（約 0.000035 ドル）が支払われることになります。）

UniswapX で使用される既存のメカニズムと比較して、これにはいくつかの潜在的な利点があります。

オランダ式オークションを使用した注文と比較して、MEV 税を使用した注文はより迅速に完了し、より良い価格で取引される可能性があります。この記事で議論されているように、ブロック間の価格変動のために、チェーン上のオランダ式オークションは MEV の一部の価値を漏洩させる可能性があり、完了するまでに多くのブロックを要する可能性があります。それに対して、MEV 税を使用した注文は通常、次のブロックで完了し、ほとんどの MEV をキャッチすることができます。

オフチェーン見積もりとは異なり、MEV 税を使用した注文のオークションは、チェーン上の取引が実行されると自動的に行われます。これは、入札者がチェーン上の取引が成功した場合にのみ注文を埋めることを保証します。これにより、AMM などのチェーン上の流動性がオフチェーン流動性と競争しやすくなり、UniswapX が Uniswap v4 などのマルチプールシステムのより効率的なルーターとして機能できるようになります。

AMM

通常、AMM はアービトラージャーに価値を漏洩させます。彼らはブロックの先頭の古い価格に基づいて取引を行い、損失と再バランスの論文で議論されているように、私たちは MEV 税を使用して AMM が MEV をキャッチできるようにします。簡単のために、集中流動性がない場合の AMM での機能について議論します。（集中流動性を通じてこのような問題を解決する方法に興味がある場合、Sorella はすぐに解決策を発表します。）

AMM は、取引優先費用の関数として追加費用を徴収することによって MEV をキャッチできます。これにより、ブロック内で最初に取引を行う権利をオークションにかけることができます。この費用を計算し、価格を設定する方法はいくつかあります。私たちは、資金プールの流動性を単位として sqrt(xy) を使用する中立的な方法を議論します。勝利した取引は、マイニングプールの流動性を最大限に増加させる取引となります。

ブロック内のプールで最初の取引を実行する際、プールは条件を強制することができます（a を特定の定数とし）、条件 xend * yend > xstart * ystart を強制するのではなく：

xend * yend > (sqrt(xstart * ystart) + a*priorityFeePerGas)\^2

この公式は、アービトラージ取引者が実際の価格で取引を行うように促し、その取引の後、プール内の中間価格は実際の価格であるべきです。

最初の取引の後、取引は Uniswap v2 のように行われ、固定のスワップ手数料を持ちます。プール内で追加の MEV 税を支払わずに取引を行いたい無知な取引は、低い優先費用を設定します。

AMM に MEV 税を実施する方法は他にも多くあり、異なる効果を生む可能性があります。たとえば、MEV 税はスワップの入力または出力トークンで価格設定され、プールに適用されるスワップ手数料のパーセンテージに影響を与える可能性があります。または、ユーザー取引の最低価格を決定することもできます。これは探求する価値のある興味深い設計空間だと考えています。

バックランオークション

上記の説明は、特定のアプリケーションを設計して MEV 漏洩を回避する方法を示しています。しかし、もしウォレットがユーザーが任意のアプリケーションとの相互作用から生成した MEV をキャッチするのを助けたい場合、特に MEV 税を含まないアプリケーションの場合、どうすればよいでしょうか？

たとえば、アリスが AMM で大規模な取引を行うとき、彼女は時々「バックランナー」にアービトラージの機会を提供し、価格を引き戻します。これは通常、アリスに対して MEV を漏洩させることになります。

MEV-Share と MEVBlocker は、ユーザーが取引から MEV をキャッチできるようにする 2 つのプロトコルですが、これらは複雑なオフチェーンオークションシステムに依存しています。注文フローオークションの設計空間は、他のいくつかの解決策を示しています。

MEV 税と意図に基づくスマートコントラクトウォレットを組み合わせることで、アリスがバックランの MEV をキャッチできる代替システムを構築できます。アリスが AMM で取引を行う取引を作成するのではなく、誰でもアリスのスマートコントラクトウォレットに提出できるようにする意図を署名したと仮定します。このアリスのスマートコントラクトウォレットは、その取引を提出した者に MEV 税を課し、その税はアリスに支払われます。

アリスの意図を提出した検索者は、彼女の取引を自動的に実行する専有権を持つことになります。したがって、検索が競争的であれば、アリスのすべての利益は MEV 税を通じてアリスの手に帰するべきです。

このシステムは、ユーザーの取引を先行取引ユーザーの取引から攻撃することからユーザーを保護するわけではありません。なぜなら、先行取引ユーザーの取引は、そのユーザーに MEV 税を支払うことを回避できる可能性があるからです。この問題（およびいくつかの可能な緩和策）は、以下の制限セクションでより詳細に議論されます。それにもかかわらず、これは少なくとも公共メモリプールを使用し、緩和策がないシステムに対する改善となる可能性があります。

その他のユースケース

これらの例に加えて、MEV 税の他の潜在的な用途には、現在オフチェーンまたはオランダ式オークションを使用しているほぼすべてのものが含まれる可能性があります。たとえば：

予言者がその創造した予言者が抽出可能な価値をキャッチするプロトコル、たとえば Oval；
Blend などの NFT 担保ローンプロトコルの再融資オークション；
借入プロトコルの清算による漏洩価値がオランダ式オークションを下回る；

クロスアプリケーション MEV キャッチ

上記の解決策は、単一のアプリケーションとの相互作用における MEV をキャッチすることを目的としています。しかし、時には検索者が同じ取引内で複数のアプリケーションと相互作用することによって、より多くの価値を得ることができる場合があります。

これらのアプリケーションのうちの 1 つだけが MEV 税を持っている場合、取引内のすべての MEV は MEV 税を持つアプリケーションに移転されるべきです。MEV 税がどれほど高いか低いかにかかわらず。

しかし、検索者の取引が MEV 税を使用する 2 つのアプリケーションと相互作用する場合はどうでしょうか？たとえば、MEV をキャッチするために、MEV 税を支払う AMM の上にある UniswapX 注文のいずれかを埋める必要がある場合はどうでしょうか？

この場合、各アプリケーションがキャッチする超過 MEV の相対的な量は、これらのアプリケーションがどのように MEV 税を設定するかに依存します。MEV 税として徴収される価値 appi が関数 taxi(priority) によって与えられる場合、勝利した取引の優先順位は次の等式の優先順位を解くことによって決定できます：

tax1(priorityPerGas) + tax2(priorityPerGas) = total MEV

（技術的には、priorityPerGas * gasUsed のために 3 番目の項を追加して、ブロック提案者に支払われる優先権費用を考慮することができますが、通常は無視できます）

MEV 税と priorityPerGas が線形関係にある単純な場合（したがって tax1(priorityPerGas) = a1 * priorityPerGas）、各アプリケーションが受け取る MEV のシェアを解決できます：

a1 * priorityPerGas + a2 * priorityPerGas = MEV
priorityPerGas = MEV/(a1 + a2)
tax1(priorityPerGas) = (a1/(a1+a2))*MEV
tax2(priorityPerGas) = (a2/(a1+a2))*MEV

自らの MEV 税を設定する際、アプリケーションはトレードオフに直面します - より高い税金は、クロスアプリケーション MEV が発生する際により大きなシェアを得ることを可能にしますが、これは、抽出するための競争的な方法が存在する場合、いくつかのクロスアプリケーション MEV を逃す可能性があることを意味します。たとえば、ある AMM が各取引に MEV 税を課す場合、MEV 税を支払う UniswapX 注文は、異なる AMM またはオフチェーンの埋め手によって埋められる可能性が高くなります。

多くの場合、2 つのアプリケーションがそれぞれの利益を最大化する方法で MEV を共有するように MEV 税を設計する均衡が存在する可能性があります。たとえば、MEV 税 AMM は、ブロックの先頭近くの単一の知情取引者から価値を得たいと考えていますが、その後、他の取引者やアプリケーション（MEV 税を使用するアプリケーションを含む）に流動性を提供したいと考えています。この場合、AMM は比較的低い MEV 税（たとえば $0.00001 * priorityFeePerGas）を設定し、アービトラージ取引（存在する場合）がブロックの早い段階で発生するようにし、その後の取引に対して MEV 税を課さないことができます。UniswapX のように AMM と相互作用したいアプリケーションは、プールがすでにアービトラージされた後に取引を含めることを保証するために、より高い MEV 税（たとえば $0.01 * priorityFeePerGas）を設定できます。これらの相対的な税金を考慮すると、UniswapX 注文に 1 ドルの MEV と 50,000 ドルの MEV がある場合でも、AMM は最初にアービトラージされることになります。

これは、将来の研究に値する広大な設計空間だと考えています。

制限

MEV 税にはいくつかの複雑さと欠点があり、これらは将来の研究の興味深い分野だと考えています。

インセンティブの不整合

MEV 税は、独占的なブロック提案者に対してインセンティブが整合しません。これは、取引の包摂性が公平な競争の下で存在する場合にのみ機能し、ブロック提案者が私たちが「競争的優先順位付け」と呼ぶルールに従う場合にのみ発生します。非公式に提案されたルールのいくつかを以下に示しますが、これに限定されません：

優先順位付け。ブロック内の取引は priorityFeePerGas に基づいて降順で順序付けられなければなりません。
検閲制度の抵抗。ブロック提案者がブロックの間に取引 t1 を受け取り、そのブロックが満杯でない場合、または特定の取引 t2 を含む場合、たとえば t2.priorityFeePerGas < t1.priorityFeePerGas の場合、そのブロックは取引 t1 を含まなければなりません。
取引前のプライバシー。ブロック提案者はプライベートエンドポイントを介して取引を受け入れ、ブロックに提出される前に他の誰ともそのような取引を共有してはならず、またその取引の内容を使用して自らの取引を構築するための入力として使用してはなりません。
最後の検閲なし。ブロック提案者は、明確なブロック時間を設定し、その時間以前に誰からの取引リクエストも受け入れ、以降は誰からの取引リクエストも受け入れないようにしなければなりません。

これらの属性のいずれかが違反されると、MEV 税の有効性が損なわれる可能性があります。検閲制度に違反するブロック提案者は、競争取引を排除し、自らの利益を得るためにゼロ優先取引を提出することで、ほとんどの MEV 税を回避できます。取引前のプライバシーに違反するブロック提案者は、他の取引から MEV を盗むか、優先費用を確認して自らの費用をどれだけ高く設定する必要があるかを正確に知ることができ、他の人よりも遅れて取引を提出できるブロック提案者は、他の人よりも高い価格で機会を得るための「最後の確認」を行うことができ、これらの状況は逆選択の問題を引き起こし、最終的には競争を妨げる可能性があります。

残念ながら、最初の属性はプロトコル層で強制するのは容易ですが、他の属性を信頼できない方法で強制することは未解決の問題です。

プロトコル層での強制が欠如している場合、これらのルールから逸脱しないことを約束する単一の信頼できるソーターを信頼する必要があり、提案者がブロック構築を競争的な収入最大化オークション（たとえばイーサリアム L1 の MEV-Boost）にアウトソーシングすると、ブロックはそれに従わない可能性があります。

これらの問題は、競争的優先順位付けを使用してブロック構築を約束する単一の信頼できるソーターによって「解決」される可能性があります。また、Sorella の Angstrom、Flashbots の SUAVE、リーダーレスオークション、またはマルチシグなど、コンセンサス、暗号学、または信頼できる実行環境のいずれかの組み合わせを使用した分散型メカニズムによっても解決される可能性があります。

完全なブロック

ブロックが完全に満杯のとき、MEV 税が正常に機能する例外が発生します。この場合、ブロック提案者は優先度の低い取引を放棄せざるを得ないかもしれません。MEV 税アプリケーションと相互作用する取引が非常に低い優先費用を持つ可能性があるため、これらのアプリケーションは MEV 税を使用しないアプリケーションや MEV 税が非常に低いアプリケーションに押し出される可能性があります。しかし、EIP-1559 のようなメカニズムを使用して個別の基本料金を設定するチェーンでは、ブロックが完全に満杯になる状況は比較的まれであるべきです。さらに、ブロックが満杯のときに特定の取引が遅延する必要があることを考慮すると、より高い MEV 税を設定して、優先度の低い取引を遅延させることは合理的な結果かもしれません。

復元された取引

MEV 税は、単一のブロックオークションに依存しており、各「入札」は 1 回の取引です。これらのオークションの欠点は、失敗した入札が通常、復元された取引がチェーン上に含まれ、基本料金を支払い、チェーンの混雑を引き起こすことです。

ソーターが失敗した取引を完全に排除できる場合、これは問題を緩和しますが、集中型ソーターを使用しても実現が難しいです。（また、上記の検閲抵抗属性を厳密に遵守することはできませんが、その定義を調整することはできます。）より複雑なソーターは、取引がどの競争的オークションに参加しているかを指定できるようにすることでこのプロセスを最適化でき、ソーターは失敗することがわかっている後続の取引をスキップするために十分な情報を持つことができます。

ユーザー意図の漏洩

MEV 税は、検索者間に競争が存在する場合にのみ機能します。これは、この機会がある程度広く知られている必要があることを意味します。AMM のようなアプリケーションにとって、機会はチェーン上で可視化されるため、これは自然に発生するはずです。しかし、意図に基づくルーティングやバックオークションなどのアプリケーションにとっては、アプリケーションがユーザーの意図を検索者と共有する必要があることを意味します。

場合によっては、ユーザーの意図が実現される前にユーザーの意図を広めることによって生じる一時的なプライバシーの損失が、MEV 税では回収できない方法で価値を漏洩させる可能性があります。

たとえば、アリスが上記のバックランオークションプロトコルを使用して流動性の低いトークンを購入したいと考えていると仮定します。彼女は AMM でそのトークンを購入するためのスマートコントラクトウォレットの署名された意図を公開し、一定のスリッページ許容範囲を設定します。検索者は、アリスのスリッページ許容範囲までそのトークンの価格を引き上げるために高優先度の取引で競争することができますが、ユーザーの注文を埋めることなく。次に、勝者のボブは、低優先度の取引にそれを含めて逆行することで、アリスの取引を挟み込み、彼女により悪い価格を提供し、同時に彼女の MEV 税を回避することができます。NFT の購入でも同様の問題が発生する可能性があります。

このような攻撃は、ボブにとってリスクがあることに注意してください。なぜなら、彼はトークンを購入してアリスに売却する間の原子性を保証できないからです。無邪気なボブは「夹击撕裂」トラップに陥る可能性があります：アリスが無価値なトークンを自分から購入する意図を最初に公開し、ボブは彼女の取引を夹击するためにそのトークンを購入しますが、ボブが夹击を完了する前にアリスが彼女の意図を撤回します。

アプリケーションは、意図を共有する検索者の集合を制限し、彼らの行動を監視することによって、この状況を緩和することもできます。これは、多くの既存の注文フローオークションが行っていることです。

MEV 税をプライバシーを意識したビルダー機能と組み合わせることもできます。これは、Flashbots が SUAVE のために設計したものです。

最後に、アリスが意図を共有するコストが競争的な検索の利益を上回ると考えた場合、彼女は自分で取引を構築し、それを直接ブロックに提出することができます。前述のように、競争的優先順位付けの理想的な実装は、ブロック提案者に取引前のプライバシーを提供します。