パラダイムからの新しい記事: MEV の課税と優先順位付け-ウェブ3.0-php.cn

著者: Dan Robinson、Dave White

編集者: Joyce、BlockBeats

はじめに

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

チェーンの 1 つに MEV 税を課すために、スマートコントラクトはトランザクション優先手数料の関数である手数料を請求します。アプリケーションが検索者優先料金 1 ドルごとに 99 ドルの MEV 税を請求すると、そのトランザクションの競争力のある MEV の 99% が取得されます。

MEV 税は、広大なデザイン空間を開くシンプルなテクニックです。これらは、チェーン上の任意のアプリケーションが、独自のオフチェーンインフラストラクチャを必要とせずに、ブロックプロポーザーによって実行される単一の共有オークションに接続するだけで、独自のカスタム MEV オークションを実行できるようにすると考えることができます。

MEV 研究における 3 つの主要な問題を解決するために MEV 税がどのように使用できるかを説明します。、流動性プロバイダーが経験する損失とリバランス（LVR）を最小限に抑えます。

ユーザーがトランザクションによって作成された「バックグラウンドで実行されている」MEVをキャプチャできるようにするウォレット

しかし、1つの質問があります。 MEV税は、ブロックの提案者が、いかなる取引も検閲、覗き見、または遅延させることなく、優先料金によって取引を注文することを含む、競争優先順位付けルールを厳密に遵守している場合にのみ機能します。ブロックの提案者がこれらのルールから逸脱すると、MEV 税を逃れて自分たちの価値を獲得できる可能性があります。そのため、現在、MEV 税は信頼できる L2 発注者に依存しており、イーサリアム L1 ではまったく機能しない可能性があります。イーサリアム L1 では、提案者の収入を最大化する競争力のあるビルダーオークションがブロック構築を支配しています。

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

優先順位付け

誰かがイーサリアム L1 または L2 でトランザクションを送信するとき、優先料金を割り当て、ブロック提案者に支払います。これは、builderPriorityFee (ETH での支払い総額) を取得するためにトランザクションで使用されるガスを掛けた数値、priorityFeePerGas として指定されると想像できます。

イーサリアムプロトコルには、ブロック内のトランザクションをpriorityFeePerGasで降順に貪欲にソートしなければならないという規定はありません。ただし、これはブロックを構築する一般的な方法です。たとえば、これは OP スタックチェーンの順序付け者であり、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)。優先料が高くなると取引は不採算になり、優先料が低くなると、より高い料金を設定する競合他社の機会損失につながります。これは、スマートコントラクトがトランザクション内の MEV の 99% を取得したことを意味します。

Paradigm 新文：MEV 税与优先排序

私たちは、スマートコントラクトによって課されるこの追加料金を MEV 税と呼びます。 MEV 税は、アプリケーションが自身の利益のために優先順位をハイジャックすることを許可しており、提案者をブロックするために MEV を漏らすのではなく、ユーザーのために MEV を取り戻すことができます。

料金が priorityFeePerGas の関数として十分な速さで増加する場合、提案者はごくわずかな MEV しか取得しません。 priorityFeePerGas の価格はウェイ (1 ETH の 10 億分の 1) で設定されているため、非常に高い精度で処理する必要があります。たとえば、MEV 税が十分に敏感であり、priorityFeePerGas が 50,000 であれば超過税となるため、提案者に支払われる合計金額は 0.01 ドル未満になります。 (5)

ただし、重要な注意点があります。「制限」セクションで説明したように、MEV 税は、ブロック提案者が特定のルール (これを「競争的優先順位付け」と呼びます) に従い、自らの収益を最大化するためにこれらのルールから逸脱しない場合にのみ機能します。これらのルールをトラストレスな方法で強制するかどうかは未解決の問題です。

シングルアプリケーション MEV キャプチャ

ここでは、競合する優先順位を使用したブロック構築を保証するチェーン上の MEV における 3 つの重要な問題を緩和するために、MEV 税をどのように使用できるかを概説します: DEX インターフェイスにより取引所による取引執行が改善され、AMM が可能になりますLP の裁定損失を削減し、ウォレットがユーザーの逆実行権を販売することでユーザーの MEV 漏洩を削減できるようにします。

分散型 Exchange Router

UniswapX や 1inch Fusion のようなインテントベースの DEX ルーティングプロトコルでは、ユーザー (Alice) が交換インテントに署名し、検索者は最良の価格でアリスをルーティングするか、そのインテントを満たすために競争します。

