我们如何在不到一秒的时间内检测到 DeFi 漏洞

Quicknode

2026年4月21日 — 阅读时间7分钟

分享

添加为首选来源

作者：Arseniy Reutov，Decurity 首席技术官兼联合创始人 发布于Quicknode 博客

我花了十多年时间构建攻击检测系统；起初是在Web2领域，从事流量分析和Web应用防火墙（WAF）相关工作；随后转战Web3领域，在那里，同样的攻击问题以更快的速度上演，且涉及的资金规模更大。我于2022年联合创立了Decurity。我们对DeFi协议进行审计，并开发用于监控其生产环境的工具。 Defimon 正是这一监控环节的核心：作为一套实时漏洞利用检测系统，它赢得了 DeFi 实际运行的各条链上协议团队、安全公司及风险管理者的信赖。它能在黑客攻击登上新闻头条之前就发出警报——否则便算未能尽职。构建这样一套能够以如此高速运行、覆盖如此多条链的系统，结果证明这更是一个基础设施难题，而非单纯的安全问题。这就是我们在构建过程中所学到的经验。

为什么检测速度是一种安全基本要素

在去中心化金融（DeFi）领域，一个协议可能在单次原子交易中就被清空。然而，从漏洞攻击的最初迹象出现到协议被彻底清空之间，往往存在一个时间窗口。Balancer事件、Yearn黑客攻击事件，在每起事件中，问题并不在于是否有人在监控，而在于他们是否及时察觉了这些最初迹象并做出了反应。

要使自动化事件响应发挥作用，警报必须及时送达，以便采取相应措施：暂停合约、通知多签名持有者、转移资金。区块处理延迟两秒听起来似乎微不足道，但在协议层面，这却意味着是发出预警还是事后追查的区别。

检测速度并非一项功能，而是产品本身。Detection speed is not a feature. It is the product.

民意调查的问题

在开始构建 Defimon 时，我们采用标准方式提取链上数据：通过 RPC 进行轮询，反复向区块链查询最新的区块、交易、日志和追踪记录。

起初还挺管用，后来就不行了。

由于需要监控数百万个钱包地址和合约交互，轮询机制带来了两个我们无法通过工程手段解决的问题。

延迟。每个轮询周期会增加大约两秒的阻塞延迟。对于一款检测时机直接决定协议equipe 能否及时收到警告的产品而言，两秒的延迟是一个结构性问题，而非性能调优问题。

可扩展性。我们监控的地址观察列表不断扩大。我们将区块链数据推送到运行在 AWS 上的 Apache Flink SQL 管道中，并将动态地址列表存储在内存中。随着监控范围的扩大，内存不足错误变得司空见惯。该系统无法满足我们监控需求所需的可扩展性。而且，对 SQL 管道的任何更改都需要完全重启 Apache Flink，每次停机时间长达 20 分钟。

最糟糕的时候，我们每月要花费4,000美元在AWS上，仅为了支持三个开发链，还需要三到四名工程师来维持管道的正常运行。我们的equipe 在检测逻辑方面拥有专业优势，但我们却把资源花在了基础设施上。

我们为何转向“Push Data”

核心变化在于用基于Quicknode 的推送模型取代了轮询机制Streams 。

不再需要向区块链请求数据，而是当区块上链的瞬间，数据便会自动推送。区块延迟从大约两秒降至0.5秒以内。Telegram通知现在能在检测到事件后一秒内触发。这绝非渐进式的改进，而是一款完全不同类别的产品。

但延迟只是问题的一部分。更大的收获在于上游过滤。

我们原有的 Apache Flink 管道基于 SQL 运行。检测逻辑包含在一个由众多子查询组装而成的大型查询中，虽然最初编写时采用声明式语法，但随着规模扩大，维护起来变得十分困难。当我们迁移到Streams 时，也将检测逻辑从 SQL 迁移到了 JavaScript，使过滤器能够直接在区块链节点内部运行。这一变更为我们带来了三点好处：

