導入

大量採用を処理するためにブロックチェーンのパフォーマンスを向上させるという目的で、Monad は、非同期 I/O、最適化された Patricia Trie、延期実行、並行処理のための楽観的並列制御など、一連の低レベルの改善により Ethereum Virtual Machine（EVM） モデルを最適化する先駆的な力として際立っています[2]。これらの改善により、Ethereum のようなプラットフォームで見られる実行のボトルネックや非効率な状態アクセスに対処し、分散化を犠牲にすることなく効果的に対応しています。

この投稿では、Monadで堅牢なマイナー抽出可能価値オークションインフラ（MEVA）の可能な実装を探っています。また、イーサリアムのFlashbotsやSolanaのJito Networkなどの既存のアプローチから、いくつかの移転可能で価値のある教訓についても説明します。

いくつかの重要な考慮事項を強調したいと思います:

1. MEVはどんなブロックチェーンネットワークにも固有のものです。強固なMEVAインフラストラクチャーは、否定的な外部性や不一致なインセンティブによる乱雑なブロック生成プロセスを避けるために重要です。
2. MEVAデザインは、チェーンの基礎となるメカニズムに深く組み込まれており、特にそのコンセンサス実行ステージングに組み込まれています。将来の拡張は、これらの要因の進化とネットワークのストレスレベルに応じたパフォーマンスに依存することになります。
3. EthereumとSolanaで見られるブロック生産の歴史的なトレンドは、Monad上のMEVAデザインに影響を与える情報を提供することができます。
4. Monadなどの高性能な遅延実行ブロックチェーン上のMEVAは、時間制約により、高頻度取引に類似した確率的なブロック構築および検索戦略が必要になる可能性があります。

これらのポイントに対処することで、Monadの独自のアーキテクチャとパフォーマンス要件に合わせたMEVAインフラストラクチャを設計する際の課題と考慮事項について洞察を提供することを望みます。

EthereumのMEVAランドスケープ

イーサリアムのコンセンサス実行ステージング下のMEVA

イーサリアムでは、コンセンサスは事前の実行を必要とします。ノードがブロックに合意するとき、それはブロック内の取引のリストと、ブロックの実行後の事後状態を要約したMerkleルートの両方に同意することを意味します。したがって、リーダーは提案されたブロック内のすべての取引を実行する必要があります。一方、検証ノードは投票する前に取引を実行する必要があります。

図1：EL-CLセパレーション下のMEV-Boostのビルダーワークフロー。

図1は、プロポーザービルダーセパレーション（PBS）のMEV-Boostにおける典型的なビルダーワークフローを示しています。ビルダーはブロックの構築を完了し、それらをリレーに提出します。リレーはブロックを実行レイヤー（EL）クライアントに転送してシミュレーションと妥当性チェックを行います。

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

ビルダーの視点：ビルダーは、すべてのトランザクションをシミュレートして、自分自身とバリデーターに対してブロックの価値を正確に見積もることができます。彼らはまた、トランザクションの並べ替えを実験して、リバートを最小限に抑え、メンプールとバンドルトランザクションの両方からガス手数料やベースチップを最大限に抽出することができます。彼らの正確な見積もりにより、バリデーターへの入札額を高く設定することができます。

Searcher’s perspective: ビルダーがチェーン上に着地する前に、ポテンシャルなリバートバンドルをスクリーニングする結果として、サーチャーは確実な戦略の実行を見ることができ、決定論が追加されます。さらに、サーチャーは最新のブロック状態にアクセスすることもできます。コンセンサスレイヤー（CL）が新しいブロックを伝播すると、サーチャーはそのブロックの状態を利用して収益性の高いバンドルを構築する出発点として利用できます。一方、ビルダーが提供するプロトコル外の取引や機能が今、より多くの指示があり、これによりサーチャーは自分の着地するブロックにバックランストラテジーを追加するための状態情報を得ることができます。

しかし、PBSの開発では、ブロック構築における中央集権化が増加しており、企業が独自のマイクロ波ネットワークチャンネルを競って裁定取引戦略の実行の優先権を得る従来の取引を模倣しています。

