我們如何在不到一秒內偵測到 DeFi 漏洞

Quicknode

2026年4月21日 — 閱讀時間 7 分鐘

分享

新增為首選來源

作者：Arseniy Reutov，Decurity 技術長暨共同創辦人 刊載於Quicknode 部落格

我花費了十多年時間建構攻擊偵測系統；起初在 Web2 領域，當時我從事流量分析與 Web 應用防火牆（WAF）相關工作；隨後轉戰 Web3 領域，在那裡同樣的攻擊問題不僅發展速度更快，涉及的資金規模也更大。我於 2022 年共同創辦了 Decurity。我們對 DeFi 協議進行審計，並開發工具來監控這些協議在生產環境中的運作狀況。 Defimon 正是監控端的解決方案：這套即時漏洞利用偵測系統，獲得了 DeFi 實際運作的各條鏈上協議團隊、資安公司及風險管理者的信賴。它會在駭客攻擊登上新聞頭條之前就發出警報——否則便稱不上盡職。打造一套能以如此速度運作、且橫跨如此多條鏈的系統，結果證明這是一個比資安問題更棘手的基础架構難題。以下便是我們在開發過程中所學到的教訓。

為何偵測速度是安全性基礎要素

在去中心化金融（DeFi）領域，一個協議可能在單一原子交易中就被徹底清空。然而，從漏洞攻擊的最初徵兆出現，到協議被完全清空之間，往往存在一段時間窗口。Balancer 事件、Yearn 駭客攻擊事件皆是如此。在每起事件中，問題不在於是否有人在監控，而在於他們是否及時察覺了這些最初徵兆並做出反應。

要讓自動化事件應對發揮作用，警報必須及時送達，才能採取相應行動：暫停合約、通知多簽名持有者、轉移資金。區塊處理延遲兩秒聽起來似乎微不足道，但在協議層面上，這卻是「預先警示」與「事後檢討」之間的關鍵差異。

偵測速度並非一項功能，而是產品本身。

民意調查的問題

在開始開發 Defimon 之際，我們採用標準方式擷取鏈上資料：透過 RPC 進行輪詢，反覆向區塊鏈查詢最新的區塊、交易、日誌及追蹤紀錄。

這方法原本很管用，直到某天不再管用為止。

由於需要監控數百萬個錢包地址和合約互動，輪詢機制導致了兩個我們無法透過工程手段解決的問題。

延遲。每個輪詢週期會增加約兩秒的區塊延遲。對於一款其偵測時機決定了協議equipe 能否及時收到警示的產品而言，兩秒的延遲屬於結構性問題，而非效能調校問題。

擴展性。我們監控的地址觀察清單不斷擴大。我們將區塊鏈資料推送至運行於 AWS 上的 Apache Flink SQL 處理管線，並將動態地址清單儲存在記憶體中。隨著監控範圍擴大，記憶體不足的錯誤變得屢見不鮮。系統無法隨著我們需要監控的範圍擴大而擴展。而且，對 SQL 處理管線的任何變更，都必須完全重新啟動 Apache Flink，每次停機時間長達 20 分鐘。

最糟糕的時候，我們每月要花費 4,000 美元在 AWS 上，用以支援三條生產線，並需要三到四名工程師來維持管道的運作。我們的equipe 專長在於偵測邏輯，卻將資源浪費在基礎設施上。

我們為何轉向「Push Data」

核心的變革在於將輪詢機制替換為採用Quicknode Streams 的推送模式。

無需向區塊鏈查詢資料，當區塊上鏈的瞬間，資料便會即時送達。區塊延遲從約兩秒降至不到 0.5 秒。Telegram 通知現在能在偵測到事件後一秒內觸發。這並非微幅的改善，而是屬於截然不同類別的產品。

但延遲只是問題的一部分。更大的優勢在於上行過濾。

我們舊有的 Apache Flink 處理流程是基於 SQL 運行的。偵測邏輯存在於一個由眾多子查詢組成的龐大查詢中，起初撰寫時採用宣告式語法，但隨著規模擴大，維護起來卻相當棘手。當我們遷移至Streams 時，也將偵測邏輯從 SQL 轉移至 JavaScript，讓篩選器能直接在區塊鏈節點內執行。這項變更為我們帶來了三項好處：

靈活性。偵測邏輯的任何變更皆可無停機上線。我們根據過往的 DeFi 事件建置了一套完整的測試套件，用以驗證我們的邏輯在經過修改後仍能保持完整。Quicknode 的 JS 篩選器測試工具讓我們能在部署前執行整套測試。

