构建防御性DeFi未来

威胁已经转移

过去一年里，最大的 DeFi 攻击事件并不是 smart-contract bug，而是凭证被攻破。

我研究了自 2025 年初以来损失达到 \$1M 或以上的 DeFi 安全事件：共有 48 起，总损失约 14 亿美元。单笔损失最大的几起，包括 Drift、Resolv、Infini 和 Step Finance，全部都是凭证或签名流程被攻破。合约利用（例如 Cetus、GMX V1、Cork、Abracadabra）和 oracle 问题（例如 Aave wstETH、KiloEX、YieldBlox）仍然在发生，但最大的资金损失已经不再来自这两类。审计、形式化验证、来自成熟提供方的去中心化价格源、时间加权定价、多源聚合以及链上偏差检查，已经实质性地压缩了这两类攻击面。（KelpDAO 因跨链 infra 和配置导致的 \$292M 损失，值得单独讨论。）

Drift 就是一个鲜明的例子。2026 年 4 月 1 日，Drift 成员被社会工程诱导签署了 Solana durable-nonce 交易，攻击者随后重放这些交易，将一个伪造的 collateral token 加入白名单，并在大约十二分钟内卷走了 \$286M。没有合约 bug。没有新颖的 exploit。admin 签名者被攻破，而合约赋予了这些签名者足够的权限来完成后续操作。

这一点很重要，因为如今大多数 DeFi 合约仍然建立在“admin multisig 是可信的”这一假设之上。升级、暂停、参数变更，以及在很多情况下对金库的直接访问，都被放在这个 multisig 后面。多年来，这一直是一个合理的假设。但到了 2025 年末并进入 2026 年，它已悄然不再成立。

更难面对的事实是，很多团队一旦部署了 multisig 就觉得安全了。有些甚至没有为 admin 操作设置 timelock，因此一旦某个签名者被攻破，操作就会立即生效，而不是先进入排队流程，让社区有时间响应。资金流动没有限速。对于签名密钥如何持有、存储或使用，也缺乏最基本的规范。Multisig 和 timelock 已经变成了安全标准，而不只是安全体系中的一层。我们需要超越 multisig 和 timelock，纳入一种更具防御性的思维方式，来指导我们如何构建和运行 DeFi。

对 Defensive DeFi 的需求

Defensive DeFi 建立在两大支柱之上：系统设计和 OpSec。两者同样关键。继 Resolv 和 Drift 等近期事件之后，OpSec 理应已经获得了大量关注：密钥如何持有、由谁持有、签名环境如何隔离和加固。相比之下，我更想在这里聚焦于另一根支柱：合约本身应如何设计，使得一个被攻破的签名者——而我们现在应该假设这只是“何时发生”而不是“会不会发生”的问题——无法造成太大损失。如果合约赋予 admin 很大的权限，那么即使一个协议在 OpSec 上做得很好，也仍然可能暴露在极大的风险之中。设计和 OpSec 同样是支撑系统的承重部分；本文讨论的是长期被低估的那一半。

并非所有 DeFi 的构建方式都一样。在一些协议中（例如 vaults、lending markets、RWA），admin 拥有比其他协议（例如纯 AMM）更多的权力。尽管本文中的原则可以适用于所有协议，但它们更适用于那些允许 admin 影响资金流动，并对 collateral、mint、funding routes 和 caps 等进行配置变更的协议。

思维方式

我想提出的、而且我真诚希望听到反对意见的操作假设是：

设计时要假设任何 multisig 都会被攻破。包括你自己的。

这听起来可能有些激进，但我越来越相信，制衡是我们这个行业里最被低估的安全护栏之一。我们推崇速度、无许可可组合性以及资本效率。相比之下，我们一直不太重视那些看似枯燥、却能阻止被攻破的签名者造成严重损害的结构性选择。

这并不是反对 admin 功能，而是主张限制 admin 能做的事情，让签名者某一天遭遇问题时，不至于变成用户的灾难日。

问任何协议的四个问题

与其抽象地罗列原则，我认为把它们转化成任何用户、allocator 或 curator 在接触任何协议时都可以提出的问题，会更有用。如果你现在正在决定哪些协议继续持有、哪些要撤出，下面这四个问题是我会先问的。

