盗難者を先回りして「資金を「救済」する」暗号ボットの背後にある爆発的な真実 — しかし、誰に返済されるかは彼らが決める

image

Source: CryptoNewsNet Original Title: Explosive truth behind crypto bots that front-run thieves to “save” funds — but they decide who gets paid back Original Link:

The Makina Finance Incident

Makina Financeは、フラッシュローンとオラクル操作の脆弱性を突かれ、1,299 ETH、概算で413万ドルを失いました。

攻撃者はプロトコルの資金を枯渇させ、その取引をEthereumのパブリックメモリプールにブロードキャストしました。本来ならバリデーターに拾われて次のブロックに含まれるはずでした。

しかし、アドレス0xa6c2で識別されたMEVビルダーが枯渇取引をフロントランし、資金の大部分をビルダー管理のカストディにリダイレクトし、ハッカーがオフチェーンに資金を移動する前に阻止しました。

ハッカーの取引は失敗し、資金はMEVビルダーに関連付けられた2つのアドレスに着地しました。

この出来事からすぐにわかるのは、Makinaのユーザーが全損を免れたことです。より深い意味合いとしては、誰が資金を保持し、それが暗号資産の新たな緊急対応アーキテクチャにとって何を意味するのかという点です。

この物語で最も重要な役者は攻撃者やプロトコルではなく、脆弱性を傍受し、現在資金の返還可否や条件、スピードをコントロールしているブロックビルディングのサプライチェーンです。

MEVボットやビルダーは、設計上ではなく構造的な立場から、暗号の最後の防衛線となりつつあります。これは問題です。なぜなら、救済能力が利益最大化を追求する仲介者の手に集中しており、その責任の所在が不明確だからです。

MEVをバックストップとするパターンは既に存在

Makinaの事例は一度きりではありません。Chainalysisは2023年のCurveとVyperの脆弱性の際にも類似のダイナミクスを記録しており、ホワイトハットハッカーやMEVボット運用者が資金回収を支援し、実現損失を初期推定より低減させたと指摘しています。

このパターンは機械的です。公開取引チャネルで脆弱性や救済試行が見える限り、洗練された検索者やビルダーは取引の再順序付けを競い合うことができます。

時には資金を救い、時には捕捉します。いずれにせよ、これらは事実上の緊急対応層として機能しています。

脆弱性取引がパブリックメモリプールに入ると、MEV検索者は利益の出る機会を監視します。ハッカーがプロトコルを枯渇させて取引を公開した場合、検索者は先に実行される競合取引を構築し、資金を別のアドレスにリダイレクトできます。

検索者は取引を束ねてブロックビルダーに提出し、利益が競合入札を上回れば含められます。ビルダーのブロックがバリデーターに選ばれれば、検索者の取引は実行され、ハッカーの取引は失敗します。

これは純粋な利潤追求ではなく、利益抽出とともに有益な副次効果をもたらす仕組みです。しかし、これはまた、リアルタイムで脆弱性を傍受するために暗号が開発した最も信頼性の高いメカニズムでもあります。なぜなら、これは取引順序層で動作し、プロトコルレベルのサーキットブレーカーやガバナンス介入に頼らないからです。

MEVビルダー依存の不安

MEVを基盤とした救済の問題は、緊急対応能力が高度に仲介されたパイプラインに集中してしまう点です。

Ethereumでは、MEV-Boostがブロック生成の支配的手段です。Ratedのリレー市場調査によると、最近のブロックの約93.5%がMEV-Boost経由でルーティングされており、従来のブロック生成は約6%です。

MEV-Boost relay market concentration

MEV-Boost内では、リレーマーケットのシェアもさらに集中しています。Ultra Sound Moneyが約29.84%、Titanが約24.24%を占めており、最大の2つのリレーだけでブロック生成の過半を処理しています。

もしほとんどのブロックがMEV-Boostを通じて流れ、かつそのトラフィックの大部分が2つのリレーを経由している場合、救済層は少数の仲介者に構造的に依存しています。これにより、ガバナンスの問題が早期に生じます。

もしビルダーが救済された資金を保持した場合、誰がカストディを承認するのか?報奨金は誰が設定するのか?恐喝や身代金要求を防ぐ手段は?ビルダーがオフショア、匿名、または法執行の弱い管轄区域で運営している場合はどうなるのか?

Makinaのケースはこの問題を示しています。資金はビルダーのカストディにありますが、公開されたSLAや事前に定められた報奨金、Makinaやそのユーザーに資金を返還する明確な仕組みはありません。

ビルダーは自主的に資金を返還したり、報奨金を交渉したり、業界標準より高い料金を要求したり、資金を返さないこともあり得ます。

プライベートルーティングが問題を悪化させる

2025年の学術論文「Sandwiched and Silent」では、取引のプライベートルーティングが広く行われていることを記録し、多くの被害者がMEVボットにサンドイッチされた後、プライベートチャネルに移行していると指摘しています。

しかし、プライベートルーティングはMEVを排除しません。むしろ、公開メモリプールからビルダーやリレーが管理するプライベートオーダーフローチャンネルにシフトさせるだけです。

