2.9亿美元“桥”攻击：其实并不是桥被攻破

上周末，朝鲜黑客通过攻破用于验证 LayerZero 跨链消息的基础设施，从 Kelp DAO 中转走了约 2.9 亿美元的 rsETH。这是有史以来规模最大、也最复杂的黑客事件之一。

KelpDAO 将责任归咎于 LayerZero，称其默认配置不安全，采用了 1/1 DVNs。LayerZero 则回应说：“我们想明确一点：LayerZero 协议本身在整个事件中都按照预期正常运行。”

当 LayerZero 和 KelpDAO 互相指责时，批评者又重复起了一个熟悉的说法：“Bridge 本来就不安全。”我与 LayerZero 没有任何关联，但我对这种回应有两个问题。

1. 这并不现实。全球前 20 大银行几乎都在不同阶段推进自己的 DLT。几乎每家中央银行也都在建设自己的系统。因此，金融机构将需要安全的跨账本消息传递。我们不能只是说“bridge 很糟”然后就不管了。
2. 我个人非常希望证明这种说法是错的。Cosmos Labs 构建了一个跨账本消息传递协议，称为 Inter-Blockchain Communication Protocol（IBC）。在其五年的生产运行中，IBC 已经处理了数千万次跨链消息和数百亿美元的跨链 Token 转移，覆盖 200 多个账本，且没有发生事故。它是行业迫切需要的中立、安全、开放的消息传递标准（见 1）。

所以我想花一点时间，简要解释一下为什么跨账本消息传递很难，LayerZero 具体是如何工作的，攻击者是如何利用它的（这也使得他们从技术上讲是对的：协议“按预期运行”），以及 IBC 如何以略有不同的方式处理构建跨账本消息传递协议时的难题，从一开始就避免这类攻击。

为什么互操作性很难

先从区块链擅长什么开始：回答“我的区块里发生了什么？”区块链是一个通过共识运行的确定性状态机。你问 Ethereum：“Alice 有没有给 Bob 转 10 ETH？”答案会是一个区块、一笔交易，以及一份任何人都可以验证的密码学收据。这听起来比实际情况更复杂一些。不过，“收据”其实只是由链上的验证者产生的一组签名——这些基础设施运营者会以 ETH、SOL 或其他 Token 作为报酬来处理交易，然后通过“验证”彼此的答案来确认自己都得到了相同的输出。

一个自然的问题是：“我们为什么要信任这些验证者？”对此有许多复杂的答案答案，以及一个非常简单的答案：Ethereum 就是它的验证者集合。Ethereum 区块链由 Ethereum 的区块定义，而让这些区块合法的唯一依据，就是区块头中那组将每个区块与前一个区块连接起来的验证者签名。除此之外什么都没有！使用 Ethereum，本质上就是付钱让这些人处理你的交易并对输出达成一致。这就是 Ethereum。所以当我说“问问 Ethereum”时……实际上翻译过来就是“问问验证者 Alice 有没有付给 Bob”。

现在设想 Alice 在 Ethereum 上，而 Bob 在 Solana 上。这个问题突然就变难了。Solana 验证者从未听说过 Ethereum 或它的验证者，反之亦然。Solana 验证者不会处理 Ethereum 交易，也不会为 Ethereum 的区块签名，所以他们没有直接的方法知道 Alice 是否真的付给了 Bob。

这就是跨链消息传递的基础问题：当 Chain B 无法直接验证 Chain A 的事件时，Chain B 如何验证 Chain A 上确实发生了某个事件？你必须决定你要信任谁，以及信任什么。

两种信任选项

桥通常通过 2 种方式来回答“信任谁”这个问题：

1. 指定一个受信任的第三方
2. 信任验证者

受信任委员会如何工作

指定一个受信任委员会意味着：为了确认 Alice 是否真的在 Ethereum 上发起了对 Bob 的支付，我们可以去问 Charlie。他运行一个 Ethereum full node（一种处理所有 Ethereum 交易的基础设施，就像验证者一样），并承诺会保持它的最新状态，而且绝不会对我们撒谎，告诉我们 Ethereum 上到底发生了什么。看起来是个值得信任的好人。

