並列実行時代の到来：Monad上のMEV構図を概観
TechFlow厳選深潮セレクト
並列実行時代の到来：Monad上のMEV構図を概観
本稿では、Monad 上で強力なマイナー抽出可能価値オークション基盤（MEVA）を構築する可能性について考察する。
Web3業界の深掘り報道に専念し潮流を洞察著者：APRIORI ⌘
翻訳：TechFlow
はじめに
大規模採用に向けてブロックチェーンのパフォーマンスを向上させる過程において、Monadは非同期I/O、最適化されたPatricia Trie、遅延実行、オプティミスティック並行制御といった一連の低レベル最適化を通じて、イーサリアム仮想マシン（EVM）モデルを効果的に改善しています。これらの改良は、分散性を損なうことなく、イーサリアムなどのプラットフォームが抱える実行ボトルネックや非効率的な状態アクセスの問題を解決しています。
本稿では、Monad上に強力なマイナブル・エクストラクト可能価値（MEV）オークションインフラ（MEVA）を構築する可能性について考察し、イーサリアムのFlashbotsやSolanaのJito Networkの経験から学びます。
特に以下の点を強調します。
-
MEVはあらゆるブロックチェーンネットワークに内在する特性です。負の外部性やインセンティブの不一致を回避するためには、堅牢なMEVAインフラが不可欠です。
-
MEVAの設計は、特にコンセンサス実行フェーズなどブロックチェーンの基盤的メカニズムと密接に関係しています。今後の進化は、これらの要素の変遷やネットワークがさまざまな負荷下でどのように動作するかに依存します。
-
イーサリアムおよびSolanaにおけるブロック生成の歴史的トレンドは、Monad上のMEVA設計の参考となります。
-
Monadのような高性能かつ遅延実行型ブロックチェーンでは、時間制約に対応するために、高頻度取引に似た確率的ブロック構築および探索戦略がMEVAに必要となるかもしれません。
これらの課題を探ることで、Monadの独自アーキテクチャと性能要件に適したMEVAインフラの設計に関する洞察を提供することを目指します。
イーサリアムにおけるMEVAの背景
イーサリアムのコンセンサス-実行フェーズにおけるMEVA
イーサリアムでは、コンセンサスの前に実行が必要です。ノードがブロックに合意する際、そこに含まれるトランザクションリストだけでなく、すべての事後状態を要約するMerkleルートにも合意していることになります。したがって、プロポーザーは提案を伝播する前に、ブロック内のすべてのトランザクションを実行しなければなりません。同時に、バリデータも投票前にそれらのトランザクションを実行する必要があります。
図1：MEV-Boostにおけるプロポーザー-ビルダー分離（PBS）のビルダー作業フロー
図1は、MEV-Boostにおけるプロポーザー-ビルダー分離（PBS）の典型的なビルダー作業フローを示しています。ビルダーがブロック構築を完了すると、リレーヤーに送信し、リレーヤーは実行層（EL）クライアントにブロックを転送してシミュレーションと有効性チェックを行います。
実行がコンセンサスの前提条件であるため、ビルダーがブロックを構築する際には、実行層（EL）クライアントにブロックを転送し、その有効性を確認するためにシミュレーションを行う必要があります。コンセンサス-実行フェーズでの必須機能に加え、このシミュレーション段階はビルダーやサーチャーにとってもメリットがあります。
ビルダーの視点からは：各トランザクションをシミュレーションすることで、自身およびバリデータにとってのブロック価値を正確に推定できます。また、トランザクションの並べ替えを試みることで、ロールバックを最小限に抑えつつ、mempoolおよびバンドル取引から得られるガス料金や基本チップを最大化できます。正確な見積もりにより、バリデータに対してより高い価格を提示できるようになります。
サーチャーの視点からは：ビルダーがオンチェーン前にロールバックしそうなバンドルをフィルタリングするため、戦略の実行を確保でき、確定性が高まります。さらに、サーチャーは最新のブロック状態にアクセスできます。コンセンサス層（CL）が新しいブロックを伝播すると、サーチャーはそのブロックの状態を起点として収益性のあるバンドルを構築できます。また、ビルダーが現在、プロトコル外の取引や機能を提供し始めている兆候もあり、これによりサーチャーは即将構築されるブロック状態の情報を入手し、即時実行戦略を次にオンチェーンされるブロックに追加できるようになっています。
しかし、PBSの発展はブロック構築の集中化を促進しており、これは企業が裁定戦略の優先実行のために専用のマイクロ波ネットワークチャンネルを競い合う従来の取引環境と類似しています。
ネットワークの成熟とともに製品が進化
ここでは、図2に示すように、イーサリアムの発展に伴ってMEVAがどのように進化してきたかを検討します。
図2：イーサリアムネットワークの発展に伴うMEVAの時系列図
優先ガスオークション（PGA）時代
図3に示すように、サーチャーは利益を得られるMEVの機会を特定し、スマートコントラクト取引を公開mempoolに提出します。この公開性により、チェーン上で公開入札および単一価格オークションが発生し、失敗した取引であってもガス料金が発生します。
この時期には、同じ（アカウント、アラート）ペアを持つ取引や、価格を上げ続ける競争など、競争が激しく高コストな非構造的MEV活動が見られ、ネットワークの混雑やコンセンサスの不安定化を引き起こしました。
図3：単純な優先ガスオークションの模式図
Flashbots と EIP-1559
これらの問題を解決するため、Flashbotsは中継器（リレー）を導入し、サーチャーとブロック生成者（PoW時代のマイナー）の中間に位置する仲介オークションハウスとして機能させました。この取り組みにより、MEV市場は公開入札の単一価格オークションから密封入札へと移行しました。図4に示すように、リレーは公開mempool内での入札の過熱を防ぎ、より秩序立てられ安全なブロック生成プロセスを確立しています。
EIP-1559の料金構造もここに貢献しています。基本料金によって入札が簡素化されましたが、ブロック内のトランザクション順序の問題は依然として優先料金によってMEVが駆動されており、解決されていません。実際、多くのサーチャーは以前、coinbase送金を通じてマイナーに直接入札していました。彼らは0ガスのバンドルを提出できなくなったことで、coinbase料金に対する不満が多くなりました。
図4：リレー付きMEVA
プロポーザーとビルダーの分離（PBS）
イーサリアムがマージを完了し、プルーフ・オブ・ステーク（PoS）に移行した後、ブロック生成パイプライン内の役割分担をさらに最適化するため、プロポーザーとビルダーの分離（PBS）が導入されました。前述のように、リレーは現在、ビルダーとプロポーザーの中間として、データ可用性とブロックの有効性を保証する役割を担っています。プロポーザーは複数のビルダーから異なるプライベート取引を受け入れることができるため、ビルダーはプロポーザーに支払いを行うことで競合しなければなりません。このダイナミクスは図5に示されています。
図5：PBS時代のMEVA
集中化のリスク
こうした歴史的な進歩があったにもかかわらず、ビルダー市場における集中化リスクの増大を強調する必要があります。過去1年間、上位9つのビルダーが常に50％以上の市場シェアを占めており、高い市場集中が示されています（図6参照）。現在の集中状況はさらに顕著で、上位3つのビルダーが90％以上のブロックを占めています。
図6：ビルダーの市場シェア。ビルダー市場における極端な集中を示している（画像出典）
Solana 上の Jito
Jito のシステムアーキテクチャ
Solana 上の標準 MEVA である Jito は、低トランザクションコストによる大量のスパム取引行為に対処するために開発されました。失敗取引のコスト（約 0.000005 SOL）が期待利益を超えない限り、スパム取引は実質的にインセンティブ付けられています。
Jito Labs が 2022 年に行った報告によると、その年、裁定および清算の試みの 96% 以上が失敗し、ブロックには MEV 関連取引が 50% 以上含まれていました。また、清算ロボットが何百万もの重複パケットをネットワークに送信し、数千回の成功した清算しか達成できず、失敗率が 99% を超えていたと報告されています。
図7：Solana 上の Jito の MEVA
Solana 上の MEV 外部性の深刻さは、Jito がブロック生成プロセスに秩序と確定性をもたらす MEVA レイヤーを開発するきっかけとなりました。図7に示すJitoが提唱した初期MEVAアーキテクチャを振り返りましょう。
Jitoは以下のコンポーネントで構成されます：
リレーヤー - プロキシとして取引を受け取り、ブロックエンジン（またはMEVAサプライチェーン）とバリデータに転送します。
ブロックエンジン - リレーヤーから取引を受け取り、サーチャーを調整し、バンドルを受け入れ、バンドルのシミュレーションを実行し、最適な取引およびバンドルをバリデータに転送します。注目すべきは、Jitoが全ブロックオークションではなく部分ブロックオークションでバンドルを採用している点です。歴史的には、2つのスロット内で80％以上のバンドルを処理しています。
疑似mempool - Jito-Solanaクライアントによって約200ミリ秒の操作時間枠が作成され、注文フローの離散化オークションが発生します。Jitoは2024年3月9日にこのmempoolを停止しました。
Jitoの設計選択
Jitoのシステム設計の具体的なコンポーネントを検討し、これらの設計選択がSolanaのブロック生成プロセスにどう由来するかを考えます。
Jitoが全ブロック構築ではなく部分ブロックオークションのみをサポートしているのは、Solanaのマルチスレッド実行モデルがグローバルスケジューラを持たないことに起因する可能性があります。具体的には、図8に示すように、並列スレッドがトランザクションを実行し、各スレッドが独自の実行待ちキューを維持しています。トランザクションはスレッドにランダムに割り当てられ、優先料金と時間に基づいてローカルにソートされます。グローバルソートがないスケジューラ（1.18.xアップデート前）では、Solanaのトランザクションは本質的にスケジューラのジッターにより非決定的になります。そのため、MEVAにおいて、サーチャーやバリデータは現在の状態を確実に把握できません。
図8：Solanaクライアントのマルチスレッド実行モデル。MEVAのバンドル段階がマルチスレッドキューに独立スレッドとして付加されていることに注意
工学的観点から、JitoのブロックエンジンをSolanaのマルチスレッドアーキテクチャに非常に適合する形で追加スレッドとして並列実行しています。バンドルオークションはJitoブロックエンジンスレッド内で優先料金に基づくソートを保証していますが、バンドルがユーザー取引に対して常にグローバルに優先されるとは限りません。
この問題を解決するため、Jitoはバンドルスレッドにブロック空間の一部を事前割当し、バンドルにブロック内スペースを保証しています。不確実性は依然存在しますが、この方法により戦略実行の成功率が向上します。また、これによりサーチャーはネットワークにスパムを送るよりもオークションに参加するインセンティブを得ます。ブロック空間をバンドルに確保することで、Jitoは秩序あるオークションの促進とトランザクションスパムの混乱効果の緩和とのバランスを取っています。
疑似mempoolの廃止
Jitoの広範な採用は、Solanaのスパム問題の緩和において前向きな成果を挙げました。p2pの研究および図9のデータによれば、Jitoクライアント採用後、相対的なブロック生成率が著しく向上しています。これは、Jitoが2023年に導入した最適化ブロックエンジンにより、トランザクション処理がより効率的になったことを示しています。
図9：JitoがSolanaのスパム問題を効果的に緩和した証拠。p2pチームの研究から引用
顕著な進展はあったものの、依然多くの課題があります。Jitoのバンドルはブロックを部分的にしか埋めないため、MEV誘導型取引はJitoオークションチャネルを回避できます。図10のDuneダッシュボードに部分的な証拠が見られ、2024年以来、ロボットによるスパム取引の影響でネットワークの平均取引失敗率が50％を超え続けています。
図10：2022年5月以来のSolana上でのロボットスパム取引活動のDuneダッシュボード（詳細は Dune）
2024年3月9日、Jitoは主力mempoolの運用を停止することを決定しました。この決定は、memecoin取引の増加とそれに伴うサンドイッチ攻撃（サーチャーが標的取引の前後に取引を配置）の急増が最終的にユーザーエクスペリエンスに悪影響を与えたためです。イーサリアムのMEVAプライベート注文流路と同様、公共mempoolを閉鎖することで、ウォレットプロバイダーやTelegramロボットなどフロントエンドサービスとの協力を通じ、プライベート注文流路の成長が促進される可能性があります。サーチャーはバリデータと直接提携し、優先実行、含め込み、除外の権利を得るかもしれません。
実際、図11はmempool停止後の最大のプライベートmempoolサーチャーの毎時サンドイッチロボット利益を示しています。
最大のプライベートmempoolサーチャー：
3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81
（訳注：サンドイッチロボットは、ブロックチェーン取引で利益を得るために主に使用される一般的なフロントラン攻撃ツールです）。
図11：「3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81」がプライベートmempoolを使用した毎時のサンドイッチロボット利益
Jitoがmempoolを閉鎖した決定は、チームがSolanaエコシステムの根本的問題に取り組む姿勢を示しています。 MEVAの反復やSolanaのガス料金メカニズムの調整に加え、Jitoはデフォルトのスリッページパラメータの制限などUI製品設計の選択を通じて、プロトコルが攻撃リスクを低減するのを支援しています。スパム取引をより高価にする料金構造の調整でも、通信プロトコルの変更でも、Jitoのインフラは今後もSolanaネットワークの健全性と安定性の維持に重要な役割を果たし続けるでしょう。
Monad 上の MEVA 設計
遅延実行とMEVAへの影響
イーサリアムとは異なり、イーサリアムではブロックに合意するにはトランザクションリスト（順序付き）とすべての事後状態を要約するMerkleルートの両方に合意する必要がありますが、Monadは先行する実行とコンセンサスを分離しています。ノードプロトコルは公式な順序問題のみを解決すればよいのです。図12に示すように、各ノードはブロックN+1のコンセンサスを開始する際に、独立してブロックNのトランザクションを実行します。この構成により、完全なブロック時間に対応するガス予算が可能になります。なぜなら、実行はコンセンサスに追いつくだけでよく、リーダーノードがファクト状態ルートを計算する必要がないため、実行は次のブロック処理のためにコンセンサス期間全体を利用できます。
図12：Monadの遅延実行とイーサリアムの実行-コンセンサスフェーズの比較。MEVA設計の観点からも操作時間枠を示しています
我々は操作時間枠を、デフォルトのブロック構築方法と比較して実現可能かつ利益がある、Monad上でブロック構築提案を完了できる時間枠と定義します。遅延実行モデルには2つの直接的な結果があります：
-
MEVAが第Nブロックの操作時間枠内で構築を行うとき、バリデータは第Nブロックのトランザクションリストのコンセンサスを形成しながら、第N-1ブロックの実行を完了しようとしています。したがって、第Nブロックの操作時間枠内では、利用可能な状態はまだ第N-2である可能性があります。つまり、この遅延実行アーキテクチャでは、リレーヤーやビルダーが「最新状態」を持つことは保証されません。したがって、次のブロック生成前に最新ブロックをシミュレーションすることは不可能であり、不確実性が生じます。
-
Monadの1秒ブロックタイムを考慮すると、MEVAの操作時間枠は極めて限定的です。つまり、ビルダーはイーサリアムで通常行われるように、フルブロックの取引やバンドルを逐次的にシミュレーションするのに十分な時間がありません。EVM上で取引シミュレーションに必要な時間に影響する変数は多数ありますが、1取引のシミュレーションに10^1～10^2マイクロ秒（概算）かかり、Monadの目標が1秒あたり10^4取引であると仮定すると、操作時間枠内でフルブロックのシミュレーションだけでも約1秒かかる可能性があります。Monadの1秒ブロックタイムを考慮すると、ビルダーまたはリレーヤーが複数のフルブロックシミュレーションを完了してブロック構築を最適化するのは困難です。
確率的ビルダーとサーチャー戦略
こうした制約を踏まえると、操作時間枠内でフルブロックのシミュレーションを完了し、最新状態を対象にすることは非現実的です。ビルダーは現在、各取引の正確なヒントを知るための時間も最新状態も欠いているため、トランザクションのロールバック可能性に基づき、サーチャーのヒントを信用評価や（おそらく最も良い）第N-2状態でのシミュレーションに頼って推論しなければなりません。これにより、ブロックの評価がより不確実になります。
トランザクションのロールバックに関する理論的保証がないため、バリデータがビルダーが構築したブロックを受け入れた後でも、サーチャーはより大きな実行不確実性に直面します。これは、専用のプライベート注文流路を通じて相対的に確実な戦略実行を競うイーサリアムのサーチャーとは対照的です。Monadのこのような相対的に確率的な設定では、サーチャーはより高いバンドルロールバックリスクに直面し、実行PnLプロファイルがより不確実になります。これは、確率的信号に基づいて取引を実行し、時間の経過とともにわずかに高い期待リターンを得る高頻度取引者に似ています。
図13：異なるMEVA設計パラダイムを、提案ブロックのチェックまたはシミュレーションの程度に応じて分類した概念スペクトル図
図13に示すように、ビルダー側が事前にバンドル／ブロックチェックを行う程度は、提案ブロックの価格付けまたは評価において不確実性のスペクトルを生み出します。一端は、正確な価格付けを行うイーサリアムスタイルのPBSモデルで、ビルダーは実行層（EL）クライアントを使用して提案ブロック内の取引をシミュレーションしなければなりません。彼らは提出されたバンドル内で広範な組み合わせを管理する必要があります。もう一端は、非同期ブロックチェックを行う楽観的ビルダーモデル[16]です。このモデルでは、ビルダーは操作時間枠内のシミュレーションに必要な時間を回避し、保証金（削減される可能性あり）を預けることで、バリデータまたはリレーヤーに表示されるヒントを現金化します。ここでMonad上で提案される確率的チェックまたは部分シミュレーション手法は中間に位置し、ある程度の不確実性はあるものの、サーチャーの戦略実行成功率を高めるものです。
例えば、オンチェーン注文ブックDEXのマーケットメーカーは、主要な一方的な価格変動を検出した際にMEVAを通じてポジションを先回りして移動し、不利な選択を回避するかもしれません。このような確率的戦略により、最新の状態情報がなくても、ダイナミックな取引環境でリスクとリターンをバランスさせながら迅速に行動できます。
まとめ
MEVAは、ブロック生成の最適化、外部影響の軽減、システムの安定性向上において重要な役割を果たしています。SolanaのJitoやイーサリアムの各種実装など、MEVAフレームワークの進化は、スケーラビリティ問題の解決を大きく促進し、ネットワーク参加者のインセンティブをより整合させました。
Monadは、まだ始まったばかりで将来性のあるネットワークであり、コミュニティに最適なMEVAを設計するユニークな機会を提供しています。Monad特有の実行とコンセンサスの分離メカニズムを考慮し、研究者、開発者、バリデータが協力して知見を共有することを呼びかけます。この協力により、強固で効率的なブロック生成プロセスが生まれ、Monadが高スループットブロックチェーンネットワークとしての可能性を実現する支援となるでしょう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@aprMEV
