驾驭互操作性网络：深入研究任意消息传递协议

驾驭互操作性网络：深入研究任意消息传递协议

介绍

未来是多链的。对可扩展性的追求已将以太坊引向了 roll-up。向模块化区块链的转变再次引起了对应用程序链的关注。在遥远的地平线上，我们听到了特定应用程序 roll-up、L3 和主权链的窃窃私语。

但这带来了碎片化的代价。因此，第一波基本桥梁被推出以满足桥接的需求，但它们在功能上通常受到限制，并且依赖于受信任的签名者来保障安全。

互联 Web3 的最终局面会是什么样子？我们认为，所有桥梁都将演变成跨链消息传递或“任意消息传递”(AMP)协议，通过允许应用程序从源链向目标链传递任意消息来解锁新的用例。我们还将看到“信任机制格局”的出现，构建者将在可用性、复杂性和安全性方面做出各种权衡。

每个 AMP 解决方案都需要两个关键功能：

• 验证： 验证来自源链的消息在目标链上的有效性的能力
• 活跃性： 从源到目标中继信息的能力

100% 无需信任的验证是无法实现的，用户需要信任代码、博弈论、人类（或实体），或者这些的组合，这取决于验证是在链上还是链下完成的。

我们基于信任机制和集成架构来划分整体互操作性格局。

信任机制：

1. 信任代码/数学：对于这些解决方案，链上证明存在并且可以被任何人验证。这些解决方案通常依赖于 轻客户端 来验证目标链上源链的共识，或者验证目标链上源链的状态转换的有效性。通过轻客户端进行验证可以通过 零知识证明 来提高效率，该技术可以在离线压缩任意长的计算，并提供简单的链上验证来证明计算。
2. 信任博弈论： 当用户/应用程序必须信任第三方或第三方网络来保证交易的真实性时，就会产生额外的信任假设。这些机制可以通过无许可网络与博弈论（例如经济激励和乐观安全性）相结合来提高安全性。
3. 信任人类： 这些解决方案依赖于大多数验证者的诚实或中继不同信息的实体的独立性。除了信任两个交互链的共识之外，它们还需要信任第三方。这里唯一受到威胁的是参与实体的声誉。如果足够多的参与实体同意某个交易有效，那么它就被认为是有效的。

重要的是要注意，所有解决方案在一定程度上都需要信任代码和人类。任何具有错误代码的解决方案都可能被黑客利用，并且每个解决方案在代码库的设置、升级或维护中都包含一些人为因素。

集成架构：

1. 点对点模型： 需要在每个源和每个目标之间建立专用通信通道。
2. Hub and Spoke 模型： 需要与一个中心 hub 建立通信通道，该 hub 能够与连接到该 hub 的所有其他区块链连接。

点对点模型相对难以扩展，因为每个连接的区块链都需要成对的通信通道。对于具有不同共识和框架的区块链来说，开发这些通道可能具有挑战性。但是，如果需要，成对桥接可以更灵活地自定义配置。也可以采用混合方法，例如，通过使用带有通过 hub 进行多跳路由的区块链间通信协议 (IBC)，从而无需直接成对通信，但会重新引入安全、延迟和成本方面的更多复杂性。

信任代码/数学

轻客户端如何验证目标链上源链的共识？

轻客户端/节点是一种连接到完整节点以与区块链交互的软件。目标链上的轻客户端通常存储源链的区块头历史记录（按顺序），这足以验证交易。链下代理（如中继器）监控源链上的事件，生成加密包含证明，并将它们与区块头一起转发到目标链上的轻客户端。轻客户端能够验证交易，因为它们按顺序存储区块头，并且每个区块头都包含 Merkle 根哈希，可用于证明状态。这种机制的关键特征是：

1. 安全性：

• 除了信任代码之外，在初始化轻客户端期间还会引入另一个信任假设。当有人创建一个新的轻客户端时，它会使用来自交易对手链的特定高度的标头进行初始化。提供的标头可能不正确，并且轻客户端以后可能会被进一步的虚假标头欺骗。一旦轻客户端被初始化，就不会引入任何信任假设。 但是，这是一个微弱的信任假设，因为任何人都可以检查初始化。
• 中继器需要传输信息，因此存在对中继器的活跃性假设。

2. 实现： 取决于验证所需的加密原语的可用性支持

• 如果连接的是同一类型的链（相同的应用程序框架和共识算法），那么轻客户端在双方的实现将是相同的。示例：所有基于 Cosmos SDK 的链的 IBC。
• 如果连接的是两种不同类型的链（不同的应用程序框架或共识类型），那么轻客户端的实现将有所不同。示例：Composable finance 正在努力使 Cosmos SDK 链能够通过 IBC 连接到 Substrate（Polkadot 生态系统的应用程序框架）。这需要在 substrate 链上使用 Tendermint 轻客户端，并在 Cosmos SDK 链上添加所谓的 beefy 轻客户端

