Paradigm新記事：MEV税と優先順位付け

2024.06.05

共有先

TechFlow厳選深潮セレクト

Paradigm新記事：MEV税と優先順位付け

MEV税メカニズムにより、あらゆるアプリケーションがそのMEVをキャプチャしつつ、引き続きコンポーザビリティを維持できるようになる。

2024.06.05 - 06:29:45

MEV

Web3業界の深掘り報道に専念し潮流を洞察

MEV税メカニズムにより、あらゆるアプリケーションがそのMEVをキャプチャしつつ、引き続きコンポーザビリティを維持できるようになる。

著者：Dan Robinson, Dave White

翻訳：Joyce，BlockBeats

はじめに

本稿では、MEV税（MEV Tax）について紹介する。これは任意のアプリケーションが自身のMEVを捕獲できるようにするメカニズムである。この仕組みは現在、OP Stack L2であるOP MainnetやBase、Blastなどですでに利用可能であり、これらのチェーンにおけるブロックプロポーザーが「競合優先順位付け」と呼ばれる一連のルールに従っているためである。

あるチェーン上でMEV税を課すには、スマートコントラクトがトランザクションのプライオリティ料金に基づく手数料を徴収する。たとえば、アプリケーションが検索者（searcher）の1ドルの優先料金に対して99ドルのMEV税を課す場合、その取引の競争的MEVの99％を回収できる。

MEV税はシンプルな技術でありながら、広大な設計空間を開く。これを用いれば、チェーン上のあらゆるアプリケーションが、独自のオフチェーンインフラを持たずに自前のカスタムMEVオークションを実行できるようになる。必要なのは、ブロックプロポーザーが運用する単一の共有オークションに接続することだけだ。

以下では、MEV税を活用してMEV研究における3つの主要課題を解決する方法を説明する。

・分散型取引所（DEX）ルーターによるスワップ価格の最適化

・自動マーケットメイカー（AMM）による流動性提供者の損失とリバランス（LVR）の低減

・ユーザーが自身の取引によって生じる「バックラン」MEVを捕獲可能なウォレットの実現

しかし問題がある。MEV税は、ブロックプロポーザーが「競合優先順位付け」と呼ばれるルールを厳密に遵守している場合にのみ有効である。これには、プライオリティ料金に基づいてトランザクションを並べ替えつつ、いかなる取引も検閲せず、覗き見ず、遅延させないことが含まれる。もしプロポーザーがこれらのルールから逸脱すれば、MEV税を回避し、自らが価値を獲得できてしまう。したがって現在のところ、MEV税は信頼されたL2ソーターやセケンサーに依存しており、特にブロック構築が競争的なビルド者オークションによって支配され、プロポーザーの収益を最大化しようとするイーサリアムL1では機能しない可能性が高い。

それでもなお、MEV税の強力さと柔軟性は、現在このサービスを提供可能なプラットフォームにとって、優先順位付けが正しい選択肢である可能性を示唆している。競合優先順位付けの相対的な単純さは、単一のソーターを信用せずに分散的に強制執行可能な手段が存在しうることを示唆している。我々は、この問題に対するさらなる研究が促進されることを期待している。

優先順位付け

誰かがイーサリアムL1またはL2上でトランザクションを送信するとき、彼／她是非にプライオリティ料金を指定し、それをブロックプロポーザーに支払う。これはpriorityFeePerGasとして指定され、ガス使用量との積により、builderPriorityFee――ETHで表される総支払い額――が決定される。

イーサリアムプロトコルは、ブロック内のトランザクションがpriorityFeePerGasの降順で貪欲に並べられなければならないとは規定していない。しかし、これは人気のあるブロック構築方式であり、例えばOP Stackチェーンのソーター、およびgethやrethが採用するデフォルトアルゴリズムでもある。優先順位付けは、取引者が自身の取引の緊急性を効果的に表現できるだけでなく、特定タイプのMEVを自然にブロックプロポーザーへと移転させる。

こうした現象は、優先順位付けがMEVの競争をプライオリティガスオークションに変換するため起こる。チェーンとのインタラクションを通じて利益を得る機会があるとき（例：AMMと中心化取引所間の裁定取引）、検索者は先んじてその利益を獲得しようとする。もしチェーンが取引の包含と順序決定に優先順位付けを用いているなら、検索者は高いプライオリティ料金を設定することで競い合う。

リスクフリーの利益がゼロとなる完全競争状態では、勝利した検索者は最終的にMEV全額をプライオリティ料金として支払うことになる。したがって、コントラクトとのインタラクションで100 ETHの利益が得られる場合、その利益を最初に取得するトランザクションは100 ETHのプライオリティ料金を設定する。（限定的な条件については後述の「限界」セクションで言及する。）

