深入解读任意消息传递协议如何破解互操作性信任难题？

作者：Shi Khai Wei，Raghav Agarwal

编译：Kxp，BlockBeats

引言

多链是未来的发展趋势，可扩展性的追求将 Ethereum 引向了 Rollup 技术的搭建。在转向模块化区块链的过程中，人们再次关注到了应用链。而在不远的未来，我们听到了关于特定应用 Rollup、L3 和主权链的传闻。但这一切都将以碎片化为代价，而目前的跨链桥通常在功能上存在限制，并依赖于可信的签名者来确保安全性。

那么，互联的 Web3 最终将呈现出怎样的局面呢？我们认为，跨链桥最终将演变为跨链消息传递或「任意消息传递」（AMP）协议，以解锁新的应用场景，让应用能够在源链和目标链之间传递任意消息。我们还将见证「信任机制格局」的出现，其中构建者将在可用性、复杂性和安全性之间做出各种权衡。

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

• 验证：能够在目标链上验证来自源链消息的有效性
• 活跃性：能够将信息从源链传递到目标链

很遗憾，百分之百的无信任验证并不现实，用户必须根据验证是在链上还是链下，选择相信代码、博弈理论、人类（或实体），或者这些的组合。

在本文中，我们将整体互操作性领域垂直划分为基于信任机制和基于集成架构两个方面。

信任机制：

1. 信任代码和数学：对于这些解决方案，存在着链上的证明，任何人都可以验证。这些解决方案通常依赖于轻客户端，用于验证源链在目标链上的共识或验证源链在目标链上状态转换的有效性。通过轻客户端进行的验证可以通过零知识证明来提高效率，将任意长的计算压缩为离线进行，同时提供简单的链上验证来证明计算结果。

2. 信任博弈论：当用户/应用程序需要相信第三方或第三方网络来保证交易的真实性时，就会涉及到额外的信任假设。通过采用无权限网络和经济激励以及乐观安全等博弈理论，可以提高这些机制的安全性。

3. 信任人类：这些解决方案依赖于大多数验证者的诚实性或独立性，这些验证者传递不同的信息。除了相信两个交互链的共识外，还需要相信第三方。这种情况下，唯一的风险在于参与实体的声誉。如果足够多的参与实体同意一笔交易是有效的，那么它就被视为有效。

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

集成架构：

1. 点对点模型：需要在每条源链和目标链之间建立专用的通信通道。

2. 中心式枢纽模型：需要建立一个与中央枢纽的通信渠道，以实现与连接到该枢纽的所有其他区块链的互联互通。

点对点模型相对难以扩展，因为每个连接的区块链都需要一个成对的通信渠道。对于具有不同共识和框架的区块链来说，开发这些通道可能是具有挑战性的。然而，如果需要，成对的桥梁提供了更多灵活性来定制配置。还可以采用混合方法，例如使用 Inter-Blockchain Communication（IBC）协议通过中继进行多跳路由，从而消除了直接点对点通信的需求，但在安全性、延迟和成本等方面引入了更多复杂性。

信任代码和数学

为了只依赖代码/数学进行信任假设，可以使用轻客户端来验证源链在目标链上的共识。轻客户端/节点是连接到全节点以与区块链交互的软件。目标链上的轻客户端通常存储源链块头的历史记录（按顺序），这足以验证交易。离线代理（如中继）监视源链上的事件，生成密码学包含证明，并将它们与块头一起转发到目标链上的轻客户端。由于轻客户端按顺序存储块头，每个块头都包含可用于证明状态的 Merkle 根哈希，因此它们能够验证交易。以下是这种方法的主要特点概述：

安全性

在轻客户端的初始化过程中引入了信任假设。在创建新的轻客户端时，它会初始化为来自对方链上特定高度的一个块头。然而，存在一个可能性，即提供的块头可能是不正确的，从而可能通过伪造的块头欺骗轻客户端。一旦轻客户端被初始化，就不会再引入进一步的信任假设。然而，值得注意的是，该初始化过程依赖于较弱的信任假设，因为任何人都可以验证它。此外，对于中继器的连续传输信息，存在活跃性假设。

