DeFi 需要速率限制来防止秒级攻击

在过去几周里，DeFi 两次上了同样的一课。Kelp DAO 损失了 $292M。Drift 损失了 $285M。不同的协议，不同的失效模式，却是相同的结果：在任何人来得及响应之前，损失就已经发生了。

没有 rate limit：Kelp 在几分钟内就被利用，Drift 也在几分钟内被利用。有 $5M/hr 限制：Kelp 需要 58 小时，Drift 需要 57 小时。

五分钟是死刑。两天是一次 incident。

静态风险 vs. 动态风险

大多数 lending protocol 使用一条规则：如果总借款保持在上限之下，并且 collateral 检查通过，交易就被允许。

这在平静的市场中有效。但 DeFi 从不平静。

Oracle 会出故障。Token supply 会被操纵。Accounting bug 会让用户提走比他们存入金额多 10 倍的资产。短短几分钟内，protocol 相信了一个谎言。它把坏的 collateral 当成有效的，或者把虚假的价值当成真实的。

在这种情况下，bug 不是唯一的杀手。速度才是。攻击者只需要一个 block，而不是一个小时。

从瞬间崩溃到受控失败

rate limit 改变了失败的形态。

protocol 不再只是检查一笔 borrow 是否落在总上限之内，还会检查最近一个时间窗口内已经借出了多少。比如，最近一小时内的总借款必须保持在某个阈值以下。

这一项检查会改变压力下的行为。

没有 rate limit 时，一次 exploit 会立刻把一切抽干。有了 rate limit，同样的 exploit 会被限流。攻击者不会被直接阻止，但会被放慢。

而这种放慢至关重要。它给 monitoring system 时间检测异常，给 multisig 时间暂停，也给用户时间反应。DeFi 很少因为问题本身而失败。它失败，是因为问题展开得太快，快到没人来得及响应。

从 Token Bucket 开始

把它想象成一个会随着时间补充的借款容量储水池。每次 borrow 都会消耗其中一部分。当储水池水位过低时，新的 borrow 会 revert，直到容量恢复到足够为止。

The Drip Reservoir

它是一个很好的默认方案，因为补充是连续的，较大的 borrow 在安静期后仍然可行，而且没有 reset 边界可供攻击者钻空子。它在链上实现起来也很便宜。

这不是理论。Chainlink 的 CCIP（https://docs.chain.link/ccip/api-reference/evm/v1.6.1/rate-limiter）已经在跨链转账中使用了 token-bucket 风格的 rate limiter。bridge 已经有了，lending 还没有，至少现在还没有。

bucketed window 也可以工作。把这个模型想象成一条传送带：borrow 会穿过固定的时间切片，而随着最旧的用量消失，容量会恢复。这是一个稳妥的替代方案，但 token bucket 通常是更顺滑的起点。

The Conveyor Belt

在线同时试试两者：https://defi-rate-limits.pages.dev

为什么这在实践中很重要

当你观察 exploit 实际是如何展开时，rate limit 的影响就会变得清晰。

想象一个存在 $250M 漏洞的 protocol。没有 rate limit，这笔价值几乎可以被瞬间抽走。加上每小时可借出的上限后，同样的 exploit 可能需要数小时甚至数天才能完全展开。

漏洞没有改变。潜在总损失没有改变。改变的只有速度。

而这一个差异，就可能决定 protocol 能否存活。

存活的数学

rate limit 对 exploit 动态的影响是惊人的。考虑一个存在 $250M exploit 漏洞的 protocol：

随着 rate limit 收紧，严重性下降——同样的 exploit 变成了可控事件。

随之而来的权衡

rate limit 不是免费的。它会引入 friction。

从经济上看，限制吞吐量可能会降低 capital efficiency。如果限额设得太低，protocol 的运行可能低于潜在利用率。若大额仓位的用户感到受限，他们可能会转向别处。

当容量变得稀缺时，用户可能会激烈竞争交易，推高费用和 borrowing cost。

最大的 UX 问题是不可预测性。一笔通常会成功的交易，可能会因为其他人消耗了容量而失败。如果没有清晰的反馈，这会让人感觉像是一个 bug。

UX 问题可以通过透明性来解决。显示剩余容量以及它何时补充。当用户能够围绕这个约束做计划时，friction 就会变得可控。

不可妥协的设计规则

要让 rate limiting 生效，有三条原则是绝对的。

withdrawals 绝不应该被限制。阻止用户在压力期间访问资金，会比任何 exploit 更快地摧毁信任。

liquidator 必须被豁免。他们维持系统健康。阻止他们带来的风险比减少的风险更多。

控制 rate limit 的机制必须被独立保护。如果攻击者能在 exploit 期间禁用限流，那么这种保护就毫无用处。

重新思考 DeFi 中的风险

DeFi 风险有多个维度。

一个是可能损失的总金额。caps 和 collateral 规则控制这一点。

另一个是这笔损失发生的速度。rate limit 控制这一点。

大多数 protocol 只关注前者。这让它们在平静市场中安全，却在压力下脆弱。

rate limit 并不会消除失败。它会重塑失败。它把灾难性事件变成可管理事件。它给 protocol 一个响应的机会，而不是直接崩溃。

在一个单次 incident 就可能终结多年工作的领域里，这种转变不是小幅改进。它是存活与消失之间的差别。

这只是一个角度，可能还有许多未被探索的方式可以处理这个问题，但核心思想很简单：控制价值被提取的速度，而不只是控制总量。

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