プロトコルにとっては、これにより公開メモリプールの救済は信頼性が低下します。なぜなら、脆弱性取引はますますプライベートチャネルを通じてルーティングされ、アクセスできるビルダーの一部だけが関与するからです。

混沌を文明化しようとする試み

SEALが開発したSafe Harborは、「MEVビルダーを偶発的なカストディにするモデル」を置き換える枠組みです。これには、認可されたレスポンダー、明示的なSLA、制限されたインセンティブが含まれます。

SEALはSafe Harborを、プロトコルがホワイトハットに介入を事前承認させることを可能にする法的・技術的枠組みと定義しています。

基本的な運用ルールは、救済資金は72時間以内に公式の回復アドレスに送付されるべきであり、事前に定められた執行可能な報奨金とともに行われることです。

SEALによると、Safe HarborはNomadハックを受けて動き出しました。ホワイトハットは支援したいと考えていましたが、資金返還が未承認のコンピュータアクセスとして訴追される可能性について法的曖昧さに制約されていたためです。

Safe Harborは、その曖昧さを排除し、プロトコルに介入の事前承認と明確な条件設定を可能にします。SEALは、Safe Harborがすでに$16 十億ドル以上の資産を保護していると主張しており、特定のDEX、Pendle、Layer-2ソリューション、zkSyncなどを含みます。

バグバウンティプラットフォームのImmunefiは、より厳格な条件でSafe Harborを運用しています。

Immunefiは、Safe HarborをSEALが開発した枠組みとし、資金をImmunefiのプラットフォーム上のプロトコル管理の金庫にリダイレクトします。ImmunefiのSafe Harborプログラムページには、「6時間以内に資金を返還してください」と記載されています。

6時間以内に返還できない場合は重大な違反となります。これはSEALの72時間の基準の4倍の速さです。

Safe Harborは、MEVインフラへの依存を排除しません。むしろ、それを形式化しようとするものです。

もしビルダーが脆弱性をフロントランし、プロトコルがSafe Harborを採用している場合、ビルダーは介入を承認されたものと認識し、SLA内に資金をプロトコルの指定回復アドレスにルーティングすることが期待されます。

ただし、それはビルダーがSafe Harborの登録を監視し、条件を尊重し、利益よりもコンプライアンスを優先することを前提としています。

シナリオの範囲

脆弱性におけるユーザーの回復率は、次のようにモデル化できます:期待される回復は、介入の確率に、報奨金の割合を引いたものの積に、失敗または漏洩の割合を引いたものの積です。

Safe Harborは、法的曖昧さを減らし、事前に報奨金の割合を制限することで、介入の可能性を高めることを目指しています。

基本シナリオでは、今後12ヶ月でSafe Harborの採用が増加します。より多くのプロトコルがガバナンス枠組みにSafe Harborの条件を追加し、より多くのホワイトハットが認可されたレスポンダーとして登録しています。

レスポンダーの法的明確さと固定された報奨金条件により、介入の確率は上昇します。特に、Immunefiの6時間ウィンドウのような厳格なSLAを採用したプロトコルでは、回復率が向上します。

強気シナリオでは、救済層は専門化します。プロトコルは堅牢な金庫アドレスを構築し、SLAを数時間に短縮し、既知のホワイトハットチームと事前に報奨金スケジュールを交渉します。

ビルダーはSafe Harborの登録を取引順序アルゴリズムに組み込み、自動的に救済資金を指定アドレスにルーティングし、手動介入を不要にします。

弱気シナリオでは、ビルダー依存が強化されます。プライベートオーダーフローとリレーの集中により、救済は透明性を欠き、寡占的になります。Safe Harborを採用していないプロトコルは、事後にビルダーと交渉し、明確なレバレッジやSLAを持たなくなります。

ガバナンスは、資金を保持し、一方的に条件を設定する仲介者に依存するようになります。

体制 介入可能者 資金の行き先 SLA 報奨金条件 責任追及 失敗時のモード
アドホックMEV救済 (Safe Harborなし) 脆弱性を見て介入できる任意のMEVサーチャー/ビルダー/リレー関係者 多くはビルダー/サーチャー管理のカストディ(または第三者アドレス) なし 交渉/不明(「支払ってくれ」的なアドホックダイナミクスに変わる可能性) 不透明(事前承認なし、正式義務なし) 身代金/恐喝リスク、資金返還拒否、長期未解決、法域の執行問題
Safe Harbor (SEAL基準) 事前承認されたホワイトハット(プロトコルによる明示的承認) プロトコル指定の回復アドレス(公式回復先) 72時間 事前定義/執行可能(事前にプロトコルが設定) ルールに基づく(限定的な承認 + 事前条件設定) 条件違反:資金未返還時、より明確なエスカレーションパス vsアドホック交渉
Safe Harbor (Immunefiプログラム) ImmunefiのSafe Harbor下の事前承認レスポンダー(SEAL由来) Immunefi上のプロトコル管理金庫(構造化されたカストディフロー) 6時間 事前定義された報酬/バウンティ構造(プロジェクト内で設定) より正式化(プラットフォーム条件 + 時間制限のコンプライアンス) 重大な違反:6時間以内に返還されない場合。SLAの厳格化は未解決期間を短縮するが、実行圧力を高める
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
0/400
コメントなし
  • ピン