实施

轻客户端的实施取决于验证所需的密码原语的可用性。如果连接的是同一类型的链，意味着它们共享相同的应用程序框架和共识算法，则两端的轻客户端实施将相同。例如，所有 Cosmos SDK-based 链都使用 Inter-Blockchain Communication (IBC) 协议。另一方面，如轻客户端的实现取决于对验证所需的密码学原语的支持情况。如果连接的是相同类型的链，即它们共享相同的应用框架和共识算法，那么两侧的轻客户端实现将相同。例如，Inter-Blockchain Communication（IBC）协议用于所有基于 Cosmos SDK 的链。另一方面，如果连接的是两种不同类型的链，例如不同的应用框架或共识类型，则轻客户端的实现将不同。一个例子是Composable Finance，他们正在努力通过 IBC 将 Cosmos SDK 链连接到 Polkadot 生态系统的 Substrate 应用框架。这就需要在 Substrate 链上使用 Tendermint 轻客户端，并在 Cosmos SDK 链上添加一个"beefy"轻客户端。最近，他们通过 IBC 在 Polkadot 和 Kusama 之间建立了第一个连接。

挑战

资源密集性是一个重要挑战。在所有链上运行成对的轻客户端可能是昂贵的，因为区块链上的写入是昂贵的。此外，在具有动态验证者资源密集性是一个重要挑战。在所有链上运行成对轻客户端可能很昂贵，因为区块链上的写入是昂贵的。此外，对于具有动态验证者集的链（如 Ethereum），运行轻客户端是不可行的。

可扩展性是另一个挑战。轻客户端的实现根据链的架构而异，这使得扩展和连接不同生态系统变得困难。

代码漏洞是一个潜在的风险，因为代码中的错误可能导致漏洞。例如，2022 年 10 月的 BNB 链漏洞就揭示了一个影响所有支持 IBC 的链的关键安全漏洞。

为了解决在所有链上运行成对轻客户端的成本和实际性问题，可以采用零知识（ZK）证明等替代解决方案，以消除对第三方信任的需求。

零知识证明作为第三方信任的解决方案

零知识证明可用于在目标链上验证源链的状态转换的有效性。与在链上执行整个计算相比，ZK proofs 仅在链上执行计算的验证部分，而实际计算发生在链下。这种方法可以更快、更高效地验证，相比重新运行原始计算。一些例子包括 Polymer Labs 的Polymer ZK-IBC和 Succinct Labs 的Telepathy。Polymer 正在开发多跳（multi-hop）的 IBC，以增强连接性并减少所需的成对连接数量。

该机制的关键方面包括：

安全性

zk-SNARKs 的安全性依赖于椭圆曲线，而 zk-STARKs 则依赖于哈希函数。zk-SNARKs 可能需要一个可信的设置（trusted setup），包括创建用于生成验证中使用的证明的初始密钥。关键是销毁设置事件的秘密，以防止通过伪造验证来进行交易。一旦可信的设置完成，就不会引入进一步的信任假设。此外，新的 ZK 框架（如 Halo 和 Halo2）完全消除了对可信设置的需求。

实施

存在多种 ZK proving 方案，如 SNARK、STARK、VPD 和 SNARG，目前最广泛采用的是 SNARK。不同的 SNARK proving 框架，如 Groth16、Plonk、Marlin、Halo 和 Halo2，在证明大小、证明时间、验证时间、内存需求和可信设置需求等方面提供了权衡。递归的 ZK proofs 也已经出现，允许将证明工作负载分布在多台计算机上，而不是单台。为了生成有效性证明，必须实现以下核心基元：验证验证者使用的签名方案、在链上存储的验证者集合承诺中包含验证者公钥的证明，以及跟踪验证者集，其可能经常变化。

挑战

