TL;DR
- 安全性仍然是 DeFi 領域一個關鍵且持續存在的挑戰,每年造成數十億美元的損失。
- DeFi 協議的安全措施應涵蓋其整個生命週期,從發布前到發布後,保障其內在安全與運營安全。實施預防性策略和應急計畫以減輕潛在攻擊的影響至關重要。
- 以程式碼審計為核心的發布前安全已成為社群共識。然而,儘管出現了發布後安全解決方案(例如攻擊監控與封鎖),其重要性尚未被社群完全認識到。
- 持續改進安全實踐並轉向以安全為先的文化,對於保護用戶資產和增強生態系統信任至關重要。

引言
隨著 DeFi 持續革新金融格局,安全性仍是該生態系統中的一大隱憂,每年造成數十億美元的損失。
根據 Chainalysis 的數據,2023 年 DeFi 駭客攻擊造成超過 11 億美元的損失。儘管這一數字較 2022 年有所下降,但 2023 年 DeFi 駭客攻擊出現了多種新趨勢。例如,多年來一直安全運行的知名協議,如 Curve 和 KyberSwap,也遭到了攻擊。此外,針對基礎設施漏洞的複雜攻擊,例如 Flashbots relay,也被曝光。
根據 Security Incidents Library 的數據,2024 年上半年發生了超過 50 起造成損失超過 10 萬美元的駭客攻擊事件。

安全性是 DeFi 應用蓬勃發展與大規模採用的關鍵因素。這是因為 DeFi 協議管理著數十億美元的用戶資產,任何針對這些協議的駭客攻擊都可能給受影響的用戶帶來重大損失。儘管在某些情況下,被盜資金可以(部分)追回(例如 the Euler security incident),但我們不能每次都指望這種情況發生。每一次攻擊都在侵蝕人們對 DeFi 的信心。
儘管已經提出了多種增強 DeFi 安全性的方法,但仍有很大的改進空間。
- 從積極的一面來看,程式碼審計已成為確保安全性的社群共識。大多數協議在發布前都會進行程式碼審計,這有助於減少因智能合約漏洞而產生的攻擊面。
- 然而,僅靠程式碼審計遠不足以解決所有安全問題。它無法防止因智能合約升級、配置變更以及不同協議間運行時依賴關係所引入的漏洞而導致的駭客攻擊。
由於這些限制,更多主動式解決方案,例如運營監控或攻擊檢測系統,已經出現並被一些協議所採用。
在這篇部落格中,我們將透過追溯協議在不同階段的安全歷程——從發布前階段到運營階段,再到攻擊應對——來探討 DeFi 安全格局。我們將詳細闡述各類安全措施,並重點介紹每個階段的主要供應商(產品),討論其優缺點。 我們希望我們的見解能夠幫助社群更好地理解當前的技術水平,更重要的是,能夠激發未來的創新解決方案。
DeFi 安全格局
DeFi 協議的安全措施必須涵蓋其整個生命週期,從發布前階段到發布後階段,確保協議的內在安全性和運營安全性。此外,必須制定預防性措施和應急計畫,以應對潛在的攻擊。為了幫助讀者理解現有的解決方案,我們將 DeFi 安全供應商(產品)分為以下幾類。
發布前安全
此類別包括在協議發布前進行的安全措施,包括程式碼審計、形式化驗證和安全測試。

