MEV対策は非公開RPCだけで足りるか｜DEX取引の送り先と障害時の扱い

あるウォレットアプリのチームが、アプリの中でできるDEXの交換に、MEV対策を入れようとしています。最初の案はすぐに出ました。取引の送り先を、公開メンプールから非公開の送信経路（非公開RPC）に切り替える案です。

非公開にするのは、公開メンプールを見張るボットに取引を見られないためです。ボットは稼げそうな取引を見つけると、その前後に自分の取引を差し込みます。

ところが、障害のときの動きを詰めると問題が見えてきます。非公開の経路が止まったら、しばらく待って公開メンプールへ自動で流す、という作りです。そうすると、隠したかった取引を、障害のときだけ攻撃者に見せることになります。しかも、特に大口の交換では、利用者がそのリスクを受け入れたかを前もって確かめられません。

では、何を決めればよいのか。取引ごとに、先に3つを決めておきます。

• 誰に、どこまで情報を渡すか
• いつまで待つか
• どんな条件で再送するか

そのうえで、非公開の経路が止まっても、公開メンプールへ自動で逃がさない。これが設計の中心です。

チームでは、プロダクト責任者が取引ごとの方針を決めます。設計者はnonceの管理と障害時の動きを作り、運用担当は監視と受け入れ試験を受け持ちます。以下では、この順に見ていきます。Ethereum上のDEX取引を例にします。

攻撃する側の仕組み（サンドイッチ攻撃やJIT流動性）はMEVとAMM｜サンドイッチとJIT流動性の読み方で解説しています。MEVを取りにいく側の実装はFlash Loan裁定botの実装で扱っています。ここで扱うのは、守る側の送信の設計です。

送り先を変えるだけでは、何が残るか

MEV（Maximal Extractable Value）は、ブロックへ入れる取引の選択・除外・順序変更から得られる価値です。公開メンプールを見張るボットは、稼げそうな取引を見つけると、その前後に取引を差し込めます（ethereum.org「Maximal extractable value」）。

DEXの交換では、サンドイッチ攻撃が代表例です。攻撃者が対象の取引の前後で売買し、利用者の約定が悪くなることがあります。

非公開の中継（private relay）は、署名済みの取引を公開メンプールへ直接流しません。ブロックビルダーなどに限って共有します。そのため、公開メンプールだけを見ている攻撃者からは、取引の意図を隠せます。

それでも消えないリスクがあります。

• 価格インパクトと、大きすぎるスリッページの許容値
• 悪意あるコントラクトとオラクル操作
• ビルダーや中継者に中身を見られること

送信経路を変えるのは、いくつかある守りのうちの1つにすぎません。守りは次の4つを組み合わせます。

• 実行条件：最小受取額（amountOutMinimum）、期限（deadline）、価格インパクトの上限を署名前に確かめる。許可するルーター・トークン・チェーンも確かめる。
• 情報の流れ：取引の中身を誰へ、どこまで細かく、何ブロックまで共有するかを絞る。
• 送信の制御：非公開、インテント・オークション型、公開のどの経路を、取引の種類ごとに許すかを決める。
• 運用の制御：保留、取り込み済み、破棄、取消、差し替えを追いかけ、同じnonceの取り合いを防ぐ。

取引ごとに、どの経路を許すかを署名前に決める

ウォレット全体のRPCを一律に切り替えるだけだと、性格の違う取引を同じ規則で扱ってしまいます。読み取りの要求、普通の送金、中身を知られたくない交換、急ぎの取引などです。

そこで、送信経路を決める中継サーバー（ルーティングゲートウェイ）を置きます。ゲートウェイは、署名の前に取引の意図を分類します。秘密鍵はゲートウェイに渡しません。方針が決まった後の取引データに、ウォレットまたは署名者が署名します。

分類に使う材料は4つです。どれかが方針の範囲を外れたら、送りません。

calldataは、取引でコントラクトに渡す入力データです。関数セレクタは、そのうち呼び出す関数を示す部分です。

判定の結果は、方針の版と一緒に保存します。取引ハッシュだけでは、何を承認して、どの方針で送ったのかまでは分からないからです。見積もり、試算したブロック、チェーンID、nonce、署名したもの、方針の版を、同じ監査記録に結び付けます。何を方針に反映し、どの項目名で保存するかは、後半の「実装する人向けの詳細」にまとめました。

経路ごとに、誰が取引の中身を見られるか

後で見るとおり、同じ製品でも、設定によって中身を見られる相手が変わります。そのため、経路は製品名では比べません。比べるのは次の3点です。

• 誰が取引の意図を、そのままの形で見られるか
• 誰がブロックへの取り込みを決めるか
• 取消がどこまで届くか

主な方式を並べると、見られる相手と利点は次のとおりです。