在 zkSNARKs 中实现各种签名方案需要实现域外算术和复杂的椭圆曲线操作，这并不简单，并且可能需要根据不同的链的框架和共识来进行不同的实现。审计 ZK circuits 是一项具有挑战性且容易出错的任务。开发人员需要熟悉领域特定语言，如 Circom、Cairo 和 Noir，或者直接实现电路，这两者都可能具有挑战性，并且可能减缓采用速度。如果证明时间和工作量非常高，可能只有专门团队和专用硬件才能处理，可能导致集中化。更长的证明生成时间也会导致延迟。增量可验证计算（Incrementally Verifiable Computation，IVC）等技术可以优化证明时间，但其中许多仍处于研究阶段，等待实现。更长的验证时间和工作量将增加链上成本。

信任博弈论

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

第一类是经济安全机制，其中多个外部参与者（如验证者）合作达成共识，确定源链的更新状态。为了成为验证者，参与者需要质押一定数量的 Token，如果发生恶意活动，这些 Token 可能会被减少。在无需许可的设置中，任何人都可以积累质押并成为验证者。此外，对遵循协议的验证者提供区块奖励等经济激励，确保诚实行为的经济动机。然而，如果潜在的被盗金额超过质押金额，参与者可能会勾结窃取资金。使用经济安全机制的协议示例包括Axelar 和 Celer IM。

第二类是乐观安全机制，其中解决方案依赖于只有少数区块链参与者是诚实的并遵守协议规则的假设。在这种方法中，一个诚实的参与者可以充当担保。例如，一种最佳解决方案允许任何人提交欺诈证明。虽然存在经济激励，但是一个诚实的观察者可能会错过一个欺诈交易。乐观 Rollups 也采用了这种机制。Nomad 和 ChainLink CCIP是使用乐观安全机制的协议示例。在 Nomad 的情况下，观察者能够证明欺诈，尽管在撰写本文时它们已被列入白名单。ChainLink CCIP 计划利用由分布式预言机网络组成的反欺诈网络来监测恶意活动，尽管 CCIP 的反欺诈网络的实施尚未可知。

安全性

在安全性方面，这两种机制都依赖于验证者和观察者的无许可参与，以确保博弈论的有效性。在经济安全机制中，如果质押金额低于可能被盗金额，资金更容易受到攻击。另一方面，在乐观安全机制中，如果没有人提交欺诈证明，或者许可观察者受到破坏或移除，少数信任的假设可能会被利用。相比之下，经济安全机制对于维护安全性并不那么依赖活跃性。

实施

在实施方面，一种方法涉及一个具有自己验证者的中间链。在这种设置中，一组外部验证者监视源链，并在检测到调用时就交易的有效性达成共识。一旦达成共识，它们会在目标链上提供证明。通常需要验证者抵押一定数量的 Token，如果检测到恶意活动，这些 Token 可能会被减少。使用这种实施方法的协议示例包括 Axelar Network 和 Celer IM。

另一种实施方法涉及使用离链代理。离链代理被用于实现类似乐观 Rollups 的解决方案。在预定义的时间窗口内，这些离链代理可以提交欺诈证明，并在必要时撤销交易。例如，Nomad 依赖于独立的离链代理来中继头部和密码学证明。另一方面，ChainLink CCIP 计划利用其现有的预言机网络来监测和证明跨链交易。

优势和挑战

博弈论的 AMP 解决方案的一个关键优势是资源优化，因为验证过程通常不在链上进行，从而降低了资源需求。此外，这些机制具有可扩展性，因为共识机制对于各种类型的链保持不变，并且可以轻松扩展到异构区块链。

与这些机制相关的挑战也有几个。如果大多数验证者勾结，信任假设可能会被利用以窃取资金，这就需要采取诸如二次投票和欺诈证明之类的对策。此外，基于乐观安全的解决方案在最终性和活跃性方面引入了复杂性，因为用户和应用程序需要等待欺诈窗口以确保交易的有效性。

信任人类

需要信任人类实体的解决方案也可以广泛分为两类：

1. 声誉安全：这些解决方案依赖于多签名实现，其中多个实体验证和签署交易。一旦达到最低阈值，交易被视为有效。这里的假设是大多数实体是诚实的，如果大多数这些实体对特定交易进行签名，则该交易是有效的。这里唯一需要承担风险的是参与的实体的声誉。一些示例包括Multichain（Anycall V6）和 Wormhole。由于智能合约漏洞，仍然可能存在漏洞，正如 2022 年初 Wormhole 的黑客攻击所证明的那样。

