2.9 亿美元跨链桥攻击如何证明单点故障的风险

Kelp DAO / LayerZero rsETH 事件提醒我们，跨链桥安全的核心在于尽量减少对任何运营者、堆栈或基础设施层的信任。上周末，DPRK 发起了一场复杂的攻击，利用了不安全的跨链桥配置，并执行了精心设计的 RPC 节点劫持，窃取了近 3 亿美元。事情是如何出错的？让我们从一些基础知识开始。

跨链桥 101

跨链桥的基本概念很简单。为了将资金从一条链转移到另一条链，资金被锁定在链 1 的托管中，并在链 2 上释放。为了确保此操作的安全，在链之间传递指示跨链桥锁定和释放资金的消息必须安全地传输。

为了确保这一过程的安全，当 oApp（LayerZero 术语中的全链应用）从链 1 发出消息时，该消息必须由一个或多个 Decentralized Verifier Networks (DVNs) 确认其真实性。DVNs 负责在消息路由到链 2 执行之前检查消息并确定其真实性。

总而言之，如果攻击者可以在目标链（链 2）上伪造消息，他们就可以指示 oApp 在资金仍保留在链 1 时从托管中释放 Token。这种情况永远不应该发生，因为它允许攻击者窃取在另一条链上合法使用的 Token。

oApp 安全的最佳实践是使用多个完全独立的 DVNs。这可以确保 DVN 网络中的单点劫持不足以破坏跨链桥系统。然而，目前 oApp 的默认配置是 1-of-1 确认，这意味着单个 DVN 确认消息的真实性，这构成了单点故障。

oApp 开发人员可以选择使用多少个以及哪些 DVNs 来确认通过 LayerZero 网络路由的消息。oApp 开发人员的不安全选择超出了推荐的最佳实践，但没有什么能阻止 oApp 开发人员做出不安全的选择。

出了什么问题？

2026 年 4 月 18 日下午 1:35 (ET)，一次配置错误将一个再质押产品变成了国家级攻击者的 2.9 亿美元目标。这次攻击现在被认为与朝鲜的 Lazarus Group 有关，它绕过了智能合约逻辑和链上安全，直接针对基础设施。

薄弱环节是决定为 Kelp DAO rsETH oApp 依赖单个 DVN（1-of-1 验证设置），这意味着单个 DVN 是锁定在 rsETH Token 中数亿美元价值的唯一安全看门人。根据 LayerZero 的公开声明，攻击者劫持了由 LayerZero Labs 运营的 DVN 所使用的多个 RPC 节点。

这些 RPC 由独立运营者（而非 LayerZero Labs）运行。攻击首先通过替换两个独立 RPC 节点上的 op-geth 二进制文件开始，使得这两个节点故意向 LayerZero Labs DVN 报告虚假的交易信息。这种劫持允许攻击者向 DVN 报告虚假交易。但仅靠 RPC 劫持还不够。

首先，攻击者仔细确保被劫持的 RPC 节点仅向 LayerZero Labs DVN 报告虚假信息，以避免被现有的 RPC 完整性监控系统检测到。

其次，由于 LayerZero Labs DVN 依赖于分布式 RPC 网络（远多于 2 个），攻击者需要迫使 DVN 听取被劫持的 RPC。攻击者对 DVN 使用的所有其他 RPC 节点发起了单独的 DDOS 攻击，从而迫使 DVN 仅依赖于那两个被劫持的节点。

没有协议层面的漏洞，也没有密钥管理失效。只有基础设施访问权限和一个仅信任一方的跨链桥。

由于在这种情况下 DVN 配置是 1-of-1，配置的单个 DVN 正在听取被投毒的 RPC 节点。没有额外的独立验证者来拒绝伪造的消息。攻击者随后开始伪造消息以窃取 Token。

接下来的事情是一连串的灾难：被投毒的 RPC 允许欺诈性伪造的消息被“验证”，从而使得大约 116,500 rsETH（当时价值约 2.9 亿美元）从 Kelp 的跨链桥中释放。

其他连接到 LayerZero 的应用急于控制风险，像 Curve 这样的项目在调查进行期间停止了 LayerZero 基础设施的使用，尽管 LayerZero 坚持认为除了 Kelp 的 rsETH 配置之外“零传染”。

LayerZero 的公开声明强调，该事件仅限于 Kelp DAO 的 rsETH 配置，并且使用单个 DVN (1-of-1) 违反了他们推荐的多 DVN 设置。与此同时，攻击路径通过了 Labs 运营的 DVN 所使用的基础设施，这凸显了即使各方都正确遵循了自己的操作协议，单一运营者的集中验证和基础设施也可能产生系统性风险。

生态系统其他成员的教训是深刻的：如果你的去中心化跨链桥安全最终瓶颈在于单个运营者的基础设施，那么它的安全性仅等同于该运营者加固程度最差的节点。

遗漏了什么？

让我们更详细地讨论 LayerZero 和 Kelp 安全模型中的问题，以及设计和构建跨链桥的最佳实践。

1-of-1 DVN 是一个危险信号

单个 DVN，无论声誉如何，都不应该独自守卫真金白银。

相反：

• 使用多 DVN、N-of-M 配置，要求独立系统在资产移动之前就状态和消息有效性达成一致。
• 确保 DVNs 由具有独立基础设施堆栈、RPC、客户端配置和操作实践的不同实体运营，而不仅仅是同一运营者机器上的不同标签。
• 这些实体中的每一个都应该是完全独立的，没有共同的故障点。