ネットワークが成熟するにつれての製品の進化

図2で年代順に示されるように、Ethereumの進展とともにMEVがどのように進化してきたかを今度は探求します。

図2：Ethereumネットワークが前進するにつれてMEVAがどのように繰り返されるかを時系列で示したもの。この図は[4]からわずかに適応されています。

Priority Gas Auction (PGA) Era

図3に示すように、検索者は利益を生むMEVの機会を特定し、スマートコントラクトを有効にしたトランザクションを公共のメンプールに送信しました。この公開の可視性により、失敗したトランザクションでもガスのコストが発生するオンチェーン上でのオープンビッドの一次価格オークション形式が行われました。

この期間には、同じ（アカウント、nounce）ペアでのトランザクションや入札の増加[6]など、競争力がありコストのかかる非構造化MEVアクティビティが見られ、ネットワークの混雑やコンセンサスの不安定化に寄与しました。

図3：シンプルな優先ガスオークション。図は[6]から若干の変更を加えています。

FlashbotsとEIP-1559

これらの問題に対処するために、Flashbotsはリレーを導入しました。これは、サーチャーとブロックプロデューサー（PoW時代のマイナー）の間にある仲介オークションハウスです。このイニシアチブにより、MEVマーケットプレイスはオープンビッドの一位価格オークションから密封入札方式に変わります。図4は、リレーがパブリックメンプールでの入札エスカレーションを防止し、より整頓された安全なブロックプロダクションプロセスを確立する方法を示しています。

EIP-1559の手数料構造もここで役割を果たします[7]。それはベース手数料を通じて部分的に掲載された価格を導入することによって入札を簡略化しましたが、ブロック内の取引順序には対応しておらず、それでもMEVを優先手数料を通じて引き起こしています。実際には、多くの検索者が以前はマイナーに直接コインベース転送を通じて入札を表明していました。彼らは0ガスのバンドルを提出できなくなったため、コインベース手数料について多くの苦情を抱えることになりました。

図4：リレーを使用したMEVA。 この図は[6]からわずかに適応されています。

提案者-ビルダー分離（PBS）

Ethereumがマージ後にProof of Stake（PoS）へ移行した後、Proposer-Builder Separation（PBS）が実装され、ブロック生成パイプラインにおける役割のさらなる分離が行われました。前述のように、リレーは今やブロックビルダーとプロポーザーの間の仲介者として機能し、データの可用性とブロックの正当性を確認する管理者として機能します。プロポーザーは異なるプライベートトランザクションのために複数のビルダーに接続できるため、ビルダーはプロポーザーに支払いを提供することで競争しなければなりません。この動学は図5で説明されています。

図5：PBS時代のMEVA。この図は[6]からわずかに変更されたものです。

集中リスク

このような歴史的な進歩にもかかわらず、建設業者市場における集中リスクの懸念が高まっていることを強調することが重要です。過去1年間、上位9社の建設業者の寡頭政治は一貫して市場の>50%を占めており、図6に示すように、市場の集中度が高いことを示しています。現在、集中状態はさらに顕著で、上位3つのビルダーがブロックの>90%以上をカバーしています。

図6：ビルダーのシェア。 グラフは、ビルダー市場における高い集中度を示しています。 このグラフは、から採用されましたhttps://arxiv.org/pdf/2405.01329

SolanaのJito

ジトのアーキテクチャ

Solanaの正式なMEVとして、Jitoはトランザクションコストが低いためにSolanaの高いスパミング率に対処するために作成されました。スパミングトレードは、失敗したトランザクションのコスト（約0.000005 SOL）が予想される利益を上回らない限り、効果的にインセンティブが与えられます。

2022年のJito Labsの報告によると、その年のアービトラージと清算の試みの96%以上が失敗し、ブロックには50%以上のMEV関連トランザクションが含まれていました。報告ではまた、清算ボットが何百万もの重複パケットをネットワークにスパムし、数千の成功した清算を達成するために行った結果、失敗率は99%を超えたことも強調されています。

図7：ソラナ上のジトのMEVAの俯瞰図。