灵活性。检测逻辑的任何变更都能在不造成停机的情况下立即生效。我们基于以往的 DeFi 安全事件构建了一套完整的测试套件，用于验证在进行修改后，我们的逻辑仍能保持完整。Quicknode 的 JS 过滤器测试工具使我们能够在部署前运行整套测试。

经济性。我们不再处理所有的区块链数据。Streams 在节点层面进行过滤，仅传输我们所需的数据。带宽消耗大幅降低。

速度。新区块一出现，数据就会立即推送。无需轮询间隔，无往返延迟。

检测架构

以下是我们目前的工作流程。

当一个区块在我们监控的八条链中的任意一条上落地时，Streams 会通过JavaScript在节点层面对其进行过滤，仅将相关数据传递给下游。Quicknode Streams 中内置的键值存储库保存着我们的监控列表，其中包含数百万个被追踪的地址，JS过滤器可直接引用这些地址。漏洞检测逻辑会对上游服务中的过滤后数据进行分析。若发现匹配的模式，则触发警报。

整个过程在不到一秒内完成。

一个具体例子：通过使用Streams 处理交易追踪数据，我们可以检测到针对未初始化的代理智能合约的后门攻击企图。这种攻击模式被我们称为CPIMP（代理中间的隐蔽代理），它发生在代理已被部署，但未在同一笔交易中以原子方式初始化时。这一漏洞使恶意攻击者能够接管代理，并设置一个恶意实现合约。 要发现这种攻击，需要尽早且快速地查看交易追踪数据。Streams 使这成为可能。

无需运维团队即可扩展至八条链equipe

我们最初在三条链上启动了Defimon。目前，我们监控的链有八条：Ethereum 、BNB Smart Chain 、Arbitrum 、Base 、Polygon 、Avalanche 、Optimism 以及HyperEVM。

在旧的架构下，增加一条链意味着需要新的基础设施、新的服务器、新的处理流程，以及更多的人手。每次新增内容都会与检测工作直接争夺工程师的时间。

在Streams 中，添加一条链只需进行配置更改。集成HyperEVM耗时不到一天。我们调整了一些常量和相关地址，这便完成了大部分工作。

如今，整个管道仅由一名工程师负责运行。其他人都专注于检测逻辑。在旧的架构下，光是维持基础设施的运行就需要三到四个人。

警报触发后会发生什么

Defimon 的订阅用户不仅仅是在关注漏洞利用。他们正在基于我们的警报构建自动化事件响应系统。警报越及时，采取行动的时间就越充裕。

一位对冲基金客户管理着一个九位数的DeFi头寸，该客户通过WebSockets与我们的系统对接，一旦我们检测到针对其配置协议的攻击初现端倪，系统便会立即自动平仓。当发现正在发生的事件时，个人投资者和交易员会利用我们的警报来调整头寸。

不过，最重要的应用场景还是积极的“白帽”干预。我们运行着一个“白帽”机器人，迄今已累计挽回超过200万美元。最近，它为一位因误操作而错误配置了代币权限的用户挽回了51.2万美元。我们行动迅速，在恶意攻击者察觉之前就采取了措施。正是底层处理流程的高速运行，才使得此次干预成为可能。

结束

每个 DeFi 协议都应实时掌握其智能合约的运行状况。在人工智能正加速推动攻击数量激增且手段日益复杂的时代，及时发现攻击的早期迹象已非可有可无，而是基本要求。

Defimon 的职责是及时触发警报，以便团队有足够的时间采取行动。数据管道要么是实现这一目标的关键，要么是阻碍这一目标的障碍。

如果你的equipe 仍处于轮询模式，问题就不再是延迟是否重要，而是何时会成为问题。从源代码重新编译确实令人头疼。但对一种本质上就很慢的架构进行打补丁，绝非实现亚秒级检测的途径。对我们而言，转向推送模式并非出于技术偏好，而是让产品真正正常运行的唯一途径。

阿尔塞尼·雷乌托夫（Arseniy Reutov）是Decurity的首席技术官兼联合创始人，Decurity是一家Web3安全公司，深受1inch、Gearbox和Arbitrum 基金会信赖。Defimon是Decurity的实时漏洞检测平台，为3,500多名订阅用户监控八条EVM链。