MEV税

スマートコントラクトが自身と相互作用するすべての取引からMEVを捕獲したいと仮定しよう。アプリケーション固有の方法で自身のMEVを捕獲しようとするさまざまなアプローチについては、すでに多くの研究が行われている。

しかし実際には、アプリケーションに関する詳細な知識は必ずしも必要ではない。もしそのブロックが競合優先順位付けによって構築されていることを知っていれば、取引中のMEV量を示す一般的なシグナルが存在する：それは「プライオリティ料金」である。

そこで我々は、スマートコントラクトが取引のプライオリティ料金を参照し、その増加関数として自らの手数料を課すことができると提案する。たとえば、コントラクトは呼び出し元に対し、applicationPriorityFee = 99 * proposerPriorityFee（ETH単位）をコントラクトに送金するよう要求できる。

この新たな手数料は、取引を送信する検索者が負担するため、検索者の行動に影響を与える。もし機会に100 MEVの価値があるなら、勝利する取引は1 ETHのプライオリティ料金を設定するだけでよい。なぜなら、これにより合計100 ETHが支払われる（1 ETHはブロックプロポーザーに、99 ETHはスマートコントラクトに）。より高い料金を設定すれば取引は非収益的になり、より低い料金では、より高い料金を提示した競争相手に機会を奪われてしまう。つまり、スマートコントラクトは取引のMEVの99%を捕獲したことになる。

我々は、スマートコントラクトが徴収するこの追加手数料を「MEV税」と呼ぶ。MEV税により、アプリケーションは優先順位付けを自らの利益のために乗っ取り、ユーザーのためにMEVを再捕獲することが可能となり、それがブロックプロポーザーに漏れ出ることを防ぐ。

もし手数料がpriorityFeePerGasの関数として十分速く増加すれば、プロポーザーが得るMEVは無視できるほど小さくなる。priorityFeePerGasはwei（1 ETHの10億分の1）単位であるため、精度の扱いに注意が必要だ。たとえば、MEV税が十分に感度高く設定されており、priorityFeePerGasが50,000であれば税額が過剰になるようにすれば、プロポーザーに支払われる金額は0.01ドル未満に抑えられる。(5)

ただし重要な注意点がある。「限界」セクションで述べるように、MEV税はブロックプロポーザーが特定のルール（我々が「競合優先順序」と呼ぶ）に従い、自らの収入を最大化するためにそれらから逸脱しない場合に限り機能する。これらルールを非信頼的に施行することは、未解決の問題である。

単一アプリケーションにおけるMEV捕獲

ここでは、競合優先順序が保証されたブロック構築を行うチェーンにおいて、MEV税がDEXルーターによる交換者の取引執行改善、AMMによるLPへの裁定損失低減、そしてユーザーの逆走（バックラン）MEVを売却することでMEV漏洩を抑えるウォレットの実現といった、MEVの3つの重要課題を緩和するためにどのように使えるかを概説する。

分散型取引所ルーター

UniswapXや1inch FusionのようなインテンションベースのDEXルーティングプロトコルでは、ユーザー（Alice）がスワップインテンションに署名し、検索者がそのインテンションを最も有利な価格でルーティングまたはフィルする競争を行う。

現在のUniswapXバージョンでは、二つのメカニズムが使われている。一つは時間とともにAliceの指値価格が変化していくダッチ式オークション、もう一つはダッチ式オークションの開始価格を設定するための初期オフチェーンRFQ（Request for Quote）オークションである。

競合優先順序が保証されたプラットフォームでは、UniswapXはこれらのメカニズムを一つの仕組み――MEV税――で置き換えることができる。具体的には、ユーザーが誰でも即座に実行可能な注文に署名するが、その執行価格はトランザクションの優先順位に応じて決まるようにする。

たとえば、Aliceが1 ETHを売るUniswapX注文を持つ場合、その執行価格をminimumPrice + ($0.01 * priorityFeePerGas)と定義できる。minimumPriceは固定値であり、現在価格より明らかに低いと予想される価格である。

検索者は取引を提出することでAliceの注文をフィルしようとする。どの取引が最高のプライオリティ料金を持ち、かつリバートしないかが注文を完了させ、交換者は検索者が見つけられる最良の価格を得ることが保証される。（例外については「限界」セクションで議論。）

もしAliceの最低価格が3,000ドルで、ETHの現在価格が3,500ドルならば、勝利取引のpriorityFeePerGasは約50,000となる。（20万ガスを使う取引の場合、ブロックプロポーザーへの支払いは約100億wei（約0.000035ドル）に過ぎないことに注意。）

