互操作性网络导航：深入探讨任意消息传递协议

前言

未来是多链的。对可扩展性的追求使以太坊走向了汇总。向模块化区块链的转变重新引发了人们对应用链的关注。在地平线的远处，我们听到了有关特定应用程序的汇总、dL3 和主权链的传闻。

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

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

每个 AMP 解决方案都需要两项重要功能：

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

100% 的去信任验证是不可能实现的，用户要么需要信任代码、博弈论、人类（或实体），要么信任这些的组合，具体取决于验证是在链上还是链下进行。

我们根据信任机制和集成架构划分整体互操作性景观。

信任机制：

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

需要注意的是，所有解决方案在一定程度上都需要对代码和人类的信任。有缺陷代码的任何解决方案都可能被黑客利用，每个解决方案在设置、升级或维护代码库方面都有一些人为因素。

集成架构：

1. 点对点模型：需要在每个源和每个目的地之间建立专用的通信通道。
2. 轮辐模型：需要与中央集线器建立通信通道，以实现与连接到该集线器的所有其他区块链的连接。

点对点模型相对难以扩展，因为每个连接的区块链都需要成对的通信通道。对于具有不同共识和框架的区块链来说，开发这些渠道可能面临困难。然而，如果需要的话，点对点桥提供了更大的灵活性来定制配置。混合方法也是可能的，例如，通过使用通过集线器进行多跳路由的区块链间通信协议（IBC），这消除了直接点对点通信的需要，但重新引入了安全性、延迟和成本方面的更多复杂性考虑因素。

信任代码/数学

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

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

1. 安全：

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

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

• 如果连接的是相同类型的链（相同的应用框架和共识算法），那么双方轻客户端的实现将是相同的。例子：适用于所有基于 Cosmos SDK 的链的 IBC。
• 如果连接两种不同类型的链（不同的应用框架或共识类型），那么轻客户端的实现将会有所不同。例子： 可组合金融正在努力使 Cosmos SDK 链能够通过 IBC 连接到 Substrate（Polkadot 生态系统的应用程序框架）。这需要在底层链上安装一个 Tendermint 轻客户端，并在 Cosmos SDK 链上添加一个所谓的强大轻客户端。

1. 挑战：

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

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

在所有链上运行点对点轻客户端成本高昂，并且对于所有区块链来说并不实用。 IBC 等实现中的轻客户端还需要跟踪源链的验证者集，这对于具有动态验证者集的链（如以太坊）来说并不实用。ZK 证明提供了一种减少 Gas 和验证时间的解决方案。不是在链上运行整个计算，而是仅在链上进行计算证明的验证，而实际计算在链下完成。与重新运行原始计算相比，验证计算证明可以用更少的时间和更少的 Gas 来完成。该机制的主要特点是：

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

• 验证验证者使用的签名方案的验证
• 将验证者公钥的证明包含在验证者集承诺中（存储在链上）
• 跟踪可能经常变化的验证者集

1. 挑战：

• 要在 zkSNARK 内实现各种签名方案，需要实现场外算术和复杂的椭圆曲线运算。这并不容易实现，并且可能需要根据每个链的框架和共识进行不同的实现。
• 如果证明时间和精力非常高，那么只有拥有专门硬件的专业团队才能做到这一点，这将导致中心化。较长的证明生成时间也会延迟。
• 更高的验证时间和精力将导致更高的链上成本。

1. 示例：Polymer ZK-IBC，由 Polymer Labs、Succinct Labs 生产。Polymer 正在研究多跳 支持的 IBC，以增加连接性，同时减少所需的点对点连接数量。

信任博弈论

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

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

• 在 Nomad 的情况下，监视者可以证明欺诈。然而，Nomad 的监视者在撰写本文时是被列入白名单的。
• ChainLink CCIP 将利用一个反欺诈网络，该网络由去中心化的 Oracle 网络组成，其唯一目的是监控恶意活动。CCIP 的反欺诈网络实现尚待观察。

这些机制的主要特点是：

1. 安全性：对于这两种机制，需要来自验证者和监视者的无许可参与，以使博弈理论机制发挥作用。在经济安全机制下，如果抵押金额低于可被盗取金额，资金可能更加危险。在乐观安全机制下，对于乐观解决方案的少数人信任假设可能被利用，如果没有人提交欺诈证明，或者如果被授权的监视者受到损害/移除，而经济安全机制在安全性方面不具有对活跃性同等的依赖。
2. 执行：

• 拥有自己验证者的中间链：一组外部验证者监视源链，在检测到调用时就交易的有效性达成共识，并在目标链上提供证明，如果达成共识，则提供证明。验证者通常需要抵押一定数量的代币，如果检测到恶意活动，可能会被罚没。示例：Axelar Network，Celer IM
• 通过离线代理：可以使用离线代理实施类似乐观 Roll-up 的解决方案，在预定义的时间窗口内，允许离线代理提交欺诈证明并撤销交易。示例：Nomad 依赖于独立的离线代理来中继区块头和密码证明。ChainLink CCIP 将利用其现有的 Oracle 网络来监控和证明跨链交易。

1. 挑战：

• 如果大多数验证者串通一气，信任假设可能会被利用来窃取资金，这需要采取二次投票和欺诈证明等对策。
• 终局性：基于安全的乐观 AMP 解决方案会带来终局性和活跃性的复杂性，因为用户和应用程序需要等待欺诈窗口。

1. 优点：

• 资源优化：这种方法通常不是高能的，因为验证通常不会在链上进行
• 可扩展性：这种方法更具可扩展性，因为各种链的共识机制保持相同，并且可以轻松扩展到异构区块链。

信任人类

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

在这两种方法中，参与的第三方实体的声誉都会抑制恶意行为。这些通常是验证者和预言机社区内受人尊敬的实体，如果他们采取恶意行为，他们将面临声誉受损的后果以及它对其他业务活动产生负面影响的风险。

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

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

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

趋势和未来展望：

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

在 Web3 开放精神的推动下，我们可能会看到一个多元的未来，这里多种方法共存。事实上，应用程序可以选择使用多种互操作性解决方案，无论是以冗余的方式，还是让用户在权衡的基础上混搭。点对点解决方案可能会在“高流量”路线之间得到优先考虑，而中心与辐射模型可能会主导链的长尾。最终，塑造互联网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/

更多阅读资料：

• Navigating Arbitrary Messaging Bridges: A Comparison Framework: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• L2Bridge Risk Framework: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Horatius at the Bridge: https://maven11.substack.com/p/horatius-at-the-bridge

声明：

1. 本文转载自[medium]，著作权归属原作者[LongHash Ventures]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。