UniswapX の現在のバージョンは、競争するために 2 つのメカニズムを使用します。1 つは、検索者が満額になるまで時間の経過とともにアリスの制限価格が変化するダッチオークションで、もう 1 つは、最初のオフチェーン見積依頼 (RFQ) オークションです。オランダのオークションの開始価格を設定します。

競争上の優先順位付けを保証するプラットフォーム上で、UniswapX はこれらのメカニズムを単一のメカニズムである MEV 税に置き換えることができます。これは、ユーザーが誰でもすぐに約定できる注文に署名できるようにすることで実現されますが、約定価格は取引の優先順位に応じて設定されます。

たとえば、Alice に 1 ETH を販売する UniswapX 注文がある場合、注文の約定価格を minimumPrice + ($0.01 * priorityFeePerGas) として定義できます。 minimumPrice はおそらく、現在の価格よりも大幅に低いと予想される固定値です。

検索者は、トランザクションを送信してアリスの注文を満たすために競い合います。どの取引が最も優先度の高い手数料を持っているかに関係なく、注文は履行され、復元されないため、交換業者は検索者が見つけられる最高の価格を得ることが保証されます。 (一部の例外については「制限事項」セクションで説明します。)

Alice の最低価格が $3,000 で、ETH の現在の価格が $3,500 である場合、落札トランザクションの priorityFeePerGas は約 50,000 です。 (200,000 Gas の費用がかかるトランザクションでは、ブロック提案者に支払われるのは ~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 * を強制する代わりに、条件 (a を定数として) を強制できます。 y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2

この式は、裁定取引トレーダーに真の価格で取引するよう促し、その取引後、プール内の中間価格が真の価格になるはずです。

最初の取引後は、Uniswap v2 と同様に、固定スワップ手数料で取引を続行できます。追加の MEV 税を支払わずにプールでの取引を希望する知識のないトレーダーには、優先料金が低く設定されます。

AMM に MEV 税を導入するには他にも多くの方法があり、それぞれに異なる効果が生じます。たとえば、MEV 税をスワップの入力トークンまたは出力トークンで指定したり、プールによって適用されるスワップ手数料の割合に影響を与えたり、ユーザートランザクションの最低価格を決定したりできます。私たちは、これは探求する価値のある興味深いデザイン空間だと考えています。

逆行オークション

上記の説明は、MEV リークを回避するために特定のアプリケーションをどのように設計できるかを示しています。しかし、ウォレットが、ユーザーがアプリケーションとやり取りするトランザクションから作成した MEV を取得できるように支援したい場合は、たとえ MEV 税が含まれていないものであってもどうでしょうか?

たとえば、Alice が AMM で大規模な取引を行うとき、「バックランナー」が価格を引き戻すために裁定取引の機会を作り出すことがあります。これは通常、アリスではなく MEV にリークされます。

MEV-Share と MEVBlocker は、ユーザーがトランザクションから MEV を取得できるようにする 2 つのプロトコルですが、複雑なオフチェーンオークションシステムに依存しています。注文フローオークションデザインスペースでは、他のいくつかのソリューションについて説明します。

MEV 税とインテントベースのスマートコントラクトウォレットを組み合わせることで、Alice のバックグラウンドで実行されている MEV をキャプチャする代替システムを構築できます。アリスは、AMM 上で取引するためのトランザクションを作成せず、その代わりに、誰でもアリスのスマートコントラクトウォレットに送信してそのアクションを実行できるインテントに署名するとします。アリスのスマートコントラクトウォレットは、トランザクションを送信する人に MEV 税を請求し、その税金はアリスに支払われます。

アリスのインテントを送信する検索者は、同じトランザクション内で自動的に彼女を実行解除できるため、彼女を実行解除する排他的な権利を持ちます。したがって、検索が競争力のある場合、アリスの利益はすべて MEV 税を通じてアリスに発生するはずです。

フロントランニングユーザーによるトランザクションは、そのユーザーへのMEV税の支払いを回避できる可能性があるため、このシステムは必ずしもフロントランニングユーザーによるトランザクションに関連する攻撃からユーザーを保護するものではないことに注意してください。この問題 (および考えられる軽減策) については、以下の「制限事項」セクションで詳しく説明します。それでも、これは少なくとも、何の緩和策も講じずに共通のメモリプールを使用するシステムよりも改善される可能性があります。

その他の使用例

これらの例に加えて、MEV 税のその他の潜在的な用途には、現在オフチェーンまたはオランダのオークションを使用しているほぼすべてのものが含まれる可能性があります。 Oval などの機械抽出可能なプロトコルを作成します。

Blend などの NFT 住宅ローンプロトコルの借り換えオークション

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

上記のソリューションは、単一のアプリケーションとの MEV インタラクションをキャプチャするように設計されています。ただし、検索者は同じトランザクションで複数のアプリケーションと対話することで、より多くの価値を取得できる場合があります。

これらのアプリケーションのうち 1 つだけが MEV 税を持つ場合、トランザクション内のすべての MEV は、MEV 税が高いか低いかに関係なく、MEV 税を持つアプリケーションに送られる必要があります。

しかし、検索者のトランザクションが MEV 税を使用する 2 つのアプリケーションと対話する場合はどうなるでしょうか?たとえば、上記の MEV 納税の UniswapX 注文の 1 つを MEV 納税の AMM に対して実行することによってのみ取得できる MEV がある場合はどうなるでしょうか?

この場合、各アプリケーションによって取得される超過 MEV の相対量は、それらのアプリケーションが MEV 税をどのように設定するかによって異なります。 MEV 税として収集された値 app_i が関数 Tax_i(priority) で与えられる場合、勝利トランザクションの優先度は次の方程式で優先度を解くことによって決定できます:

tax_1(priorityPerGas) + Tax_2(priorityPerGas) = 合計 MEV

(技術的には、ブロック提案者に支払われる優先料を考慮して、priorityPerGas *gas used に 3 番目の項目を追加できますが、通常の状況ではおそらく無視されて機能するため、それは無視します)

In MEV 税が priorityPerGas に線形関係がある単純なケース (つまり、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 が欠落する可能性があることを意味します。。たとえば、すべての取引に MEV 税を課す AMM がある場合、MEV 税の UniswapX 注文は、別の AMM またはオフチェーンフィラーによって約定される可能性が高くなります。

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

私たちは、これは将来の研究に値する幅広いデザイン空間であると信じています。

制限事項

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

インセンティブの非互換性

MEV税は、独占ブロックの提案者にとってインセンティブと互換性がありません。これらは、トランザクションを含めるための平等な競争条件がある場合にのみ機能します。これは、ブロック提案者が自らの収益を最大化するのではなく、いわゆる「競争的優先順位付け」ルールに従う場合にのみ当てはまります。以下を含むがこれらに限定されない、いくつかの推奨ルールの非公式リスト:

優先順位。ブロック内のトランザクションは、priorityFeePerGas の降順で並べる必要があります。

検閲に抵抗してください。ブロック提案者がブロック中にトランザクション t1 を受信し、ブロックがいっぱいではないか、または t2.priorityFeePerGas

取引前のプライバシー。ブロックの提案者は、プライベートエンドポイントを介してトランザクションを受け入れる必要があり、そのようなトランザクションをブロックに送信する前に他の人と共有したり、これらのトランザクションの内容を独自のトランザクションを構築するための入力として使用したりすることはできません。

最終レビューはありません。ブロック提案者は、明確なブロック時間を設定する必要があります。この時間より前は、誰からのトランザクションリクエストも受け付けません。この時間以降は、誰からもトランザクションリクエストを受け付けなくなります。

これらのプロパティの 1 つ以上に違反すると、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を購入する際にも同様の問題が発生する可能性があります。

ボブにとって、トークンの購入とアリスへの販売の間のアトミック性を保証できないため、このような攻撃は危険であることに注意してください。ナイーブなボブは、「締め付けと引き裂き」の罠に陥る可能性があります。アリスは最初に自分自身から価値のないトークンを購入する意向を発表し、ボブはトランザクションを側面から攻撃するためにトークンを購入しますが、ボブが側面攻撃を完了する前に、アリスはその意図を撤回します。。

アプリは、多くの既存の注文フローオークションと同様に、意図を共有する検索者のセットを制限し、その行動を監視することでこれを軽減することもできます。

Flashbot が SUAVE デザインで想定したもののように、MEV 税とプライバシーを意識したビルダー機能を組み合わせることも可能です。

最後に、Alice がインテントを共有するコストが競合検索のメリットを上回ると判断した場合は、トランザクションを自分で構築し、ブロックに直接送信できます。上で述べたように、競合優先順位付けの理想的な実装では、ブロック提案者にトランザクション前のプライバシーが提供されます。