程式碼審計服務與競賽
程式碼審計是社群中廣為接受的保障協議安全的做法。在此過程中,安全公司將以半自動化的方式審查程式碼,即自動掃描程式碼以尋找常見漏洞,並手動審查較複雜的漏洞。具代表性的公司包括 OpenZeppelin、ChainSecurity、BlockSec 等。
此外,還有審計競賽平台,其進行審計的方式與安全審計公司有所不同。這些平台發起審計競賽,邀請社群中的安全研究人員參與審計競賽,並將獎勵分發給在協議中發現問題的人。當然,各平台在評估嚴重程度的方式、獎勵分配演算法以及參與安全研究人員的標準方面可能存在一些細微差異。此類平台包括 Code4rena、SHERLOCK、Cantina 和 Secure3。
程式碼審計(及競賽)是協議安全的主要防線。然而,它存在實際的局限性,這也解釋了為什麼許多經由知名公司審計過的協議仍然遭到駭客攻擊。
- 首先,靜態程式碼審計無法完全評估因協議依賴關係而產生的安全問題,尤其是由於 DeFi 協議的可組合性所致。
- 其次,在程式碼審計過程中,一些問題的安全影響被低估了。例如,精度損失是一個常見問題,可能會被審計人員和協議雙方所忽視。直到 Hundred Finance 和 Channels Finance 事件發生後,其安全影響才被社群完全認識到。
- 最後但同樣重要的是,高品質的程式碼審計仍然是一項聲譽卓著且稀缺的資源,需要精通安全、金融和電腦科學的跨學科人才。目前,很少有大學能夠持續且大規模地培養此類人才。因此,協議可能會由不具備從事此業務資格的公司進行審計。
形式化驗證
「形式化驗證是指使用數學的形式化方法,針對某一形式化規範或屬性,證明或反駁系統的正確性。」由於形式化驗證能夠證明系統的正確性,它已被應用於 DeFi 協議中。具體而言,它可以確保 DeFi 協議的行為滿足形式化規範。DeFi 協議形式化驗證產品的代表是由 Certora 開發的 Prover。開發人員提供規則(規範),Prover 會透過探索每一個可能的程式狀態,將結果與規則進行比較以識別錯誤。
形式化驗證最具前景的一面在於,它能夠以數學方式證明 DeFi 協議的正確性。然而,在實際應用中,它仍存在一些阻礙其廣泛採用的局限性。
- 首先,規範需要由開發人員提供,這要求開發人員擁有一份記錄完善的協議預期行為規範。考慮到大多數開發人員並非此領域的專家,這並非易事。
- 其次,協議的頻繁升級可能需要更新規範並重新評估協議。一些協議可能無法承擔所需的時間和精力。
儘管如此,協議仍應進行形式化驗證,尤其是那些尚未經過實戰考驗且管理著大量用戶資產的新協議。然而,提升形式化驗證的可用性並提高其採用率仍是一項持續的挑戰。
安全測試
安全測試是指使用測試用例來發現協議中錯誤的過程。與以數學方式證明協議正確性的形式化驗證相比,安全測試通常使用具體的輸入值,而非形式化驗證中的符號化輸入值,因此效率更高但嚴謹性較低。
- Foundry 是智能合約領域頗受歡迎的開發與測試框架之一。開發人員可以在 Foundry 中運行測試。它還提供了對 DeFi 協議進行模糊測試(fuzz testing)、不變量測試(invariant testing)和差異測試(differential testing)的能力。
- 其他安全測試工具包括 Tenderly 和 Hardhat。
發布後安全
此類別包括在協議發布後(或在主網上運行後)進行的安全措施,包括漏洞賞金計畫、攻擊檢測和運營監控。