既存のUniswapXメカニズムと比較すると、いくつかの潜在的利点がある。

ダッチ式オークションを使った注文と比べ、MEV税を使う注文はより早く、より良い価格で完了する。本稿でも論じられているように、オンチェーンのダッチ式オークションはブロック間の価格変動によりMEVに価値を漏らし、多くのブロックを要する可能性がある。一方、MEV税を使う注文は通常次のブロックで完了し、MEVのほとんどを回収できる。

オフチェーンRFQとは異なり、MEV税によるオークションはオンチェーン取引実行時に自動的に行われる。つまり、落札者はオンチェーン取引が成功した場合にのみ注文をフィルすることを約束する。これにより、AMMなどのオンチェーン流動性がオフチェーン流動性と競争しやすくなり、結果としてUniswapXがUniswap v4のようなマルチプールシステム向けのより効率的なルーターになれる。

AMM

通常、AMMはブロックトップでの古くなった価格に基づいて取引を行う裁定者に価値を漏らしてしまう。これは「Loss Versus Rebalancing（LVR）」論文で詳述されている。我々はMEV税を使ってAMMがMEVを捕獲できるようにできる。簡潔さのため、集中流動性なしのAMM上での動作について説明する。（集中流動性を用いた解決法に興味がある場合は、Sorellaが近々ソリューションを発表する予定である。）

AMMは、取引のプライオリティ料金の関数として追加手数料を課すことでMEVを捕獲でき、ブロック内で最初に取引を行う権利をオークション形式で提供できる。この手数料の算出と課金方法には複数の選択肢がある。ここでは中立的とされる方法――プール流動性単位sqrt(xy)――について議論する。勝利取引は、プール流動性を最大限に増加させる取引となる。

ブロック内のプール上で最初のトランザクションを実行する際、プールはx_end * y_end > x_start * y_startという条件ではなく、次のように設定できる（aはある定数）：

x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2

この式は、裁定取引者が真の価格で取引を行うよう促し、取引後のプールの中間価格が真の価格となるようにする。

第一取引後は、Uniswap v2と同様に固定スワップ手数料で通常通り取引が進行する。MEV税を支払わず取引を行いたい unaware trader は、低いプライオリティ料金を設定する。

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

バックランオークション

上述の説明は、特定アプリケーションがMEV漏洩を回避する設計方法を示している。しかし、ウォレットがユーザーが任意のアプリケーションと相互作用する取引から生成するMEVを捕獲しようとする場合、どうすべきだろうか？　たとえそのアプリケーションがMEV税を持っていなくても。

たとえば、AliceがAMMで大口取引を行うとき、しばしば「バックランナー」に裁定機会を与え、価格を戻す。これは通常、AliceではなくMEVに漏れる。

MEV-ShareやMEVBlockerはユーザーが取引からMEVを捕獲できるプロトコルだが、複雑なオフチェーンオークションシステムに依存している。Order Flow Auctionの設計空間は他の解決策を提示している。

MEV税とインテンションベースのスマートコントラクトウォレットを組み合わせることで、AliceがバックランMEVを捕獲する代替システムを構築できる。AliceがAMM上で取引するトランザクションを作成する代わりに、その操作を実行できるように誰でも提出可能なインテンションに署名すると仮定する。Aliceのスマートコントラクトウォレットは、その取引を提出する者に対してMEV税を課し、その税はAliceに支払われる。

Aliceのインテンションを提出する検索者は、同一トランザクション内で自動的にバックランを実行できるため、排他的な権利を持つ。したがって、検索者が競争的であれば、Aliceが生み出した利益はすべてMEV税を通じてAliceの手に戻る。

ただし、このシステムは、ユーザーの取引を前方から挟み撃つ（フロントラン）攻撃からユーザーを保護するものではない。なぜなら、フロントランを行う取引はMEV税を回避できる可能性があるためだ。この問題（および緩和策）については、後述の「限界」セクションで詳しく議論する。とはいえ、パブリックmempoolを使用し、何の緩和策もないシステムと比べれば、少なくとも改善にはなる。

その他のユースケース

これら以外にも、MEV税の潜在的用途として、現在オフチェーンまたはダッチ式オークションを使っているほぼすべてのものが考えられる。

・Ovalのように、自身が創出するオラクル抽出可能価値（Oracle Extractable Value）を捕獲するプロトコル

・BlendのようなNFT担保ローンプロトコルにおけるリファイナンスオークション

