本文最早作为《 PAKA跨链研究报告》的 5.9 章节发布。

作者：MiddleX

与我交流：

• Twitter：@middlex0

• VX：xuezhijie156

跨链桥项目有上百个，其技术类型也有很多种，但有没有一个通用的结构呢？或者说，我们有没有一个通用的思维框架来理解一个跨链桥的构成？

在研究了众多的跨链桥项目，尤其是AMB(任意消息桥)项目之后，我们抽象出了一个分层结构。任意一个跨链桥都可以拆解为这三个层次去理解。

• 信任层

• 传输层

• 应用层

信任层

跨链桥首先要解决的问题是：一条链如何感知另一条链，更准确的说：一条链如何可信的感知另一条链。

将一条链的消息传递到另一条链并不困难，但核心是如何信任它，或者说：如何验证它！

传递跨链消息的人可以是任何人，包括发起跨链事务的应用或是用户自身，但如何验证消息这个环节，我们必须有一个机制来保证它是可信的。这就是信任层要完成的任务。

对于原生验证桥，信任层是链上的轻客户端程序，以及负责传递区块头的 Head Relayer ；

对于外部验证桥，信任层是一个 PoA/PoS 网络，或是一个外部 Oracle 网络；

对于本地验证桥，信任层是交易流程本身；

对于乐观验证桥，信任层则是PoS验证者+负责报告验证者欺诈行为的观察者。

传输层

在确定信任层的构建方式后，传输层的设计成了跨链桥的重头戏。有的跨链桥构建了较为完善的传输层，有的跨链桥的传输层则相对简单，更多传输层的事务交给了应用层去设计。相对完善的传输层更便于应用程序的接入。

传输层的基本任务是构建消息传输的秩序，管理消息的时序、状态，如果是多链跨链，还要管理消息的寻址，收发权限，并制定统一的消息格式。传输层一般由一组负责管理消息队列的一组链上智能合约和一套消息状态更新逻辑组成。不同的跨链桥对这一组链上智能合约的称呼不同，但其职能是相同的。

如何理解跨链消息

跨链的应用场景可能是多样的，包括

• 跨链合约调用：一条链调用另一条链上的合约执行某种功能，并返回执行结果

• 跨链计算：将多条链上的参数作为输入，计算一个值作为应用程序的输入

• 跨链治理执行：将应用程序在一条链上的治理投票结果，同步在多条链上执行

• 跨链资产映射：将资产在一条链上锁定的消息传递给另一条链，触发映射资产的铸造

但所有的场景，其本质或者说实现途径都是跨链消息的传输，也就是说如果能实现消息在链间的可信传输，以上的跨链应用场景，就都可以实现。

跨链消息的本质是一条链上发生的事情，体现为一笔或多笔交易，当然“交易”一词并不意味着一定有资产的转移，“交易”在区块链中往往指的是任意形式的状态转换。跨链桥会为消息制定一个统一的格式，其中会包含“交易”的相关元数据、应用程序为交易写入的备注信息（payload）等，对于原生跨链桥，或者采用消息树结构的跨链桥，消息还包括“交易”的默克尔路径。

消息生命周期（Message Lifecycle）

跨链消息的传输一般会经历这样的过程：

1. 应用程序向源链上管理发送队列的合约提交格式化后的消息；

2. 消息被传递到目标链上的管理接收队列的合约，当然，消息必须经过信任层的验证，可能在传递到目标链之前，也可能在传递到目标链之后；

3. 目标链上管理接收队列的合约将被验证后的消息转发给目标应用程序进行执行；

4. 消息执行成功的回执返回源链，更新消息在发送队列中的状态为已发送或直接删除。

在部分外部验证桥中，会有例外，跨链消息的传输可能是这样的过程：

1. 源链的应用程序提交跨链消息到发送队列

2. 消息被验证后，也就是外部验证者集对消息达成共识之后 ，外部验证者集可以签名一条执行该消息的交易；

3. 交易上链，消息被执行。

不过我们在第 2 步中可以看到，这样做的前提是外部验证者集需要知道消息将如何被执行。这意味着，如果某个应用层采用这种传输方式，那么信任层和传输层是为其定制的。由于这种传输过程链上步骤更少，Gas更低。

我们以 wrap 桥为例进行进一步的说明：

假如我们依托一个外部验证型 AMB 桥创造一个 wrap 桥，