後追い取引は、対象の取引の直後に入れる取引です。還元は、そこで生まれた利益の一部を利用者に戻す仕組みです。

方式ごとの注意点は次のとおりです。

• 単一の非公開中継：取り込まれる率、1社が止まると全部止まること、検閲、破棄された後の扱い
• 複数ビルダー：共有先を増やすほど、漏れる先も広がる
• オークション：共有するヒント、落札の規則、支払先、失敗したときの責任
• インテント型：署名がどこまでを約束するか、期限、取消、ソルバーの障害、決済コントラクト
• 公開メンプール：機密の取引を自動でここへ切り替えると、守りの前提が崩れる

同じ製品でも、設定で見られる相手が変わります。Flashbots Protectの既定設定では、取引はFlashbotsのビルダーだけに転送されます。25ブロックの間試して、取り込まれなければ破棄されます。

高速モード（fast mode）では、登録済みの全ビルダーへ共有されます。還元の配分や、共有される情報の範囲も変わります（Flashbots Protect Settings Guide）。「非公開」という一言だけでは、誰に見られるかは決まりません。

MEV BlockerはEthereum向けに、複数のRPCエンドポイントと注文フローのオークションを提供しています。先回り取引・サンドイッチ攻撃への対策と、後追い取引による還元が設計の対象です（MEV Blocker公式Docs）。

CoW Protocolは、バッチオークション方式です。利用者が署名した注文を、ソルバーが競って一括で決済します（CoW Protocol公式Docs）。

生の取引を非公開で送る方式と、結果の条件に署名するインテント方式では、取消・期限・責任の分担が違います。別の経路として評価してください。

同じ署名者のnonceを、1か所で順番に振る

Ethereumの取引のnonceは、送信アカウントごとの通し番号です（ethereum.org「Transactions」）。

同じ署名者から、複数の処理が別々に送ると困ったことが起きます。非公開側の保留中の取引は、公開側からは見えません。そのため、公開側で取ったnonceと食い違い、後の取引が止まることがあります。

そこで、nonceを振る仕組みは署名者ごとに1つだけにします。経路の変更も含め、すべての送信を同じ台帳で順番に処理します。

1本の取引は、次の順に進みます。方針の承認、署名、非公開での送信、取り込み、確定です。途中で破棄・期限切れになったら、取り込まれていないと確かめてから、署名し直すかを判断します。状態の一覧は後半にまとめました。

取消にも限界があります。Flashbotsのeth_sendPrivateTransactionでは、取り込みを許す最大のブロック番号を指定できます。eth_cancelPrivateTransactionでは、それ以降のブロックへの送信停止を頼めます。取消の要求は、送信時と同じ鍵で署名したものに限られます。

ただし、取消の要求が通っても、すでに伝わった取引や取り込まれた取引をチェーンから消せるわけではありません（Flashbots private transaction API）。

タイムアウトの直後に、同じnonceの別の取引を公開で送るとどうなるか。2つの経路が同じnonceを取り合います。

非公開の経路が止まったら、どう立て直すか

冒頭のチームの問題に戻ります。止まったら公開メンプールへ自動で送る作りは、「攻撃者に見せない」という大事な約束を、障害のときだけ外すことになります。

基本は、止まったら送らずに待つことです（fail closed）。そのうえで、次の順で立て直します。

1. 中継者の状態とチェーンのレシートを、別の読み取り用RPCで突き合わせる。応答がタイムアウトしただけか、そもそも送れていないかを見分ける。
2. 対象ブロックか期限まで、同じ取引ハッシュを追う。その間に並行して送り直さない。
3. 期限の後で、中継者側の破棄・取消の状態と、チェーン上のnonceを確かめる。
4. 見積もりとシミュレーションを取り直し、同じ業務の意図について、新しく送信を承認する。
5. 公開経路を使うなら、別の方針として扱う。取引の種類・金額の上限・追加の承認・短い期限を満たすものに限る。

送金や緊急停止のように、情報が漏れるより急ぐ方が大事な取引もあります。その場合は、公開経路に切り替えるのが理にかなうこともあります。

一方、交換、流動性の移動、清算回避などは、価格への影響が大きい取引です。送金と同じ切り替えの方針を使い回しません。清算回避の取引の扱いはDeFiポジション監視と清算リスク対策で扱っています。

何を監視するか

サンドイッチの被害額だけを見ていると、その手前の兆しを見落とします。取引が詰まる、非公開のはずの送信がいつの間にか公開になっている、特定のビルダーへの依存が強まっている、などです。

次の指標を、経路・方針の版・取引の種類ごとに集計します。

