DeFi协议引入速率限制：将秒级攻击转为可控事件

在 DeFi 世界，漏洞本身并不可怕，真正可怕的是攻击在几分钟内就能完成。如果所有价值能在几秒内被抽干，再先进的抵押检查和总量上限也无济于事。今天，我们聊聊速率限制（Rate Limit）这个被多数协议忽视，却能决定生死的关键防御手段。

Kelp DAO 损失了 285M。不同的协议，不同的失效模式，却是相同的结果：在任何人来得及响应之前，损失就已经发生了。

如果没有速率限制，Kelp 几分钟内就被清空；但假如施加了每小时 500万美元的出借上限，同样的攻击需要将近 58 小时才能完成。五分钟是灾难，两天只是一次事件。

静态风险 vs. 动态风险

大多数借贷协议只用一条规则：只要总借款低于上限，并且抵押检查通过，交易就被允许。这在平静的市场中有效，但 DeFi 从不平静。

预言机会出故障，代币供应会被操纵，记账 bug 会让用户提走比存款多 10 倍的资产。短短几分钟内，协议相信了一个谎言——把坏的抵押品当成有效的，或者把虚假价值当作真实资产。

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

从瞬间崩溃到受控失败

速率限制改变了失败的形态。协议不再只检查一笔借款是否落在总上限内，而是同时检查最近一个时间窗口内的总借款额度。例如，限制最近一小时内的总借款必须保持在某个阈值以下。

没有速率限制时，一次攻击会立刻把所有资产抽干；有了速率限制，同样的攻击会被限流——攻击不会被直接阻止，但会被显著放慢。

这种放慢至关重要。它给监控系统时间检测异常，给多签钱包时间暂停，给用户时间反应。DeFi 很少因为问题本身而失败，它失败，是因为问题展开得太快，快到没人来得及反应。

从 Token Bucket 开始

想象一个会随时间补充的借款容量储水池。每次借款都会消耗池中的 token，当池子水位过低时，新的借款会 revert，直到容量回充到足够为止。

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

这并非纸上谈兵。Chainlink 的 CCIP（文档链接）已经在跨链转账中使用了 token-bucket 风格的限制器。桥接有，但借贷还没有——至少现在还没有。

分桶窗口（bucketed window）也能工作。想象一条传送带，借款会穿过固定的时间切片，随着最旧区间的用量消失，容量会恢复。这是一个稳妥的替代方案，但 token bucket 通常是更顺滑的起点。

在线试试这两种方案：https://defi-rate-limits.pages.dev

为什么这在实践中很重要

观察一次攻击实际展开的方式，速率限制的效果就很清晰了。

假设一个协议存在 2.5亿美元漏洞。没有速率限制，这笔价值几乎能被瞬间抽走；加上每小时 100万美元的出借上限，同样的攻击需要超过 10 天才能完全展开。漏洞本身没变，潜在总损失没变，改变的只有速度。而这一项差异，可能决定协议能否存活。

存活的数学

速率限制对攻击动态的影响是惊人的。考虑一个存在 2.5亿美元漏洞的协议：

速率限制	耗尽时间	结果
无限制	秒级	彻底崩溃
每小时 2500万	10 小时	危急但可控
每小时 500万	50 小时	干预时间充裕
每小时 100万	~10.4 天	轻微事件

随着速率限制收紧，严重性持续下降——同样的攻击变成了一个可控的事件。

随之而来的权衡

速率限制不是免费的，它会引入摩擦。

从经济上看，限制吞吐量可能降低资金效率。如果限额设得太低，协议运行可能低于潜在利用率。大额仓位用户感到受限后，可能会转向别处。当容量变得稀缺时，用户可能会激烈竞争交易，推高费用和借款成本。

最大的体验问题是不确定性。一笔通常会成功的交易，可能因为其他人消耗了容量而失败。如果没有清晰的反馈，这很容易被误认为是一个 bug。

体验问题可以通过透明性来解决：直接在界面上显示剩余容量以及补充时间。当用户能够围绕这个约束做计划时，摩擦就会变得可控。

不可妥协的设计规则

要让速率限制生效，三条原则是绝对的：

1. 提现绝不应受到限制。阻止用户在压力期间访问资金，会比任何攻击更快地摧毁信任。
2. 清算人必须被豁免。他们维持系统健康，阻止他们带来的风险比减少的风险更多。
3. 控制速率限制的机制必须独立保护。如果攻击者能在攻击期间禁用限流，这种保护就毫无意义。

重新思考 DeFi 中的风险

DeFi 风险有多个维度。一个是可能损失的总金额——caps 和抵押规则控制这一点。另一个是损失发生的速度——速率限制控制这一点。大多数协议只关注前者，这让它们在平静市场中安全，却在压力下脆弱。

速率限制不会消除失败，它会重塑失败：把灾难性事件变成可管理的事件，给协议一个响应的机会，而不是直接崩溃。

在云栈社区的 后端&架构 板块中，关于系统设计的高可用性讨论也印证了这个思路：控制价值被提取的速度，而不只是控制总量。

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

原文链接： x.com/saurabh_evm/status...