漏洞賞金計畫
漏洞賞金計畫在協議與安全研究人員之間搭起了一座橋樑。其基本理念是激勵研究人員報告零日漏洞以換取獎勵。具體而言,協議可以在漏洞賞金平台上列出其賞金,詳細說明賞金範圍以及舉報漏洞的獎勵金額。Immunefi 是 Web3 領域具代表性的漏洞賞金平台之一。
攻擊檢測
攻擊檢測平台掃描交易以定位惡意交易。具體而言,這些平台會審查與協議互動的交易是否存在惡意行為。一旦發生此類交易,將觸發警報。
- 例如,BlockSec Phalcon Security 掃描交易,並採用基於行為的檢測引擎來偵測惡意活動(例如惡意合約或提案)。可以將其想像成一名虛擬保安人員,觀察金融交易的每一步,尋找任何可疑行為。它從這些交易中提取行為模式,就像偵探分析線索一樣,然後使用類似於銀行用於偵測詐欺的金融模型來識別潛在攻擊。
- 類似的系統包括 Hypernative 和 Hexagate 提供的產品。
- 此外,Ironblocks 的 Venn Security network 提供了一個去中心化的基礎設施,將來自多個來源的檢測結果整合在一起。
運營監控
運營監控框架提供了一種為 DeFi 協議實施運營安全的方法。例如,DeFi 協議需要了解管理員密鑰的變更、執行智能合約的部署與升級,並自動掃描 pull request 以尋找安全漏洞。
- OpenZeppelin Defender 提供了一個平台,讓開發人員能夠安全地編寫程式碼、部署及運行智能合約。
- BlockSec Phalcon Security 可以監控與合約升級、Safe 錢包交易創建、新簽署與執行、存取控制以及治理相關的風險。
- Forta Network 擁有一套基礎設施,讓用戶可以 建立自己的機器人 來監控其協議,或 訂閱現有的機器人 以獲取釣魚攻擊或威脅警報。
攻擊應對
此類別包括在攻擊發生時觸發的安全措施,包括攻擊封鎖、自動應對、作戰室(war room)、根本原因分析以及攻擊者資金流向追蹤。

在攻擊應對的五項措施中,攻擊封鎖尤為值得注意,因為它使項目團隊能夠提前部署預防性措施,成功地在攻擊執行前將其封鎖,將損失降至零。自動應對平台也有助於減少攻擊造成的損害。
建立作戰室、進行根本原因分析以及追蹤被盜資金,都是在攻擊發生後採取的被動應對步驟。雖然這些策略可以減輕部分損害,並有助於防止未來發生類似的攻擊,但損失可能已經產生,且難以追回。此外,對項目聲譽的損害以及由此導致的用戶信心喪失可能是深遠的。
風險無處不在,且往往超出可控範圍,然而選擇部署預防性防禦措施是完全可以做到的,並且是我們強烈建議的。
攻擊封鎖
在實踐中對抗駭客攻擊時,僅靠攻擊檢測是不夠的。這是因為,若沒有自動封鎖駭客攻擊的能力,人工應對的速度就不夠快。在某些情況下(下表中的 KyberSwap、Gamma Strategies 和 Telcoin),協議需要幾分鐘甚至幾個小時才能採取人工行動,這對於挽救協議中的資產而言已為時過晚。在近期針對 Velocore 和 Rho 的駭客攻擊中,整個 Linea 鏈和 Scroll 鏈分別被暫停,這引發了外界對 L2 鏈中心化的擔憂。