1. 用户通过源链上的 wrap 桥合约，发起 lock 交易，wrap 桥合约将 lock 交易提交到 AMB 桥的待发队列；

2. 消息被被验证后传递到 AMB 桥在目标链上部署的接收队列；

3. 接收队列将消息转发给目标链上的 wrap 桥合约，mint 操作被触发执行。

但如果外部验证者知道“ lock 要触发 mint ”这一逻辑，就可以有更简洁的流程

1. 用户调用源链上的 wrap 桥合约，发起 lock 交易

2. 消息被外部验证者监听到并被验证，此时外部验证者可以直接发起一个 mint 交易，并在共识签名后，提交到链上，触发 mint 操作的执行。

所以，我们发现，对于外部验证的 wrap 桥，如果不依托 AMB 桥，而是独立构建 AMB 层，就可以直接在链下触发 mint /unlock 操作。这样反而可以让 wrap 桥更加快速，更加便宜。

AMB 桥之所以在链上验证和链上触发执行，是因为 AMB 桥并不知道应用层想要如何执行这条消息，对于 AMB 桥而言，只需要把验证后的消息转发给目标应用程序，任务就完成了，目标应用程序决定如何执行这条消息。AMB 桥要创造的是一个足够通用的、支持任意跨链消息有序传递的传输层。

然而，在采用外部验证作为信任层的前提下，由应用层自建的、或者定制的传输层则可以实现更好的性能，因为桥的验证节点可以明确知道应用层的执行逻辑，知道 lock 要触发 mint，知道 burn 要触发 unlock ，进而直接在链下触发执行，节约在链上触发执行的 Gas 费，也让链上的合约代码更加简洁。对于 wrap 桥是如此，对于其他类型的跨链应用也是如此。

消息队列结构

大多数跨链桥的消息队列是消息原文的队列，一些跨链桥会在消息队列的基础上，构建消息树，形成一个根值队列，例如 Hyperlane、Nomad、XCMP ，这样做可以分离根值的传输和消息原文的传输，以实现消息的抗审查性和防篡改性，还可以降低根值传输层的负荷。

Channel

在一些多链跨链桥当中，还存在 Channel 的概念，Channel 的概念是虚构的，其本质是建立在两条链上的一对消息队列。Channel 概念的存在，意义在于

• 组织消息时序：Channel 内部的消息将有时序关系，不同 Channel 之间的消息则没有时序属性；

• 管理消息收发权限：没有 Channel 的链间无法传输消息，如果某条链不想接受另一条链的消息，可以拒绝打开对应的 Channel 。

包含 Channel 概念的跨链桥有 Cosmos、XCMP、Nomad ，但它们各自的设计又有所不同。在 Comsos 中，Channel 是建立在应用程序之间的（建立在链之间的 Channel 被称为 Connection ）而且是双向的，两条链之间建立 Channel 意味着二者可以进行消息的双向传输。但在 XCMP 和 Nomad 中，Channel 是单向的，双向跨链传输需要成对的两个 Channel 。

应用层

AMB 类的跨链桥项目往往会为应用提供一套组件，应用程序通过集成这些组件、调用相关模块来实现跨链消息的收发。如果跨链桥是作为一个独立的应用程序运行的，那么它就没必要考虑为其他应用的接入提供便利。

激励层

信任层还是传输层都会涉及到激励的问题。我们不妨把它单独拿出来作为一个新的层。

• 信任层激励：对于原生跨链桥，需要激励 Relayer 提交区块头以维护轻客户端；对于外部验证桥（PoS），需要激励验证者忠实的履行职责；对于乐观验证桥，需要激励验证者和观察者忠实履行职责；对于本地验证桥，则需要激励公共交易对手提供充足的流动性。

• 传输层激励：需要激励有关角色向目标链提交跨链消息，垫付目标链上跨链消息验证和执行产生的费用。

激励的方式可能是多种多样的，主要以下几种方式：

• 将用户端的收费直接支付给激励对象；

• 跨链桥项目方用自身金库或是通胀奖励来补贴激励对象；

• 应用层为激励对象制定激励规则，或者应用层直接承担激励对象的职责。

我们可以用下图来描述跨链桥的分层模型。

该分层模型可以作为我们分析跨链桥项目的一个有效工具。如果你想了解具体的案例分析，请查看完整报告。