1. 如果 admin multisig 明天被攻破，用户资金会如何被转移？

这是最重要的问题。如果一个协议根本不允许 admin 触碰用户资金，那就是 holy grail。如果一个被攻破的签名者可以在一笔交易中卷走 treasury，那就是灾难性的。合约只是在用一层很薄的外壳保护用户资金。额外的护栏（也就是接下来的问题）限制了能移动多少以及能移动到哪里；这些护栏越完善，设计就越具有防御性。这里值得点名一个陷阱：即使当前合约阻止了被攻破的签名者直接转移资金，如果 admin multisig 也能升级合约，它仍然可以部署一个不再阻止资金转移的新合约。

移动资金的权限和升级系统的权限，不应由同一批签名者掌握。

2. 资金移动是否被限制在由合约强制执行的预配置目的地？

这就是白名单 contract-to-contract calls（在 EVM 上是 internal calls，在 Solana 上是 cross-program invocation）发挥作用的地方。一个设计良好的协议中，大多数资金流动应发生在合约中硬编码的白名单目的地之间，而不是通过一个私钥签署任意转账。admin 签署的转账应尽量减少，并设定上限（见下文）。

3. 链上是否强制执行硬上限和速率限制？

单笔上限。每日上限。累计上限。应由合约强制执行，而不是依赖链下 policy，尤其是对于外部签名的转账。Rate limiting 是 DeFi 中最被低估的策略之一：悄然有效、很少炫目，而且常常是糟糕的一天与灾难性的一天之间的最后一道防线。即使前面的每一道控制都失效了，上限仍能把最坏结果约束在协议能够承受的范围内。

4. mint 是否在链上由实时 collateral 检查保护？

每一个被 mint 出来的单位，都必须在 mint 时由合约本身依据一个设计良好的 oracle 系统进行检查，并确认存在 backing。对于任何 admin 可以在没有实时 backing 检查的情况下 mint 的协议，都应保持警惕。如果你有一个没有防护的 mint，灾难只是时间问题，而不是会不会发生的问题。最近几起重大损失中，有几起都涉及没有被完全保护的 mint 路径，例如 Resolv。

总体而言，我希望我们的行业首先尽量减少 admin 直接接触用户资金的必要性。对于确实需要由 admin 发起的资金移动，应使用 contract-to-contract calls，将资金流动限制在由合约强制执行的预定义目的地之间。把外部签名的转账留作最后手段，而在它们不可避免时，把 caps 设得更紧。对于一般的 admin 功能，包括升级和 mint 路径，timelock 都应成为默认配置。

OpSec 支柱

上面的四个问题关注的是系统设计。OpSec 是 Defensive DeFi 的第二根支柱，也值得单独讨论：将最小权限原则扩展到组织设计、把任何单一个人或设备被攻破后的影响范围降到最低、隔离的签名环境，以及对特权基础设施施加分层的身份和网络绑定控制，从而确保攻破任何单一设备、凭证或 endpoint，都不足以触及真正关键的密钥。正如 Drift 清楚表明的那样，它还必须包括检测和经过演练的响应机制，这样像 timelock 被悄悄移除这样的可疑治理变更，才能在最终生效前被发现并受到阻止。我会在后文单独回到 OpSec。就这篇文章而言，重点仍然放在系统设计上。

让我们一起把门槛抬高

Multisig 和 timelock 是必要的，但还不够。我们需要转向一个新的范式：设计时要假设你的 multisig 凭证会被攻破。如果我们都遵循这一原则，攻击发生的概率和损失规模都将变得更加可控。

每个严肃的项目大概率都能对这四个问题中的至少一个给出扎实答案，但几乎没有哪个能有把握地回答全部四个。我们，包括安全专家在内，都在学习新的攻击向量，并摸索如何防范它们。攻击者并没有停下脚步：得益于 AI，他们正变得更强也更快。DeFi 生态系统高度互联，我们谁都无法免疫于他人的失误。我们需要一起防御攻击者。这就是为什么我把这些内容公开出来讨论，而不是私下打磨后再发布。

如果这些观点中的任何一点引起了你的共鸣，如果你想反驳，或者你看到了我遗漏的关键角度，请分享并参与讨论。让我们一起构建 Defensive DeFi。

• 原文链接： x.com/DrPayFi/status/204...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～