SolanaへのMEV外部性の深刻さがJitoによってMEVAレイヤーの開発につながり、ブロック生産プロセスに秩序と決定論をもたらすことを目指しています。図7に示されているように、Jitoによって提案された元のMEVAアーキテクチャを見直しましょう。

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

Relay - プロキシとして機能し、取引を受信し、それをブロックエンジン（またはMEVAサプライチェーン）およびバリデータに転送します。

Block Engine-リレーからトランザクションを取り込み、サーチャーと調整し、バンドルを受け入れ、バンドルシミュレーションを実行し、最高のトランザクションとバンドルをバリデーターに転送します。特に、Jitoは、完全なブロックオークションではなく、バンドルの含まれ方のための一部のブロックオークションを実施し、歴史的には2つのスロットで80％以上のバンドルを処理しています[9]。

疑似メンプール - Jito-Solanaクライアントを介して約200ミリ秒の操作時間ウィンドウを作成し、オーダーフローの離散化オークションを誘発する[10]。Jitoはこのメンプールを2024年3月9日にシャットダウンしました。

Jitoのデザインの選択

Jitoのシステム設計の具体的な構成要素を探って、これらの設計選択肢がSolanaのブロック生産プロセスに由来する方法を考えてみましょう。

Solanaのマルチスレッド実行モデルにグローバルスケジューリングがないため、Jitoは完全ブロックビルドではなく部分的なブロックオークションのみをサポートしています。具体的には、図8に示すように、並列スレッドがトランザクションを実行し、それぞれが実行を待っているトランザクションのキューを維持しています。トランザクションはランダムにスレッドに割り当てられ、手数料と時間の優先度でローカルに順序付けられます。スケジューラ側でグローバルな順序付けがない（1.18.xアップデート以前）ため、Solanaのトランザクションにはスケジューラのジッタからの不確定性がある[11]。そのため、MEVAでは、サーチャーやバリデーターは現在の状態を信頼性を持って決定することができません。

図8：Solanaクライアントのマルチスレッド実行モデル。MEVAのバンドルステージがマルチスレッドキュー内の別のスレッドとして追加されていることに注意してください。

エンジニアリングの観点からは、既存のスレッドと並行して実行される追加スレッドとしてJitoのブロックエンジンフィードを統合することは、Solanaのマルチスレッドアーキテクチャにうまく適合しています。バンドルオークションによって、Jitoブロックエンジンスレッド内での優先料金ベースの順序付けが保証されますが、バンドルが常にユーザートランザクションよりも前に配置されることは保証されません。

これに対処するために、Jitoはバンドルスレッドのためにブロックスペースの一部を事前に割り当て、ブロック内でスペースを確保します。不確実性は残りますが、このアプローチにより成功した戦略の実行の確率が高まります。また、ネットワークをスパムするのではなく、オークションに参加することを促進します。バンドルのためにブロックスペースを予約することで、Jitoはバランスを取ることができ、秩序あるオークションを促進し、トランザクションのスパムの混乱効果を緩和します。

擬似メンプールの削除

Jitoの広範な採用により、Solanaでのスパム問題の緩和に良い結果が出ています。p2p [12]による調査と図9に示されるデータによると、Jitoクライアントの採用後、相対的なブロック生産率に統計的に有意な改善が見られました。これは、2023年に導入されたJitoの最適化されたブロックエンジンのおかげで、トランザクション処理がより効率的になったことを示しています。

図9：Solanaでのスパム問題の緩和におけるJitoの効果の証拠。 グラフはp2pチームによって実施された[12]の研究から抽出されました。

大きな進歩が見られましたが、多くの課題が残っています。Jitoバンドルはブロックを部分的にしか埋めないため、MEVを誘発する取引はJitoオークションチャネルをバイパスすることができます。この問題は、図10 [13]のDune Dashboardによって少なくとも部分的に証明されており、2024年以降、ネットワークではボットスパムによるトランザクションの平均50%以上が失敗していることを示しています。

図10：ダンネダッシュボード（https://dune.com/queries/3537204/59512852022年5月以来、Solanaでのボットスパム活動を示す図。

