並行実行の時代が到来し、Monad上のMEVの状況を一望する

深潮TechFlow
2024-07-03 09:45:42
コレクション
この記事では、Monad上に強力なマイナー抽出可能価値オークションインフラストラクチャ(MEVA)を構築する可能性について探討します。

著者:APRIORI

編纂:深潮TechFlow

イントロダクション

ブロックチェーンのパフォーマンスを向上させて大規模なアプリケーションを実現する過程で、Monadは非同期I/O、最適化されたPatricia Trie、遅延実行、楽観的並行制御などの一連の基盤最適化手段を通じて、Ethereum仮想マシン(EVM)モデルを効果的に最適化しました。これらの改善は、分散化を犠牲にすることなく、Ethereumなどのプラットフォームにおける実行のボトルネックや非効率な状態アクセスの問題を解決しました。

本稿では、Monad上に強力なマイナー抽出可能価値オークションインフラ(MEVA)を構築する可能性を探り、EthereumのFlashbotsやSolanaのJito Networkの貴重な経験を参考にします。

いくつかの重要なポイントを強調したいと思います:

  1. MEVはあらゆるブロックチェーンネットワークの固有の特性です。強力なMEVAインフラは、ブロック生成プロセスにおける負の外部性とインセンティブの不一致を回避するために不可欠です。

  2. MEVAの設計は、ブロックチェーンの基盤メカニズム、特にコンセンサス実行段階と密接に関連しています。将来の改善は、これらの要因の進化とネットワークが異なる圧力下でのパフォーマンスに依存します。

  3. EthereumとSolanaにおけるブロック生成の歴史的傾向は、Monad上のMEVA設計に参考を提供します。

  4. Monadのような高性能で遅延実行のブロックチェーンでは、MEVAは時間制限に対処するために、高頻度取引に似た確率的ブロック構築と検索戦略を必要とする可能性があります。

これらの問題を探求することで、Monadの独自のアーキテクチャとパフォーマンス要件に適応したMEVAインフラの設計に関する洞察を提供したいと考えています。

EthereumにおけるMEVAの背景

Ethereumのコンセンサス実行段階におけるMEVA

Ethereumでは、コンセンサスは先に実行される必要があります。ノードがブロックに同意する際、彼らが同意するのはブロック内のトランザクションリストだけでなく、ブロック実行後に要約されたMerkleルートも含まれます。したがって、提案者は提案を広める前にブロック内のすべてのトランザクションを実行する必要があります。同時に、検証ノードも投票前にこれらのトランザクションを実行する必要があります。

図 1:MEV-Boostにおける提案者-ビルダー分離(PBS)のビルダー作業フロー

図1は、MEV-Boostにおける提案者-ビルダー分離(PBS)の典型的なビルダー作業フローを示しています。ビルダーがブロック構築を完了した後、それをリレイヤーに提出し、リレイヤーはそのブロックを実行層(EL)クライアントに転送してシミュレーションと有効性チェックを行います。

実行はコンセンサスの前提条件であるため、ビルダーがブロックを構築する際には、ブロックを実行層(EL)クライアントに転送し、その有効性を確認するためにシミュレーションを行う必要があります。コンセンサス-実行段階の必要な役割に加えて、シミュレーション段階はビルダーとサーチャーに利益をもたらします。

ビルダーの観点から見ると:各トランザクションをシミュレーションすることで、ビルダーはブロックが自分自身と検証者にとってどれだけの価値があるかを正確に見積もることができます。また、トランザクションの順序を再調整して、ロールバックを最小限に抑え、メモリプールやバンドルトランザクションから抽出されるガス料金や基本的なチップを最大化することもできます。正確な見積もりにより、彼らは検証者に対してより高い価格を提示することができます。

サーチャーの観点から見ると:ビルダーがトランザクションをオンチェーンにする前に、ロールバックの可能性があるバンドルトランザクションをフィルタリングすることで、サーチャーは戦略の実行を確実にし、確実性を高めることができます。さらに、サーチャーは最新のブロック状態にアクセスできます。コンセンサス層(CL)が新しいブロックを広めると、サーチャーはそのブロックの状態を利用して、利益を上げるバンドルトランザクションを構築する出発点とすることができます。同時に、ビルダーが現在、サーチャーが次に構築されるブロックの状態情報を取得できるように、より多くのプロトコル外トランザクションや機能を提供している兆候もあります。