2. 独立性：这些解决方案将整个消息传递过程分为两部分，并依赖于不同的独立实体来管理这两个过程。这里的假设是这两个实体彼此独立，不会勾结。LayerZero 就是一个例子。块头通过分布式预言机按需传输，交易证明通过中继器发送。如果证明与头部匹配，则交易被视为有效。虽然证明匹配依赖于代码/数学，但参与者需要信任这些实体保持独立，没有恶意意图。构建在LayerZero上的应用程序可以选择他们的预言机和中继器（或托管自己的预言机/中继器），从而将风险限制在个别预言机/中继器上。最终用户需要相信 LayerZero、第三方或应用程序本身正在独立运行预言机和中继器，没有恶意意图。

在这两种方法中，参与的第三方实体的声誉会阻止恶意行为。这些通常是验证者和预言机社区中受尊敬的实体，如果他们表现恶意，会冒着声誉损害和对其他业务活动的负面影响的风险。

AMP 解决方案的其他考虑因素

在考虑 AMP 解决方案的安全性和可用性时，我们还需要考虑基本机制以外的细节。由于这些是可以随时间改变的组成部分，我们没有将它们包括在整体比较中。

代码完整性

最近的黑客攻击利用了代码错误，突显了可靠的审计、漏洞赏金和多样化的客户端实现的必要性。如果所有验证者（在经济/乐观/声誉安全中）运行相同的客户端（用于验证的软件），它增加了对单一代码库的依赖性，并减少了客户端的多样性。例如，Ethereum 依赖于多个执行客户端，如 geth、nethermind、erigon、besu、akula。各种语言的多个实现可能会增加多样性，没有任何一个客户端主导网络，从而消除了潜在的单点故障。拥有多个客户端还可以帮助保持活跃性，如果少数验证者/签署者/轻客户端因为某一特定实现的漏洞/攻击而失效。

设置和可升级性

用户和开发者需要知道验证者/观察者是否可以以无许可的方式加入网络，否则信任将被选择许可的实体隐藏。智能合约的升级也可能引入漏洞，从而导致攻击，甚至可能改变信任假设。可以实施不同的解决方案来减轻这些风险。例如，当前的实例化中，Axelar 网关可以升级，但需要离线委员会的批准（4/8 阈值），然而，Axelar 在不久的将来计划要求所有验证者集体批准网关的任何升级。Wormhole 的核心合约是可升级的，并通过 Wormhole 的链上治理系统进行管理。LayerZero 依赖于不可变的智能合约和不可变的库，以避免任何升级，但可以推送新的库，设置默认设置的 dapp 将获得更新的版本，手动设置版本的 dapp 需要将其设置为新版本。

最大可提取价值（MEV）

不同的区块链通过共同的时钟不同步，并具有不同的最终性时间。因此，目标链上的执行顺序和时间可能因链而异。在跨链世界中，MEV 很难明确定义。它在活跃性和执行顺序之间引入了权衡。有序通道将确保消息的有序传递，但如果一个消息超时，通道将关闭。另一个应用程序可能更喜欢无需排序，但其他消息的传递不受影响。

源链确定性

理想情况下，AMP 解决方案应该在将源链的状态信息传输到一个或多个目标链之前等待源链达到最终性。这将确保源链上的区块几乎不会被撤销或更改。然而，为了提供最佳用户体验，许多解决方案提供即时消息传递，并对最终性进行了信任假设。在这种情况下，如果源链在消息传递和桥接资产后经历状态回滚，可能会导致桥接资金的双重花费等情况。AMP 解决方案可以通过多种方法来管理这种风险，例如根据链的去中心化程度为不同的链设置不同的最终性假设，或者通过在速度和安全性之间进行权衡。利用 AMP 解决方案的桥梁可以在源链达到最终性之前设置桥接的资产金额限制。

趋势和未来展望可定制并可附加的安全性