3. 挑战：

• 资源密集型： 在所有链上运行成对的轻客户端成本很高，因为在区块链上进行写入的成本很高，并且在具有动态验证器集的链（如以太坊）上运行不可行。
• 可扩展性： 每种链组合都需要轻客户端实现。鉴于实现方式因链的架构而异，因此很难扩展和连接不同的生态系统。
• 代码漏洞利用： 代码中的错误可能导致漏洞。2022 年 10 月的 BNB 链漏洞利用暴露了一个影响所有启用 IBC 的链的关键安全漏洞。

ZK 证明如何验证目标链上源链的状态转换的有效性？

在所有链上运行成对的轻客户端成本高昂，并且对所有区块链来说都不实用。像 IBC 这样的实现中的轻客户端还需要跟踪源链的验证器集，这对于具有动态验证器集的链（如以太坊）来说是不实用的。ZK 证明提供了一种减少 gas 费和验证时间的解决方案。无需在链上运行整个计算，只需在链上验证计算证明，而实际计算在链下完成。验证计算证明比重新运行原始计算花费的时间更少且 gas 费更低。这种机制的关键特征是：

1. 安全性： zk-SNARK 依赖于椭圆曲线来保证其安全性，而 zk-STARK 依赖于哈希函数。zk-SNARK 可能需要也可能不需要可信设置。可信设置仅在最初需要，指的是用于创建证明所需的密钥的初始创建事件，这些证明用于验证这些证明。如果设置事件中的密钥没有被销毁，它们可能会被利用通过虚假验证来伪造交易。一旦完成可信设置，就不会引入任何信任假设。
2. 实现： 如今存在不同的 ZK 证明方案，如 SNARK、STARK、VPD、SNARG，目前 SNARK 应用最广泛。递归 ZK 证明是另一项最新进展，它允许将证明的总工作量分配给多台计算机，而不是仅仅一台计算机。为了生成有效性证明，需要实现以下核心原语：

• 验证验证器使用的签名方案
• 在验证器集承诺（存储在链上）中包含验证器公钥的证明
• 跟踪可以频繁更改的验证器集

3. 挑战：

• 为了在 zkSNARK 中实现各种签名方案，需要实现 out-of-field 算术和复杂的椭圆曲线运算。这不容易实现，并且可能需要针对每个链的不同实现，具体取决于它们的框架和共识。
• 如果证明时间和精力非常高，那么只有具有专门硬件的专门团队才能做到这一点，这将导致中心化。更高的证明生成时间也可能导致延迟。
• 更高的验证时间和精力将导致更高的链上成本。

4. 示例： Polymer Labs 的 Polymer ZK-IBC，Succinct Labs。Polymer 正在开发支持多跳的 IBC，以增加连接性，同时减少所需的成对连接数量。

信任博弈论

依赖于博弈论的互操作性协议可以根据它们如何激励参与实体的诚实行为大致分为两类：

1. 经济安全性： 多个外部参与者（如验证者）就源链的更新状态达成共识。这类似于多重签名设置，但为了成为验证者，参与者需要质押一定数量的代币，如果检测到任何恶意活动，这些代币可能会被削减。在无许可设置中，任何人都可以积累质押并成为验证者。当参与的验证者遵循协议时，还会有区块奖励作为经济激励。因此，参与者在经济上有动力保持诚实。但是，如果可以窃取的金额远高于质押的金额，那么参与者可能会试图合谋窃取资金。示例： Axelar、Celer IM
2. 乐观安全性： 乐观安全解决方案依赖于少数信任假设，该假设假设只有少数区块链参与者是活跃的、诚实的并遵守协议规则。该解决方案可能只需要一个诚实的参与者持有保证。最常见的示例是最佳解决方案，任何人都可以提交欺诈证明。乐观 roll-up 也利用了这种方法。示例： Nomad、ChainLink CCIP

• 在 Nomad 的案例中，观察者可以证明欺诈。但是，在撰写本文时，Nomad 观察者已列入白名单。
• ChainLink CCIP 将利用反欺诈网络，该网络将由去中心化预言机网络组成，其唯一目的是监控恶意活动。CCIP 的反欺诈网络实施还有待观察。

这些机制的关键特征是：

1. 安全性： 对于这两种机制，验证者和观察者的无许可参与对于博弈论机制的有效性至关重要。在经济安全机制下，如果质押金额低于可以窃取的金额，则资金可能面临更大的风险。在乐观安全机制下，如果没有人提交欺诈证明，或者如果已许可的观察者受到损害/移除，则乐观解决方案的少数信任假设可能会被利用，而经济安全机制对安全没有相同的活跃性依赖性。
2. 实现：