・ダッチ式オークションよりもMEV漏れが少ない、貸出プロトコルの清算

複数アプリケーション間のMEV捕獲

上記の解決策は、単一アプリケーションとの相互作用におけるMEV捕獲を目的としている。しかし、検索者が同一トランザクション内で複数のアプリケーションと相互作用することで、さらに多くの価値を得られる場合もある。

こうしたアプリケーションのうち一つだけがMEV税を持っている場合、取引中のすべてのMEVは、その税の高低に関わらず、MEV税を持つアプリケーションに流れることになる。

しかし、検索者の取引がMEV税を課す二つのアプリケーションと相互作用する場合はどうなるか？　たとえば、MEV税を課すAMMに対して、前述のMEV税付きUniswapX注文をフィルすることでしか捕獲できないMEVがあるとしたら？

この場合、各アプリケーションが捕獲する超過MEVの相対的金額は、それらがMEV税をどのように設定するかに依存する。app_iがMEV税として受け取る価値が関数tax_i(priority)で与えられる場合、勝利取引のプライオリティは以下の式を解くことで求められる：

tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV

（技術的には、proposerの優先料金を考慮してpriorityPerGas * gasUsedの第三項を加えることもできるが、通常は無視できるほど小さいため省略する。）

単純な線形関係（tax_1(priorityPerGas) = a_1 * priorityPerGas）の場合、各アプリケーションが受け取るMEVの割合は次のように計算できる：

