MEV の今後 5 年間: MEV 分野の最新トレンドを理解する
元の編集: aididiaojp.eth、Foresight News
元の編集: aididiaojp.eth、Foresight News
最近「」という記事を書きました。Penumbraバッチオークションと閾値暗号取引により、SBP市場構造は形成されません。また、Osmosis チームは MEV 対策メカニズムに多くの研究時間を費やしてきましたが、これらのチェーンでの MEV 市場構造がどのようになるかは明らかではなく、少なくとも一時的に成熟した MEV サプライチェーンを形成することができません。
ソースリンク
論争の再燃
私たちは、MEV が道徳的または法的に盗難に該当するかどうかについて、素晴らしい議論を行ってきました。強気相場の間、誰もが MEV の取得に忙しく、市場の熱気によって多くのことが隠蔽されました。現在、オンチェーンの金融活動は落ち着いており、MEV 買収に対する「道徳的利益」が見られると期待しています。 Twitter では古いエピソードの再放送も行われ、誰が MEV に値するかについてファンの間で白熱した議論が行われる予定です。しかし検索者は気にも留めず、MEVの取得は今後も続くだろう。
MEV 対応ハードフォーク
MEVの料金市場はファーストプライスオークションに移行します。コア開発者は、プロトコル設計の観点から MEV を検討してきました。いくつかのエコシステムとのやり取りから、コア開発者は 2 つの陣営に傾く傾向があることがわかりました。
コア開発者の最初の陣営は、MEV の取得コストを増加させるメカニズムを設計しました。これらは、バッチ オークション、しきい値暗号化、事前コンセンサスなどのように見えます。彼らは、これらのメカニズムによって MEV の抽出のコストが高くなるのではないかと期待しています。潜在的な罰則に直面して抽出にバリデーターとの共謀が必要な場合、それはまったく不可能である可能性があります。ただし、これらのメカニズムにより、ユーザー対話とプロトコル インセンティブのコストと複雑さが増加します。現時点では、具体的なメカニズムの設計についてはまだ広範な合意に達していません。
プロトコル開発者の別のグループは、価値の回避を最小限に抑え、プロトコル自体に対する MEV の影響を軽減し、参加者の公平な配分を確保することに重点を置き、エレガントなメカニズムを策定し、より文明的なブロックチェーンを構築するアプローチを採用しました。つまり、次の 3 つの質問です。まず、プロトコル ユーザーに対する MEV の影響を最小限に抑えるにはどうすればよいでしょうか。次に、プロトコル自体に対する MEV の影響を軽減するにはどうすればよいでしょうか?第三に、プロトコルが MEV を公平に分配できるようにするにはどうすればよいでしょうか?
ソースリンク
EIP-1559 のような複雑なメカニズムは広く使用することが難しく、実際には適切なソリューションではありません。開発者は提案者手数料の削減を目標に EIP-1559 の足跡をたどると思います。 MEV のシャドウフィー市場は、提案者と MEV 構築者に利益をもたらしますが、他のすべてのユーザーには不利益をもたらします。 EIP-1559 以前の料金と同様、MEV ブロックの生成と包含のダイナミクスは根本的に不公平な市場を生み出します。そのために、建設者と提案者の関係を改善することを特に目的とした 1559 のようなメカニズムが登場することを願っています。
提案者であれ、収入を抑制されるべき役立たずの投機家であれ、私の将来予測は非常にシンプルです。今後 5 年以内に、さまざまなエコシステムで複数のハードフォークが発生するでしょう。これらのハードフォークは明らかに特定のチェーンの MEV 市場をターゲットとしています。 MEV に対するコストや MEV 利益の分配を抽出できます。理想的には、MEV サプライ チェーンと L1 が緊密に統合されることになります。
垂直統合
市場では、提案者、構築者、検索者の間の垂直統合について多くの議論が行われてきました。基本的な考え方は、提案者がビルダーの収益のために内部ビルダーを維持することも、ビルダーが特定の検索者を優先することもできるということです。垂直統合は中小企業を圧迫し、少数の大手建設会社が市場を独占する可能性があります。
その恐怖は少し大げさだと思います。プロトコルは提案者をランダムに選択し、検索市場と構築市場は非常に競争が激しくなります。 （市場の全権力を有する）提案者間の水平的な協力は、より懸念されるように思われる。提案者間の価格固定協定は、ステーカーがアクティブ化するソフトフォークを通じて強制できます。有害な PBS 市場がユーザー エクスペリエンスに影響を与えるのを防ぐために、プロトコルは提案者の信頼を破る必要がある場合があります。さらに悪いことに、共謀している提案者が隣接するスロットを持っている限り、MEV の複数のブロックが撤回される可能性があり、ブロックチェーンの最終化に不安定な影響を与える可能性があります。
垂直統合は特殊な場合に必ず起こります。バンドル間の相互作用によって一定量の MEV が生成されます。ビルダーはこのクロスバンドル MEV にアクセスでき、内部の専用サーチャーを統合できます。調査者、建設者、提案者の間の緊密でより信頼できる関係を経済的に実行可能にする他の特別な状況が存在する可能性があります。
MEV を意識したアプリケーション設計
それはすでに起こっているので、それは不正行為のようなものです。例えばCowSwapチームはすでに MEV 対応アプリケーションを展開しています。トレードオフを行う必要があるため、MEV の最小化がしばらく議論の中心となるでしょう。ここでの研究は、「MEV を排除するには何を放棄しなければならないのか」という 1 つの核心的な質問によって推進されています。
協定の設計範囲は非常に限られていますが、実際には合意に達することも困難です。ただし、アプリケーションには MEV の最小化を実現するためのオプションが多数あります。何が機能するかはアプリケーションによって異なります。また、レンディング プロトコルでは機能しない DEX 最小化メカニズム (バッチ処理など) も登場します。新しい研究により、各 dApp 分野でいくつかの変化がもたらされます。ただし、新しい MEV 最小化モデルは、既存のアプリケーションの勢いに対抗する必要があります。どの dApp が MEV 耐性設計をユーザーに広く採用するか、またどの dApp が現在のレベルの MEV 世代を採用するかは不明です。
ただし、MEV を最小限に抑えるためのプロトコルの設計にとどまりません。代わりに、MEV はアプリケーション設計のツールとなり、アプリケーション設計者がいつ、どのように MEV を生成するかを選択します。私たちは、MEV がいつ受け入れられるかを決定するための独自のフレームワークと、システムによって生成される MEV の量を調整するための一連の標準技術を提案します。
明示的な MEV
MEV を意識したアプリケーション設計の結果として、MEV が取り込まれ、ツールとして使用されます。驚いたことに、MEV サプライ チェーンは、通常のトランザクションにアクセスできないこと、MEV トランザクションが決して復元されないこと、そしてビルダーが不採算チェーンでブロック スペースを無駄にしないことを保証します。 MEV トランザクションはより速く確認され、シーカーはその MEV をシャドウ手数料に変換して、トランザクションに高い優先順位を与えます。アプリケーションはこれらの関数にアクセスするために意図的に MEV を使用し始めます。これを私は「明示的 MEV」と呼んでいます。
明示的な MEV はアプリケーションに特定のスーパーパワーを与えることができます。これにより、ユーザーは EIP-1559 ヒントをオプトアウトしても、トランザクションを迅速に確認できるようになります。アプリケーションは意図的に MEV の機会を解放し、重要なシステム運用に結び付けることができます。たとえば、Oracle アップデートに 0.1 ETH MEV を追加できます。この MEV の機会によりシーカー間で競争が発生し、トランザクションを確認した最初のシーカーがその MEV を獲得します。 PBS MEV が登場する前は、これにより優先ガス オークションが行われ、参加するシーカーにとっては非常に高価になる可能性がありました。しかし、最新の MEV サプライ チェーンでは、このレースに負けた場合のコストがなくなり、検索者はトランザクションを復元すると製造者によって削除されることがわかります。
MEV を意識した設計の論理的な結論は、MEV を含む設計です。アプリケーションは明示的に MEV を作成し、MEV を設計に組み込み、ブロックスペース市場で特権的な地位を購入するためにそれを使用します。明示的な MEV トランザクションは、高価値のユースケースの標準トランザクションを効果的に置き換えます。
MevWeth
明示的 MEV には次の 2 つのことが必要です。
まず、標準を作成する必要があります。高価なガスを避けるために、すべての明示的な MEV は、それを作成したコントラクトに関係なく、同じオンチェーン状態を使用する必要があります。これにより、MEV は複雑さを大幅に増すことなく、多くのトランザクションにわたって接続を確立できます。探索者は、アプリケーションが明示的な MEV を作成しているかどうかを知る簡単な方法を必要としています。探索者は、特定の予測可能な状態変化を探すことができる必要があります。明示的な MEV を検出するために多くの契約をスキャンする必要はありません。各コントラクトが独自の明示的な MEV を管理する場合、検索者は多くの状態検索と変更を行わなければそれを取得できません。単一の特定のコントラクトで明示的な MEV を管理できる必要があります。
第二に、別の会計システム、明示的に MEV は ETH 建てである必要があります。シーカーはガス価格のリスクを負うため、支払いはガス資産で行う必要があり、これによりすべてが大幅に簡素化されます。ただし、これにより、明示的な MEV を生成するコントラクトに新しい要件が課されます。コントラクトは、MEV にどれだけの ETH を費やすことができるかを追跡する必要があります。 DEX が明示的な MEV に誤ってユーザー ETH を費やしてしまうと、悲惨な結果になります。したがって、明示的な MEV と ETH を使用する契約は、MEV 対応 ETH と MEV 非対応 ETH のバランスを維持する必要があります。
したがって、MEV を作成するための標準と MEV 用の会計システムが必要です。非常に明確かつ明白で直観的なソリューションはこれらのニーズを組み合わせたもので、MEV 対応 ETH のユーザー残高を追跡するシステムを簡単に構築できます。私たちは ETH を受け入れてユーザーのために保持するコントラクトを構築する方法を正確に知っており、明示的な MEV 機能の追跡と管理の実装は簡単です。
これを「MEV Wrapped ETH」または MevWeth と呼ぶことができます。
このコードは、明示的な MEV 管理インターフェイスを備えた WETH 10 の拡張機能のように見える場合があります。このインターフェイスは次の場所でホストされている可能性があります。githubオン、そしておそらくすでにメインネットにデプロイ済み優れた。
MevWeth は、以下の標準を提供する ERC 20 です。
addMev() 一連の関数を通じて MEV を作成する
getMev() ファミリを介して MEV を取得する
Mevitize.sol 基本コントラクトを介して、明示的な MEV 作成をコントラクトに追加します。
ネガティブ MEV
明示的な MEV を、それを作成したトランザクションから分離することはできません。明示的 MEV は、暗黙的 MEV をトランザクションに追加します。これらを組み合わせて、より迅速な確認 (および最新の MEV サプライ チェーンのその他すべての利点) を補助するために使用されます。ただし、特定のカテゴリのトランザクションにはすでに大量の MEV があります。清算や DEX 取引などでは、明示的な価値創造がなくても優先順位の確認を得るのに十分な MEV がすでに生成されています。明示的な MEV を母集団に追加すると、MEV サプライ チェーンへのアクセス料金が過剰になります。
いずれにせよ、これらの取引コストは法外に高額です。 Uniswap ユーザーは、自分の取引での MEV 作成の範囲を座って計算したり、それを「手数料優先市場で清算された MEV」の概念と比較したりしません。 MEV を優先料金として扱っている人はまだ誰もおらず、たとえ扱っていたとしても、その価値を回収する効率的な方法はありません。マイナスの MEV はすべてを変える可能性があります。
負の MEV は、ゼロ未満の明示的な MEV です。マイナスの MEV を使用したオンチェーン操作では、MevWeth 経由で MEV を支払う必要があります。事前の支払いがなければ操作を完了することはできません。 MEV サプライ チェーンにおける既存の力関係を理解することが重要です。ユーザーとアプリケーションは抽出される価値を生み出しますが、抽出サプライ チェーンにはまだ参加していません。提案者は他のサプライ チェーン参加者にレンタル料を請求します。マイナス MEV は、提案者が最終的にこのプロセスを制御できないこと、および提案者はユーザーとアプリケーションが生み出す価値に依存していることを認識するものです。
負の MEV を指定すると、ユーザーまたはプロトコルは価値のある操作によって作成された MEV を再キャプチャできます。私たちは提案者から MEV を受け取り、その価値を生み出した人にそれを返すことができます。ネガティブ MEV は、MEV サプライ チェーンで機能するためのシンプルかつ直接的な方法を提供します。ネガティブ MEV では、ユーザーは価値抽出プロセスのターゲットではなく参加者になります。
たとえば、Uniswap ユーザーは、取引のスリッページ マージンを減らすことで MEV から身を守ることができます。ただし、これにより取引が悪化したり、成立の可能性が低くなったりすることがよくあります。ネガティブ MEV は、トランザクション自体を変更せずにトランザクションの結果を改善する帯域外の方法を提供します。スリッページの範囲を狭める代わりに、ユーザーはトランザクションに少量のマイナス MEV を付加することができます。これにより、検索者との対話を通じて料金リベートが効果的に提供されます。ユーザーはより良い結果を得ることができます。トランザクション自体には影響はありません。ユーザーへのトランザクションと支払いのアトミックな結合により、ユーザーは最終的にユーザーが生み出す価値を明示的に共有できるようになります。
ネガティブ MEV は、清算などの高 MEV プロセスへのアクセスをプロトコルが制御する方法を変更し、ユーザーが DEX 取引などの高 MEV 操作を実行する方法を変更します。
MevWallet
MevWalletは、ユーザーが明示的な MEV をトランザクションに添付できるようにするスマート コントラクト ウォレットです。これは非常に標準的な EIP-712 メタトランザクション標準に従っており、ユーザーはどのトランザクションにチップを渡すかを指定できます。トランザクションが署名されると、誰でもそれをブロードキャストできます。 MevWallet はトランザクションの詳細を確認し、トランザクションを実行する前にいくつかの基本条件を適用します。他のスマート コントラクト ウォレットと同様、トランザクションは EOA からではなくウォレットから実行されます。 msg.sender はウォレット、tx.origin はサーチャーです。
トランザクションの実行後、MevWallet はガスの使用量を計算してチップを追加し、結果がプラスの場合は MevWeth のシーカーに補償します。結果が否定的な場合は、保存されている MEV を MevWeth から取得します。マイナスの取引手数料を支払うことができ、取引によって実行を完全に相殺するのに十分な MEV が生成された場合、ユーザーは支払いを受けられます。生産した MEV に対する補償を要求することで、ユーザーは提案者をブロックするために放棄していたであろう価値を MEV サプライ チェーンを通じて取り戻すことができます。
MevWallet トランザクションは、タイムロックと期限に加え、ノンスベースの重複支払い保護をサポートしています。この組み合わせにより、時間に基づいた複雑な料金調整が可能になります。たとえば、トランザクションは、確認されるまで時間の経過とともにより明示的な MEV を生成する場合があります。これにより、検索者間でダッチオークションが形成され、市場で入手可能な最低価格で取引が確実に確定されます。他の多くの興味深い料金エスカレーター モデルは、オンチェーンのオーバーヘッドなしで実装できます。料金オークションはシーカー間で行われ、トランザクション確認をロールバックするため、ガス オークションがどれほど複雑になっても、ユーザーもシーカーも追加のガス費用が発生することはありません。
そしてTypeScriptそしてRustコードベースがあります最小限のエージェント工場新しい MevWallet をデプロイします。コードはライセンス供与されており、GitHub で入手できます。 MevWallet に現時点で欠けている主な点は、検索者が取引を確認する方法です。私はこれを行うための最良の方法をまだ探しています。シンプルな CRUD API と専用メモリ プールを検討しましたが、それが長期的に実行可能なソリューションであるかどうかはわかりません。
MEV の今後 5 年間
MEV の次の 5 年間が初年度と同じくらい素晴らしいものになることを楽しみにしています。 MEV 研究が思春期を経て成熟期に入るにつれて、私たちはそれをアプリケーション設計に歓迎する必要があります。私たちはその強みを探し、それを私たちのアプリケーションやプロトコルに貢献させるべきです。 MEV は窃盗ではなく、倒すべき敵でもありません。MEV は私たちの実践に不可欠な部分です。
元のリンク
