原作者:アプリオリ ⌘
オリジナル編集: Deep Chao TechFlow
導入
大規模なアプリケーションを実現するためにブロックチェーンのパフォーマンスを向上させるプロセスにおいて、Monad はイーサリアム仮想マシン (EVM) モデルを効果的に最適化します。これらの改善により、分散化を犠牲にすることなく、イーサリアムなどのプラットフォームでの実行のボトルネックや非効率な状態アクセスの問題に対処できます。
この記事では、イーサリアム上の Flashbot と Solana 上の Jito Network からの貴重な経験を活用して、Monad 上に強力なマイナー抽出可能価値オークション インフラストラクチャ (MEVA) を構築する可能性を検討します。
いくつかの重要なポイントを強調したいと思います。
MEV は、あらゆるブロックチェーン ネットワークに固有のプロパティです。強力な MEVA インフラストラクチャは、ブロック生産プロセスにおける負の外部性やインセンティブの不整合を回避するために不可欠です。
MEVA の設計は、ブロックチェーンの基礎となるメカニズム、特にコンセンサス実行フェーズと密接に関連しています。将来の改善は、これらの要因の進化と、さまざまなストレス下でネットワークがどのように機能するかによって決まります。
イーサリアムとソラナでのブロック生成の歴史的傾向は、モナドでの MEVA の設計の参考となります。
Monad のような高性能の遅延実行ブロックチェーンでは、MEVA は時間の制約に対処するために、高頻度取引と同様の確率的なブロック構築と検索戦略を必要とする場合があります。
これらの質問を調査することで、Monad の独自のアーキテクチャとパフォーマンスのニーズに対応する MEVA インフラストラクチャの設計に関する洞察を提供したいと考えています。
イーサリアムの MEVA 背景
イーサリアムコンセンサス実行段階のMEVA
イーサリアムでは、最初にコンセンサスを実行する必要があります。ノードがブロックに同意すると、ブロック内のトランザクションのリストだけでなく、ブロックの実行後に要約されるマークル ルートにも同意します。したがって、プロポーザーは、プロポーザルを伝播する前に、ブロック内のすべてのトランザクションを実行する必要があります。同時に、検証ノードも投票前にこれらのトランザクションを実行する必要があります。
図 1: MEV-Boost の提案者とビルダーの分離 (PBS) を使用したビルダーのワークフロー
図 1 は、MEV-Boost における提案者とビルダーの分離 (PBS) の典型的なビルダー ワークフローを示しています。ビルダーはブロックの構築を完了すると、それをリレーラーに送信し、リレーラーはシミュレーションと妥当性チェックのためにブロックを実行層 (EL) クライアントに転送します。
実行はコンセンサスの前提条件であるため、ビルダーはブロックを構築するときに、ブロックを実行層 (EL) クライアントに転送し、ブロックをシミュレートしてその有効性をチェックする必要があります。コンセンサス実行フェーズで必要な役割に加えて、シミュレーションフェーズも構築者と検索者にメリットをもたらします。
ビルダーの観点: 各トランザクションをシミュレートすることで、ビルダーは自分自身とバリデーターに対するブロックの価値を正確に見積もることができます。また、ロールバックを最小限に抑え、メンプールおよびバンドルされたトランザクションから引き出されるガス料金または基本チップを最大化するために、トランザクションの順序を変更することもできます。正確な見積もりにより、バリデーターに対してより高い入札を行うことができます。
検索者の観点: ビルダーは、トランザクションがチェーンに追加される前にロールバックされる可能性のあるバンドルされたトランザクションをフィルターで除外するため、検索者は戦略の実行を確実にし、確実性を高めることができます。さらに、検索者は最新のブロック ステータスにアクセスできます。コンセンサス層 (CL) が新しいブロックを伝播すると、検索者はブロックの状態を開始点として使用して、収益性の高いバンドル トランザクションを構築できます。同時に、ビルダーが現在、今後のブロックにフォールバック戦略を追加するために、検索者が今後のブロックのステータスに関する情報を取得できるようにする、プロトコル外のトランザクションや機能をさらに提供しているという兆候もあります。
しかし、PBS の成長により、企業が裁定取引戦略の実行を優先するために専用のマイクロ波ネットワーク チャネルを奪い合う従来の取引で発生していることと同様に、ブロック構築の集中化が進んでいます。
ネットワークが成熟するにつれて、製品は反復されます
ここでは、図 2 に示すように、イーサリアムの開発とともに MEVA がどのように進化するかを調査します。
図 2: イーサリアム ネットワークの進化に伴う MEVA の時系列図
優先ガスオークション（PGA）時代
図 3 に示すように、検索者は収益性の高い MEV の機会を特定し、スマート コントラクト トランザクションをパブリック メモリプールに送信します。この一般公開により、チェーン上で公開入札やワンプライス オークションが行われ、失敗した取引でもガス料金が発生します。
この期間には、同一の (アカウント、アナウンスメント) ペアによるトランザクションや入札の増加など、競争が激しく高価な非構造化 MEV アクティビティが発生し、ネットワークの輻輳やコンセンサスの不安定化を引き起こしました。
図 3: 単純な優先ガスオークションの図
Flashbot と EIP-1559
これらの問題を解決するために、Flashbot は検索者とブロックプロデューサー (PoW 時代のマイナー) の間の仲介オークションハウスとしてリレーラーを導入しました。この動きにより、MEV 市場は自由入札 1 プライス オークションから非公開入札オークションに変わります。図 4 に示すように、リレーはパブリック メモリプールでの入札のエスカレーションを防ぎ、より秩序正しく安全なブロック生成プロセスを確立するのに役立ちます。
EIP-1559 の料金体系もここで役割を果たします。基本料金を通じて入札を簡素化しますが、ブロック内のトランザクション順序の問題は解決されず、依然として優先料金によって MEV が駆動されます。実際、多くの検索者は以前、コインベース転送を通じてマイナーに直接入札していました。彼らは、0-gas バンドルトランザクションを送信できなくなったため、コインベースの手数料についてさらに多くの苦情を抱えることになりました。
図 4: リレーを備えた MEVA
提案者と構築者の分離 (PBS)
イーサリアムが合併を完了し、プルーフ・オブ・ステーク (PoS) に移行した後、ブロック生成パイプラインにおける役割の分離をさらに最適化するために、提案者と構築者の分離 (PBS) が実装されました。前述したように、リレーラーはブロック ビルダーとプロポーザーの間の仲介者として機能し、データの可用性とブロックの有効性を確保する責任を負います。提案者はさまざまなプライベート トランザクションのために複数の建設者を接続できるため、建設者は提案者に料金を支払うことで競争する必要があります。このダイナミクスを図 5 に示します。
図 5: PBS 時代の MEVA
集中リスク
このような歴史的な進歩にもかかわらず、建設業者市場における集中リスクの増大を強調することが重要です。図 6 に示すように、過去 1 年間、上位 9 社の建設業者は一貫して市場シェアの 50% 以上を保持しており、高度な市場集中を示しています。現在の集中度はさらに顕著で、上位 3 つのビルダーがブロックの 90% 以上をカバーしています。
図 6: 建設業者の市場シェア、この図は建設業者市場に蔓延する高度な集中を示しています (画像出典)
ジト オン ソラナ
Jitoのシステムアーキテクチャ
Solana の標準 MEVA として、Jito はトランザクション コストが低いため、Solana のスパム トランザクション動作が多いことに対処するために作成されました。失敗した取引に対する手数料 (約 0.000005 SOL) が予想利益を超えない限り、スパム取引行為は効果的に奨励されます。
Jito Labs の 2022 年のレポートによると、その年は裁定取引と清算の試みの 96% 以上が失敗し、ブロックには MEV 関連の取引の 50% 以上が含まれていました。このレポートでは、数千件の清算を成功させるためだけに、清算ボットが何百万もの重複パケットをネットワークに送信し、その結果失敗率が 99% を超えたと述べています。
図 7: ソラナ上の Jito の MEVA
ソラナにおける MEV 外部性問題の深刻さにより、Jito はブロック製造プロセスに秩序と確実性をもたらすように設計された MEVA レイヤーを開発するようになりました。図 7 に示すように、Jito によって提案された元の MEVA アーキテクチャを確認してみましょう。
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 クライアントの採用後、相対的なブロック生産性が大幅に向上しました。これは、2023 年に Jito によって導入された最適化されたブロック エンジンにより、トランザクション処理がより効率化されたことを示しています。
図 9: Jito が Solana 上のスパム問題を効果的に軽減しているという証拠。この数字は、p2p チームが実施した調査から取得したものです。
大きな進歩が見られましたが、多くの課題が残されています。 Jito バンドルはブロックを部分的にのみ埋めるため、MEV によるトランザクションは依然として Jito オークション チャネルをバイパスできます。証拠の一部は図 10 の Dune ダッシュボードにあります。これは、2024 年以降、ネットワークでは依然としてボット スパム トランザクションによるトランザクションの平均 50% を超えるエラーが発生していることを示しています。
図 10: 2022 年 5 月以降の Solana でのボット スパム活動の Dune ダッシュボード (詳細についてはDuneを参照)
2024 年 3 月 9 日、Jito は主力メモリ プールの停止を決定しました。この決定は、ミームコイントランザクションの増加と、それに伴うサンドイッチ攻撃（検索者がターゲットトランザクションの前後にトランザクションを配置する攻撃）の急増によるもので、最終的にユーザーエクスペリエンスに影響を与えました。イーサリアム上の MEVA プライベート注文フロー チャネルと同様に、パブリック メモリプールを閉じることで、ウォレット プロバイダーやテレグラム ボットなどのフロントエンド サービスとの連携を通じてプライベート注文フローの成長が促進される可能性があります。検索者は、優先実行、包含、または除外の権利を取得するために、バリデーターと直接パートナーシップを結ぶことができます。
実際、図 11 は、mempool が閉鎖された後の、最大のプライベート mempool サーチャーのサンドイッチ ボットの 1 時間あたりの利益を示しています。
最大のプライベート メモリ サーチャー:
3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81
(翻訳者注: サンドイッチ ロボットは一般的な最前線の攻撃ツールであり、主にブロックチェーン トランザクションで利益を得るために使用されます)。
図 11: プライベート メモリプールを使用した検索者「3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81」の時間ごとのサンドイッチ ボットの利益
mempool をシャットダウンするという Jito の決定は、Solana エコシステムの根本的な問題を解決するというチームの取り組みを示しています。 Jito は、MEVA の反復や Solana のガス料金メカニズムの調整に加えて、UI 製品設計の選択 (デフォルトのスリッページ パラメーターの制限など) を通じてプロトコルが攻撃リスクを軽減するのにも役立ちます。スパム取引をより高価にする料金体系の調整を通じて、または通信プロトコルの変更を通じて、Jito のインフラストラクチャは、Solana ネットワークの健全性と安定性を維持する上で重要な役割を果たし続けるでしょう。
モナド上の MEVA デザイン
実行の遅延とそれによる MEVA への影響
ブロックの合意にはトランザクションのリスト（順序付き）とイベント後のすべての状態を要約するマークルルートが必要なイーサリアムとは異なり、モナドは以前の実行をコンセンサスから切り離します。ノード プロトコルは、公式の順序付けの問題を解決することのみが必要です。図 12 に示すように、各ノードは、ブロック N+1 でコンセンサスに達し始めると、ブロック N 内のトランザクションを独立して実行します。この取り決めにより、コンセンサスに合わせて実行するだけで済むため、ブロック時間全体に相当するガスバジェットが可能になります。リーダーノードは事実上の状態ルートを計算する必要がないため、実行ではコンセンサス期間全体を利用して次のブロックを処理できます。
図 12: Monad の遅延実行と Ethereum の実行合意フェーズの比較。動作時間ウィンドウも MEVA 設計の観点から示されています。
運用時間枠は、MEVA がデフォルトのブロック構築方法と比較して実現可能で収益性の高い Monad 上でのブロック構築提案を完了できる時間枠として定義されます。遅延実行モデルには、次の 2 つの直接的な影響があります。
操作時間枠内で N 番目のブロックに対して MEVA が構築されると、バリデーターは同時に N 番目のブロックのトランザクション リストについて合意に達し、N-1 番目のブロックの実行を完了しようとします。したがって、N 番目の操作時間ウィンドウ内では、利用可能なステータスは依然として N-2 番目にあります。これは、この遅延実行アーキテクチャでは、リレーまたはビルダーが「最新の状態」であるという保証がないことを意味します。したがって、次のブロックが生成されるまで最新のブロックに対してシミュレーションを行うことは不可能であり、不確実性が生じます。
Monad のブロック時間が 1 秒であることを考えると、MEVA の動作時間枠は非常に限られています。これは、イーサリアムで通常行われるように、ビルダーがトランザクションとバンドルの完全なブロックを順番にシミュレートするのに十分な時間がない可能性があることを意味します。多くの変数が EVM での取引シミュレーションに必要な時間に影響を与える可能性があります。ただし、トランザクションのシミュレーションに 10^1 ～ 10^2 マイクロ秒 (概算) かかり、モナドが 1 秒あたり 10^4 トランザクションをターゲットにしていると仮定すると、動作時間枠内の完全なブロックのシミュレーションだけでも約 1 秒かかる可能性があります。 。 Monad のブロック時間が 1 秒であることを考えると、ビルダーやリレーが複数の完全なブロック シミュレーションを完了してビルディング ブロックを最適化することは困難になります。
確率的ビルダー戦略とサーチャー戦略
これらの制限を考慮すると、動作時間枠内でブロック全体のシミュレーションを完了し、最新の状態に対してシミュレーションすることは現実的ではありません。現在、ビルダーには各トランザクションの正確なヒントを知るための時間と最新のステータスの両方が欠けているため、トランザクションのロールバックの可能性に基づいて、評判に依存するか、または (おそらく最良の) N-2 番目のステータス シミュレーションをターゲットにすることによって、シーカー ヒントを推測する必要があります。 。これにより、ブロックの評価の信頼性が低くなります。
トランザクションのロールバックに対する理論的な保証がないため、バリデーターがビルダーによって構築されたブロックを受け入れると、検索者はより大きな実行の不確実性に直面します。これは、検索者がビルダーへの専用のプライベートオーダーフローチャネルで競争し、比較的確実な戦略で実行するイーサリアムとは対照的です。モナドのこの相対確率設定では、サーチャーはバンドルのロールバックの高いリスクに直面し、その結果、実行損益プロファイルがより不確実になります。これは、確率的なシグナルに基づいて取引を実行し、時間の経過とともにわずかに高い期待収益を達成する高頻度トレーダーに似ています。
図 13: 提案されたブロックの検査またはシミュレーションの程度に応じて分類された、さまざまな MEVA 設計パラダイムを示す概念的なスペクトル図
図 13 に示すように、建設業者側の事前のバンドル/ブロック チェックの程度によって、提案されたブロックの価格設定や評価に関して不確実性の範囲が生じます。一方の端には、正確な価格設定を備えたイーサリアム スタイルの PBS モデルがあり、ビルダーは実行層 (EL) クライアントを使用して、提案されたブロック内のトランザクションをシミュレートする必要があります。提出されたバンドルの幅広いポートフォリオをナビゲートする必要があります。もう一方の端には、非同期ブロック チェックを備えた楽観的なビルダー モデル [16] があります。このモデルでは、ビルダーは動作時間枠内のシミュレーションに必要な時間をバイパスし、担保（スラッシュされる場合もある）を預けることによってバリデーターまたは中継者に示されたチップを現金化します。ここでモナドに関して提案されている確率的チェックまたは部分シミュレーションのアプローチは、その中間に位置し、多少の不確実性にもかかわらず、探索者が戦略を首尾よく実行する可能性が高まります。
たとえば、オンチェーンのオーダーブック DEX のマーケットメーカーは、大きな一方向の価格変動が検出されたときに、逆選択を避けるために MEVA を介してポジションを事前に移動する可能性があります。この確率論的な戦略により、最新のステータス情報がなくても迅速に行動でき、動的な取引環境でリスクと報酬のバランスを取ることができます。
結論
MEVA は、ブロック生成の最適化、外部影響の軽減、システムの安定性の向上において重要な役割を果たします。 Solana 上の Jito やイーサリアム上のさまざまな実装など、MEVA フレームワークの継続的な開発により、スケーラビリティの問題の解決が大幅に促進され、ネットワーク参加者に対するインセンティブがより一貫したものになりました。
Monad は、コミュニティに可能な限り最高の MEVA を設計するユニークな機会を提供する、初期段階にある有望なネットワークです。 Monad では実行とコンセンサスが独自に分離されているため、研究者、開発者、検証者を協力して洞察を共有するよう招待します。このコラボレーションは、堅牢で効率的なブロック生成プロセスの作成に役立ち、Monad が高スループットのブロックチェーン ネットワークとしての約束を実現するのに役立ちます。