a_1 * priorityPerGas + a_2 * priorityPerGas = MEV
priorityPerGas = MEV/(a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

MEV税を設定する際、アプリケーションはトレードオフに直面する。より高い税は、複数アプリケーション間のMEV発生時により大きなシェアを得られるが、同時に、抽出方法が競合する場合には一部のMEVを逃すリスクがある。たとえば、あるAMMがすべての取引にMEV税をかける場合、MEV税付きUniswapX注文は別のAMMやオフチェーンのフィラーによって埋められる可能性が高くなる。

多くの場合、均衡が成立し、両アプリケーションが自らの利益を最大化するようにMEV税を設計してMEVを共有する。たとえば、MEV税付きAMMは、ブロックトップ近くの単一の情報保有者から価値を抽出したいが、その後は他取引者や他アプリケーション（MEV税付き含む）に低固定料金で流動性を提供したいかもしれない。この場合、AMMは比較的低いMEV税（例：$0.00001 * priorityFeePerGas）を設定し、裁定取引があれば早期に発生させ、その後の取引にはMEV税をかけない。一方、AMMと相互作用したいUniswapXのようなアプリケーションは、プールが裁定済み後に取引が含まれるように、より高いMEV税（例：$0.01 * priorityFeePerGas）を設定できる。このような相対的な税率を考えれば、UniswapX注文に1ドルのMEVしかない一方でAMMに5万ドルのMEVがあっても、AMMがまず裁定されることになる。

我々は、これが将来の研究に値する広大な設計空間であると考えている。

限界

MEV税にはいくつかの複雑さと欠点があり、これらはすべて今後の研究にとって興味深い領域であると考える。

インセンティブ不整合

MEV税は独占的なブロックプロポーザーに対してインセンティブ互換的ではない。MEV税が機能するのは、取引の包含において公正な競争が存在する場合に限られ、それはブロックプロポーザーが「競合優先順序」と呼ばれるルールに従い、自らの収益を最大化しないときにのみ成立する。非公式にいくつかの推奨ルールを列挙すると、以下の通り：

・優先順位付け：ブロック内の取引はpriorityFeePerGasの降順で並べられなければならない。

・検閲抵抗：ブロック期間中にトランザクションt1を受け取り、ブロックが満杯でないか、t2.priorityFeePerGas < t1.priorityFeePerGasであるようなt2を含む場合、ブロックはt1を含まなければならない。

・取引前プライバシー：ブロックプロポーザーはプライベートエンドポイントで取引を受け入れ、ブロックに提出する前に他者と共有したり、その内容を自らの取引作成に使ったりしてはならない。

・最後の審査禁止：ブロックプロポーザーは明確なブロック時刻を設定し、その時刻までは誰からの取引リクエストも受け入れ、その後は一切受け入れない。

これらの属性の一つ以上が違反されると、MEV税の有効性が損なわれる可能性がある。検閲を行うプロポーザーは、競合取引を除外し、ゼロプライオリティの取引を自分用に提出することで、ほとんどのMEV税を回避できる。取引前プライバシーを破るプロポーザーは、他者の取引からMEVを盗んだり、そのプライオリティ料金を見て自分がどれだけ高く設定すべきか正確に把握できたりする。また、他より遅れて取引を提出できるプロポーザーは、「最後の確認」の特権を得て、他人より高い価格で機会を得られる。いずれも逆選択問題を引き起こし、競争を阻害する。

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

プロトコル層での強制が欠如しているため、これらのルールにコミットした単一のセケンサーを信用する必要がある。また、プロポーザーがブロック構築を競争的な収益最大化オークション（例：イーサリアムL1のMEV-Boost）に外部委託する場合、ブロックはこれらのルールに従わない可能性がある。

これらの問題は、「競合優先順序」でブロック構築を行うことを約束する単一の信頼できるセケンサーによって「解決」できる。あるいは、コンセンサス、暗号学、および／またはTEE（Trusted Execution Environment）の組み合わせによる分散型メカニズムでも解決可能で、SorellaのAngstrom、FlashbotsのSUAVE、リーダーレスオークション、Multiplicityなどが該当する。

満杯ブロック

ブロックが完全に満杯になると、MEV税の正常な動作に例外が生じる。この場合、プロポーザーは単に取引をブロックに含めるのではなく、優先順位の低い取引を放棄せざるを得なくなる。MEV税付きアプリケーションとの相互作用取引は極めて低いプライオリティ料金を持つため、MEV税を使わない、あるいは非常に低い税のアプリケーションに押し出される可能性がある。しかし、EIP-1559のような別個の基本料金を設定するメカニズムを使うチェーンでは、ブロックが完全に満杯になることは比較的稀である。また、満杯時には一部の取引が遅延せざるを得ないことを踏まえれば、より高いMEV税を設定することで緊急性の低い取引を遅らせることは合理的な結果かもしれない。

リバートされた取引

MEV税は実質的に単一ブロックオークションに依存しており、各「入札」が一つの取引である。このオークションの欠点の一つは、失敗した入札がリバート取引としてチェーン上に残り、基本料金を支払い、ネットワークを混雑させることにある。

ソーターが失敗した取引を完全に除外できれば、この問題は緩和されるが、集中型ソーターであっても実現は難しい。（厳密には上記の検閲抵抗属性にも反するが、定義を調整可能である。）より複雑なソーターは、取引がどの競合オークションに参加しているかを指定できるようにすることで、失敗が確定している後続取引をスキップできる十分な情報を得られる。

ユーザーインテンションの漏洩

MEV税は検索者間の競争がある場合にのみ有効であり、つまりその機会が一定程度広く知られている必要がある。AMMのようなアプリケーションでは、機会はオンチェーンで可視であるため、自然に発生する。しかし、インテンションベースのルーティングやバックランオークションのようなアプリケーションでは、ユーザーのインテンションを検索者と共有しなければならない可能性がある。

場合によっては、ユーザーインテンションが実行前に公開されることによる一時的なプライバシー損失が、MEV税では回収できない形で価値を漏らす可能性がある。

たとえば、Aliceが上記のバックランオークションプロトコルを使って低流動性トークンを購入したいとする。彼女はAMMでそのトークンを購入する署名付きインテンションをスマートコントラクトウォレットに公開し、一定のスリッページ許容範囲を設定する。検索者は、彼女のスリッページ許容範囲までそのトークン価格を高プライオリティ取引で引き上げることができる。ユーザーの注文をフィルせず、価格を吊り上げるだけだ。その後、勝者Bobは低プライオリティ取引でそのインテンションを実行し、バックランすることでAliceの取引を挟み撃ちにして悪価格を提示しつつ、MEV税を回避できる。NFT購入でも同様の問題が発生しうる。

ただし、このような攻撃はBobにとってリスクがある。購入と販売の間にアトミック性が保証されないためだ。素朴なBobは「はさみうち引き裂き（sandwich tear）」の罠にはまりうる。Aliceがまず、自分から無価値なトークンを買うインテンションを公開し、Bobがはさみうちしようとそのトークンを購入するが、Bobがはさみを完成させる前にAliceがインテンションを取り下げるのだ。

アプリケーションは、インテンションを共有する検索者の範囲を制限し、その行動を監視することでこれを緩和できる。これは多くの既存の注文流オークションが行っていることである。

また、FlashbotsがSUAVE向けに設計したような、プライバシー意識のあるビルド機能とMEV税を組み合わせることも可能である。

最後に、Aliceがインテンションの共有コストが競争的検索の利益を上回ると判断すれば、自ら取引を構築し、ブロックに直接提出することもできる。上述のように、理想的な競合優先順序の実装は、プロポーザーに取引前プライバシーを提供するはずである。