• 送信から取り込みまでのブロック数（中央値・95パーセンタイル）、期限切れ率、失敗（revert）率
• 見積もり額と実際の受取額、価格インパクト、スリッページの消費率、サンドイッチの推定有無
• 非公開・公開別の件数、手動での切り替え件数、切り替えの承認者と理由
• 中継者のエラー、レート制限、届くビルダーの範囲、取消の成功率、状態不明の時間
• 署名者ごとの保留中のnonce数、nonceの欠番、差し替え、同じnonceの取り合い
• 共有したヒント、送信先の範囲、設定変更、方針からの逸脱

アラートからは、取引ハッシュ、意図のID、見積もり、シミュレーション、方針の版、中継者の応答、レシートへたどれるようにします。

ただし、calldataや利用者の識別子を、監視の仕組みへ無制限に写さないでください。セキュリティ調査とプライバシーの両方から見て、保存する範囲を決めます。

本番の前に、どんな障害と情報漏れを試すか

合格の目安は、「非公開のRPCへ送れた」ではありません。障害を起こしても守りが崩れないことです。

DEX、トークン、手数料の水準、取引量、混雑、再編成（直近のブロックの置き換わり）も変えて試します。利用者の実際の受取額と、状態の流れまで再現できることを確かめてください。価格インパクトとスリッページの違いは価格インパクトとスリッページ｜大口取引者のコスト計算と対策で詳しく整理しています。

その経路を採用しないのはどんなときか

次のどれかに当たる経路は、本番で「守られた経路」として使いません。

• 取引が誰へ共有されるかを、設定と契約の両方で確かめられない。
• 未取り込み・取消・破棄を見分けられず、nonceを安全に使い直せない。
• 障害時に公開メンプールへ自動で送られ、取引ごとに止められない。
• 経路の変更、共有するヒント、ビルダーの範囲を監査記録に残せない。
• 対応チェーン、取引の型、レート制限、最大の取引条件が本番の要件に足りない。
• 1社が止まったときの代わりの経路を、同じ受け入れ試験で確かめられない。

DeFiを企業の資金で運用する場合の上限と回収手順は企業財務のDeFi運用ポリシーをご覧ください。採用前のプロトコル評価は企業向けDeFiプロトコルの調査・評価で扱っています。

実装する人向けの詳細

方針に反映する項目と、保存する項目

前半の4つの材料は、それぞれ次の項目として送信経路に反映します。

方針の出力はroute_id、policy_version、allowed_destinations、max_block、privacy_hints、fallback_actionとして保存します。

取引の状態

1. 方針の承認（POLICY_APPROVED）：見積もり、シミュレーション、スリッページ、経路、期限を承認する。
2. 署名済み（SIGNED）：チェーンID、nonce、手数料、calldataを固定して署名する。
3. 非公開で送信済み（PRIVATE_SUBMITTED）：送信先、リクエストID、取引ハッシュ、対象ブロックの範囲を記録する。
4. 取り込み済み（INCLUDED）：レシートのブロック、状態、実際の受取額、ガスを確かめる。
5. 確定（FINALIZED）：業務の方針が定める確定条件を満たして完了する。
6. 破棄・期限切れ（DROPPED / EXPIRED）：チェーンと中継者を突き合わせ、取り込まれていないと確かめてから、署名し直すかの判断へ戻る。
7. 取消の依頼中（CANCEL_REQUESTED）：取消の受付を記録する。チェーン上で取り込まれていないと確かめるまで、取消完了とみなさない。

XTELAができること

私たちは、DeFi連携の脅威モデル、取引ごとの送信経路の方針、nonceを含む取引の状態管理、監視と障害試験を設計・開発します。まず代表的な交換取引で、非公開経路の停止や価格変動を注入するPoC（概念実証）を回し、貴社のプロダクトで保護が崩れない構成を確かめます。システム要件と検証計画の整理はお問い合わせからご相談ください。

主要参考資料

• ethereum.org「Maximal extractable value」（2026年8月13日確認）
• ethereum.org「Transactions」（2026年8月13日確認）
• Flashbots Protect「MEV Protection Overview」（2026年8月13日確認）
• Flashbots Protect「Settings Guide」（2026年9月24日確認）
• Flashbots Protect「eth_sendPrivateTransaction」（2026年9月24日確認）
• MEV Blocker Documentation（2026年8月13日確認）
• CoW Protocol Documentation（2026年8月13日確認）

資料の確認日と注意

仕様・公式Docsは2026年8月13日に確認しました。Flashbots Protectの2つのページは、2026年9月24日に確認し直しています。一般的な技術情報にもとづく設計の解説で、特定取引の投資判断、価格予測、損失回避を保証するものではありません。中継者、ビルダー、オークション、RPCエンドポイント、対応チェーン、プライバシー設定、還元の条件は更新されます。本番で採用するときは、対象サービスの最新Docs、契約、実測結果をご確認ください。