しかし、PBSの発展はブロック構築の集中化を招き、これは従来の取引において企業が競争専用のマイクロ波ネットワークチャネルを利用してアービトラージ戦略を優先的に実行する状況に似ています。

ネットワークの成熟と製品のイテレーション

現在、MEVAがEthereumの発展に伴ってどのように進化してきたかを探ります。図2に示します。

図 2:Ethereumネットワークの発展に伴うMEVAの時間順序ビュー

優先ガスオークション(PGA)時代

図3に示すように、サーチャーは有利なMEVの機会を特定し、スマートコントラクトトランザクションを公共メモリプールに提出します。この公開性は、チェーン上での公開入札と一価格オークションを引き起こし、失敗したトランザクションでさえガス料金を発生させます。

この時期には、同じ(アカウント、アナウンス)ペアのトランザクションや、増加する入札によってネットワークが混雑したり、コンセンサスが不安定になるなど、競争が激しく高価な非構造化MEV活動が発生しました。

図 3:シンプルな優先ガスオークションの概念図

FlashbotsとEIP-1559

これらの問題を解決するために、Flashbotsはリレイヤーを導入し、サーチャーとブロック生産者(PoW時代のマイナー)との間の仲介オークションハウスとして機能します。この措置により、MEV市場は公開入札の一価格オークションから密封入札に変わりました。図4に示すように、リレイヤーは公共メモリプール内の入札のエスカレーションを防ぎ、より秩序ある安全なブロック生成プロセスを確立するのに役立ちます。

EIP-1559の料金構造もここで役立ちました。基本料金を通じて入札を簡素化しましたが、ブロック内のトランザクション順序の問題は解決されず、依然として優先料金によってMEVが駆動されます。実際、多くのサーチャーは以前、coinbase転送を通じて直接マイナーに入札していました。彼らは最終的にcoinbase料金に対してより多くの不満を持つことになりました。なぜなら、彼らはもはや0ガスのバンドルトランザクションを提出できなくなったからです。

図 4:リレー付きのMEVA

提案者とビルダーの分離(PBS)

Ethereumがマージを完了し、プルーフ・オブ・ステーク(PoS)に移行した後、提案者とビルダーの分離(PBS)が実施され、ブロック生成パイプライン内の役割分離をさらに最適化しました。前述のように、リレイヤーは現在、ブロックビルダーと提案者の間の仲介役を果たし、データの可用性とブロックの有効性を確保する責任を負っています。提案者は複数のビルダーに接続して異なるプライベートトランザクションを行うことができるため、ビルダーは提案者に料金を支払うことで競争しなければなりません。このダイナミクスは図5に示されています。

図 5:PBS時代のMEVA

集中のリスク

これらの歴史的な進展にもかかわらず、ビルダー市場における集中リスクの増大を強調する必要があります。過去1年間、上位9名のビルダーは市場シェアの50%以上を持ち続けており、高度な市場集中を示しています。現在の集中状態はさらに顕著で、上位3名のビルダーが90%以上のブロックをカバーしています。

