優先順位さえあれば十分
はじめに
この投稿では、任意のアプリケーションが独自のMEVを取得するために使用できるメカニズムであるMEV税を紹介します。
このメカニズムは、OP メインネット、Base、BlastなどのOPスタックL2で現在使用できますが、これは、これらのチェーンのブロック提案者が、競争的な優先順位付けと呼ばれる一連のルールに従うためです。
これらのチェーンの1つにMEV税を実装するために、スマートコントラクトはトランザクションの優先手数料の関数である手数料を請求します。アプリケーションが検索者に(たとえば)優先料金1ドルごとに99ドルのMEV税を請求する場合、そのトランザクションの競争力のあるMEVの99%をキャプチャできることを示しています。
MEV税は、広大な設計空間を開く単純な手法です。これらは、ブロック提案者によって実行される単一の共有オークションにフックするだけで、チェーン上の任意のアプリケーションが独自のオフチェーンインフラストラクチャを必要とせずに、独自のカスタムMEVオークションを実行できるようにすると考えることができます。
MEV研究における3つの主要な問題を解決するために、MEV税をどのように使用できるかを示します。
- スワッパーが受け取る価格を最適化する分散型取引所(DEX)ルーター
- 流動性プロバイダーが経験する損失対リバランス(LVR)を最小限に抑える自動マーケットメーカー(AMM) ユーザーが
- トランザクションによって作成された「バックランニング」MEVをキャプチャできるようにするウォレット
しかし、落とし穴があります。MEV税は、ブロック提案者が、検閲、覗き見、または遅延することなく、優先手数料で取引を並べ替えるなど、競争力のある優先順位付けのルールに厳密に従う場合にのみ機能します。ブロック提案者がこれらのルールから逸脱した場合、彼らはMEV税を逃れて自分たちの価値を獲得することができます。したがって、今日では、MEV税はL2シーケンサーを信頼することに依存しており、ブロック構築が提案者の収益を最大化する競争力のあるビルダーオークションによって支配されているイーサリアムL1ではまったく機能しない可能性があります。
それでも、MEV税の力と柔軟性は、優先順位付けが今日それを提供できるプラットフォームにとって正しい選択である可能性があることを示唆しています。また、競合する優先順位付けが比較的単純であることは、単一のシーケンサーを信頼することなく、分散型の方法でそれを実施する実行可能な方法がある可能性があることを示唆しています。この投稿が、この問題に対するさらなる作業の動機付けになることを願っています。
優先順位
付け誰かがイーサリアムL1またはL2でトランザクションを送信する場合、優先手数料を指定し、ブロック提案者に支払います.1 これは、トランザクションで使用されるガスを掛けた数値である priorityFeePerGas として指定され、builderPriorityFee (ETH での合計支払い) を取得することを想像できます。2
イーサリアム プロトコルには、ブロック内のトランザクションをpriorityFeePerGasの降順で貪欲に並べなければならないというルールはありません。ただし、これはブロックを構築するための一般的な方法であり、たとえば、OP スタック チェーンのシーケンサー、および geth と reth で使用される既定のアルゴリズムです。優先順位付けにより、トランザクションアクターはトランザクションの緊急性を効率的に表現できるだけでなく、特定の種類のMEVをブロック提案者に自然にチャネル化します。
これは、優先順位付けによって、MEVをめぐる競争が優先度ガスオークションに変わるためです。中央集権的な取引所に対してAMMを仲裁するなど、チェーンとの相互作用から利益を得る機会がある場合、検索者は最初にその機会を主張するために競争します。チェーンが優先順序を使用してトランザクションの包含と順序を決定する場合、検索者はトランザクションに高い優先度の手数料を設定することで競争します。
リスクのない利益がゼロになるまで競争する競争シナリオでは、勝者の検索者は、優先料金でMEVの全額を支払うことになります。3 したがって、コントラクトとのやり取りから得られる利益が100 ETHの場合、それを請求する最初のトランザクションは100 ETHの優先手数料を設定します。(これに関するいくつかの注意点については、「制限事項」セクションで説明します)。
MEV 税金
スマートコントラクトが、それと対話するトランザクションからMEVを取得したいとします。スマートコントラクトが独自のMEVをキャプチャしようとするさまざまなアプリケーション固有の方法に関する研究の膨大なライブラリがあります。
しかし、実際には、必ずしもアプリケーションについて何も知る必要はありません。ブロックが競争力のある優先順位付けによって構築されていることがわかっている場合、トランザクション内のMEVの量に関する1つの普遍的なシグナル、つまり優先手数料があります。
スマートコントラクトは、トランザクションの優先手数料を見て、その増加機能として独自の手数料を請求できることを提案します。たとえば、コントラクトでは、呼び出したユーザーが ETH の applicationPriorityFee = 99 * proposerPriorityFee をコントラクトに転送する必要がある場合があります。4
この新しい手数料は、トランザクションを送信する検索者によって支払われるため、その検索者の行動に影響を与えます。オポチュニティに 100 MEV がある場合、落札されたトランザクションは、合計 100 ETH (ブロック提案者に 1 ETH、スマートコントラクトに 99 ETH) の支払いとなるため、優先手数料 1 ETH のみを設定するようになりました。より高い優先手数料は、取引を不採算にします。優先度の低い手数料は、より高い手数料を設定した競合他社に機会を奪われることになります。これは、スマートコントラクトがトランザクションでMEVの99%を獲得したことを意味します。
スマートコントラクトによって課されるこの追加料金をMEV税と呼びます。MEV税により、アプリケーションはそれ自体の利益のために優先順位を乗っ取り、ブロック提案者に漏らすのではなく、ユーザーのためにMEVを再取得できます。
この料金が priorityFeePerGas の関数として十分に速く増加する場合、提案者にはごくわずかな量の MEV しか発生しません。priorityFeePerGasはウェイ(1 ETHの10億分の1)で表されるため、作業する精度が高くなります。たとえば、MEV税が50,000のpriorityFeePerGasが法外に高い税金になるほど敏感ロング、提案者への支払い総額は0.01ドル未満になります。5
ただし、重要な注意点があります。制限のセクションで説明したように、MEV税は、ブロック提案者が特定のルール(「競争的優先順位付け」と呼ばれるもの)に従っている場合にのみ機能し、注文でそれらのルールから逸脱して収益を最大化する必要はありません。これらのルールをトラストレスな方法で適用することは、未解決の問題です。
単一アプリケーションMEVキャプチャ
ここでは、ブロック構築に競争力のある優先順位を使用することが保証されているチェーン上で、MEV税を使用して、MEVにおける3つの重要な問題を軽減する方法、つまり、DEXインターフェースがスワッパーの取引執行を改善すること、AMMがLPの裁定取引の損失を減らすこと、ウォレットがユーザーのバックラン権を販売することでユーザーのMEV漏洩を減らす
ことを可能にする方法を紹介します。DEX routers
UniswapX や 1inch Fusion などのインテントベースのDEXルーティング プロトコルでは、ユーザー(Alice)がスワップのインテントに署名し、検索者は Alice にとって可能な限り最良の価格でそのインテントをルーティングまたは埋めるために競い合います。
UniswapXの現在のバージョンでは、アリスの指値価格が検索者が満たすまで時間の経過とともに変化するダッチオークションと、そのダッチオークションの開始価格を設定する最初のオフチェーン見積依頼(RFQ)オークションの2つのメカニズムを使用して、そのコンペティションを運営しています。
競争力のある優先順位を保証するプラットフォームでは、UniswapXはこれらを単一のメカニズムであるMEV税に置き換えることができます。これは、誰でもすぐに入力できる注文書にユーザーに署名してもらうことで実装できますが、トランザクションの優先度の関数として設定された実行価格を使用します。
例えば、アリスが1 ETHを売るUniswapX注文を持っている場合、アリスは注文の約定価格をminimumPrice + ($0.01 * priorityFeePerGas)と定義することができます。 minimumPrice は、現在の価格よりも大幅に低くなると予想される固定値である可能性があります。
検索者は、トランザクションを送信することによってアリスの注文を埋めるために競争します。最も優先度の高い手数料を持ち、元に戻らないトランザクションは、注文を満たすことになり、スワッパーが検索者が見つけることができる最良の価格を取得することを保証する必要があります。(これに対するいくつかの例外については、「制限事項」セクションで説明します。
Aliceの最低価格が$3,000で、ETHの現在の価格が$3,500の場合、落札トランザクションのpriorityFeePerGasは約50,000になります。(200,000ガスの費用がかかる取引では、ブロック提案者への支払いは約100億ウェイ(約0.000035ドル)にとどまることに注意してください。
これには、UniswapXで使用されている既存のメカニズムに比べて、いくつかの潜在的な利点があります。
MEV税を使用する注文は、オランダのオークションを使用する注文よりも速く、より良い価格で完了する可能性があります。本稿で説明したように、オンチェーンのダッチオークションは、ブロック間の価格変動により、MEVに何らかの価値を漏らし、完了するまでに多くのブロックを要する場合があります。対照的に、MEV税を使用する注文は、通常、MEVの大部分を獲得しながら、次のブロックで完了することができます。
オフチェーンRFQとは異なり、MEV税を使用する注文を埋めるためのオークションは、オンチェーンでのトランザクション実行でアトミックに発生します。これは、落札者がオンチェーントランザクションが成功した場合にのみ注文を満たすことを約束することを保証できることを意味します。これにより、AMMのようなオンチェーンの流動性がオフチェーンの流動性と競合しやすくなり、UniswapXはUniswap v4のようなマルチプールシステムにとってさらに効果的なルーターとして機能する可能性があります。
AMMs
通常、AMMは、loss-vs-rebalancing papersで議論されているように、ブロックの一番上で古い価格に対して取引する裁定取引者に価値を漏らします。MEV税を使用して、AMMにそのMEVをキャプチャさせることができます。物事をシンプルに保つために、これが集中流動性のないAMMでどのように機能するかについて説明します。(この種の問題を集中流動性でどのように解決できるかに興味がある場合は、Sorellaがまもなく1つの解決策を公開する予定です。
AMMは、取引の優先手数料の関数として追加料金を請求することでMEVをキャプチャし、ブロックで最初に取引する権利をオークションにかけることができます。その料金を計算して定義する方法はたくさんあります。ここでは、ほぼ間違いなく中立的な1つ、つまりプールの流動性の単位であるsqrt(xy)で表す方法について説明します。落札された取引は、プールの流動性を最も高める取引となります。
ブロック内のプールで最初のトランザクションを実行するとき、y_end > x_start y_start x_end条件を適用する代わりに、プールは条件を強制できます(定数としてaを使用)。
x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2
この式は、アービトラージトレーダーが真の価格で取引するインセンティブを与え、その取引の後、プールの中間価格が真の価格になるはずです。6
その最初の取引の後、取引はUniswap v2と同じように、固定のスワップ手数料で機能します。追加のMEV税を支払わずにプールで取引したい情報のない取引は、優先度の低い手数料を設定します。
AMMにMEV税を実装する方法は他にもたくさんあり、さまざまな効果があります。たとえば、MEV税は、スワップのインプットトークンまたはアウトプットトークンで建てられたり、プールによって適用されるスワップ手数料の割合に影響を与えたり、ユーザーの取引の最低価格を決定したりできます。これは興味深いデザイン空間だと思います。
バックランニングオークション
上記の説明は、MEVの漏洩を避けるために特定のアプリケーションをどのように設計できるかを示しています。しかし、ウォレットが、MEV税を組み込んでいないアプリケーションであっても、任意のアプリケーションと対話する任意のトランザクションから作成したMEVをユーザーがキャプチャできるようにしたい場合はどうでしょうか。
たとえば、アリスがAMMで大規模な取引を行うと、「バックランナー」が価格を戻すための裁定取引の機会を作成することがあります。これは通常、アリスに行くのではなく、MEVにリークされます。
MEV-ShareとMEVBlockerは、ユーザーがトランザクションからMEVを取得できるようにする2つのプロトコルですが、複雑なオフチェーンオークションシステムに依存しています。Orderflow Auction Design Spaceには、他にもいくつかの解決策が説明されています。
MEV税は、インテントベースのスマートコントラクトウォレットと組み合わせると、AliceのバックランニングMEVをキャプチャするための代替システムを構築できる可能性があります。AMMで取引するトランザクションを作成する代わりに、アリスが誰でもアリスのスマートコントラクトウォレットに送信できるインテントに署名して、そのアクションを実行させるとします。アリスのスマートコントラクトウォレットは、そのトランザクションを送信した人にMEV税を請求し、アリスに支払われます。
アリスのインテントを送信した検索者は、同じトランザクションでアトミックにバックランできるため、アリスをバックランする独占的な権利を持ちます。その結果、検索が競争的である場合、アリスをバックランすることによるすべての利益は、MEV税を通じてアリスに発生するはずです。
このシステムは、ユーザーをフロントランするトランザクションがそのユーザーへの MEV 税の支払いを回避できる可能性があるため、ユーザートランザクションのフロントランニングを含む攻撃から必ずしもユーザーを保護するとは限らないことに注意してください。この問題 (および考えられる軽減策) については、以下の「制限事項」セクションで詳しく説明します。それにもかかわらず、これは少なくとも、緩和策なしでパブリックmempoolsを使用するシステムの改善である可能性があります。
その他のユースケース
これらの例に加えて、MEV税のその他の潜在的な用途には、現在オフチェーンまたはオランダのオークションを使用しているほとんどすべてのものが含まれます。
- a href="
- Refinancingオークションのような、オラクルが生み出すオラクルの抽出可能な価値をキャプチャするためのプロトコル
- オランダのオークションよりも価値がある
クロスアプリケーションMEVキャプチャ
上記のソリューションは、単一のアプリケーションとの対話からMEVをキャプチャするように設計されています。しかし、検索者が同じトランザクションで複数のアプリケーションと対話することで、さらに多くの価値を獲得できる場合があります。
これらのアプリケーションの 1 つだけに MEV 税が課されている場合、トランザクションからのすべての MEV は、その MEV 税の高低に関係なく、MEV 税が課されたアプリケーションに送られる必要があります。
しかし、検索者のトランザクションが MEV 税を使用する 2 つのアプリケーションとやり取りする場合はどうなるでしょうか。たとえば、上記の MEV 課税された UniswapX 注文の 1 つを MEV 課税された AMM に対して約定することによってのみキャプチャできる MEV がある場合はどうなりますか?
その場合、各アプリケーションによってキャプチャされた超過 MEV の相対的な量は、それらのアプリケーションが MEV 税をどのように設定するかによって決まります。app_i MEV税として請求する値が関数tax_i(priority)によって与えられる場合、勝ち取った取引の優先順位は、次の式で優先順位を解くことで決定できます。
tax_1(priorityPerGas) + tax_2(priorityPerGas) = 合計MEV
(技術的には、優先順位の3番目の用語を追加することができますPerGas * gasブロック提案者に支払われる優先料金のアカウントに使用されますが、付録Aで説明したように、通常の状態では無視できる可能性が高いため、無視します。
priorityPerGas が線形である (つまり tax_1(priorityPerGas) = a_1 * priorityPerGas) であるMEV税の単純なケースでは、各アプリケーションが受け取る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)を設定できます。これらの相対的な税金では、AMMは、UniswapXの注文で1ドルのMEVと50,000ドルのMEVしかなかったとしても、最初に予約されることになります。
これは、今後の研究に値する幅広いデザイン空間であると考えています。
税金MEV制限
には、いくつかの複雑さと欠点があります。それぞれが今後の研究で興味深い分野だと考えています。
税MEVインセンティブの非互換性
は、独占的なブロック提案者にとってインセンティブと互換性がありません。これらは、トランザクションを含めるための公正な競争がある場合にのみ機能し、ブロック提案者が自分の収益を最大化するのではなく、「競争力のある優先順位付け」と呼ばれるルールに従う場合にのみ発生します。非公式かつ非網羅的に、これらの規則には以下を含めることを提案します。
- 優先順位付け。ブロック内のトランザクションは、priorityFeePerGas の降順の注文で順序付けする必要があります。
- 検閲抵抗。ブロック提案者がブロック中にトランザクション t1 を受信し、ブロックがいっぱいでないか、t2.priorityFeePerGas が t1.priorityFeePerGas <ようなトランザクション t2 を含む場合、ブロックにはトランザクション t1 を含める必要があります。
- 取引前のプライバシー。ブロック提案者は、プライベートエンドポイントを介してトランザクションを受け入れる必要があり、ブロックにコミットする前にそのようなトランザクションを他の人と共有したり、それらのトランザクションの内容を独自のトランザクションを構築する際の入力として使用したりしてはなりません。
- 最後の一瞥はありません。ブロック提案者は、明確な時間 blockTime を設定し、それ以前は誰からのトランザクションも受け入れず、その後は誰からのトランザクションも受け入れません。
これらの特性の1つ以上に違反した場合、MEV税の有効性が弱まる可能性があります。検閲抵抗に違反するブロック提案者は、競合するトランザクションを除外し、その機会を利用するゼロプライオリティトランザクションを送信することで、ほとんどのMEV税を回避できます。取引前のプライバシーを侵害するブロック提案者は、他の取引からMEVを盗んだり、優先手数料を覗き見して、自分で設定する必要がある高さを正確に知ることができますが、他の誰よりも遅く取引を提出できる人は、機会のために他の人を上回っているかどうかについて無料の「最後の外観」を持っています。 いずれの場合も、逆淘汰の問題を引き起こし、最終的に競争を阻害する可能性があります。
残念ながら、最初のプロパティはプロトコル層で簡単に適用できますが、他のプロパティを信頼せずに強制することは未解決の問題です。
プロトコル層で強制力がない場合、これらのルールにコミットする単一のシーケンサーは、ルールから逸脱しないように信頼される必要があり、提案者がブロック構築を競争力のある収益最大化オークション(イーサリアム L1のMEV-Boostなど)にアウトソーシングした場合、ブロックはそれらに従わない可能性があります。
これらの問題は、ブロック構築に競争力のある優先順位を使用することを約束する単一の信頼できるシーケンサーで「解決」できます。また、SorellaのAngstrom、FlashbotsのSUAVE、Leaderless Auctions、Multiplicityなど、コンセンサス、暗号化、信頼できる実行環境を組み合わせて使用する分散型メカニズムで解決できる場合もあります。
フルブロック
MEV税の通常の操作の 1 つの例外は、ブロックが完全にいっぱいになったときに発生します。その場合、ブロック提案者は、優先度の低いトランザクションを単にブロックの後半に含めるのではなく、除外する必要があるかもしれません。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 の現在のシーケンサー、7 など、トランザクション順序付けルールを通じて緩和MEVいくつかの試みは、ブロック提案者が注文しなければならない別の順序付けルール、先着順(「公平な順序付け」と呼ばれることもあります)を適用することに焦点を当てていますそれらが表示される注文のトランザクション。
優先順位付けでは、特定の期間内に到着するトランザクションを平等に扱い、代わりに宣言された優先順位で並べ替えるという、別のアプローチを取ります。
先着順は、複数のバリデーターがいる実際のネットワーク環境で実施したり、定義したりすることさえ困難です。また、単一の信頼できるシーケンサーを使用しても、無駄なレイテンシーの競合やスパムが発生する可能性があります。最後に、MEV税は、資産価格の不連続な「ジャンプ」による裁定利益など、先着順ではできない特定の種類のMEVを排除できる可能性があります。先着順に対する優先的な順序付けの潜在的な利点は、Budish, Cramton, Shim (2015) で議論されている連続時間交換に対する離散時間の利点といくらか関連しています。
一方、優先順位付けはデフォルトでMEVに価値を漏らしているように見えますが、この投稿では、それを再キャプチャするようにアプリケーションを設計する方法を示します。
料金の分担。イーサリアム L2 である Blast は、トランザクションでアクセスされたスマートコントラクトと優先手数料と基本手数料の両方の一部を共有します。
MEV税は(少なくとも優先手数料については)同様のことを許可しますが、料金共有のための特別なサポートなしに、競争力のある優先順位付けを使用する任意のチェーンのアプリケーション層で実装できます。また、アプリケーションが独自の税金を優先料金のカスタム関数として定義できるため、柔軟性が向上し、MEV対応アプリケーションの構成可能性が高まる可能性があります。
トラストレスソリューション。この投稿では、プラットフォームが競争力のある優先順位付けを使用する動機と、それを使用するプラットフォームを活用する方法に焦点を当てています。
競争的な優先順位付けに必要な他の各プロパティについては、事前にかなりの議論がありました。例えば、Fox, Pai, Resnick (2023)では、検閲抵抗がない場合のオンチェーンオークションの脆弱性について議論し、複数の提案者を同時に使用する検閲耐性オークションの設計について説明しています。ただし、トランザクションの特定の順序は提案されません。
FlashbotsのSUAVEs、Sorella's Angstrom、Leaderless Auctions、Espresso、Offchain Labsなど、信頼を最小化したブロック構築のメカニズムを構築する研究が行われています。@espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost、Péter Szilágiによるパブリックトランザクションのインクルージョンを義務付けました。
結論
この投稿が、L2 が優先順位付け (OP スタックでデフォルトでサポートされているように) の使用を検討するよう促し、サポートされている場合はMEV税を試すアプリケーションを刺激することを願っています。
また、L1 と L2 の両方で信頼を最小化した競争上の優先順位付けのためのプロトコルのさらなる研究の動機付けにもなることを願っています。この問題に協力することに興味があり、6月6日(木)までにこれを読んでいる場合は、TLDRフェローシップに応募して、DanとMEV耐性L2シーケンサーに取り組むことができます。または、dan@paradigm.xyz と dave@paradigm.xyz にアイデアをお寄せください。
脚注
- この投稿では、「プロポーザー」を使用して、特定のブロックに含まれるトランザクションを決定するアクターまたはプロセスを指します。イーサリアムL2では、この役割は通常「シーケンサー」によって満たされます。イーサリアムL1では、プロポーザーと呼ばれる特定のイーサリアムバリデーターによって埋められますが、多くの場合、プロポーザーはブロックを構築するタスクを「リレイヤー」と「ビルダー」が参加する競争オークションに委託します。これらの責任がどのように分担されるかについての詳細は、この投稿の範囲外です。 ↩
- ガスごとの優先手数料は、実際にはトランザクションで明示的に指定されていませんが、トランザクションで計算できます。トランザクションはガス価格を指定しますが、イーサリアムは基本料金も請求し、ガス価格から差し引かれて燃やされます。基本料金は、取引者の管理下にないため、MEV税の目的で無視する必要があります。ガスあたりの優先手数料(ブロック提案者に支払われる取引手数料の部分の価格)は、SolidityでpriorityGasPrice = tx.gasprice - block.basefeeとして計算できます。 ↩
- あるいは、単に「MEV」を定義して、検索者の利益を除外し、バリデーターに送られる値のみを参照することもできます。 ↩
- proposerPriorityFee(priorityFeePerGasにトランザクションで使用されるガスの合計を掛けたものに等しい)は、トランザクションが最終的に使用するガスの量を知る方法がないため、契約中に実際に計算することはできません。ただし、必要なのは上限だけなので、これは一般的には問題になりません。安全のために、priorityFeePerGasに3,000万(イーサリアムブロックの現在の最大ガス)を掛けることができます。この値を過大評価することは、単にMEV税がMEVのさらに大きな割合を占めることを意味します。 ↩
- トランザクションが3,000万ガスを超えることができないと仮定すると、priorityFeePerGasが50,000の場合、ガスの支払いは1500 gwei(ETH価格4,000ドルで約0.006ドル)になります。 ↩
- アービトラージの利益がゼロになるようにpriorityFeePerGasが設定されている場合、利益最大化アービトラージ取引は、関数最大化AMM上の同じ取引に対応する必要があります。これを証明することは、読者の練習問題として残されています。 ↩
- ArbitrumはこれをTimeboostと呼ばれる優先順位付けの形式に置き換えることについて議論していますが、この記事の執筆時点では本番環境には入っていません。 ↩
免責事項:
この記事は [paradigm] からの転載です。すべての著作権は原作者に帰属します [Dan Robinson & Dave White]。この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、迅速に対応いたします。
免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。
関連記事
ETHを賭ける方法は?
ステーブルコインとは何ですか？
優先順位さえあれば十分
はじめに
この投稿では、任意のアプリケーションが独自のMEVを取得するために使用できるメカニズムであるMEV税を紹介します。
このメカニズムは、OP メインネット、Base、BlastなどのOPスタックL2で現在使用できますが、これは、これらのチェーンのブロック提案者が、競争的な優先順位付けと呼ばれる一連のルールに従うためです。
これらのチェーンの1つにMEV税を実装するために、スマートコントラクトはトランザクションの優先手数料の関数である手数料を請求します。アプリケーションが検索者に(たとえば)優先料金1ドルごとに99ドルのMEV税を請求する場合、そのトランザクションの競争力のあるMEVの99%をキャプチャできることを示しています。
MEV税は、広大な設計空間を開く単純な手法です。これらは、ブロック提案者によって実行される単一の共有オークションにフックするだけで、チェーン上の任意のアプリケーションが独自のオフチェーンインフラストラクチャを必要とせずに、独自のカスタムMEVオークションを実行できるようにすると考えることができます。
MEV研究における3つの主要な問題を解決するために、MEV税をどのように使用できるかを示します。
- スワッパーが受け取る価格を最適化する分散型取引所(DEX)ルーター
- 流動性プロバイダーが経験する損失対リバランス(LVR)を最小限に抑える自動マーケットメーカー(AMM) ユーザーが
- トランザクションによって作成された「バックランニング」MEVをキャプチャできるようにするウォレット
しかし、落とし穴があります。MEV税は、ブロック提案者が、検閲、覗き見、または遅延することなく、優先手数料で取引を並べ替えるなど、競争力のある優先順位付けのルールに厳密に従う場合にのみ機能します。ブロック提案者がこれらのルールから逸脱した場合、彼らはMEV税を逃れて自分たちの価値を獲得することができます。したがって、今日では、MEV税はL2シーケンサーを信頼することに依存しており、ブロック構築が提案者の収益を最大化する競争力のあるビルダーオークションによって支配されているイーサリアムL1ではまったく機能しない可能性があります。
それでも、MEV税の力と柔軟性は、優先順位付けが今日それを提供できるプラットフォームにとって正しい選択である可能性があることを示唆しています。また、競合する優先順位付けが比較的単純であることは、単一のシーケンサーを信頼することなく、分散型の方法でそれを実施する実行可能な方法がある可能性があることを示唆しています。この投稿が、この問題に対するさらなる作業の動機付けになることを願っています。
優先順位
付け誰かがイーサリアムL1またはL2でトランザクションを送信する場合、優先手数料を指定し、ブロック提案者に支払います.1 これは、トランザクションで使用されるガスを掛けた数値である priorityFeePerGas として指定され、builderPriorityFee (ETH での合計支払い) を取得することを想像できます。2
イーサリアム プロトコルには、ブロック内のトランザクションをpriorityFeePerGasの降順で貪欲に並べなければならないというルールはありません。ただし、これはブロックを構築するための一般的な方法であり、たとえば、OP スタック チェーンのシーケンサー、および geth と reth で使用される既定のアルゴリズムです。優先順位付けにより、トランザクションアクターはトランザクションの緊急性を効率的に表現できるだけでなく、特定の種類のMEVをブロック提案者に自然にチャネル化します。
これは、優先順位付けによって、MEVをめぐる競争が優先度ガスオークションに変わるためです。中央集権的な取引所に対してAMMを仲裁するなど、チェーンとの相互作用から利益を得る機会がある場合、検索者は最初にその機会を主張するために競争します。チェーンが優先順序を使用してトランザクションの包含と順序を決定する場合、検索者はトランザクションに高い優先度の手数料を設定することで競争します。
リスクのない利益がゼロになるまで競争する競争シナリオでは、勝者の検索者は、優先料金でMEVの全額を支払うことになります。3 したがって、コントラクトとのやり取りから得られる利益が100 ETHの場合、それを請求する最初のトランザクションは100 ETHの優先手数料を設定します。(これに関するいくつかの注意点については、「制限事項」セクションで説明します)。
MEV 税金
スマートコントラクトが、それと対話するトランザクションからMEVを取得したいとします。スマートコントラクトが独自のMEVをキャプチャしようとするさまざまなアプリケーション固有の方法に関する研究の膨大なライブラリがあります。
しかし、実際には、必ずしもアプリケーションについて何も知る必要はありません。ブロックが競争力のある優先順位付けによって構築されていることがわかっている場合、トランザクション内のMEVの量に関する1つの普遍的なシグナル、つまり優先手数料があります。
スマートコントラクトは、トランザクションの優先手数料を見て、その増加機能として独自の手数料を請求できることを提案します。たとえば、コントラクトでは、呼び出したユーザーが ETH の applicationPriorityFee = 99 * proposerPriorityFee をコントラクトに転送する必要がある場合があります。4
この新しい手数料は、トランザクションを送信する検索者によって支払われるため、その検索者の行動に影響を与えます。オポチュニティに 100 MEV がある場合、落札されたトランザクションは、合計 100 ETH (ブロック提案者に 1 ETH、スマートコントラクトに 99 ETH) の支払いとなるため、優先手数料 1 ETH のみを設定するようになりました。より高い優先手数料は、取引を不採算にします。優先度の低い手数料は、より高い手数料を設定した競合他社に機会を奪われることになります。これは、スマートコントラクトがトランザクションでMEVの99%を獲得したことを意味します。
スマートコントラクトによって課されるこの追加料金をMEV税と呼びます。MEV税により、アプリケーションはそれ自体の利益のために優先順位を乗っ取り、ブロック提案者に漏らすのではなく、ユーザーのためにMEVを再取得できます。
この料金が priorityFeePerGas の関数として十分に速く増加する場合、提案者にはごくわずかな量の MEV しか発生しません。priorityFeePerGasはウェイ(1 ETHの10億分の1)で表されるため、作業する精度が高くなります。たとえば、MEV税が50,000のpriorityFeePerGasが法外に高い税金になるほど敏感ロング、提案者への支払い総額は0.01ドル未満になります。5
ただし、重要な注意点があります。制限のセクションで説明したように、MEV税は、ブロック提案者が特定のルール(「競争的優先順位付け」と呼ばれるもの)に従っている場合にのみ機能し、注文でそれらのルールから逸脱して収益を最大化する必要はありません。これらのルールをトラストレスな方法で適用することは、未解決の問題です。
単一アプリケーションMEVキャプチャ
ここでは、ブロック構築に競争力のある優先順位を使用することが保証されているチェーン上で、MEV税を使用して、MEVにおける3つの重要な問題を軽減する方法、つまり、DEXインターフェースがスワッパーの取引執行を改善すること、AMMがLPの裁定取引の損失を減らすこと、ウォレットがユーザーのバックラン権を販売することでユーザーのMEV漏洩を減らす
ことを可能にする方法を紹介します。DEX routers
UniswapX や 1inch Fusion などのインテントベースのDEXルーティング プロトコルでは、ユーザー(Alice)がスワップのインテントに署名し、検索者は Alice にとって可能な限り最良の価格でそのインテントをルーティングまたは埋めるために競い合います。
UniswapXの現在のバージョンでは、アリスの指値価格が検索者が満たすまで時間の経過とともに変化するダッチオークションと、そのダッチオークションの開始価格を設定する最初のオフチェーン見積依頼(RFQ)オークションの2つのメカニズムを使用して、そのコンペティションを運営しています。
競争力のある優先順位を保証するプラットフォームでは、UniswapXはこれらを単一のメカニズムであるMEV税に置き換えることができます。これは、誰でもすぐに入力できる注文書にユーザーに署名してもらうことで実装できますが、トランザクションの優先度の関数として設定された実行価格を使用します。
例えば、アリスが1 ETHを売るUniswapX注文を持っている場合、アリスは注文の約定価格をminimumPrice + ($0.01 * priorityFeePerGas)と定義することができます。 minimumPrice は、現在の価格よりも大幅に低くなると予想される固定値である可能性があります。
検索者は、トランザクションを送信することによってアリスの注文を埋めるために競争します。最も優先度の高い手数料を持ち、元に戻らないトランザクションは、注文を満たすことになり、スワッパーが検索者が見つけることができる最良の価格を取得することを保証する必要があります。(これに対するいくつかの例外については、「制限事項」セクションで説明します。
Aliceの最低価格が$3,000で、ETHの現在の価格が$3,500の場合、落札トランザクションのpriorityFeePerGasは約50,000になります。(200,000ガスの費用がかかる取引では、ブロック提案者への支払いは約100億ウェイ(約0.000035ドル)にとどまることに注意してください。
これには、UniswapXで使用されている既存のメカニズムに比べて、いくつかの潜在的な利点があります。
MEV税を使用する注文は、オランダのオークションを使用する注文よりも速く、より良い価格で完了する可能性があります。本稿で説明したように、オンチェーンのダッチオークションは、ブロック間の価格変動により、MEVに何らかの価値を漏らし、完了するまでに多くのブロックを要する場合があります。対照的に、MEV税を使用する注文は、通常、MEVの大部分を獲得しながら、次のブロックで完了することができます。
オフチェーンRFQとは異なり、MEV税を使用する注文を埋めるためのオークションは、オンチェーンでのトランザクション実行でアトミックに発生します。これは、落札者がオンチェーントランザクションが成功した場合にのみ注文を満たすことを約束することを保証できることを意味します。これにより、AMMのようなオンチェーンの流動性がオフチェーンの流動性と競合しやすくなり、UniswapXはUniswap v4のようなマルチプールシステムにとってさらに効果的なルーターとして機能する可能性があります。
AMMs
通常、AMMは、loss-vs-rebalancing papersで議論されているように、ブロックの一番上で古い価格に対して取引する裁定取引者に価値を漏らします。MEV税を使用して、AMMにそのMEVをキャプチャさせることができます。物事をシンプルに保つために、これが集中流動性のないAMMでどのように機能するかについて説明します。(この種の問題を集中流動性でどのように解決できるかに興味がある場合は、Sorellaがまもなく1つの解決策を公開する予定です。
AMMは、取引の優先手数料の関数として追加料金を請求することでMEVをキャプチャし、ブロックで最初に取引する権利をオークションにかけることができます。その料金を計算して定義する方法はたくさんあります。ここでは、ほぼ間違いなく中立的な1つ、つまりプールの流動性の単位であるsqrt(xy)で表す方法について説明します。落札された取引は、プールの流動性を最も高める取引となります。
ブロック内のプールで最初のトランザクションを実行するとき、y_end > x_start y_start x_end条件を適用する代わりに、プールは条件を強制できます(定数としてaを使用)。
x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2
この式は、アービトラージトレーダーが真の価格で取引するインセンティブを与え、その取引の後、プールの中間価格が真の価格になるはずです。6
その最初の取引の後、取引はUniswap v2と同じように、固定のスワップ手数料で機能します。追加のMEV税を支払わずにプールで取引したい情報のない取引は、優先度の低い手数料を設定します。
AMMにMEV税を実装する方法は他にもたくさんあり、さまざまな効果があります。たとえば、MEV税は、スワップのインプットトークンまたはアウトプットトークンで建てられたり、プールによって適用されるスワップ手数料の割合に影響を与えたり、ユーザーの取引の最低価格を決定したりできます。これは興味深いデザイン空間だと思います。
バックランニングオークション
上記の説明は、MEVの漏洩を避けるために特定のアプリケーションをどのように設計できるかを示しています。しかし、ウォレットが、MEV税を組み込んでいないアプリケーションであっても、任意のアプリケーションと対話する任意のトランザクションから作成したMEVをユーザーがキャプチャできるようにしたい場合はどうでしょうか。
たとえば、アリスがAMMで大規模な取引を行うと、「バックランナー」が価格を戻すための裁定取引の機会を作成することがあります。これは通常、アリスに行くのではなく、MEVにリークされます。
MEV-ShareとMEVBlockerは、ユーザーがトランザクションからMEVを取得できるようにする2つのプロトコルですが、複雑なオフチェーンオークションシステムに依存しています。Orderflow Auction Design Spaceには、他にもいくつかの解決策が説明されています。
MEV税は、インテントベースのスマートコントラクトウォレットと組み合わせると、AliceのバックランニングMEVをキャプチャするための代替システムを構築できる可能性があります。AMMで取引するトランザクションを作成する代わりに、アリスが誰でもアリスのスマートコントラクトウォレットに送信できるインテントに署名して、そのアクションを実行させるとします。アリスのスマートコントラクトウォレットは、そのトランザクションを送信した人にMEV税を請求し、アリスに支払われます。
アリスのインテントを送信した検索者は、同じトランザクションでアトミックにバックランできるため、アリスをバックランする独占的な権利を持ちます。その結果、検索が競争的である場合、アリスをバックランすることによるすべての利益は、MEV税を通じてアリスに発生するはずです。
このシステムは、ユーザーをフロントランするトランザクションがそのユーザーへの MEV 税の支払いを回避できる可能性があるため、ユーザートランザクションのフロントランニングを含む攻撃から必ずしもユーザーを保護するとは限らないことに注意してください。この問題 (および考えられる軽減策) については、以下の「制限事項」セクションで詳しく説明します。それにもかかわらず、これは少なくとも、緩和策なしでパブリックmempoolsを使用するシステムの改善である可能性があります。
その他のユースケース
これらの例に加えて、MEV税のその他の潜在的な用途には、現在オフチェーンまたはオランダのオークションを使用しているほとんどすべてのものが含まれます。
- a href="
- Refinancingオークションのような、オラクルが生み出すオラクルの抽出可能な価値をキャプチャするためのプロトコル
- オランダのオークションよりも価値がある
クロスアプリケーションMEVキャプチャ
上記のソリューションは、単一のアプリケーションとの対話からMEVをキャプチャするように設計されています。しかし、検索者が同じトランザクションで複数のアプリケーションと対話することで、さらに多くの価値を獲得できる場合があります。
これらのアプリケーションの 1 つだけに MEV 税が課されている場合、トランザクションからのすべての MEV は、その MEV 税の高低に関係なく、MEV 税が課されたアプリケーションに送られる必要があります。
しかし、検索者のトランザクションが MEV 税を使用する 2 つのアプリケーションとやり取りする場合はどうなるでしょうか。たとえば、上記の MEV 課税された UniswapX 注文の 1 つを MEV 課税された AMM に対して約定することによってのみキャプチャできる MEV がある場合はどうなりますか?
その場合、各アプリケーションによってキャプチャされた超過 MEV の相対的な量は、それらのアプリケーションが MEV 税をどのように設定するかによって決まります。app_i MEV税として請求する値が関数tax_i(priority)によって与えられる場合、勝ち取った取引の優先順位は、次の式で優先順位を解くことで決定できます。
tax_1(priorityPerGas) + tax_2(priorityPerGas) = 合計MEV
(技術的には、優先順位の3番目の用語を追加することができますPerGas * gasブロック提案者に支払われる優先料金のアカウントに使用されますが、付録Aで説明したように、通常の状態では無視できる可能性が高いため、無視します。
priorityPerGas が線形である (つまり tax_1(priorityPerGas) = a_1 * priorityPerGas) であるMEV税の単純なケースでは、各アプリケーションが受け取る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)を設定できます。これらの相対的な税金では、AMMは、UniswapXの注文で1ドルのMEVと50,000ドルのMEVしかなかったとしても、最初に予約されることになります。
これは、今後の研究に値する幅広いデザイン空間であると考えています。
税金MEV制限
には、いくつかの複雑さと欠点があります。それぞれが今後の研究で興味深い分野だと考えています。
税MEVインセンティブの非互換性
は、独占的なブロック提案者にとってインセンティブと互換性がありません。これらは、トランザクションを含めるための公正な競争がある場合にのみ機能し、ブロック提案者が自分の収益を最大化するのではなく、「競争力のある優先順位付け」と呼ばれるルールに従う場合にのみ発生します。非公式かつ非網羅的に、これらの規則には以下を含めることを提案します。
- 優先順位付け。ブロック内のトランザクションは、priorityFeePerGas の降順の注文で順序付けする必要があります。
- 検閲抵抗。ブロック提案者がブロック中にトランザクション t1 を受信し、ブロックがいっぱいでないか、t2.priorityFeePerGas が t1.priorityFeePerGas <ようなトランザクション t2 を含む場合、ブロックにはトランザクション t1 を含める必要があります。
- 取引前のプライバシー。ブロック提案者は、プライベートエンドポイントを介してトランザクションを受け入れる必要があり、ブロックにコミットする前にそのようなトランザクションを他の人と共有したり、それらのトランザクションの内容を独自のトランザクションを構築する際の入力として使用したりしてはなりません。
- 最後の一瞥はありません。ブロック提案者は、明確な時間 blockTime を設定し、それ以前は誰からのトランザクションも受け入れず、その後は誰からのトランザクションも受け入れません。
これらの特性の1つ以上に違反した場合、MEV税の有効性が弱まる可能性があります。検閲抵抗に違反するブロック提案者は、競合するトランザクションを除外し、その機会を利用するゼロプライオリティトランザクションを送信することで、ほとんどのMEV税を回避できます。取引前のプライバシーを侵害するブロック提案者は、他の取引からMEVを盗んだり、優先手数料を覗き見して、自分で設定する必要がある高さを正確に知ることができますが、他の誰よりも遅く取引を提出できる人は、機会のために他の人を上回っているかどうかについて無料の「最後の外観」を持っています。 いずれの場合も、逆淘汰の問題を引き起こし、最終的に競争を阻害する可能性があります。
残念ながら、最初のプロパティはプロトコル層で簡単に適用できますが、他のプロパティを信頼せずに強制することは未解決の問題です。
プロトコル層で強制力がない場合、これらのルールにコミットする単一のシーケンサーは、ルールから逸脱しないように信頼される必要があり、提案者がブロック構築を競争力のある収益最大化オークション(イーサリアム L1のMEV-Boostなど)にアウトソーシングした場合、ブロックはそれらに従わない可能性があります。
これらの問題は、ブロック構築に競争力のある優先順位を使用することを約束する単一の信頼できるシーケンサーで「解決」できます。また、SorellaのAngstrom、FlashbotsのSUAVE、Leaderless Auctions、Multiplicityなど、コンセンサス、暗号化、信頼できる実行環境を組み合わせて使用する分散型メカニズムで解決できる場合もあります。
フルブロック
MEV税の通常の操作の 1 つの例外は、ブロックが完全にいっぱいになったときに発生します。その場合、ブロック提案者は、優先度の低いトランザクションを単にブロックの後半に含めるのではなく、除外する必要があるかもしれません。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 の現在のシーケンサー、7 など、トランザクション順序付けルールを通じて緩和MEVいくつかの試みは、ブロック提案者が注文しなければならない別の順序付けルール、先着順(「公平な順序付け」と呼ばれることもあります)を適用することに焦点を当てていますそれらが表示される注文のトランザクション。
優先順位付けでは、特定の期間内に到着するトランザクションを平等に扱い、代わりに宣言された優先順位で並べ替えるという、別のアプローチを取ります。
先着順は、複数のバリデーターがいる実際のネットワーク環境で実施したり、定義したりすることさえ困難です。また、単一の信頼できるシーケンサーを使用しても、無駄なレイテンシーの競合やスパムが発生する可能性があります。最後に、MEV税は、資産価格の不連続な「ジャンプ」による裁定利益など、先着順ではできない特定の種類のMEVを排除できる可能性があります。先着順に対する優先的な順序付けの潜在的な利点は、Budish, Cramton, Shim (2015) で議論されている連続時間交換に対する離散時間の利点といくらか関連しています。
一方、優先順位付けはデフォルトでMEVに価値を漏らしているように見えますが、この投稿では、それを再キャプチャするようにアプリケーションを設計する方法を示します。
料金の分担。イーサリアム L2 である Blast は、トランザクションでアクセスされたスマートコントラクトと優先手数料と基本手数料の両方の一部を共有します。
MEV税は(少なくとも優先手数料については)同様のことを許可しますが、料金共有のための特別なサポートなしに、競争力のある優先順位付けを使用する任意のチェーンのアプリケーション層で実装できます。また、アプリケーションが独自の税金を優先料金のカスタム関数として定義できるため、柔軟性が向上し、MEV対応アプリケーションの構成可能性が高まる可能性があります。
トラストレスソリューション。この投稿では、プラットフォームが競争力のある優先順位付けを使用する動機と、それを使用するプラットフォームを活用する方法に焦点を当てています。
競争的な優先順位付けに必要な他の各プロパティについては、事前にかなりの議論がありました。例えば、Fox, Pai, Resnick (2023)では、検閲抵抗がない場合のオンチェーンオークションの脆弱性について議論し、複数の提案者を同時に使用する検閲耐性オークションの設計について説明しています。ただし、トランザクションの特定の順序は提案されません。
FlashbotsのSUAVEs、Sorella's Angstrom、Leaderless Auctions、Espresso、Offchain Labsなど、信頼を最小化したブロック構築のメカニズムを構築する研究が行われています。@espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost、Péter Szilágiによるパブリックトランザクションのインクルージョンを義務付けました。
結論
この投稿が、L2 が優先順位付け (OP スタックでデフォルトでサポートされているように) の使用を検討するよう促し、サポートされている場合はMEV税を試すアプリケーションを刺激することを願っています。
また、L1 と L2 の両方で信頼を最小化した競争上の優先順位付けのためのプロトコルのさらなる研究の動機付けにもなることを願っています。この問題に協力することに興味があり、6月6日(木)までにこれを読んでいる場合は、TLDRフェローシップに応募して、DanとMEV耐性L2シーケンサーに取り組むことができます。または、dan@paradigm.xyz と dave@paradigm.xyz にアイデアをお寄せください。
脚注
- この投稿では、「プロポーザー」を使用して、特定のブロックに含まれるトランザクションを決定するアクターまたはプロセスを指します。イーサリアムL2では、この役割は通常「シーケンサー」によって満たされます。イーサリアムL1では、プロポーザーと呼ばれる特定のイーサリアムバリデーターによって埋められますが、多くの場合、プロポーザーはブロックを構築するタスクを「リレイヤー」と「ビルダー」が参加する競争オークションに委託します。これらの責任がどのように分担されるかについての詳細は、この投稿の範囲外です。 ↩
- ガスごとの優先手数料は、実際にはトランザクションで明示的に指定されていませんが、トランザクションで計算できます。トランザクションはガス価格を指定しますが、イーサリアムは基本料金も請求し、ガス価格から差し引かれて燃やされます。基本料金は、取引者の管理下にないため、MEV税の目的で無視する必要があります。ガスあたりの優先手数料(ブロック提案者に支払われる取引手数料の部分の価格)は、SolidityでpriorityGasPrice = tx.gasprice - block.basefeeとして計算できます。 ↩
- あるいは、単に「MEV」を定義して、検索者の利益を除外し、バリデーターに送られる値のみを参照することもできます。 ↩
- proposerPriorityFee(priorityFeePerGasにトランザクションで使用されるガスの合計を掛けたものに等しい)は、トランザクションが最終的に使用するガスの量を知る方法がないため、契約中に実際に計算することはできません。ただし、必要なのは上限だけなので、これは一般的には問題になりません。安全のために、priorityFeePerGasに3,000万(イーサリアムブロックの現在の最大ガス)を掛けることができます。この値を過大評価することは、単にMEV税がMEVのさらに大きな割合を占めることを意味します。 ↩
- トランザクションが3,000万ガスを超えることができないと仮定すると、priorityFeePerGasが50,000の場合、ガスの支払いは1500 gwei(ETH価格4,000ドルで約0.006ドル)になります。 ↩
- アービトラージの利益がゼロになるようにpriorityFeePerGasが設定されている場合、利益最大化アービトラージ取引は、関数最大化AMM上の同じ取引に対応する必要があります。これを証明することは、読者の練習問題として残されています。 ↩
- ArbitrumはこれをTimeboostと呼ばれる優先順位付けの形式に置き換えることについて議論していますが、この記事の執筆時点では本番環境には入っていません。 ↩
免責事項:
この記事は [paradigm] からの転載です。すべての著作権は原作者に帰属します [Dan Robinson & Dave White]。この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、迅速に対応いたします。
免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。
関連記事
ETHを賭ける方法は?
ステーブルコインとは何ですか？