2024年3月9日、Jitoは主力のmempoolを一時停止することを決定しました。この決定は、ミームコイン取引の増加とそれに伴うサンドイッチ攻撃(検索者がターゲットトランザクションの前後にトランザクションを行うフロントランニングの一種)の急増によって促され、最終的にユーザーエクスペリエンスが低下しました。MEVAのプライベートオーダーフローチャネルでイーサリアムで観察された傾向と同様に、パブリックmempoolをシャットダウンすることで、ウォレットプロバイダーやTelegramボットなどのフロントエンドサービスとのパートナーシップを通じて、プライベートオーダーフローの成長が促進される可能性があります。検索者は、バリデーターと直接パートナーシップを結び、優先的な実行、包含、除外を行うことができます。実際、この証拠は図11に見られ、mempoolのシャットダウン後の最大のプライベートmempoolサーチャー(3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81)の1時間あたりのサンドイッチボットの利益プロファイルを示しています。

図11：検索者「3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81」用のプライベートメンプールを備えたサンドイッチボットの時給利益。

Mempoolを閉鎖するというJitoの決定は、Solanaエコシステム内の根本的な問題に取り組むというチームの強いコミットメントを強調しています。Jitoは、MEVAのイテレーションやSolanaのガス料金メカニズムの調整だけでなく、デフォルトのスリッページパラメータの制限など、UI製品設計の選択を通じて、攻撃ベクトルを軽減するためのプロトコルの教育にも役立ちます。スパムをより高価にする料金体系の調整や、通信プロトコルの変更など、Jitoのインフラストラクチャは、Solanaのネットワークの健全性と安定性を維持するために不可欠であり続けます。

Monad上のMEVAデザイン

遅延実行とMEVAへの影響

イーサリアムとは異なり、ブロックの合意にはトランザクションのリスト（順序付けあり）と事後状態を要約するMerkleルートの両方が必要ですが、Monadは事前の実行をコンセンサスから分離しています。ノードの合意には公式の順序の確定のみが必要です。図12に示すように、各ノードはブロックNのトランザクションを独立して実行し、同時にブロックN+1に対するコンセンサスを開始します。この仕組みにより、実行はコンセンサスに追いつく必要があるため、実行には完全なブロック時間に対応したガス予算が可能となります。[15]先導ノードが事実上の状態ルートを計算する必要がないため、実行は次のブロックのためのコンセンサス期間全体を利用することができます。

図12：Monad Deferred Executionは、EthereumのExecution-Consensusステージングと比較しています。MEVAデザインの観点から、オペレーション時間ウィンドウも説明されています。

MEVのMonadでのMEVAに許可された時間枠を操作時間ウィンドウと定義します。これは、デフォルトのブロック構築方法と比較して実現可能かつ利益をもたらすブロック構築提案を完成するためのものです。deferred executionモデルには2つの直接の結果があります。

1. MEVAが運用時間枠内にN番目のブロックに対してビルドする場合、バリデーターはN番目のブロックのトランザクションリストについて同時に合意し、N-1番目のブロックの実行を完了しようとしています。したがって、N での動作時間枠内では、使用可能な状態が N-2 のままである可能性が非常に高いです。つまり、この遅延実行アーキテクチャでは、リレーまたはビルダーに対して「最新の状態」は保証されません。したがって、次のブロックが生成される前に最新のブロックに対してシミュレーションを行うことは不可能であり、不確定性が生じます。
2. モナドのブロック時間が1秒であることを考えると、MEVAの運用時間枠は極めて限られている。これは、ビルダーがイーサリアムで通常行うように、トランザクションとバンドルの完全なブロックを順番にシミュレートするのに十分な時間がない可能性があることを意味します。多くの変数は、EVMでのトランザクションシミュレーションに必要な時間に影響を与える可能性があります。しかし、トランザクションのシミュレーションに 10^1 から 10^2 マイクロ秒 (大まかな仮定) かかると仮定すると、モナドの目標が 1 秒あたり 10^4 トランザクションであると仮定すると、操作時間枠内でブロック全体をシミュレートするだけで約 1 秒かかる可能性があります。モナドのブロック時間が1秒であることを考えると、ビルダーやリレーが複数のフルブロックシミュレーションを完了してビルドされたブロックを最適化することは困難です。