效能。我們不再處理所有的區塊鏈資料。Streams 會在節點層級進行篩選，並僅傳送我們所需的資料。頻寬消耗大幅降低。

速度。只要出現新的區塊，資料便會立即推送。無輪詢間隔。無往返延遲。

偵測架構

以下是我們目前的工作流程。

當有區塊在我們監控的八條區塊鏈中的任何一條上上鏈時，Streams 會透過 JavaScript 在節點層級對其進行過濾，僅將相關資料傳送至下游。內建於Quicknode Streams 的鍵值儲存庫（Key-Value Store）存放著我們的監控清單，其中包含數百萬個受追蹤的地址，這些地址可由 JavaScript 過濾器直接參照。漏洞利用偵測邏輯會針對上游服務中的過濾後資料進行運算。若發現模式匹配，系統便會觸發警報。

整個過程在不到一秒內就完成了。

一個具體的例子：透過使用Streams 處理交易追蹤資料，我們能夠偵測到企圖在未初始化的代理智慧合約中植入後門的行為。這種我們稱為 CPIMP（代理中的隱蔽代理，Clandestine Proxy In the Middle of Proxy）的攻擊模式，發生於代理合約雖已部署，卻未在同一筆交易中以原子性方式完成初始化時。此漏洞使惡意行為者得以接管該代理，並設定惡意實作的合約。 要偵測此類攻擊，必須及早且迅速地檢視交易追蹤資料。Streams 使這成為可能。

無需運維團隊即可擴展至八條鏈equipe

我們最初在三條鏈上啟動了 Defimon。目前我們監測的鏈有八條：Ethereum 、BNB Smart Chain 、Arbitrum 、Base 、Polygon 、Avalanche 、Optimism 以及 HyperEVM。

在舊的架構下，新增一條鏈意味著需要新的基礎設施、新的伺服器、新的處理流程，以及更多人力。每次新增項目都會與偵測工作直接競爭工程團隊的時間。

在Streams 中，新增一條鏈僅需進行配置變更。整合 HyperEVM 耗時不到一天。我們調整了部分常數和相關地址，這就佔了大部分的工作量。

如今，整條管道僅由一名工程師負責運作。其餘人員則專注於偵測邏輯。在舊的架構下，光是維持基礎設施的運作就需要三到四個人。

警報觸發後會發生什麼事

Defimon 的訂閱用戶不僅是為了監控漏洞而觀看。他們正基於我們的警示，建置自動化事件應變機制。警示發送得越快，可採取行動的時間就越充裕。

某對沖基金客戶管理著一筆九位數的 DeFi 倉位，透過 WebSockets 與我們的系統整合，一旦我們偵測到針對其設定之協議的攻擊初現端倪，系統便會立即自動平倉。當發現正在發生的事件時，個人投資者與交易員會利用我們的警示來調整倉位。

不過，最重大的應用案例莫過於「白帽」的主動干預。我們運行著一個「白帽」機器人，迄今已總計挽救超過 200 萬美元。最近，它為一位因誤設代幣配額而受損的用戶追回了 51.2 萬美元。我們行動迅速，在惡意攻擊者察覺之前就已採取行動。正是底層處理流程的速度，才使得這次干預成為可能。

結語

每個 DeFi 協議都應即時掌握其合約的運作狀況。在人工智慧正加速增加攻擊事件數量與複雜度的時代，及早察覺攻擊徵兆已非可有可無之事，而是基本要求。

Defimon 的任務是及時觸發警報，讓團隊有足夠的時間採取行動。資料管道要麼是實現這一點的關鍵，要麼就是阻礙。

如果您的equipe 仍採用輪詢模式，問題不在於延遲是否會造成影響，而在於何時會造成影響。從原始碼重新編譯確實令人不適，但對根本上速度緩慢的架構進行修補，並非實現亞秒級偵測的途徑。對我們而言，轉向推送模式並非出於技術偏好，而是讓產品真正能運作的唯一途徑。

阿爾塞尼·雷烏托夫（Arseniy Reutov）是 Decurity 的技術長暨共同創辦人，這家 Web3 資安公司深受 1inch、Gearbox 以及Arbitrum 基金會的信賴。Defimon 是 Decurity 的即時漏洞偵測平台，為 3,500 多名訂閱者監控八條 EVM 鏈。