为了更好地服务于多样化的用例，AMP 解决方案受到激励提供更多的灵活性给开发者。Axelar 引入了一种方法，用于实现消息传递和验证的可升级性，而无需更改应用层逻辑。HyperLane V2 引入了模块，允许开发者从多个选择中选择，如经济安全、乐观安全、动态安全和混合安全。CelerIM 除了经济安全外，还提供了额外的乐观安全。许多解决方案在传递消息之前会等待源链上预定义的最低区块确认数。LayerZero 允许开发者更新这些参数。我们预计一些 AMP 解决方案将继续提供更多的灵活性，但这些设计选择需要一些讨论。应用程序是否应该能够配置它们的安全性，到什么程度，以及如果应用程序采用次优的设计架构会发生什么？用户对安全性背后基本概念的意识可能变得越来越重要。最终，我们预见 AMP 解决方案的聚合和抽象，可能以某种形式的组合或「附加」安全性的形式出现。

「信任代码和数学」机制的成熟

在理想的最终阶段，所有跨链消息将通过使用零知识（ZK）证明来实现最小化信任。我们已经看到类似项目如 Polymer Labs 和 Succinct Labs 的出现。Multichain 也发表了一个关于通过 ZK 证明实现互操作性的 zkRouter 白皮书。通过最近宣布的 Axelar 虚拟机，开发者可以利用 Interchain Amplifier 来无需许可地建立与 Axelar 网络的新连接。例如，一旦为 Ethereum 的状态开发了强大的轻客户端和 ZK 证明，开发者可以轻松地将它们集成到 Axelar 网络中，以替换或增强现有连接。Celer Network 宣布了 Brevis，一个 ZK 跨链数据证明平台，使 dApps 和智能合约能够访问、计算和利用多个区块链上的任意数据。Celer 利用 ZK 轻客户端电路实现了一个面向用户的资产 zkBridge，用于 Ethereum Goerli 测试网和 BNB Chain 测试网之间的跨链。LayerZero 在其文档中讨论了在将来添加新的优化证明消息库的可能性。像 Lagrange 这样的新项目正在探索从多个源链聚合多个证明，而 Herodotus 则通过 ZK 证明使存储证明成为可能。然而，这种过渡需要时间，因为这种方法难以在依赖不同共识机制和框架的区块链之间进行扩展。

ZK 是一种相对较新且复杂的技术，难以审计，目前的验证和证明生成成本不是最优化的。我们相信，从长远来看，为了支持在区块链上高度可扩展的跨链应用，许多 AMP 解决方案很可能会将可验证的软件与可信任的人类和实体相结合，因为：

1. 通过审计和漏洞赏金，可以将代码利用的可能性最小化。随着时间的推移，随着这些系统的历史成为它们安全性的证明，信任这些系统将变得更加容易。

2. 生成 ZK 证明的成本将降低。随着对 ZKP 的更多研究和开发，递归 ZKP、证明聚合、折叠方案和专门的硬件，我们预计证明的生成和验证时间成本将大幅降低，使其成为更具成本效益的方法。

3. 区块链将变得更加支持 ZK。在未来，zkEVM 将能够对执行的有效性提供简洁的证明，基于轻客户端的解决方案将能够轻松验证源链的执行和共识。在 Ethereum 的最终阶段，还计划「将所有东西都 zk-SNARK」，包括共识机制。

人类的证明、声誉和身份

像 AMP 解决方案这样的复杂系统的安全性无法仅通过单一框架来封装，需要多层次的解决方案。例如，除了经济激励外，Axelar 还实施了二次投票机制，以防止投票权力集中在节点的子集之间，并促进去中心化。其他人类的证明、声誉和身份证明也可以作为设置和许可机制的补充。

结论

在 Web3 开放的精神中，我们可能会看到一个多元的未来，多种方法共存。事实上，应用程序可以选择使用多个互操作性解决方案，可以是冗余方式，也可以让用户根据权衡选择进行组合。在「高流量」路线之间，点对点解决方案可能会优先考虑，而中心与辐射模型可能会主导链的长尾部分。最终，我们作为一个用户、构建者和贡献者的社区，将塑造 Web3 互联网的基本样貌。