如果 rsETH 由多个异构 DVNs 保护，那么被投毒的 DVN（通过被劫持的 RPC）将不足以推送伪造的消息。

加固验证者之下的基础设施

rsETH 漏洞不需要破坏 LayerZero 协议或 DVN 签名密钥。它依赖于破坏 LayerZero DVN 用来查看区块链活动的 RPC 节点。

实际的预防措施是什么样的？

• 在加固的环境中运行你自己的全量 RPC 节点，并结合公共 RPC 实施严格的访问控制，以在多个故障点之间实现客观且正确的法定人数 (Quorum)。
• 实施二进制完整性控制（签名二进制文件、可重现构建、度量启动），以便能够检测到未经授权的客户端替换并阻止 RPC 参与法定人数。
• 使用多样化的客户端和提供商（不同的基础设施供应商、不同的客户端实现和独立的监控），以增加攻击者劫持你所有数据源的成本。
• 始终监控 RPC 状态——如果多个 RPC 宕机或受到攻击，跨链桥应立即采取行动。

在高级持续性威胁 (APT) 驱动的世界中，RPC 端点不仅仅是管道——它们是你攻击面的一部分。

向集成商明确信任假设

Kelp DAO 的 rsETH 设置展示了当一个应用悄悄接受单一运营者安全堆栈为“足够好”时会发生什么。跨链桥框架应该：

• 强制执行最安全的设置，并禁止像 Kelp 选择的那种 1-of-1 不安全设置。
• 公开配置风险等级（例如，“1-of-1 DVN：高风险”，“3-of-5 异构 DVNs：首选”），以便产品团队和用户能够做出明智的决定。

如果一个应用不顾警告选择了 1-of-1 配置，该选择应被拒绝，或者至少在公开场合显而易见，并体现在资产价格中。

嵌入持续监控和熔断机制 (Kill Switches)

Curve 在 rsETH 调查期间立即暂停 LayerZero 基础设施，是互联生态系统中防御姿态的教科书案例。概括来说，跨链协议应该：

• 在跨链桥流量上建立自动异常检测，寻找异常的交易量、路由模式或消息序列。
• 为异常超过阈值时暂停特定路由、DVNs 或链预定义紧急策略。
• 定期模拟事件场景（桌面演练和混沌练习），以便团队知道在怀疑跨链基础设施被劫持时如何反应。

快速、协调的反应可以限制损失，并防止局部故障演变成系统性威胁。

使审计与实际威胁模型保持一致

许多跨链桥审计仍然几乎完全集中在合约逻辑和消息传递的正确性上，低估了这次攻击实际发生的链下 Web2 层。现代跨链桥安全计划应该：

• 包括对 RPC 堆栈、DVN 环境和连接一切的链下跨链桥代码的基础设施级红队演练。
• 如果涉及 TVL，应明确考虑国家级攻击者，包括长期持久性和供应链劫持场景。
• 准确记录谁/什么可以导致价值移动（验证者、守护者、升级密钥），以及哪些劫持会导致“停机”与“损失”。
• 验证暴露给集成商的配置选项在默认情况下是安全的，或者有明确的警告保护。通过 API/UX 公开每个通道的“风险态势”（DVN 数量、独立性、限制），以便集成商和用户可以看到保护每个通道的安全措施。

保护跨链桥的最佳实践

精心的设计、配置和防护栏

我们再怎么强调这些措施也不为过。高风险配置不应出现在测试网之外。

• 在任何生产通道上不得使用 1-of-1 验证者或 DVNs。在代码中强制执行多 DVN / 多验证者 N-of-M 法定人数。
• DVNs/验证者必须由具有非重叠基础设施堆栈和治理的独立实体运营。
• 为每个通道和资产配置速率限制（吞吐量和总未结清额），以便单一故障无法耗尽跨链桥。
• 任何通道验证者法定人数或风险态势的降级都必须要求明确的确认（或治理批准）。

消息验证和资产逻辑

遵循这些关键实践以加强身份验证、防止重放并避免未经授权的操作。

• 使用强身份验证验证消息：签名必须针对包含链 ID、通道 ID 和 Nonce 的消息哈希。
• 实施重放保护：每个发送者的 Nonce、已处理消息跟踪和链绑定负载。
• 对于锁定与铸造设计，强制执行供应量守恒：总包装供应量在任何时候都必须 ≤ 锁定的链上抵押品。
• 将铸造/销毁/解包权限限制在经过验证的跨链桥合约中；移除管理员铸造快捷方式。

跨链桥关键基础设施和 RPC 的使用

坚定的威胁行为者会尽可能深入地挖掘。将 RPC 视为处于风险之中并据此计划。

• 将验证者使用的 RPC 视为跨链桥信任基础的一部分。不要依赖单个 RPC 提供商或单节点视图。
• 使用多个独立的 RPC 提供商和/或自运行节点。DVNs 应要求在多样化的 RPC 后端之间达成法定人数一致。
• 持续监控与跨链桥安全相关的 RPC 行为（例如，意外的客户端版本、分叉、延迟或数据偏差），并将异常与自动安全模式/暂停触发器Hook。

跨链桥范围的监控、限制和熔断机制 (Kill Switches)

持续监控跨链桥流量（按通道、资产、链对）以发现异常：交易量突然跳跃、异常路由、重复失败。

当任何通道上的交易量或模式偏离历史常规时，添加自动减速和硬上限。实施跨链桥级别的断路器，以进行全局、按链和按通道的暂停。

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