十亿美元的教训：DeFi 安全重心正从代码转向运营治理

By: rootdata|2026/05/04 12:12:08

原文编译：登链社区

内容摘要与导读：

近一年 DeFi 近 10 亿美元损失，真正的大额损失已不再主要来自合约代码漏洞，而是来自权限管理、签名流程、社工攻击、第三方基础设施与跨链可组合性风险。借鉴 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 条链上的单点故障标记为最大的风险向量，并将该设置与 2022 年的 Ronin 和 Harmony bridge exploit 进行了对照。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 流程的签名权限，铸造了 8000 万枚无 backing 的 USR，并盗走了 2500 万美元的 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 在 11 月损失超过 1.2 亿美元，以及 Aerodrome 不是因为 smart contract exploit，而是因为其域名注册商遭遇 DNS hijack 而损失超过 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------这些框架已经存在。它们在数十年的银行倒闭、交易中断、网络攻击和运营事故中接受了压力测试。

特权 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 才刚刚开始。让我们确保十年后它仍然存在。