攻擊封鎖是自動防止駭客攻擊的能力,需要兩項關鍵技術:早期檢測與自動搶先攔截駭客攻擊。
- 早期檢測意味著系統能夠在攻擊交易於區塊鏈上最終確認之前,具體而言是在其仍處於記憶體池(mempool)中待處理時,識別出這些交易。
- 搶先攔截攻擊涉及在攻擊交易之前,於鏈上放置一筆交易以暫停協議,從而在攻擊得以執行之前有效阻止它。
在此類別中,BlockSec Phalcon Security 是唯一擁有這些關鍵技術的產品。當駭客發起攻擊交易後,Phalcon Security 的攻擊監控引擎能夠立即檢測到該交易,向用戶發送攻擊警報,並自動搶先攔截以暫停協議,將損失降至零。其關鍵技術已經過實戰考驗,成功挽救超過 2000 萬美元的資產,涉及超過二十次的救援行動。
自動應對
Phalcon Security、Hexagate 和 Hypernative 等平台在攻擊發生時也能自動做出應對。
訂閱此類平台後,用戶可以針對各種協議風險設置監控與應對措施。如果某筆交易符合監控規則,系統將自動啟動用戶預先設定的應對行動(例如暫停協議),從而減少損失。
然而,有些平台不具備攻擊檢測引擎,系統無法直接識別攻擊交易並通知用戶。相反地,它需要用戶自行定義在何種條件下一筆交易可以被視為攻擊。由於攻擊交易的特徵非常複雜,而用戶(通常是合約開發人員)可能不具備足夠的安全知識,這對他們來說可能相當具有挑戰性。
作戰室(War Room)
當協議遭受攻擊時,需要建立作戰室。這有助於協議了解事態發展,在社群中分享情報,並調動資源採取進一步行動。這通常需要來自不同視角的專家參與。
SEAL 911 是一個「讓用戶、開發人員和安全研究人員在緊急情況下能夠與一小群高度信任的安全專業人員聯繫的無障礙管道」的項目。可透過 SEAL 911 Telegram Bot 與其聯繫。若某個項目遭受駭客攻擊,可以建立作戰室以協助該協議。
根本原因分析
當攻擊發生時,協議需要了解根本原因,例如智能合約中的漏洞以及該漏洞是如何被利用的。這需要一些實用的工具來分析攻擊交易。Phalcon Explorer、OpenChain 和 Tenderly 皆可用於此目的。
資金流向追蹤
資金流向追蹤是指在區塊鏈上追蹤攻擊者的初始資金及攻擊獲利,以定位相關地址與實體。若資產流入中心化實體(例如中心化交易所及其他機構級實體),則可聯繫執法部門協助凍結資金。
此類別中有多家公司和工具,包括 Chainalysis、TRM Labs、ARKHAM、ELLIPTIC、MetaSleuth 等。
- 例如,由 BlockSec 開發的 MetaSleuth 能夠自動追蹤跨鏈資金流向,並提供豐富的錢包地址標籤。
- ARKHAM 擁有一個社群,協議可以在其中就調查工作懸賞獎勵,藉此激勵社群協助追蹤攻擊者的資金。
安全教育資源
具備充分知識的頭腦才能建立更強大的防禦。除了上述提及的安全供應商與產品外,DeFi 安全還有另一個至關重要的組成部分:教育平台。

這些平台為 DeFi 從業人員和用戶提供了寶貴的資源,幫助他們了解安全見解、提升安全意識,並培養安全技能。它們在推動 DeFi 安全發展方面發揮著至關重要的作用。我們對這些教育平台表示感謝,並列舉幾個值得關注的範例。
- SΞCURΞUM:一個專注於以太坊安全的 Discord 社群。它還舉辦每月一次的智能合約安全問答比賽,即「Secureum RACE」。
- Security Incidents Library:此平台收集所有造成損失超過 10 萬美元的攻擊事件,詳細記錄損失金額、受影響的鏈、漏洞、根本原因以及概念驗證(PoC)。
- Rekt:被譽為 DeFi 新聞界的暗網,Rekt 對生態系統中的漏洞利用、駭客攻擊和詐騙事件提供深入的分析。
- RugDoc:一個評估項目風險的 DeFi 安全與教育社群。它還擁有一個名為 RugDocWiKi 的平台,介紹 DeFi 生態系統與技術。
- DeFiHackLabs:一個擁有超過 2,600 名成員、近 200 名白帽駭客的 Web3 安全社群,旨在銜接 Web2 與 Web3 安全專業知識。
- Solodit:一個彙整來自各家 Web3 審計公司歷史報告的平台,為智能合約審計人員提供寶貴的資源。
- Ethernaut:一款基於 Web3/Solidity 的遊戲,玩家需識別以太坊合約中的漏洞,類似於 CTF 挑戰賽。
結論
安全性仍然是 DeFi 生態系統中一個持續存在且嚴峻的威脅,每年造成數十億美元的損失。目前,大多數安全措施都是在發布前階段執行。然而,安全領域並沒有萬能解方,不同的方法應貫穿 DeFi 協議的整個生命週期。我們期待業界能夠採用發布後安全解決方案,進行監控,更重要的是能夠自動封鎖攻擊。我們期待生態系統中能夠建立起以安全為先的文化,全面保障用戶資產的安全。



