十億美元的教訓:DeFi 安全重心正從程式碼轉向營運治理
內容摘要與讀取導數>
近一年 DeFi 近一年 DeFi 近一年 億美元損失,真正的大額損失已不再主要來自合約程式碼漏洞,而是來自權限管理、簽名流程、社工攻擊、第三方基礎設施與跨鏈可組合性風險。 借鑒 TradFi 的營運韌性、三道防線、緊急凍結、風險數據治理和資產准入審查,配合 AI 輔助安全分析,才能在保持開放與可組合的同時提升用戶資金安全。
我們本來不必損失的十億美元
在過去十二個月裡,近 10 億美元因 DeFi 事故而損失,但其中大部分本可以避免。
先從最近的一次 exploit 說起:4 月 18 日 Kelp DAO 的 2.92 億美元 exploit。
AAVE 下跌了 15%。 Aave 在所有部署中凍結了 rsETH 市場,隨後又出於預防目的凍結了 WETH 借貸。 Aave 自己的合約從未被 exploit,但在幾個小時內,Aave 的 WETH 市場利用率就達到了 100%。 那些從未碰過 rsETH 的 WETH 供應方,突然無法提現。
隨後便是常見的 crypto twitter 觀點:Bridge 壞了。 DeFi 壞了。 這就是為什麼真正的資金不會進來。
我認為這些說法都沒有抓到重點。
這 10 億美元中的大部分,都是因為那些早已有人討論過修復方案的攻擊向量而損失的。 最大的損失,主要由特權存取、簽名工作流程、社工和第三方基礎設施驅動,而不是孤立的 smart contract bug。 然而,這些修復方案並不在 DeFi 文件裡,而是在銀行風控手冊、工程韌性研究,以及 TradFi 幾十年來不斷打磨的營運 playbook 中。
Kelp 就是最清晰的例子。
一個 verifier。 一個故障點。
Kelp exploit 並不是 smart contract bug。 根本原因在於 @KelpDAO 在 LayerZero bridge 上選擇了 1-of-1 的 decentralised validator network (DVN) 設定。 據稱與北韓網路犯罪集團 Lazarus Group 有關的攻擊者,並沒有攻破 DVN 本身。 首先,他們識別出 LayerZero 的 DVN 依賴哪些 RPC providers。 然後,他們攻破其中兩個,讓其返回偽造數據。 接著,他們對剩餘的 providers 發動 DDoS,迫使系統 failover 到已被攻破的那些。 DVN 在善意前提下簽署了一條偽造的跨鏈訊息——由於沒有其他 verifier 來核驗結果,這個簽名就足夠了。
一個 verifier。 一個故障點。
116,500 rsETH 從以太坊上 LayerZero 的 OFT Adapter(它管理跨多個區塊鏈的 token)中被釋放給攻擊者,導致十六條 L2 上的 rsETH OFTs 失去 backing。 攻擊者將以太坊側的 rsETH 作為 collateral 存入 Aave、Compound 和 Euler,並以此借出了 2.36 億美元的 WETH,直到有人發現。 現在,所有在某條 L2 上持有 rsETH 的人,持有的都是對一個已被掏空的 lockbox 的索賠權。
這明確的風險面,在十二天前就已標示出來。
4 月 6 日,任職於 @get_truenorth 的工程師 @liliangjya5 發布了一個開源 Claude Code skill,其中點名了 DVN 配置不透明的問題,將 16 條鏈上的單點故障標記為最大的風險向量,並將該對照設定為 Ron 20 和 Ron 20 和 222 年的 202222 年 232222222 2222222229229899999點故障了。 commit 時間戳記是公開的——任何人都能看到。
[https://x.com/liliangjya5/status/2045751262222885193]
Kelp 從未公開他們的 DVN threshold。 LayerZero 在整合 checklist 中明確建議使用 multi-DVN 設定。 Kelp 仍然選擇了 1-of-1。 沒人強迫他們公佈,沒人強迫他們修改。
十二天后,2.92 億美元沒了。
過去十二個月並不能否定 DeFi
Kelp exploit 是最大的,但不是唯一的。
-
就在兩週前,也就是 4 月 1 日,Drift 在一場持續數月的社工攻擊後損失了 2.85 億美元。 攻擊者利用 Solana 的 durable nonces 獲取了有效的管理員簽名,將一個毫無價值的 token 白名單化為 collateral,並據此掏空了真實資產。 至少還有 20 個其他 protocol 報告了受影響。 Drift 自己在事故後的重構方案中,也加入了專用 signer 裝置、對管理員操作的 timelock,以及重建的治理 multisig。
-
3 月 22 日,Resolv 透過 offchain 基礎設施遭到攻擊。 攻擊者從第三方專案的入侵點橫向進入 Resolv 的 GitHub 和雲端環境,取得了 minting 流程的簽章權限,鑄造了 8,000 萬枚無 backing 的 USR,並盜走了 2,500 萬美元的 ETH。 smart contract 沒有失效,脆弱環節是特權 key 以及其周圍的運營棧。
-
3 月 10 日,Aave 自身的 risk tooling 在兩個配對 oracle 參數之間出現配置不匹配後,觸發了大約 2600 萬美元的清算,涉及 34 個帳戶,該不匹配使 wstETH 價格下跌了 2.85%。 在這個案例中,沒有惡意 actor,也沒有 exploit。 這次損失源於一次出於善意的配置更新,但它並沒有按 hostile 場景來進行測試。
-
就在 2026 年開始之前,我們還經歷了 Cetus 在 Sui 上損失 2.23 億美元,Cork 在多次審計後因 wstETH 損失 1200 萬美元,Balancer DNS 在 11 月損失超過 1.2 億美元,以及 Aerodrome 而損失超過 100 萬美元。 再次強調,合約本身並未受損。 一個 phishing 頁面完成了最後一擊。

合計起來,這幾乎就是 10 億美元的損失。 每一次事故的直接原因都不同,但一種模式正在形成。
這些 exploit 已經轉移到 offchain
smart contract 風險並沒有消失-Cetus、Cork 和 Balancer 都是真實的 onchain 邏輯失敗。 任何仍然認為 invariant testing、adversarial simulation 和 formal methods 是可選項的 protocol,都只差一次 release 就會學到教訓。 但這已經不再是故事的主體了。
放眼整個 crypto,Chainalysis 估計 2025 年有超過 65 億美元被盜,其中僅前三大 hack 就佔了損失的 69%。 如同前面所提到的,最大的損失正在由特權存取、簽署工作流程、社工和第三方基礎設施驅動,而不是孤立的 smart contract bug。

我把這當作三種不同的失敗模式:Code layer、Control plane、Composability。
Code 是 DeFi 實際上最擅長防禦的一層,然而即便如此,它也還沒有被徹底解決。 我們有 fuzzing、static 和 dynamic analysis、formal verification、bug bounty、audits、invariant testing——現在每個嚴肅的團隊都知道該怎麼做這些。
Control plane 是 DeFi 至少落後 TradFi 十年的地方。 簽名設備、key rotation、特權存取審查、CI/CD provenance、DNS hardening、網域註冊商安全。 大多數 protocol 甚至沒有這些 surface 的 inventory,更不用說對它們的控制了。
Composability 雖然是 DeFi 最強大的優勢之一,但也帶來了最新、且最被低估的風險——當一個 lending market 列出某個 wrapped asset 時,它就把 bridge 的 failure mode 變成了自己的 failure mode。 當一個 collateralised debt position 接受一個 liquid staking token 時,它就繼承了發行方的治理延遲。 Aave 沒有寫 Kelp 的任何一行程式碼,但仍然繼承了 Kelp 失敗所造成的損害——這也暴露了它自身的治理問題。
如果一個 protocol 列出了自己無法在壓力下獨立估值、凍結、haircut 或清算的 collateral,那麼它實際上就是把該資產的 tail risk 放進了自己的資產負債表,無論 treasury 是否簽字同意。
TradFi 早已寫好了 playbook
關於變得「更像 TradFi」的 DeFi 爭論,通常會在同一步走偏。 crypto 裡的直覺是,變得更像 TradFi 就意味著更慢、更 custodial、更 permissioned、更監管。
[https://x.com/mert/status/2045875457359220928]
我認為這不對。
雖然 TradFi 當然不算完美,但它想出了一些比 permissioning 有用得多的東西。 它想出瞭如何在 disruption 中運行 critical systems——這些框架已經存在。 它們在數十年的銀行倒閉、交易中斷、網路攻擊和營運事故中接受了壓力測試。
相關範例:
-
NIST Cybersecurity Framework 2.0 將 Govern 提升為與 Identify、Protect、Detect、Respond 和 Recover 並列的核心功能。
-
Basel Committee on Banking Supervision 將 operational resilience 定義為在 disruption 中交付 critical operations 的能力。
-
英國 Financial Conduct Authority 要求 firms 識別重要 business services,設定 impact tolerances,並測試 disruption 是否會突破這些閾值。
-
Institute of Internal Auditors 透過其 Three Lines model 將 management、risk challenge 和 independent assurance 分離開來。
以上皆不需要 TradFi 的資產負債表,也不需要 permission。 所有這些都可以移植到 DeFi 中。 安全的 DeFi 並不意味著賣身變成銀行,而是意味著在保持用戶層 open 和 composable 的同時,在 control layer 中採用銀行級紀律。
當 Lazarus 針對 LayerZero 的 RPC providers 下手時,他們使用的是與攻擊 SWIFT 和企業軟體 supply chain 相同的 playbook。 TradFi 在這個問題上已經有三十年的經驗累積了。 然而,DeFi 彷彿認為自己從 TradFi 的歷史中無可藉鏡。
特權 power 是一種系統重要性 utility
特權 power 必須比普通 protocol 功能更難使用。 任何能夠列出 collateral、移動 reserves、更新 oracle、改動 bridge peer 或更改 liquidation logic 的 key、multisig 或 service account,都是一種具有系統重要性的金融 utility。 最低標準:
-
Hardware wallets
-
防 phishing 認證
-
獨立的 signer 機器
-
交易的 out-of-band 解碼
-
Quorum 分離
-
對所有非緊急操作設定 timelock
-
明確拒絕那些會讓 dormant signatures 未來被武器化的便利功能
Drift 的事故後重構方案,是一個不錯的最低基準。
offchain 堆疊也是 protocol 的一部份。 原始碼管理、CI/CD、雲端 IAM、package registries、domains、DNS、wallet-connect surface 和瀏覽器交付的前端,都處於真實的威脅邊界之內。 工程標準包括最小權限存取、硬體支援的身份、無 secret 部署、帶有 software bill of materials 的可複現構建,以及 dependency pinning。 在邊界層,registrar lock、DNS hardening 和去中心化 mirror front end 可以在事故期間提供連續性。
Aerodrome 的 DNS hijack 提醒我們,邊界比大多數團隊所劃定的要大得多。
每一次變更都應該按 hostile 場景來測試。 跨鏈 verifier 應該檢查 proof,而不是 attestation。 Canonical bridge 會對經過簽署 block headers 的 merkle proof 進行驗證,這是一種加密保證:被攻破的節點可以拒絕提供數據,但不能偽造。 Proof-verification 比 attestation 更強,但基於 proof 的 bridge 仍然繼承了 consensus risk、implementation risk 和 upgrade risk。 問題在於,這種設計排除了哪些失敗,又保留了哪些失敗。
基於 attestation 的 verifier 不具備相同的保證。 它們簽署的是 RPC endpoints 返回的任何內容,這使得這些 endpoints 本身成為 attack surface。 若使用 attestation 是為了速度或鏈相容性,那麼 quorum 代表的是獨立性,而不是數量。 五個讀取同樣被投毒 RPC 的 validator,會把同一個謊言簽五遍。 只有當 quorum 成員擁有真正獨立的資料來源時,安全性才會出現,理想情況下應混合 private 和可信任的 public nodes。 Kelp 是 sophisticated attacker 利用這一缺口的結果。
並非所有 collateral 都值得進入共享資產負債表。 Bridge 資產、liquid restaking token、vault share、synthetic dollars 和 wrapper token 都應被視為 structured products。 它們需要獨立的 onboarding memo,涵蓋廣泛的風險畫像和保守的限額。 在大多數情況下,它們應該進入隔離市場,而不是共享的 core pool。
Aave 早在 2025 年 4 月就因 Kelp 的 over-minting bug 暫停過 rsETH。 rsETH 一年後又回到 shared market,這件事值得更嚴格的審視。
偵測和回應必須以機器速度運作。 當一個 protocol 可以在幾分鐘內被掏空時,僅靠人工介入就是治理表演。 受限自動化才是常態:對管理員操作、mint 和 burn 事件、利用率激增、oracle 脫錨以及 bridge 流量進行異常檢測,再結合 protocol 原生的 rate limit、borrow throttle,以及基於事先約定條件觸發、且事後可由治理審查、作用範圍狹窄的 auto-freeze。
我們需要開始優先保障用戶資金的安全。 像這類自動化偶爾被觸發所帶來的些許不便,遠小於一開始根本沒有這些自動化的代價。
治理必須定義什麼不能失敗
為了幫助團隊倒推安全目標,治理必須定義那些絕對不能失敗的事。 董事會、基金會 council 或 DAO 應明確列出其重要 business services:用戶存款和提款、清算、oracle 更新、治理執行、bridge 進出、前端訪問、事故溝通。
對於每一項,都應設定 impact tolerance,包括最大可容忍的用戶損害、償付能力損失、停機時間和資料不確定性,然後測試這些容忍度在嚴重但合理的場景下是否仍然成立。
這正是銀行業中 operational resilience 的意義,而且可以直接移植到 DeFi。
DeFi 應該採用真正的 Three Lines model:
-
第一線:產品、工程、treasury 和營運對其創造的風險及緩解這些風險的控制措施負責。
-
第二線:獨立的風險與安全職能擁有明確界定的權限,對 listing、參數、升級和交易對手提出挑戰,並減緩或阻止不安全的變更。
-
第三線:獨立 assurance 報告第一線和第二線是否真的在發揮作用。
獨立性,是阻止成長激勵自己給自己批次作業的方法。

Asset onboarding 應該更像信用 underwriting,而不是 business development。 listing memo 應涵蓋流動性與集中度、治理中心化、bridge 路徑與可升級性、贖回機制、circuit breaker、oracle 建構方式以及法律包裝。 如果這些假設中的任何一個被打破,每份 memo 都需要明確的降級程序。
緊急權限應該是狹窄、預先定義範圍並設定 sunset 的。 Cetus 和 Sui recovery vote 展示了這件事的兩個方面——緊急幹預可以挽救數億美元。 它也引出了嚴肅的問題:誰可以覆蓋那些理論上不可阻擋的系統,以及依據是什麼。 答案是在上線之前,而不是在危機中,定義觸發條件、授權 actor、證據標準、最長持續時間、透明度義務以及回歸正常治理的路徑。
每個 protocol 都需要在危機發生前準備好 resolution plan。 Drift 正在事後組成 recovery pool。 Aave 在 oracle misalignment 之後轉向補償用戶。 Resolv 按 1:1 補償了 hack 前持有者。 這些都是合理的回應,但更高的標準是預先授權 waterfall:先是使用者保護,然後是 treasury buffer,再然後是 insurance 或 safety module,接著是 service-provider liability,並為 socialised loss 設定明確閾值。
區分那些認真對待治理的 protocol 和那些沒有認真對待治理的 protocol,有三個問題:誰可以阻止一個不安全的 launch? 誰可以在預定義條件下凍結市場? 當一個 delegated service provider 造成損失時,誰來付錢?
一個無法說出相關人員、觸發條件和責任路徑的 protocol,根本沒有定義好自己的治理,只是在祈禱 exploit 永遠不會發生。
風險資料決定控制措施的成敗
安全的 DeFi 需要一個 live data plane:驅動 protocol 中每一個 freeze、cap 和 liquidation control 的 onchain 與 offchain signals。 control plane 負責行動,data plane 負責告訴 control plane 是否應該行動。
資料標準與資料本身同樣重要。 輸入到 oracle、freeze 和參數變更的數據,需要明確的 freshness window、記錄在案的 provenance、confidence scoring,以及與獨立 feed 的交叉驗證。 當 feed 出現分歧時,fallback 行為必須提前定義,而不是臨時決定。
Aave 為 USDe 提議的 risk-managed oracle,以及其按時間加權的 Slope2 Risk Oracle,都指向了正確方向。 wstETH 事件提醒我們,每個自動化 control loop 都需要防止自身配置錯誤的護欄。
揭露本身就是一種控制。 使用者應該有 public status page、attacker-address watchlist、即時 incident log、快速且事實明確的 initial statement,以及一份 post-mortem,將已確認事實與假設區分開來,精確量化損失,列出已更改的控制措施,並解釋賠付路徑。 Drift 的 recovery update、Resolv 的 post-mortem 和 Aave 的 oracle 說明,實際上都比過去 DeFi 那種發完含糊推文後便沉默的做法要好得多。 業界標準應為一套在需要之前就已演練過的 communication playbook。

風險資料存在的意義,是為了驅動 action。 限流借貸、降低 cap、暫停市場、升級給手動處理、證明某個市場可以安全地繼續開放。 不能輸入到 control、limit 或 assurance process 的 analytics,還配不上 risk infrastructure 這個稱號。
AI 威脅模型已經改變
AI 威脅模型在 2026 年 4 月發生了變化。 Anthropic 的 Claude Mythos Preview 已被證明能夠識別並 exploit 所有主流作業系統和瀏覽器中的 zero-day vulnerabilities。 它發現的漏洞中有超過 99% 仍未公開,因為還沒有人給它們打補丁。 英國、美國和德國的銀行與監管機構已經把 Mythos 級能力視為現實中的 cyber risk。
DeFi protocol 也應該這麼做。
從實際角度看,spear-phishing 更便宜,exploit 開發更快,recon 更自主,而且低訊號邊緣 case 會更早被發現。 防禦響應應為:
-
開發者工作站應像特權 endpoint 一樣被加固
-
程式碼審查應在受控存取下包含 AI 輔助的 adversarial analysis
-
signer workflow 預設應具備防 phishing 能力
-
異常偵測與受限 auto-response 應假設攻擊者的迭代速度遠快於任何人工團隊
Kelp 的故事其實是這件事較為樂觀的版本。 威脅 protocol 的同一種 AI 能力,也可以防禦 protocol。 在 Claude Code 上運行的開源審計工具,在駭客攻擊前十二天標記出了 Kelp 的精確風險面。 這個工具並不完美:它將風險評為 medium,而實際上應該是 critical;它無法在沒有 onchain verification 的情況下穿透配置層;而且它還遺漏了這樣一點:DVN 配置其實可以透過 LayerZero 的 EndpointV2 contracts 在鏈上查詢。
但它問出了其他人都沒有提出的正確問題。
這是接下來應當採用的模型。 AI 作為獨立的安全層,任何 LP、任何 protocol、任何 auditor 都可以在資金移動之搶跑它。
安全的 DeFi 並不意味著緩慢的 DeFi
Kelp 事件之後的共識觀點是,DeFi 有安全問題。 我認為這種 framing 本身就是錯的。
DeFi 有的是 control plane 問題、composability 定價問題與治理紀律問題。 這三者都有已知的解決方案。 其中大多數在三十年前的銀行風險手冊裡就寫好了。 橫亙在 DeFi 和用戶安全大幅提升之間的唯一障礙,是創辦人是否會把它們落實。
安全的 DeFi 並不意味著緩慢的 DeFi。 slow 和 safe 是不同的屬性。 面向使用者的 open access、composability 和 24/7 全球結算;control layer 中的銀行級紀律、獨立 challenge、機器速度控制和持續 assurance。 兩者可以同時成立。
工具已經存在。 playbook 已經存在。 想要安全 DeFi 的資本也已經存在。
DeFi 才剛開始。 讓我們確保十年後它仍然存在。
登入回覆
登入分享您的看法評論
相關文章
|Square
下載BTCC APP,您的加密之旅從這啟程
立即行動 掃描 加入我們的 100M+ 用戶行列