• 具有自己验证者的中间链： 一组外部验证者监视源链，在检测到调用时就交易的有效性达成共识，并在达成共识时在目标链上提供证明。验证者通常需要质押一定数量的代币，如果检测到恶意活动，这些代币可能会被削减。示例： Axelar Network、Celer IM
• 通过链下代理： 链下代理可用于实现类似于乐观 roll-up 的解决方案，其中在预定义的时间窗口内，允许链下代理提交欺诈证明并恢复交易。示例： Nomad 依赖于独立的链下代理来中继标头和加密证明。ChainLink CCIP 将利用其现有的预言机网络来监控和证明跨链交易。

3. 挑战：

• 如果大多数验证者串通，则可以利用信任假设窃取资金，这需要像二次投票和欺诈证明这样的对策。
• 最终性： 基于乐观安全性的 AMP 解决方案在最终性和活跃性方面引入了复杂性，因为用户和应用程序需要等待欺诈窗口。

4. 优势：

• 资源优化： 这种方法通常不占用大量资源，因为验证通常不会在链上发生
• 可扩展性： 这种方法更具可扩展性，因为共识机制对于所有类型的链都保持不变，并且可以轻松扩展到异构区块链。

信任人类

1. 大多数诚实假设： 这些解决方案依赖于多重签名实现，其中多个实体验证和签署交易。一旦达到最小阈值，该交易就被认为是有效的。这里的假设是大多数实体是诚实的，并且如果这些实体中的大多数签署特定交易，则该交易是有效的。这里唯一受到威胁的是参与实体的声誉。示例： Multichain (Anycall V6)、Wormhole。由于智能合约错误导致的漏洞利用仍然是可能的，Wormhole 在 2022 年初的黑客攻击证明了这一点。
2. 独立性： 这些解决方案将整个消息传递过程分成两个部分，并依赖于不同的独立实体来管理这两个过程。这里的假设是这两个实体彼此独立并且没有串通。示例： LayerZero。区块头按需由去中心化预言机流式传输，交易证明通过中继器发送。如果证明与标头匹配，则该交易被认为是有效的。虽然证明匹配依赖于代码/数学，但参与者需要信任实体保持独立。在 LayerZero 上构建的应用程序可以选择他们的预言机和中继器（或托管他们自己的预言机/中继器），从而将风险限制在个别预言机/中继器串通。最终用户需要信任 LayerZero、第三方或应用程序本身正在独立且没有恶意意图地运行预言机和中继器。

在这两种方法中，参与的第三方实体的声誉可以阻止恶意行为。这些通常是验证者和预言机社区中受人尊敬的实体，如果他们采取恶意行动，他们将面临声誉后果并对其其他商业活动产生负面影响。

超越信任假设和互操作性的未来

在考虑 AMP 解决方案的安全性和可用性时，我们还需要考虑基本机制之外的细节。 由于这些是会随着时间变化的移动部件，因此我们没有将它们包含在整体比较中。

• 代码完整性： 最近的许多黑客攻击都利用了代码中的错误，这需要可靠的审计、周密的漏洞赏金计划以及多个客户端实现。如果所有验证者（在经济/乐观/声誉安全中）运行相同的客户端（用于验证的软件），则会增加对单个代码库的依赖性，并降低客户端多样性。例如，以太坊依赖于多个执行客户端，如 geth、nethermind、erigon、besu、akula。多种语言的多种实现可能会增加多样性，而没有任何客户端主导网络，从而消除了潜在的单点故障。如果少数验证者/签名者/轻客户端由于特定实现中的漏洞/错误而停止运行，则拥有多个客户端也可能有助于活跃性。
• 设置和可升级性： 用户和开发人员需要了解验证者/观察者是否可以以无许可的方式加入网络，否则信任会被许可实体的选择所隐藏。智能合约的升级也可能引入错误，从而导致漏洞利用，甚至可能改变信任假设。可以实施不同的解决方案来减轻这些风险。例如，在当前实例中，Axelar 网关是可升级的，但需要离线委员会（4/8 阈值）的批准，但是，在不久的将来，Axelar 计划要求所有验证者共同批准对网关的任何升级。Wormhole 的核心合约是可升级的，并通过 Wormhole 的链上治理系统进行管理。LayerZero 依赖于不可变的智能合约和不可变的库来避免任何升级，但是，它可以推送一个新的库，具有默认设置的 dapps 将获得更新的版本，并且具有手动设置的版本的 dapps 需要将其设置为新版本。
• MEV： 不同的区块链不是通过公共时钟同步的，并且具有不同的最终性时间。因此，目标链上的执行顺序和时间可能因链而异。跨链世界中的 MEV 难以明确定义。它引入了活跃性和执行顺序之间的权衡。有序通道将确保消息的有序传递，但如果一条消息超时，则该通道将关闭。另一个应用程序可能更喜欢不需要排序但其他消息的传递不受影响的情况。