更进一步，我们可以去问一整组人——Charlie、David 和 Emily。然后只有在他们中至少 2 个，或者 3 个全都同意 Alice 确实在 Ethereum 上向 Bob 发起了支付时，我们才把 Token 发给 Bob。

LayerZero 和 KelpDAO Bridge 漏洞利用

这就是大多数桥的默认工作方式，包括 LayerZero。LayerZero 把它们称为“Decentralized Verifier Networks”（DVNs）。桥合约会指定一个签名者列表，这些签名者对对手方账本上发生的相关事件进行证明。

Kelp 的 bridge 被配置为单个 DVN，其中只有一个签名者（“1-of-1”），由 LayerZero Labs 运行。换句话说，Kelp bridge 对“信任谁”的回答是 LayerZero Labs：只有当 LayerZero Labs 这么说时，Alice 才算是在 Ethereum 上给 Bob 付了款。即便对于一个基于 oracle 的 bridge 来说，这也是一个极其危险的配置。既然只需付出相近的成本，你为什么只问 LayerZero Labs，而不是再加入其他几个信誉良好的节点运营者，组成受信任委员会？现在外界正在公开争论那到底是 Kelp 的选择还是 LayerZero 的默认设置，但实际运行效果是一样的：只有一个验证者，轮询一些 Ethereum RPC 节点，签名确认某条消息已经发生。

攻击者并没有碰 Ethereum。他们没有破坏任何密码学。他们针对的是 RPC。他们攻破了 LayerZero 验证者所轮询的两个 RPC 节点上运行的软件，用恶意版本替换了二进制程序。这些恶意程序会选择性地撒谎（向 LayerZero 的验证者返回一条伪造的跨链消息，同时对其他所有调用者返回准确数据，这样就没人会注意到）。然后他们又对 LayerZero 为冗余而轮询的未被攻破的 RPC 发起 DDoS，迫使验证者切换到那些被投毒的节点。

验证者完成了它的工作。它看到了“一个事件”，于是签名。目标链交付了这条消息。Kelp 的 bridge 释放了 116,500 rsETH。随后恶意 RPC 软件自毁以掩盖痕迹。

在任何时候，都没有人对 Ethereum 上的内容撒谎。他们撒谎的是“有人声称 Ethereum 上发生了什么”。用 LayerZero 的话说，协议“完全按预期运行”，因为协议的意图就是信任验证者，而验证者信任了 RPC。信任链条的设计本来就是如此；只是其中有一个没人盯着的薄弱环节。

更好的方式：信任验证者

另一条路径是去掉中间人。与其问 Charlie、David 和 Emily（或者 LayerZero Labs）Alice 是否在 Ethereum 上付给了 Bob，不如直接问 Ethereum 验证者。是他们在出块。他们已经签过一份收据了。为什么还要引入另一组人来证明第一组人已经证明过的事情？

难点在于，Solana 不可能在其共识中真的运行一个 Ethereum full node 来直接验证 Ethereum 事件。在 Solana 上处理每一笔 Ethereum 交易会贵得离谱，而且时间上也行不通。所以我们需要一个捷径：一种方式，让 Solana 在不重放 Ethereum 全部工作的情况下检查 Ethereum 的签名。

这个捷径叫做 light client。light client 是一段运行在 Chain B 上的小代码，它对 Chain A 了解得足够多，可以验证其验证者的签名。具体来说，它会保存 Chain A 当前的验证者集合，以及一个随时间更新该验证者集合的算法。当有人想证明 Chain A 上发生了某个事件时，他们会向 Chain B 提供一个来自 Chain A 的区块头、指向该区块头内事件的证明，以及该区块头上的验证者签名。Chain B 的 light client 会将这些签名与其已知的验证者集合进行检查，再检查该证明是否与区块头一致；如果两者都通过验证，就接受该事件确实发生了。

没有 Charlie、David 或 Emily。没有 RPC 轮询。Chain B 询问的是 Chain A 自己的验证者已经回答过的同一个问题，并用他们自己的签名来核对答案。这就是我们的 Cosmos 互操作协议 IBC 默认的工作方式。

