Defimon：基于Streams实时 DeFi 安全解决方案

传统的流式数据管道难以适应链上监控

Defimon 实时追踪数百万个钱包地址和合约交互。其最初的架构是在 AWS 上运行的 Apache Flink SQL 管道，该架构将这份监控列表保存在内存中。随着监控范围的扩大，内存不足错误促使他们开始寻找替代方案。该系统无法随着需要监控的范围扩大而进行扩展。

3家连锁店每月4,000美元，由4人团队负责运营

在 AWS 上，仅维持三个网络的基础设施成本每月就高达约 4,000 美元，且需要三到四名工程师：手动提取 RPC 数据、管理 SQL 模式、调试管道故障。该团队的专业领域在于检测逻辑，却不得不将精力耗费在基础设施的维护工作上。

导致告警质量下降的区块延迟

手动 RPC 轮询导致每个区块的延迟约为两秒。对于一款检测时机直接决定协议团队能否及时收到预警的产品而言，这便是一个结构性问题。

Defimon 用Quicknode Streams 取代了其自主管理的管道。迁移过程near完成的。现有的检测逻辑得以保留，团队无需从头重建，便迅速投入运行。

内存问题，从源头解决

Streams上游过滤功能及其与键值存储列表的原生集成，Defimon 能够根据地址、合约或事件类型，在数据进入其管道之前，精确定义哪些数据可以进入其系统。监控列表不再以不断增长、容易崩溃的列表形式驻留在内存中。添加或移除受监控的地址已成为一项配置变更，而非工程任务。

一条管道。八条链。

Ethereum、BNB Smart Chain、Arbitrum、Base、Polygon、Avalanche、Optimism 和 HyperEVM 均通过单一的Streams 运行。添加新链不再意味着需要新建基础设施，只需更新配置即可。团队从过去在分散的 AWS 环境中管理三条链，转变为现在由一人管理八条链。

采用推送数据，而非轮询

将手动 RPC 调用替换为Streams推送模型后，区块延迟从大约两秒降至不到 0.5 秒。Telegram 漏洞警报现在能在不到一秒内触发。

检测速度提升4倍

区块延迟从每块约两秒降至不到0.5秒。Telegram警报在检测到异常后不到一秒内即会触发。

每一个协议。每一条链。每一个区块。

Defimon 不会仅监控部分协议。它会监控所有协议，并在对 DeFi 至关重要的各条链上检测所有漏洞。无死角，无例外。

一名工程师。八条链。零运维负担。

过去需要三到四人维护的基础设施，现在仅需一人即可运行，且该人员可完全专注于检测逻辑，而非管道管理。

过去用于维持基础设施正常运行的工程时间，现在被用于它本应专注的领域：改进检测机制，并始终领先于未来的发展趋势。