趋势和未来展望：

• 可定制和可添加的安全性： 为了更好地服务于多样化的用例，AMP 解决方案有动力为开发人员提供更大的灵活性。Axelar 引入了一种方法，用于升级消息传递和验证，而无需更改任何应用程序层逻辑。HyperLane V2 引入了模块，允许开发人员从多种选择中进行选择，如经济安全性、乐观安全性、动态安全性和混合安全性。CelerIM 在经济安全性的基础上提供了额外的乐观安全性。许多解决方案在传输消息之前，会等待源链上预定义的最小区块确认数。LayerZero 允许开发人员更新这些参数。我们预计一些 AMP 解决方案将继续提供更大的灵活性，但这些设计选择值得讨论。应用程序是否应该能够配置其安全性，在多大程度上？如果应用程序采用次优的设计架构会发生什么？用户对安全性背后基本概念的认识可能变得越来越重要。最终，我们预见到 AMP 解决方案的聚合和抽象，可能以某种组合或"可相加"安全性的形式出现。
• “信任代码/数学”机制的增长和成熟： 在理想的最终局面中，所有跨链消息都将通过使用零知识 (ZK) 证明来验证消息和状态来实现最小化信任。我们已经目睹了随着像 Polymer Labs 和 Succinct Labs 这样的项目的出现而发生的这种转变。Multichain 最近还发布了 zkRouter 白皮书，以通过 ZK 证明实现互操作性。借助最近宣布的 Axelar 虚拟机，开发人员可以利用 Interchain Amplifier 以无许可的方式设置与 Axelar 网络的新连接。例如，一旦开发出用于以太坊状态的强大轻客户端和 ZK 证明，开发人员就可以轻松地将它们集成到 Axelar 网络中，以替换或增强现有连接。LayerZero 在其文档中讨论了将来添加新的优化证明消息传递库的可能性。像 Lagrange 这样的新项目正在探索聚合来自多个源链的多个证明，而 Herodotus 正在通过 ZK 证明使存储证明可行。但是，这种转变需要时间， 因为对于依赖于不同共识机制和框架的区块链来说，这种方法很难扩展。ZK 是一项相对较新且复杂的技术，审计起来具有挑战性，并且目前验证和证明生成的成本不是最佳的。我们认为，从长远来看，为了支持区块链上高度可扩展的跨链应用程序，许多 AMP 解决方案可能会通过可验证的软件来补充受信任的人类和实体，因为：
• 代码漏洞利用的可能性可以通过审计和漏洞赏金来最小化。随着时间的流逝，由于其历史将作为其安全性的证明，因此更容易信任这些系统。
• 生成 ZK 证明的成本将会降低。随着 ZKP、递归 ZK、证明聚合和专用硬件领域的更多研发，我们预计证明生成和验证的时间和成本将大大降低，使其成为一种更具成本效益的方法。
• 区块链将变得更加 ZK 友好。将来，zkEVM 将能够提供简洁的执行有效性证明，并且基于轻客户端的解决方案将能够轻松验证源链在目标链上的执行和共识。在以太坊的最终局面中，还有计划“zk-SNARK 一切”，包括共识。
• 人/声誉/身份证明： 像 AMP 解决方案这样的复杂系统的安全性无法通过单个框架来概括，并且需要多个解决方案层。例如，除了经济激励之外，Axelar 还实施了二次投票以防止投票权集中在一部分节点中并促进去中心化。其他人类、声誉和身份证明也可以补充设置和许可机制。

在 Web3 开放精神中，我们可能会看到多种方法共存的多元化未来。实际上，应用程序可以选择使用多种互操作性解决方案，无论是采用冗余方式，还是让用户混合和匹配并披露权衡。点对点解决方案可能会在“高流量”路线之间优先考虑，而 hub and spoke 模型可能会主导链的长尾。最后，由我们，用户、构建者和贡献者的集体需求来塑造互连 web3 的地形。

感谢 Polymer Labs 的 Bo Du 和 Peter Kim、Axelar Network 的 Galen Moore、Succinct Labs 的 Uma Roy、LayerZero 的 Max Glassman 和 Ryan Zarick 对本文进行评审并提供宝贵反馈。

参考列表：

• Axelar: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP: https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/
• debridge: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• LayerZero: https://layerzero.gitbook.io/docs/
• Multichain: https://docs.multichain.org/getting-started/introduction
• Nomad: https://docs.nomad.xyz/nomad-101/introduction
• Polymer Labs: https://polymerlabs.medium.com/
• Succinct Labs: https://blog.succinct.xyz/
• Wormhole: https://docs.wormhole.com/wormhole/

附加阅读清单：

• 驾驭任意消息传递桥：比较框架: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• L2Bridge 风险框架: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• 桥上的 Horatius: https://maven11.substack.com/p/horatius-at-the-bridge

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