例如，在使用基于 Tendermint 共识的账本时，Chain B 上的共识 light client 会验证来自 Chain A 的 Tendermint 验证者集合的签名。对于 Ethereum，IBC light client 会验证来自 Ethereum sync committee 的证明——这是一个轮换的验证者子集，通过验证来自所有验证者的数千个签名，使 Ethereum light client 更具可扩展性。目标链不会信任 oracle 对其他地方发生了什么的说法。它是在链上、在智能合约中，直接验证对手方链的密码学承诺。

这里仍然涉及基础设施。必须有人在两条链之间传递区块头和证明。在 IBC 中，这些链下工作者被称为 relayers。Relayer 与 DVN 有本质不同：它们无权决定什么是真实的。它们不是“受信任的”，只是搬运数据。任何人都可以运行 relayer。如果某个 relayer 掉线了，另一个会接手。如果某个 relayer 试图提交伪造的区块头，light client 会拒绝，因为签名无法通过验证。Relayer 在系统中根本没有任何权力。

这就是为什么 IBC 如此适合机构场景。运营一个账本并将存款 Token 化的银行，不需要信任像 LayerZero Labs、Axelar 的验证者集合，或某个 oracle 联盟，来在自己的链和像 Ethereum 这样的结算链之间转移价值。相反，银行可以运行自己的 relayer。它的信任边界是它自己的云环境（它已经知道如何保护的边界），再加上另一侧那条链的共识，而后者无论如何它都必须信任。这就是完整的图景。

回到 KelpDAO：导致 2.9 亿美元损失的那种具体攻击，在这个模型中根本不是一种攻击向量。这里没有一个链下验证者可以去问“这事发生了吗？”，也没有一个 bridge 会依赖某个 RPC 的回答。问题变成了“这些签名能否通过 Ethereum sync committee 的验证？”，而被投毒的 RPC 节点、DDoS、被攻破的二进制程序，都无法改变这个答案。签名要么能通过验证，要么不能。要攻破这个模型，你需要攻破 Ethereum 验证者集合本身。

为什么我们不总是使用 light client？

Cosmos 的 IBC 同时支持这两种信任模型——light-client 和 committee-based——因为 light client 确实有实际权衡。

1. 它们在链上运行的成本比信任 oracle 更高（例如，你必须验证数百个验证者签名，或者用简洁的 ZK proofs 对其进行压缩，而不是只用一个签名）。
2. 它们要求对手方链具有可以高效验证的共识结构。Bitcoin 的共识就没有一个可以高效验证的 light client。Ethereum L2 的 light client 通常需要数周才能验证（原因超出本文范围）。
3. 它们在智能合约中实现起来可能非常困难。

这些都不是致命缺陷，但它们确实存在。对于一个小型应用来说，如果少数信誉良好的验证者愿意签名背书，而且这种信任假设是可以接受的，那么基于 oracle 的 bridge 是一个合理的选择。

关键在于验证机制

回到我们开始的地方：“bridge 不安全，crypto 不安全”——这是从 KelpDAO 和 LayerZero bridge 黑客事件中得出的错误结论。

正确的结论是，跨链验证机制很重要，而业内一直没有很好地区分：一类 bridge 信任一个（小得惊人！）委员会，另一类 bridge 则直接验证共识。这是截然不同的两种方法，具有截然不同的安全属性，把它们混为一谈，会让那些如今正试图弄清如何在账本之间转移真实价值的机构受到误导。

对于在链之间转移真金白银的机构来说，当验证机制必须满足风险委员会的要求时，使用 light client 直接验证对手方共识，通常才是正确的设计。如果这不现实，还有一条中间路径：自己运行委员会。银行可以不把证明职责外包给 LayerZero Labs 或第三方 oracle 联盟，而是自己运行 signer（或者由少数已知的机构对手方组成一个小型联盟），并由银行已经用于在其他场景中保护数十亿美元资产的同样的 HSM 和密钥管理基础设施来支持。此时的信任假设不再是“某个没有和我们一样安全记录的第三方不会被攻破”，而是“我们自己的签名基础设施——我们已经在核心业务中信任它——不会被攻破”。这正是风险委员会已经知道如何评估的信任边界风险。

我们很乐意与正在思考更安全、更灵活、更中立的互操作性方法的银行和其他机构合作，一起探索 IBC。

欢迎通过 DM 联系我，或者在下方留言。

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