図 6:ビルダーの市場シェア。この図はビルダー市場における高度な集中の一般的存在を示しています(画像出典

Solana上のJito

Jitoのシステムアーキテクチャ

Solana上の標準MEVAとして、JitoはSolanaが低い取引コストにより高いゴミ取引行動を引き起こす問題を解決するために作成されました。失敗した取引の料金(約0.000005 SOL)が予想利益を超えない限り、ゴミ取引行動は効果的にインセンティブされます。

Jito Labsの2022年の報告によると、その年に96%以上のアービトラージおよび清算試行が失敗し、ブロックには50%以上のMEV関連取引が含まれていました。報告はまた、清算ボットがネットワークに数百万の重複パケットを送信し、数千回の成功した清算を完了するためだけに、99%以上の失敗率を引き起こしたことを指摘しています。

図 7:Solana上のJitoのMEVA

SolanaにおけるMEV外部性問題の深刻さは、Jitoがブロック生成プロセスに秩序と確実性をもたらすことを目的としたMEVA層を開発するきっかけとなりました。Jitoが提案した元のMEVAアーキテクチャを振り返ってみましょう。図7に示します。

Jitoには以下のコンポーネントがあります:

リレイヤー - 代理としてトランザクションを受信し、ブロックエンジン(またはMEVAサプライチェーン)と検証者に転送します。

ブロックエンジン - リレイヤーからトランザクションを受信し、サーチャーを調整し、バンドルを受け入れ、バンドルシミュレーションを実行し、最適なトランザクションとバンドルを検証者に処理させるために転送します。特に注目すべきは、Jitoがバンドルを含めるために部分ブロックオークションを行い、全ブロックオークションを行わないことです。歴史的に、2つのスロット内で80%以上のバンドルを処理しました。

擬似 メモリプール - Jito-Solanaクライアントを通じて約200ミリ秒の操作時間ウィンドウを作成し、注文フローの離散化オークションを引き起こします。Jitoは2024年3月9日にこのメモリプールを閉鎖しました。

Jitoの設計選択

Jitoシステム設計の具体的なコンポーネントを探り、これらの設計選択がSolanaのブロック生成プロセスからどのように派生したかを考慮します。

Jitoは全ブロック構築ではなく部分ブロックオークションのみをサポートしているのは、Solanaのマルチスレッド実行モデルがグローバルスケジューリングを欠いているためかもしれません。具体的には、図8は並行スレッドがトランザクションを実行している様子を示しており、各スレッドは自分の待機実行トランザクションキューを維持しています。トランザクションはスレッドにランダムに割り当てられ、優先料金と時間に基づいてローカルでソートされます。スケジューラー側にグローバルソートがない場合(1.18.xの更新前)、Solanaのトランザクションは本質的にスケジューラーの揺らぎにより非決定的な結果を経験します。したがって、MEVAにおいて、サーチャーや検証者は現在の状態を信頼性高く特定することができません。

図 8:Solanaクライアントのマルチスレッド実行モデル。MEVAのバンドル段階が独立したスレッドとしてマルチスレッドキューに追加されていることに注意してください

エンジニアリングの観点から、Jitoのブロックエンジンを追加のスレッドとして並行して実行することは、Solanaのマルチスレッドアーキテクチャに非常に適合します。バンドルオークションはJitoブロックエンジンスレッド内で優先料金に基づくソートを確保しますが、バンドルが常にユーザートランザクションよりもグローバルに優先されることは保証されません。

この問題を解決するために、Jitoはバンドルスレッドにブロックスペースの一部を事前に割り当て、バンドルがブロック内にスペースを持つことを保証します。非決定性は依然として存在しますが、このアプローチは戦略実行の成功確率を高めます。これにより、サーチャーはオークションに参加するインセンティブを得ることができ、ネットワークにゴミ取引を送信するのではなくなります。バンドルのためにブロックスペースを確保することで、Jitoは秩序あるオークションを促進し、取引のスパムの混乱効果を緩和するバランスを取ることができます。

擬似メモリプールの削除

Jitoの広範な採用は、Solanaにおけるスパム問題の緩和において積極的な成果を上げています。p2pの研究と図9に示されるデータによると、Jitoクライアントを採用した後、相対的なブロック生産率が著しく向上しました。これは、Jitoが2023年に導入した最適化されたブロックエンジンにより、取引処理がより効率的になったことを示しています。

図 9:JitoがSolana上のスパム問題を効果的に緩和した証拠。この図はp2pチームによる研究からの抜粋です

顕著な進展があったものの、依然として多くの課題が存在します。Jitoのバンドルがブロックを部分的に埋めるため、MEV誘発トランザクションはJitoオークションチャネルを回避することができます。部分的な証拠は、図10のDune Dashboardに見られ、2024年以降、ロボットスパム取引のためにネットワークは依然として平均して50%以上の取引が失敗しています。

図 10:2022年5月以降のSolanaにおけるロボットスパム取引活動のDune Dashboard(詳細はDune

2024年3月9日、Jitoはそのフラッグシップメモリプールを一時停止することを決定しました。この決定は、memecoin取引の増加とそれに伴うサンドイッチ攻撃(サーチャーがターゲット取引の前後に取引を配置する)によるもので、最終的にユーザー体験に影響を与えました。Ethereum上のMEVAプライベートオーダーフローのチャネルと同様に、公共メモリプールを閉鎖することで、フロントエンドサービス(ウォレットプロバイダーやTelegramボットなど)との協力を通じてプライベートオーダーフローの成長を促進する可能性があります。サーチャーは検証者と直接協力関係を築き、優先実行、含めるまたは除外する権利を得ることができます。

実際、図11はメモリプールが閉鎖された後、最大のプライベートメモリプールサーチャーの毎時サンドイッチボットの利益状況を示しています。

最大のプライベートメモリプールサーチャー:

3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81

(訳者注:サンドイッチボットは、主にブロックチェーン取引で利益を得るために使用される一般的な先行攻撃ツールです)。

図 11:サーチャー "3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81" がプライベートメモリプールを使用した毎時サンドイッチボットの利益

Jitoは メモリプールを閉鎖することを決定し、Solanaエコシステム内の根本的な問題を解決することにチームが取り組んでいることを示しています。 MEVAのイテレーションやSolanaのガス料金メカニズムの調整に加えて、Jitoはデフォルトのスリッページパラメータを制限するなどのUI製品設計選択を通じてプロトコルの攻撃リスクを減少させる手助けをしています。ゴミ取引をより高価にする料金構造の調整や通信プロトコルの変更を通じて、JitoのインフラはSolanaネットワークの健康と安定を維持する上で重要な役割を果たし続けるでしょう。

Monad上のMEVA設計

遅延実行とMEVAへの影響

Ethereumとは異なり、Ethereumではブロックに同意するためにはトランザクションリスト(順序付き)とすべての事後状態を要約したマークルルートが必要ですが、Monadは以前の実行とコンセンサスを分離します。ノードプロトコルは公式な順序問題を解決するだけで済みます。図12に示すように、各ノードはブロックN+1のコンセンサスを開始する際に、独立してブロックNのトランザクションを実行します。この配置により、実行はコンセンサスのペースに追いつくだけで済むため、完全なブロック時間に対応するガス予算が許可されます。リーダーノードが事実状態ルートを計算する必要がないため、実行は次のブロックを処理するためにコンセンサス期間全体を利用できます。

図 12:Monadの遅延実行とEthereumの実行-コンセンサス段階の比較。MEVA設計の観点からも操作時間ウィンドウを示しています

私たちは操作時間ウィンドウを、MEVAがMonad上でブロック構築提案を完了するための時間枠として定義します。この提案はデフォルトのブロック構築方法と比較して実行可能かつ利益をもたらすものです。遅延実行モデルには2つの直接的な結果があります:

  1. MEVAが操作時間ウィンドウ内で第Nブロックを構築する際、検証者は同時に第Nブロックのトランザクションリストのコンセンサスに達しようとしながら、第N-1ブロックの実行を完了しようとします。したがって、第Nの操作時間ウィンドウ内で利用可能な状態は、依然として第N-2にある可能性があります。これは、この遅延実行アーキテクチャの下では、リレーやビルダーが「最新の状態」を持つことが保証されないことを意味します。したがって、次のブロック生成前に最新のブロックに対してシミュレーションを行うことは不可能であり、不確実性を引き起こします。

  2. Monadの1秒ブロック時間を考慮すると、MEVAの操作時間ウィンドウは非常に限られています。これは、ビルダーがEthereumで通常行うように、完全なブロックのトランザクションとバンドルを順序通りにシミュレーションするための十分な時間がない可能性があることを意味します。EVM上でトランザクションシミュレーションに必要な時間に影響を与える多くの変数があります。しかし、シミュレーションに10^1から10^2マイクロ秒(大まかな推定)が必要であり、Monadの目標が毎秒10^4トランザクションであると仮定すると、操作時間ウィンドウ内で完全なブロックをシミュレーションするには約1秒かかる可能性があります。Monadの1秒ブロック時間を考慮すると、ビルダーやリレーが複数の完全なブロックシミュレーションを完了してブロック構築を最適化することは困難でしょう。

確率ビルダーとサーチャー戦略

これらの制限を考慮すると、操作時間ウィンドウ内で完全なブロックシミュレーションを完了し、最新の状態に対してシミュレーションを行うことは現実的ではありません。ビルダーは現在、時間も最新の状態も欠いているため、各トランザクションの正確なヒントを理解することができず、トランザクションのロールバックの可能性に基づいてサーチャーのヒントを推測しなければなりません。これは、評判に依存するか、(おそらく最良の方法として)第N-2の状態に対してシミュレーションを行うことに依存します。これにより、ブロックの評価が不確実性を増すことになります。

トランザクションのロールバックに対する理論的な保証が欠如しているため、一度検証者がビルダーが構築したブロックを受け入れると、サーチャーはより大きな実行の不確実性に直面します。これはEthereumと対照的で、Ethereumではサーチャーが専用のプライベートオーダーフローをビルダーに競争させ、比較的確実な戦略を実行します。Monad上のこの相対的な確率設定では、サーチャーは現在、より高いバンドルロールバックリスクに直面し、より不確実な実行PnLプロファイルを引き起こします。これは、高頻度取引者が確率信号に基づいて取引を実行し、時間の経過とともにわずかに高い期待リターンを得るのに似ています。

図 13:提案されたブロックのチェックまたはシミュレーションの程度に基づいて異なるMEVA設計パラダイムを分類した概念スペクトル図

図13に示すように、ビルダー側の事前のバンドル/ブロックチェックの程度は、提案されたブロックの価格設定または評価において不確実性のスペクトルを生み出します。一方は、正確な価格設定を持つEthereumスタイルのPBSモデルであり、ビルダーは提案されたブロック内でトランザクションをシミュレーションするために実行層(EL)クライアントを使用しなければなりません。彼らは提出されたバンドル内で広範な組み合わせをナビゲートしなければなりません。もう一方は、楽観的ビルダーモデル[16]であり、非同期ブロックチェックを持っています。このモデルでは、ビルダーは操作時間ウィンドウ内で必要なシミュレーションの時間を回避し、担保を預け入れることで(削減される可能性があります)検証者やリレイヤーに提示を示します。ここでMonad上に提案された確率チェックまたは部分シミュレーションのアプローチは中間に位置し、いくつかの不確実性が存在するものの、サーチャーが戦略を成功裏に実行する可能性を高めます。

例えば、オンチェーンオーダーブックDEXのマーケットメーカーは、主要な一方向の価格変動を発見した際に、MEVAを通じて事前にポジションを移動させ、不利な選択を回避することができます。この確率戦略により、彼らは最新の状態情報がなくても迅速に行動し、動的な取引環境でリスクとリターンのバランスを取ることができます。

結論

MEVAは、ブロック生成の最適化、外部影響の軽減、システムの安定性向上において重要な役割を果たしています。Solana上のJitoやEthereum上のさまざまな実装など、MEVAフレームワークの進化に伴い、スケーラビリティの問題の解決が大いに促進され、ネットワーク参加者のインセンティブメカニズムがより一貫性を持つようになりました。

Monadは、始まったばかりで将来性のあるネットワークであり、コミュニティに最適なMEVAを設計するユニークな機会を提供します。Monadの独自の実行とコンセンサスの分離メカニズムを考慮し、研究者、開発者、検証者が協力して洞察を共有することを心よりお待ちしています。この協力は、Monadが高スループットブロックチェーンネットワークとしての展望を実現するための強力で効率的なブロック生成プロセスの構築に寄与するでしょう。

ChainCatcherは、広大な読者の皆様に対し、ブロックチェーンを理性的に見るよう呼びかけ、リスク意識を向上させ、各種仮想トークンの発行や投機に注意することを提唱します。当サイト内の全てのコンテンツは市場情報や関係者の見解であり、何らかの投資助言として扱われるものではありません。万が一不適切な内容が含まれていた場合は「通報」することができます。私たちは迅速に対処いたします。
チェーンキャッチャー イノベーターとともにWeb3の世界を構築する