加密機器人背後的驚人真相：它們在盜賊前面搶先行動以「拯救」資金——但由它們決定誰能獲得償還

資料來源：CryptoNewsNet 原文標題：揭露加密貨幣機器人背後的爆炸性真相：它們在前置盜賊以“拯救”資金——但由它們決定誰獲得償還 原始連結：

Makina Finance 事件

Makina Finance 在閃電貸款與預言機操控漏洞中損失了 1,299 ETH，約合 413 萬美元。

攻擊者耗盡協議資金，並將交易廣播到以太坊公共內存池，理應由驗證者捕捉並包含在下一個區塊中。

然而，一個由地址 0xa6c2 識別的 MEV 建構者先行前置，搶先執行了抽資交易，將大部分資金轉入由建構者控制的保管地址，趕在駭客將資金轉移出鏈之前。

駭客的交易失敗了。資金最終落入與該 MEV 建構者相關的兩個地址。

立即的結論是 Makina 的用戶避免了全面損失。更深層的訊號是，誰最終持有這些資金，以及這對加密貨幣新興的緊急應變架構意味著什麼。

這個故事中最重要的角色不是攻擊者或協議本身，而是攔截漏洞並控制資金回收的區塊建構供應鏈，牠們決定用什麼條件、以及多快讓用戶拿回資金。

MEV 機器人和建構者正逐漸成為加密貨幣的最後防線，這不是出於設計，而是由於其結構性位置所致。這是一個問題，因為救援能力集中在追求最大利潤的中介手中，且責任不明。

MEV 作為後備方案已成為一種模式

Makina 事件並非孤例。Chainalysis 在 2023 年 Curve 和 Vyper 漏洞事件中也記錄到類似的動態，指出白帽駭客和 MEV 機器人操作者協助追回資金，降低了實現損失，低於最初預估。

這種模式是機械式的：只要漏洞或救援行動在公共交易通道中可見，精明的搜尋者和建構者就能競爭重排交易。

有時他們會救回資金，有時則會奪取資金。無論如何，他們都在扮演事實上的緊急應變層。

當漏洞交易進入公共內存池時，MEV 搜尋者會監控有利可圖的機會。如果駭客抽走協議資金並公開廣播交易，搜尋者可以構建一個競爭交易，先行執行，將資金轉向另一個地址。

搜尋者將交易打包並提交給區塊建構者，若利潤高於競爭出價，建構者會將其包含在區塊中。如果建構者的區塊被驗證者選中，搜尋者的交易就會執行，駭客的交易則會失敗。

這是以利潤為導向的提取，同時具有正面副作用，而非純粹的利他行為。但這也是加密貨幣在實時攔截漏洞方面最可靠的機制，因為它運作在交易排序層，而非依賴協議層的電路斷路器或治理干預。

為何依賴 MEV 建構者令人不安

以 MEV 為基礎的救援方案的問題在於，它將緊急應變能力集中在一個高度中介化的流程中。

在以太坊上，MEV-Boost 主導區塊產出。Rated 的中繼平台顯示，近 93.5% 的區塊經由 MEV-Boost 路由，而僅約 6% 使用原生區塊產出。

在 MEV-Boost 內，中繼市場份額進一步集中：Ultra Sound Money 約佔 29.84%，Titan 約佔 24.24%，也就是說，兩大中繼合計處理超過 54% 的區塊產出。

如果大多數區塊都經由 MEV-Boost，且大多數流量都經由兩個中繼，救援層在結構上就依賴少數中介。這會很快引發治理問題。

如果建構者最終持有救援資金，誰來授權保管？誰來設定獎金？什麼能阻止勒索或贖金要求？如果建構者在海外、匿名，或在執法較弱的司法管轄區運作，又會怎樣？

Makina 案例說明了這個問題。資金由建構者保管，但沒有公開的服務水平協議（SLA）、預先設定的獎金，或明確的資金返還機制。

建構者可以自願返還資金、協商獎金、要求高於行業標準的費用，或完全拒絕返還。

私人路由使問題更嚴重

2025 年一篇題為《Sandwiched and Silent》的學術論文記錄了交易的廣泛私人路由，並發現許多受害者在被 MEV 機器人夾擊後轉向私人通道。

然而，私人路由並未消除 MEV，只是將其從公共內存池轉移到由建構者和中繼控制的私人訂單流通道。

對協議而言，這意味著公共內存池的救援變得不那麼可靠，因為漏洞交易越來越多地通過僅對部分建構者開放的私人通道路由。

嘗試將混亂文明化

Safe Harbor 是由 SEAL 開發的一個框架，旨在用授權應答者、明確的 SLA 和有限的激勵來取代“MEV 建構者作為意外保管人”的模式。

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 平台上的協議控制金庫。其 Safe Harbor 計畫頁面規定：「你有 6 小時時間轉回資金。」

未在六小時內完成則構成重大違約。這比 SEAL 的 72 小時基準快四倍。

Safe Harbor 並未消除對 MEV 基礎設施的依賴，而是試圖將其制度化。

如果建構者先行搶跑漏洞，且協議已採用 Safe Harbor，建構者預期會將干預視為授權行為，並在 SLA 內將資金轉入協議指定的救援地址。

但這假設建構者會監控 Safe Harbor 註冊，尊重條款，並將合規置於利潤之上。

情境範圍

在漏洞中，用戶的預期救援率可以用以下模型估算：預期救援=干預概率×（1-獎金百分比）×（1-失敗或洩漏百分比）。

Safe Harbor 旨在通過降低法律模糊性和提前設定獎金百分比來提高干預的可能性。

在基本情境下，未來 12 個月內，Safe Harbor 的採用率將逐步提高。越來越多的協議將 Safe Harbor 條款加入其治理架構，越來越多的白帽駭客註冊成為授權應答者。

由於應答者擁有法律明確性和固定的獎金條款，干預的概率也會提高。救援率會改善，尤其是對於採用更嚴格 SLA（如 Immunefi 的六小時窗口）的協議。

在牛市情境中，救援層將專業化。協議建立緊湊的金庫地址，將 SLA 縮短到單位數小時，並預先與已知白帽團隊協商獎金安排。

建構者將 Safe Harbor 註冊整合到交易排序算法中，能自動將救援資金路由到指定地址，無需人工干預。

在熊市情境中，對建構者的依賴將變得更為鞏固。私人訂單流和中繼集中使救援變得不那麼透明，且更具寡頭壟斷性。未採用 Safe Harbor 的協議，最終只能在事後與建構者協商，缺乏明確的杠杆或 SLA。

治理將依賴持有資金並單方面設定條款的中介。