確率的ビルダー＆サーチャー戦略

制約条件を考慮すると、運用時間ウィンドウ内で完全なブロックシミュレーションを完了し、最新の状態に対してシミュレートすることは実用的ではありません。ビルダーは現在、各トランザクションから正確なチップを知るための時間と最新の状態の両方が不足しているため、信頼性に依存するか（おそらく最良の場合）N-2状態に対してシミュレートすることによってトランザクションの逆転の可能性に基づいてサーチャーチップを推測しなければなりません。これにより、ブロックの評価がより決定論的ではなくなります。

検索者は、バリデーターがビルダーによって構築されたブロックを受け入れると、トランザクションのリバートに対する理論的な保証がないため、実行の不確実性が高まります。これは、検索者が比較的決定論的な戦略の実行のために、専用のプライベートオーダーフローからビルダーへのチャネルを競うイーサリアムとは対照的です。モナドのこの比較的確率的な設定では、検索者はバンドルがオンチェーンに戻るリスクが高くなり、実行PnLプロファイルがより不確実になります。これは、時間の経過とともにわずかにプラスの期待リターンを持つ確率的シグナルで実行する高頻度トレーダーを反映しています。

図13: 提案されたブロックのチェックまたはシミュレーションの度合いによって分類される異なるMEVAデザインパラダイムを示す概念的なスペクトル図。

図13に示すように、ビルダー側の事前バンドル/ブロックチェックの程度によって、提案されたブロックの価格または評価に関する不確実性のスペクトラムが生じます。一方には、正確な価格を持つEthereumスタイルのPBSモデルがあります。ここでは、ビルダーは提案されたブロック内のトランザクションをシミュレートするために実行レイヤー（EL）クライアントを使用しなければなりません。彼らは提出されたバンドルの幅広い組み合わせの中を航海しなければなりません。一方、非同期ブロックチェックを行う楽観的ビルダーモデル[16]があります。このモデルでは、ビルダーは運用時間枠内でのシミュレーションに必要な時間を省略し、バリデータまたはリレーに表示されたチップを尊重するために、スラッシングの対象となる担保を預け入れます。ここで提案されているMonadの確率的なチェックまたは部分的なシミュレーションアプローチは、いくつかの不確実性にもかかわらず、サーチャーの成功戦略の実行の可能性を高めるため、その中間に位置しています。

たとえば、オンチェーンのオーダーブックDEX上のマーケットメーカーは、重大な一方向の価格変動を確認した場合、逆選択を避けるためにMEVAを介してポジションを事前に移動するために支払うことがあります。この確率的戦略により、彼らは最新の状態情報を持っていなくても迅速に行動することができ、動的な取引環境でリスクと報酬をバランスさせることができます。

クロージングの言葉

MEVAは、外部性を軽減し、システム全体の安定性を高めることでブロックの生産を最適化する上で重要な役割を果たしています。Solana上のJitoやEthereum上のさまざまな実装など、MEVAフレームワークの継続的な進化は、スケーラビリティの課題に対処し、ネットワーク参加者のインセンティブを整合させる上で非常に役立つものです。

Monadはまだ幼い有望なネットワークであり、コミュニティが最適なMEVAデザインを形成するためのユニークな機会を提供しています。Monad独自の実行・コンセンサスのステージングを考慮すると、研究者、開発者、およびバリデーターが協力し、洞察を共有するように招待します。この協力は、堅牢で効率的なブロック生産プロセスを作成し、Monadが高スループットのブロックチェーンネットワークとしての潜在能力を発揮するのに重要な役割を果たします。

免責事項：

1. この記事は[0xapr]. すべての著作権は元の著者に帰属します [APRIORI ⌘].この転載に異議がある場合は、Gate Learnチームが迅速に対処します。
2. 免責事項: この記事に表明されている見解と意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。