解读20座跨链桥及4种跨链技术范式

原文标题：《Paka Labs 跨链研报（3/4）| 将孤岛连成大陆：解读 20 座跨链桥及 4 种跨链技术范式》

原文作者：MIDDLE.X，Paka Labs

Paka Labs 跨链研报（1/4）见：《跨链技术及应用形态全景图》

Paka Labs 跨链研报（2/4）见：《BTC 锚定资产与以太坊跨层快速通道》

5.3 跨链的分类维度

根据跨链桥所支持的消息类型，我们可以分为：

· 任意消息桥 ：一般被简称为 AMB，Arbitrary-Message-Briage，支持任意类型消息的跨链传递，在此基础上实现跨链合约调用、跨链计算等复杂功能。

· 资产桥：包括 Wrap 桥和 Swap 桥，前者指资产映射桥，支持跨链资产传递，后者指流动性互换桥，支持跨链资产兑换。

任意消息桥可以作为底层平台，搭载资产桥，从这个意义上讲，资产桥是建构在任意消息桥上的应用之一。事实上，在 LayerZero 推出 Stargate 之后，越来越多的 AMB 桥项目，选择将资产桥剥离出来作为应用层，而非将资产桥的功能内置其中。

对于 Wrap 桥，根据资产的托管方案，还会有更进一步的细分：

· Lock-Mint（包括见证人托管、合约托管）

· Burn-Mint（无托管）

更细致的分类见下图：

不同的资产托管方案，我们已经在 5.1 小节 BTC 锚定资产一节中有充分的探讨。

根据跨链桥的建设目标，我们可以分为：

· 通用桥：以连接尽可能多的链为目标

· 专用桥：为特定的公链、特定资产或是特定应用提供跨链功能

在众多通用桥项目中，有的通用桥项目，颇具野心的提出了 OmniChain（全链）的概念，希望能够连接几乎全部的主流公链，乃至联盟链。通用桥的优势在于可以一站式的满足多链间跨链的需求，专用桥的优势则在于某种意义上的官方背书，在跨链桥的背后，有公链项目方、资产发行方、或是应用程序项目方的安全承诺。

根据桥梁所连接的公链，我们又可以分为：

· 异构跨链桥：旨在连接不同架构的公链

· 同构跨链桥：旨在连接相同架构的公链

其中同构跨链桥往往会辅以一套造链协议，实现对基于该造链协议的公链的被动兼容。不过目前跨链桥项目所面对的往往是异构跨链，区块链在共识机制、通信规范上的创新层出不穷，这导致新的类型的区块链不断涌现。一劳永逸的思路是正确的，但任何项目都不可能甘心将自己禁锢在一个封闭生态内，因此即便是 Polkadot、Coos 这样的以同构跨链为核心的项目，也在积极的推动与其他异构生态的跨链桥接。

以上三个分类维度，各有千秋，但都没有从跨链桥的技术本质切入。我们认为对跨链桥最重要的分类维度，应该是信任层的构建机制。跨链的一个核心问题是要解决：一条链如何感知另一条链。对这个问题更好的问法是：如何可信的感知另一条链。将一条链的消息传递到另一条链并不困难，但核心是如何信任它，换句话说，如何验证它！

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

5.4 跨链的验证方式分类

我们引入 Connext 创始人 Arjun Bhuptani 提出的一个跨链分析框架，这是去年以来，跨链研究领域最重要的理论成果之一。该框架被提出后，迅速被众多跨链相关文章引用。

Arjun Bhuptani 将跨链桥按照消息验证的方式分为三大类别，分别是原生验证、外部验证和本地验证。

5.4.1 原生验证

原生验证指的是在目标链部署源链的轻节点，对源链来的消息进行验证。相比全节点，轻节点是轻量化的节点，它不存储完整区块的序列，而仅存储区块头的序列。尽管区块头体积很小，但它包含了对区块中完整数据的密码学概括，可以对区块内的交易执行 SPV 验证。为了维护目标链上部署的源链轻节点，需要由 Head Relayer 将源链的区块头中继到目标链。

尽管 Head Releyer 作为一个链下角色，是不可或缺的，但原生验证对 Relayer 并没有信任假设，因为部署在目标链上的轻节点程序会对 Head Relayer 提供的区块头进行验证，Head Relayer 无法欺骗轻节点。

对区块头的验证会分为两个部分，分别是有效性验证和最终性验证。

对区块的有效性验证逻辑，取决于共识机制。

对于 PoW 系统，除了验证区块的基本格式外，最核心的验证逻辑是验证区块中包含的工作量证明：

（图片源于 Composable Finance Docs）

如上所示，找到一个满足这个方程的值需要大量的计算，因为哈希函数不能被暴力破解，但是验证这个共识证明相对便宜且快速。

在 PoS 系统中，核心的验证逻辑通常是验证一个随机函数输出：

（图片源于 Composable Finance Docs）

也就是说：验证该块是由一个被随机选中的合法验证人生成的。

然而，区块的有效性不等于最终性。

在中本聪共识中，最终性是概率性的，因此验证最终性的办法是等待该区块后有更多的有效区块被追加。在 BTC 中，一般认为 6 个区块的追加可以让一个区块几乎无法被逆转，这大概需要 1 小时，这就是为什么多数 BTC 跨链衍生品在 mint 时，都需要等待 1 小时左右；在以太坊中，一般认为 25 个区块的追加可以让一个区块几乎无法被逆转，这大约需要 5 分钟左右。

在 BFT 类共识中，则是通过验证一个区块已有 2/3 权重的验证人签名来确认其最终性，因此 BFT 类共识，具有即时最终性。

无论是有效性验证，还是最终性验证，轻客户端对区块头的验证，与其他类型的节点对区块的验证逻辑是完全相同的。因此 Head Relayer 向轻节点合约传递的区块头完全无法造假，原生验证对 Head Relayer 没有信任假设。

5.4.2 外部验证

外部验证则指的是引入一组外部的见证人来负责验证跨链消息，用户必须相信这些见证人是可信的，见证人内部可能有某种机制来达成共识。外部验证者会体现为许多形式，MPC 网络、PoS/PoA 网络、TEE 网络、多签小组、Oracle，本质上都是一回事。

我们需要意识到，在引入外部验证人的同时，引入了新的安全假设。假设 A 链的安全性是 x，B 链的安全性是 y，外部验证者集的安全性是 z，那么在 A 链、B 链之间传递跨链消息的安全性 s = min (x、y、z)，大多数情况下，z 都是其薄弱环节，也就是说 s = z。这是外部验证模式，最被诟病的缺点。

5.4.2.1 共享验证

我们需要考虑外部验证中的两种例外情况：

其一，在由一些由公链项目方直接发起的跨链桥当中，有可能让链的验证者集，直接成为跨链桥的验证者集，在这种情况下，外部验证的安全性 s 提升至 min(x，y)，与原生验证相当。

该结构的典型代表有：

· BTC 侧链 RootStock 的用自身全体验证人作为 RootStack-BTC 桥的验证人

· 由 Compound 开发和维护的 Substrate-based 链 Gateway，则复用全体 Gateway 的验证人，作为 Gateway-以太坊桥的验证人；

· 致力于桥接 Coos 生态与以太坊生态的 Gravity Bridge 使用 Gravity Chain 的全体验证人作为 Gravity Bridge 的验证人。

其二，我们将上述情况，做一个延伸。将 A 链和 B 链的验证者集聚合为一个并集，设立一个中继链 R 链，以该并集作为验证人集，我们便得到了一个更具拓展性的结构。

该结构的典型代表是 Avalanche 和 Polkadot。Polkadot 的中继链为每个平行链随机分配验证者，以此来实现共享安全性，Avalanche 则要求所有子网的验证者必须同时成为三大主网（P 链、C 链、X 链）的验证者，以向子网索取安全性。Polkadot 利用该结构，开发了平行链间的跨链消息传递协议 XCMP，不过 Aclanche 似乎没有利用该结构来实现跨链消息传输。

这两种例外情形，形式上依旧属于外部验证，但其核心特征和适用场景已发生重大变化，在后文我们对各类验证机制的特征对比中，提及到的外部验证将不包含这两种例外。更进一步，我们认为，应该将其命名为一种新的类型，称之为「共享验证」。

5.4.3 本地验证

本地验证也被称为点对点验证，指的是交易对手对交易直接进行验证。典型的范式是基于哈希时间锁的原子交换，在这样的交易过程中，交易双方相互验证对方已经完成了某种行为。由于交易双方的经济利益是对抗的，因此不存在合谋的可能性。大多数采用本地验证方式的跨链项目设计中，为了避免要求交易双方同时在线，都存在一个中间的流动性提供方作为公共的交易对手。

5.4.4 跨链互操作不可能三角

三种验证方式中，原生验证的信任假设最小，理论上只要源链和目标链不发生重组，跨链消息传递就是安全的，但原生验证的多链适配成本是**的。几乎每条链的轻节点方案都要单独设计，更要根据部署环境的某些限制（也就是目标链的情况）进行优化，假如你在 A 链上实现了 B 链的轻节点合约，也只是实现了从 BA 的单向消息传递，如果你要实现一座双向桥，你还需要在 B 链上实现 A 链的轻节点合约，这两项工作是完全独立的，没有可复用性。假如你要适配更多链，那就要付出更多的成本，每接入一条新链，就需要开发一对轻节点合约。因此我们看到，采用原生验证机制的跨链桥项目以专用跨链桥和同构跨链桥居多，异构通用桥很少采用。

外部验证的优势和劣势与原生验证刚好相反，外部验证的多链适配成本较低，其缺点是引入新的信任假设，假设外部验证人通过是 m-of-n 投票机制来达成共识，我们需要恶意串通的验证人数量不能超过 n-m。如果我们想要降低信任假设，那就需要验证人做抵押，这带来的是跨链的成本的增加。

本地验证尽管具备无信任假设、多链适配容易的双重优点，但是其适用范围相对狭窄，只能支持 Swap 桥，无法支持 Wrap 桥，遑论 AMB 桥。

Arjun Bhuptani 在他的文章中，提出了**的跨链互操作性不可能三角（The Interoperability Trilemma），即

任何跨链方案设计，最多只能满足以下三者当中的两者：

· 可扩展性（Extensible）：支持任意消息传传递

· 无需信任（Trustless）：不引入新的信任假设

· 易适配性（Generalizable）：能够轻易适配更多区块链

可以说，各类跨链桥项目都在试图从不同的角度优化乃至破解不可能三角，试图使得综合性能达到**。

5.4.5 乐观验证

乐观验证一般被认为是外部验证方案的优化，但由于其信任假设产生明显变化，我们认为应该将其作为一种独立的验证方案来探讨。乐观验证的基本逻辑是：在外部验证的基础上，设置一批挑战者和一个挑战窗口期，对不正确的验证进行挑战，验证者需要抵押，当其行为不当时，挑战者将提出挑战，并提供欺诈证明。若挑战成功，验证者的抵押金将成为挑战者的赏金。

乐观验证被人所熟知的应用是 Optimistic Rollop，但乐观验证在用于对等跨链，和用于 Op Rollup 时，情形是完全不同的。首先要明确，乐观验证并不是一个可以单独使用的验证机制，因此要使用欺诈证明的前提条件是，有验证欺诈证明的机制。这意味着我们必须有一个可靠的「真相」来源。这个真相端承担着最终裁决的功能。

在对等跨链中，真相就在源链，不正确的状态转换很容易与源链上的「正确答案」进行比对，从而对欺诈证明进行验证。Op Rollups 则比这复杂，Rollups 要求 L2 继承 L1 的安全性，因此只能以 L1 上的真相作为最终裁决的依据，但矛盾的是，L1 并不天然保有 L2 上的状态转换信息，任何从 L2 提交到 L1 的信息都要经过激烈的证明过程，因此需要一个足够长的时间，让异议者能充分参与博弈，大多 Op Rollups 都把这个时间定为 7 天或以上。

在对等跨链中，乐观验证不需要 7 天这么长时间，只需一个足够挑战者进行反应的时间即可，Nomad 将其设定为 30min。乐观验证的信任假设是：至少有一个挑战者是诚实的，且会受到经济激励而忠实的履行职责。这相比外部验证而言，是更小的信任假设，在这样的信任假设下，攻击者无论付出多大的经济代价，都不能保证攻击一定成功。

相比外部验证，乐观验证用几十分钟的延迟换来了信任假设的放宽。乐观验证的机制也可以融入原生验证，用于帮助轻客户端验证区块头。关于乐观验证的更多特点，我们将在后文结合案例来具体说明。

5.5 原生验证桥项目

5.5.1 轻节点合约总论

原生验证桥中最重要的组件便是轻节点合约，为了更好的理解原生验证桥，我们需要先对轻节点合约有一个基本的认识。

轻节点合约，我们也可以称之为轻客户端，它的出现源于人们对于提升区块链去中心化程度的努力。区块链的数据会不断积累，使得全节点的体积不断增大，这使得运行全节点的设备门槛和成本门槛，不断升高，进而将普通用户拒之门外，只留下少数的机构用户运行全节点，区块链的分布式精神遭受挑战。

5.5.1.1 SPV 轻节点

比特币是最早面临这种挑战的区块链，于是中本聪提出了 SPV（简单支付验证）的概念。SPV 轻节点不存储全部的区块数据，而只是存储区块头。尽管 SPV 轻节点没有区块体中的交易数据，但当它需要知道一笔交易是否被包含在链中时，可以从全节点获取该交易的 Merkle 路径，然后用区块头中的 Transaction Root 对该交易进行 SPV 验证。

（蓝色方块的合集，就是黑色方块的默克尔路径）

5.5.1.2 Fclient 超轻节点

超轻节点，是指比 SPV 节点更轻的节点，超轻节点往往可以实现跳跃式的同步新区块头或是不断修剪旧区块头。我们在本系列第一篇中提到过一种超轻节点方案：MMR 超轻节点。在这里，我们需要做一个更正：对 MMR 超轻节点更准确的称呼应该叫 Fclient 超轻节点。MMR 是 Fclient 提出的一种承诺结构。

Fclient 是 2019 年被提出的一个针对 PoW 的超轻节点方案，该方案通过 MMR 实现了「一，即所有」的证明结构，使得**的一个区块头中可以包含所有历史区块头的承诺。与此同时，Fclient 通过一套概率抽查算法，实现了在没有区块头历史的情况下，对区块头最终性的验证。但可惜的是，Fclient 并不适用于跨链场景，迄今为止，也没有任何将 Fclient 应用于跨链桥构建的范例。

原因有两点：

1.Fclient 的 MMR 承诺结构可以让轻节点只保有**的区块头，而不断修剪旧的区块头，虽然可以让链上轻客户端保持较小的体积，但不断同步**区块头还是需要花很多的 Gas，对于链上轻客户端而言，**要做到的是尽可能少的同步区块头，比如说跳跃式的同步区块头，甚至按需同步区块头；

2.Fclient 的抽查算法比较复杂，对于本地 CPU 而言不算什么，但对于链上这样一个计算资源稀缺的环境，显得过于**了，不具备经济可行性。链上轻客户端必须尽可能的节约区块头的验证成本。

对于原生验证桥而言，轻节点合约的性能将直接决定跨链桥的性能。我们在本节对跨链桥项目的举例说明中，将尤其关注项目构建轻节点合约的方法。

5.5.2 BTC Relay

BTC-Relay 是最早的轻节点合约，也是最早的原生验证跨链桥。其工作原理很简单，那就是在以太坊上部署一个 BTC 的 SPV 轻节点，用于对 BTC 链上的交易做 SPV 验证。

（图片源于 BTC Relay 官网）

链下角色「Relayer」负责不断的将 BTC 链的区块头传递到轻节点合约，轻节点合约在对区块头进行有效性验证和最终性验证之后将其正式接受。对区块头的有效性验证是以验证工作量证明为核心，而最终性验证则是等待该区块头后面被追加了 6 个以上的有效区块。正如我们前文所说，这个过程是不需要信任假设的。

Relayer 会向以太坊支付存储和验证区块头的 Gas 费用，与此同时，Relayer 从发起跨链请求的用户那里获得费用作为补偿，并获得适当的利润。任何人都可以成为 Relayer，并自设置每次调用的收费标准，其他人如果想成为 Relayer，可以通过向当前 Relayer 支付一小笔费用，并设置更少的收费标准来取而代之，用户如果担心收费过高，也可以自己运行 Relayer 服务。

需要注意的是，BTC Relay 是一座单向桥，仅仅支持在以太坊上验证 BTC 的信息，不支持相反方向的信息验证。因此 BTC Relay 并没有发行 BTC 的跨链衍生资产，其用例仅限于支持用户使用比特币支付以太坊上的费用。

当然，BTC Relay 可以作为一块积木，作为一个单向信任层，为其他的 BTC 跨链衍生品提供 BTC 以太坊方向上的交易验证服务。

BTC Relay 官网BTC Relay 文档

5.5.3 Waterloo Bridge

WaterLoo Bridge 是由 Kyber Network 开发的一座跨链桥，也是**实现双向原生验证的跨链桥，其实现的是以太坊和 EOS 之间的双向跨链。尽管随着 EOS 的衰落，WaterLoo Bridge 目前鲜有问津，但其技术方案依旧具有代表性。

Waterloo Bridge 通过以太坊智能合约实现了 EOS 的轻客户端，同时也通过 EOS 智能合约实现了以太坊的轻客户端。

由于以太坊出块相对较慢，而 EOS 上的计算和存储资源相对充足，所以 WaterLoo 在 EOS 上建立的以太坊轻节点合约是 SPV 轻节点，与 BTC Relay 原理一致，会将以太坊的区块头逐个的同步到轻节点合约。

但 EOS 出块速度较快，且以太坊上的资源紧张，因此在以太坊上的 EOS 轻节点合约被设计为仅同步 BP 集有变动的区块，而不去逐个的、连续的同步所有区块。但这样的设计需要解决两个问题：

1.如何验证历史区块头：当要验证的交易不在已存储区块当中的时候，轻节点合约需要首先从全节点获取相应区块头。但这里还需要一个验证过程，轻节点合约如何验证这些获取到的区块头？

2.如何验证**区块头：在不掌握区块头完整历史的情况下，如何验证**同步的区块头的最终性？

如何验证历史区块头

轻节点合约需要有能力依据已存储的区块头，验证从全节点获取到的区块头。如何做到这一点呢？我们需要了解，EOS 的共识协议是 DPoS，$EOS 的 Staker 通过投票选出 21 个 BP（Block Producer），这 21 个 BP 以循环方式轮流出块，每生成一个区块，都会由 21 个 BP 进行签名，有 15 个以上 BP 签署的区块被认为具备最终性，这些签名会在区块头中体现。尽管 EOS 出块速度较快，但 BP 集的变动却不会很频繁，轻客户端只要掌握 BP 集的名单（公钥列表），就可以验证该 BP 集任期内的所有区块头。也就是说，从全节点获取的区块头已被相应任期内的 BP 集当中的 15 个签署，就会被轻客户端合约接受。

如何验证**区块头

由于对 BP 集的选举投票发生在链上，投票结果会反映在某个区块 Block{i} 的区块头中，Block{i} 的区块头中会体现该 BP 集的名单，以及他们的任期。在 Block{i} 及其中包含的新 BP 集被生成时，这个新的 BP 集还未生效，Block{i} 会被旧的 BP 集签名。简单来讲，我们也可以这样理解，旧的 BP 集通过签署某个包含新 BP 集选举结果的区块，批准了新的 BP 集。轻客户端只要正确的掌握最初始的 BP 集，并且掌握每次 BP 集发生变化的区块，通过这样一个「批准关系链条」，就可以一路追溯到**的 BP 集。掌握** BP 集，就可以验证**的区块。

我们注意到，这里有个安全假设，那就是轻客户端需要正确掌握初始的 BP 集，如果这个条件不具备，轻节点合约就无**常工作。但对于轻节点合约的部署者而言，这是可以轻易做到的。

所以我们可以明确的是，当 EOS 上有消息需要跨链传递到以太坊，Waterloo Bridge 会：

1. 看消息所在区块的区块头在轻客户端中是否已存在，如果不存在则进行步骤，如果存在则进行步骤 ；

2. Relayer 从全节点获取消息所在区块的区块头，提交给轻客户端，轻客户端根据掌握的** BP 者集来验证该区块头，也就是说，轻客户端通过查看该区块头是否被 2/3 以上的 BP 集签名来判断其是否有效；

3. 用验证通过的区块头，对消息执行 SPV 验证。

EOS 的共识机制属于 BFT 类共识机制，EOS 的轻客户端实现方法，成为了 BFT 类公链轻客户端的典型范式。

WaterLoo Bridge 简介（上）WaterLoo Bridge 简介（下）

5.5.4 Rainbow Bridge

Rainbow bridge 是 Near 开发的连接 Near 生态与以太坊生态的官方跨链桥。Rainbow bridge 文档中提到：Rainbow bridge 的主要设计者是 Anton Bukov，他现在是 1inch 的 CTO，尽管已经不在 Near 全职工作，但他仍然指导着 Rainbow bridge 的发展。

结构与原理

Rainbow Bridge 的核心组成部分是两个链上合约和三个链下**：

链上合约：

· EthOnNearClient：在 Rust 中作为 Near 合约实现的以太坊轻节点

· NearOnEthClient：在 Solidity 中作为以太坊合约实现的 Near 轻节点

链下**：

· Eth2NearRelay：负责将以太坊区块头传递给 EthOnNearClient

· Near2EthRelay：负责将 Near 区块头传递给 NearOnEthClient

· Watchdog：负责向提交无效区块头的 Near2EthRelay 提出挑战，稍后详述

EthOnNearClient 需要跟踪以太坊上的每一个区块头，NearOnEthClient 只需要每个 Epoch 跟踪一个区块头，一个 Epoch 大约是 43,000 个区块，4 小时左右。如果全部同步的话是不现实的，幸运的是，Near 的验证人集每个 Epoch 只会变更一次，每个 Epoch 只有一个包含验证者集改选信息的区块头。NearOnEthClient 的设计很大程度上借鉴了 WaterLoo Bridge 中的 EosOnEthClient，甚至重用了 WaterLoo Bridge 的一部分代码。

但对于 NearOnEthClient，还有个技术难题，那就是以太坊不兼容 Near 所采用的 Ed25519 签名格式，这使得 NearOnEthClient 对 Near 区块头的验证变的很麻烦。因此 Rainbow Bridge 引入了乐观验证的方案。

当 Near2EthRelay 向 NearOnEthClient 提交区块头时，需要在 Near 链上抵押一些 $NEAR，在 4 小时的窗口期内，被称为 Watchdog 的挑战者可以提出挑战，如果所有 Watchdog 都不提出挑战，窗口期结束时，区块头被 NearOnEthClient 正式接纳。如果 Watchdog 提出挑战，并且挑战成功，提交无效区块头的 Near2EthRelay 将付出经济代价，其抵押金的一半将被销毁，剩余的一半将成为提出挑战的 Watchdog 的赏金。

乐观验证的引入，带来了新的信任假设：至少有一个 Watchdog 是忠实的。

在 BTC Relay 中，同一时间，只有一个 Relayer 运行，但在 Rainbow Bridge 中，无论是 Eth2NearRelay，还是 Near2EthRelay，都允许多个同时运行。多个 Relayer 可以相互竞争，尝试同时提交相同的块，每次只有一个成功；多个 Relayer 也可以相互形成备份，如果某个 Relayer 没有及时交块，其他 Relayer 依旧会提交，这样降低了服务不可用的可能性。

激励措施

当前 Rainbow Bridge 没有为转发区块头的两组 Relay 服务提供经济激励，因为 Near 预期运行在 Rainbow Bridge 上的主要应用（例如：$ETH 资产桥、$NEAR 资产桥、ERC20 资产桥、NFT 桥）将自行运行 Relay 服务，并且至少有一对 Relay 服务是由 Near 官方运行的。Rainbow Bridge 的未来版本可能会增加对 Relay 服务的经济激励，并增加相应的对跨链用户/应用的收费机制。

**进展

Near 发布了 EVM 兼容环境 Aurora，目前 Rainbow Bridge 2.0 支持的是以太坊与 Aurora 的跨链，如果需要从以太坊跨链到 Near，需要经过 Aurora 中转。需要注意的是，Aurora 尽管维护了一个独立的账本，有独立的区块链浏览器，但并不是一条独立区块链，而是 Near 上的一个 runtime，Aurora 没有独立的验证者集，Near 与 Aurora 之间的桥不是跨链桥，而是 runtime 之间的桥。

我们还需要留意的是，在本文写作的时候，以太坊刚刚完成 PoS 转型。所以 Rainbow Bridge 和 WaterLoo Bridge 中的针对 PoW 版本 设计的以太坊轻客户端，可能在不久之后被重新设计。

Near 介绍文档

5.5.5 Snowbridge（Snowfork）

SnowBridge 是带有波卡官方性质的跨链桥项目，由 Snowfork 团队开发，其目的是创建波卡生态和以太坊之间的原生验证桥。

Snowbridge 是一个仍在开发中的项目，我们对其的知识源于 SnowBridge 的现行文档，该文档看起来还未完成，有些地方写的还是「coming soon」，我们只能基于现有的材料对 snowbridge 进行分析。

Snowbridge 将有一条自己的平行链，未来将作为一条公益平行链运行，称为 SnowBridge Parachain，由该平行链负责与以太坊建立桥接，其他的平行链将通过 SnowBridge Parachain 与 XCMP，间接与以太坊桥接。这意味着，将在 SnowBridge Parachain 上面运行以太坊的轻节点 Pallet。

* Substrate 当中没有合约的概念，开发者通过添加 Pallet 向链部署应用程序，但其本质与合约是相同的，都是链上的 runtime。 

Snowbridge 将由以下模块构成

部署在以太坊上的合约：

· Polkadot RPC：用于处理以太坊上的跨链请请求

· 波卡及其平行链轻客户端验证器（POLKADOT AND PARACHAIN LIGHT CLIENT VERIFIER）

部署在 Snowbridge Parachain 上的 Pallet ：

· ETHEREUM RPC 用于处理波卡上的跨链请求

· 以太坊轻客户端验证器（ETHEREUM LIGHT CLIENT VERIFIER）

Snowbridge Parachain 上的以太坊轻客户端

根据 Snowbridge 的现行文档（2022.10.14），以太坊轻客户端被设计为了一个 SPV 轻节点，Relayer 将负责逐个的将以太坊的区块头同步过来，轻客户端 Pallet 将检查工作量证明，并遵循最重的分叉。但为了适配转型为 PoS 之后的以太坊，Snowbridge 应该会有新的方案。

以太坊上的波卡轻客户端

需要注意的是，由于 SnowBridge Parachain 的共识是中继链负责的，因此该轻客户端同步的将是中继链的区块头，而非 SnowBridge Parachain 的区块头。为了随时掌握**的验证人集信息，必须同步包含验证者集改选的区块头，这意味着每个 Epoch 至少需要同步一个区块头。当有交易需要验证时，再按需从中继链请求 SnowBridge Parachain 的区块头，并用包含它的中继链区块头验证其最终性。

相比 WaterLoo，Snowfork 要面对一个新问题：EOS 只有 21 个验证人，但波卡有 1000 个左右的验证者，即便刚好有 2/3 的验证人签名了一个区块，在以太坊验证 600 多个签名消耗的 Gas 也高到令人发指。Rainbow Bridge 通过乐观验证机制，绕开了这个问题，而 Snowfork 选择直面它。Snowbridge 的方案是采取一个抽样机制：在获取区块头时，轻客户端从该区块头对应的验证者集中，随机抽取一个子集，轻客户端将仅仅验证这个子集的签名，而不必验证所有的签名。根据 Snowfork 的研究论证，这个子集的验证人数量仅需 ceil(log2(3*N)) 个（N 为验证总数）。如果 N 是 1000，那么只需要抽取 12 个验证人的签名。

BEEFY

Polkadot 为了更好的支持与其他公链的桥接，在 GRANDPA 共识基础上，开发了一个最终性小工具，称为 BEEFY（截止撰文，BEEFY 的代码还在完善中）。当波卡中继链的区块被 GRANDPA 终结之后，还有一个 BEEFY 共识签名环节，在该环节，验证人需要为区块头添加 MMR 根植，然后对区块头进行单独的一轮共识签名。

有了 BEEFY 之后，轻客户端将不需要了解 GRANDPA 的复杂性，只需验证 BEEFY 签名。最重要的是 BEEFY 签名格式完全兼容以太坊，方便在以太坊端进行验证。

激励措施

SnowBridge 分为两个阶段发布，第一个阶段发布的是 Basic Bridge，该阶段已具备跨链桥的基本功能，但没有激励层，对于 Head Relayer 和 Message Relayer 都没有激励措施。如果用户/应用 想要保证自己的消息被中继成功，需要自己运行 Relayer 服务。第二个阶段将过度到 Incentive Bridge，该阶段将设立对 Relayer 的激励措施。

应用层

在 Snowfork 团队的规划中，在 SnowBridge 上线之后，将很快发布三座资产桥，分别是

· DOT 资产桥：支持在以太坊上创建 snowDOT

· ETH 资产桥：支持在波卡端创建 snowETH

· ERC20 资产桥：支持在波卡端创建 ERC20 资产的映射版本，命名格式为：snow-[资产名]。

Snowbridge 文档

5.5.6 LCMP（Darwinia）

LCMP（Light-client Cross-chain Messaging Protocol）是 Darwinia 开发的异构跨链协议，是一个基于轻客户端方案的通用的、开放的跨链传输协议。该协议目前以 SDK 的方式，允许 Dapp 自由集成。

Darwinia 构筑的跨链生态结构中，有 Darwinia Chain、Darwinia Parachain 两条链，其中 Darwinia Parachain 是 Polkadot 的平行链，二者都有相应的金丝雀网络，Crab Chain、Crab Parachain，其中 Crab Parachain 是 Kusama 的平行链。

Darwinia Chain 上被部署了一个 EVM 的兼容环境，称为 Darwinia art Chain，被称为 Chain 是因为 Darwinia art Chain 拥有独立的状态机和浏览器，但它并不是一条独立的区块链。（参见 Aurora 与 Near 的关系）

相应的，Crab Chain 上也有一个 EVM 兼容环境，被称为 Crab art Chain。

5.5.6.1 轻客户端设计

截止撰文，LCMP 已经实现了

· Darwinia Chain 与 以太坊的桥接

· Crab Chain 和 Crab Parachain 的桥接

其中，后者用到的轻客户端方案与 Waterloo 别无二致，我们重点关注 Darwinia Chain 与以太坊的桥接用到的这组轻客户端。

Darwinia Chain Client On Eth

由于 Beefy 还不可用，基于 Substrate 开发的 Darwinia Chain 的区块头签名，不被以太坊兼容。Darwinia 目前采取了一个过渡方案，通过议会的治理选举了一个签名人小组，专门负责签署 Darwinia Chain 的区块头，轻客户端将通过验证该小组的签名来确认区块头是否合法。尽管 Darwinia Chain 上有超过 100 个验证人，但签名人小组不超过 10 人，验证这些签名，在以太坊端的经济成本是可接受的。

Eth Client On Darwinia Chain 

合并之后的以太坊信标链，作为一条 PoS 链，有数十万个验证人，验证他们的签名显然不现实。因此以太坊在一次被称为 Altair 的升级中，增设了一个新的共识环节。Altair 升级后，以太坊链上每 256 epoch（大约 27 小时）就会从验证人中选出一个委员会，该委员会有 512 名验证者，他们将负责对已经终结的区块头进行签名。轻客户端仅需验证委员会当中是否已经有 2/3 签署，就可以验证一个区块头。不过 512 个仍然有些多，因此以太坊还采用 BLS 技术，将委员会的众多签名聚合为一个签名，这进一步降低了轻客户端的验证成本。Darwinia 已经基于 Altair 升级，在 Darwinia Chain 上实现了以太坊的轻客户端，该轻客户端只需每 27 小时同步一个区块头。这应该是基于 PoS 转型后的以太坊实现的第一个链上轻客户端。

5.5.6.2 LCMP 的结构

LCMP 的整体结构设计的非常优雅且清晰。

如上图，LCMP 分为信任层（Truth Layer）、传输层（Message Layer）和应用层（App Layer），其中，信任层由源链和目标链上的轻客户端和 Head Relayer 组成，传输层由一组负责处理消息收发的合约，以及 Message Relayer 组成。图中，没有区分 Head Relayer 和 Message Relayer，但在实际运行中，这是两个不同的服务。

LCMP 的消息传输 

LCMP 的消息发送遵循「三次握手」原则，熟悉 TCP 协议的朋友对此应该不陌生。这意味着消息的发送会经历三个环节

· 消息从源链发出，抵达目标链

· 消息抵达的回执从目标链返回源链

· 回执抵达的消息从源链再被发送到目标链

在完成这三个环节之后，有两个条件被满足

· 源链知道目标链已经收到消息

· 目标链也知道源链知道目标链已经收到消息

这对于应用层的设计将提供很大便利。

消息流

在了解了这一层之后，我们再来看 LCMP 的消息流（Message Lifecycle）

1. send_message 

应用层合约调用 outbound 合约中的 send_message 功能，outbound 合约将存储该消息并发出一个 “MessageAccepted” 事件。消息进入待发列表，初始状态为 ：undelivered（待发送）

2. relay

Relayer 作为一个链下**角色，将消息传送到目标链的 inbound 合约，并生成消息送达的证明 receive_messages_proof()，消息会被 inbound 合约传递给目标应用程序，发出 “MessageDispathed” 事件，此时，消息状态在目标链的 inbound 合约中被标记为 delivered（已送达）。

· 消息所承载的任务将由目标应用程序执行。此处，开发者可以提供一个自定义的过滤器，过滤不需要的消息。

3. confirm (source chain)

Relayer 将 receive_messages_proof 传回源链，并生成 receive_messages_delivery_proof，发出 MessageDelivered 事件，消息在源链 outbound 合约中被标记为 Comfirmed（已确认）状态。

· 源应用程序收到 MessageDelivered 事件，可以去执行开发者自定义的一系列动作。

4. reward 

在源链 outbound 合约中的消息被标记为 Comfirmed 之后，进行费用清算，Relayer 在源链的账户自动获得报酬。

5. comfirm (target chain)

Relayer 将消息在源链 comfirmed 并且 rewarded 的信息传递到目标链，目标链 inbound 合约将消息状态标记为 comfirmed。

· Relayer 可以批量处理该动作，但如果目标链的 inbound 合约中积累的 deliverd（已送达但未确认）消息过多，会导致其停止接收新消息。Relayer 必须定期执行此动作，才能让消息不至于被阻塞。

费用与激励

跨链发起者（可能是用户，也可能是 Dapp）在发送跨链消息时需要支付费用，费用将包含三个部分：

1. 执行源链交易的 Gas 费用。

2. 支付给 Relayer 的费用。

具体定价由市场决定，众多的 Relayer 可以展开价格竞争。

需要注意的是，Relayer 需要支付目标链上的 Gas 费用，Relayer 会在定价中体现这部分成本，也就是说，跨链发起者无需再单独支付目标链上的 Gas 费用。

3. 支付给 Treasure 的费用。

跨链发起者支付的跨链费用中，会有一定比例进入 Darwinia Treasure。Treasure 会有部分资金用于补贴 Head Relayer。

Darwinia Docs以太坊 Altair fork

5.5.7 zkBridge

在撰写本文时，zkBridge 是一个刚启动不久的项目，只完成了少量的开发。但该项目是目前为止，为数不多的将零知识证明技术用于跨链桥构建的项目之一。zkBridge 将 ZK-SNARK 证明用于轻节点的扩容。

目前 zkBridge 已经以 Solidity 在以太坊上实现了一个 Coos Client 的实例，据测试，可以在 2 分钟内生成一个 Coos Zone 区块头的 ZK-SNARK 证明，然后在以太坊端，仅仅花 220k gas 就可以验证它，对比来看，如果不用 ZK-SNARK 证明，这个费用将是 64 Million Gas。

zkBridge 的主要创新是：

· deVirgo：采用分布式的方法来生成 ZK-SNARK 证明，该方法称为 deVirgo，该方法通过将计算工作进行拆分，分配给更多的设备，大幅度提升了在链下生成 ZK-SNARK 证明的时间。

· 递归证明：为了降低链上成本，zkBridge 使用递归证明的方案（生成证明的证明），通过两次递归，将 ZK-SNARK 证明的体积压缩到 131 字节左右

· 批处理：zkBridge 实现了一个区块头的更新合约，它以区块高度为输入，返回相应区块头。但 zkBridge 并不会在每个新区块产生时，调用更新合约，证明者可以先收集 N 个区块头，生成一个单一的证明。N 值可以设置，N 越大，用户等待时间越长但系统运行成本越低。

不得不说，零知识证明技术是一项可以创造奇迹的技术。限制其采用的主要瓶颈在于技术门槛高，开发难度大，但在零知识证明技术的开发上，回报与付出总是相称的。

关于 zkBridge，更多的技术细节还有待披露，我们将保持关注。

zkBridge 推特长文zkbridge 论文：zkBridge: Trustless Cross-chain Bridges Made Practical (arxiv.org) 

5.5.8 MAP Protocol

MAP Protocol 是一个基于轻客户端和中继链的通用异构跨链协议。与前述的众多项目不同，MAP 选择建立一条中继链 MAP Chain，作为跨链消息传递的中转站。接入链之间无需直接建立连接，而是都与 MAP Chain 建立连接，也就是说：每条接入链只需部署 MAP Chain 的轻节点合约，MAP Chain 上部署每条接入链的轻节点合约。

MAP Protocol 的架构分为三层，分别是协议层，跨链服务层、应用层。其中：

· 协议层我们可以理解为信任层，包括 MAP Chain 和各个接入链轻客户端程序；

· 跨链服务层为应用层提供一些通用模块，让应用层不必「重造车轮」，例如一个通用的 Vault 模块，可以替一些资产桥应用程序锁定资金，不过应用程序也可以选择自建 Vault 而不使用该模块。

· 应用层是指使用 MAP protocol 作为跨链消息传输媒介的应用程序。

此外，MAP Protocol 包括三个链下角色

· 维护者（Maintainer）：负责更新各轻节点合约的区块头，可以获得 $MAP 通胀奖励。

· 信使（Messager）：负责传递跨链消息，可以获得用户支付的跨链费用，但需要垫付目标链和中继链上的 Gas 费用。

· MAP Chain 验证者：负责 MAP Chain 共识过程，需要质押 $MAP，可以获得 $MAP 通胀奖励。MAP Chain 目前采用 IBFT-PoS 共识机制。

消息流 

MAP Protocol 的文档中对消息传输机制没有过多着墨，从目前的只言片语中看，消息流应该是这样的：

当源应用程序发起跨链请求时，跨链消息 M 被包含在一笔交易 T1 中，被信使发送到中继链上，中继链收到交易 T1 之后，将交易 T1 及其携带的消息 M，包含在交易 T2 中，信使将 T2 中继到目标链，目标链收到 T2，将其验证之后发给目标应用程序。

尽管 MAP Protocol 是一个 2019 年发起的项目，但由于轻节点合约的不通用性，迄今为止，支持的链也只有 以太坊，BSC 和 Pogon，于「通用」二字，还有所名不副实。

在 MAP Protocol **发布的 Litebook 里提到，MAP 将会采用 ZK-SNARK 技术来提高链上轻节点合约的性能，但我们目前还没有看到与此相关的实例。

MAP Protocol 文档

5.5.9 Coos IBC

IBC 是一个设计非常精巧的同构跨链协议，是 Coos 跨链网络的重要组成部分。

Coos 跨链网络主要由 Hub 和 Zone 组成，Zone 与 Hub 之间通过 IBC（InterBlcokChain）协议建立桥接，Zone 与 Zone 之间以 Hub 为中继建立桥接。Coos 跨链网络还包括 Peg Zone 与异构桥接的部分，不属于 IBC 的范畴。

Hub 和 Zone 都是开放准入的，任何基于 Coos SDK 构建的区块链都可以成为一个 Hub，或成为一个 Zone 并向任意一个 Hub 注册为接入链。不同于波卡的中继链，Coos 的 Hub 不是唯一的。

5.5.9.1 轻客户端

每个向 Hub 注册的 Zone 都需要部署一个 IBC 模块，该模块中包含了 Hub 的轻客户端合约，Hub 当中的 IBC 模块也会集成每个接入的 Zone 的轻客户端合约。

Tendermint 共识机制中没有 epoch 的概念，每个区块都有可能会产生验证者的变动。但 IBC 中的轻客户端合约中有一个 TrustPeriod（信任期）的概念，这是轻客户端在初始化时需要设置的一个参数，在一个 TrustPeriod 内，允许验证者集产生微小的变化，个别验证者可能加入或者退出，但不会有大的变动。

这种微小的变化是可以接受的，因为每次签名几乎不会只有刚好 2/3 的投票权签名，总会有一定的溢出，即便个别验证者加入或者退出，轻客户端按照变化前的验证者集去检查该区块头，大概率还是能观察到 2/3 权重的投票权签了名。

因此 IBC 中的轻客户端合约，只需每个 TrustPeriod 更新一次验证人集的信息即可，这意味着每个 TrustPeriod 只需同步一个区块头。同步区块头的工作将由 Relayer 来执行。

5.5.9.2 核心概念与原理

IBC 构建了三个抽象概念，分别是 Connection（连接）、Channel（信道）、Packet（数据包）。

Connection 

是指两个 Zone 之间的连接，建立 Connection 可以理解为将两个 Zone 进行配对，此时，两个 Zone 向 Hub 请求对方的轻客户端的**区块头。Connection 的建立遵循三次握手原则（握手通讯均由 Relayer 触发），握手完成后，Conenction 开启。此时，可以在 Connection 之上，建立 Channel。

Channel

Connecion 连接的是两个 Zone，而 Channel 连接的则是 分别在两个 Zone 上的一对应用程序（这一对应用程序可能是同一个应用，也可能是不同的应用）。两个应用程序通过三次握手原则建立 Channel（握手通讯由 Relayer 触发），Channel 建立之后，这两个应用程序就可以相互发送 Packet 了。

Channel 是 IBC 中最核心的概念，他让应用程序直接建立连接。作为一个抽象概念，Channel 并不存在一个实体，对于接受端应用程序而言，Channel 定义了发件者，知道消息从哪个 Channel 传过来，就知道消息来自哪个 Zone 上的哪个应用程序，对于发送端应用程序而言，Channel 定义了收件端，想要向哪个应用程序发送消息，就把消息放进对应的 Channel。

Channel 还定义了消息时序，同一个 Channel 当中的消息遵循一个队列，具有严格的时序关系，先发的消息始终先到。不同 Channel 中的消息之间则没有时序关系。

这里需要注意的是，一个应用程序**稳定的使用一个 Channel。例如，一个资产桥应用如果使用多个 Channel 来在目标链创建映射资产，那么多个 Channel 会生成不同的映射资产，这将带来不必要的麻烦。

Packet

Packet 是一个规范的数据结构，是在 Channel 中被允许传送的跨链消息的规定格式。Packet 的传送分为三个步骤：

1.sendPacket：发送端的应用程序在源链上创建一个序号为 N 的 Packet，并加入待发队列；

2.recvPacket：Relayer 将该 Packet 中继到目标链，由接收端的应用程序存储。

3.acknowledgePacket：Relayer 将接收端应用程序已经存储该 Packet 的证明，传回源链，源链在待发队列中删除序号为 N 的 Packet。如果接收端合约长时间没有存储该 Packet，Relay 返回 timeout 的讯息。

需要注意的是，Coos IBC 与 MAP Protocol 不同，Packet 的发送是直接从源 Zone 抵达目标 Zone 的，并不需要在 Hub 中转。这是因为目标 Zone 可以向 Hub 直接 query 源 Zone 的区块头，然后执行对 Packet 的验证。这意味着，Hub 只需中转区块头就可以了。

Hub 上有源 Zone 的轻节点，可以验证源 Zone 的区块头，目标 Zone 上有 Hub 的轻节点，可以验证 Hub 的区块头，当目标 Zone 需要某个源 Zone 区块头 SourceZoneBlockHead{i} 的时候，可以让 Relayer 从 Hub 去获取，目标 Zone 上的轻节点验证 HubBlockHead{i}，并用 HubBlockHead{i} 验证 SourceZoneBlockHead{i} 之后，就可以用 SourceZoneBlockHead{i} 验证源 Zone 的 Packet 了。

费用与激励 

IBC 当中有一个可配置的费用模块，Connection 的发起方可以自定义收费标准及对 Relayer 的支付标准。不过根据我们的观察，Zone 的项目方和应用程序项目方往往都有动力自己运行 Relayer。

Coos IBC DocsCoos IBC 代码分析

5.5.10 原生验证桥小结

以上我们列举了若干个原生验证桥，可以发现大多数原生验证桥，都只连接了 2 个或者略多于 2 个链，这是由于轻客户端的不通用性导致的，随着兼容链的增加，边际成本并不会递减。另外，我们看到，随着以太坊的 PoS 转型，不少连接以太坊的原生验证桥都需要重新开发轻客户端，轻客户端是和源链的共识机制高度相关，往往需要随着链的升级而升级，这是原生验证桥的另一大困扰。由于以上两个原因，导致原生验证桥整体发展较慢，且不少项目还在艰苦的开发过程中。

Coos 则通过 Coos SDK 以及内置于其中的 Tendermint 共识协议，创造了一套开箱即用的造链工具，使得 Coos IBC 能够被动兼容基于 Coos SDK 开发的链。Coos 已成为目前是区块链世界仅次于以太坊的生态网络，刚刚完成 2.0 升级的 Coos，正在继续发力，完善跨链可组合性。

目前来看，在轻客户端方案的设计上，PoW 轻客户端还是以 SPV 轻客户端为主，逐个同步源链的所有区块头，PoS 轻客户端则大多采用跳跃式同步区块头的方案，仅同步验证者集发生变化的区块头，我们只需要让轻客户端在初始化正确的情况下，掌握验证者集的变化，就可以让轻客户端掌握**的验证者集。

实践中，轻客户端的构建还会遇到区块头验证成本过高，签名方案不兼容等问题，不同的项目会采取不同的方法应对，包括乐观验证（RainbowBridge）、验证者集抽样（Snowfork）、链下生成零知识证明（zkBridge），此外，公链为了更好的支持跨链，也有动力对自身进行改造和升级，例如以太坊 Altair 升级和 Polkadot 开发 Beefy 模块。

总之，轻客户端技术依旧处于激烈的演化之中，随着更多研究与探索的进行，未来构建轻客户端的难度会逐步降低。而我们本文所讲的这些案例中提及的方案，过时的速度可能比我们想象的快。

下面的章节，我们将开始一个新的旅程，那就是目前在跨链桥项目中占比**的外部验证桥。

5.6 外部验证桥

外部验证由于开发成本较低，通用性好，可以迅速兼容大部分的公链，成为大多数的跨链桥项目选取的路线。我们将在本文中，挑选几个具有代表性的展开介绍。

在本章中，我们依旧会重点关注跨链桥的信任层构建，因此项目举例会以 AMB 桥为主，资产桥的部分我们后文有专门的章节。

5.6.1 Anycall（Multichain）

Mutichain 是入场较早的跨链桥项目，产品上线于 2020 年 7 月，当时的名字叫 Anyswap。2021 年底融资之后，品牌名称改为了 Multichain，治理通证也从 $ANY 置换为了 $MULTI。在遭遇 2022 年初的合约漏洞事件之前，Mutichain 的业务规模是跨链桥领域无可争议的**，但在漏洞事件造成很多用户的资产损失后，TVL 有所缩减。

现在 Multichain 的业务被规划为三条产品线，分别是

· Swap 桥：Anyswap

· Wrap 桥：Crosschain Router Protocol（CRP）

· 任意消息桥：Anycall

其中 Anycall 是前两者的信任层。

AnyCall 是一个用户交换任意数据的通用跨链传递基础设施，采用 PoA 的方式构建。它由部署在链上的一组智能合约（anycall/anyExec），和一个 PC 网络组成。PC 的含义是安全多方计算（Secure Multi-Party Computation），Anycall 当中的每个 PC 节点独立验证消息，并基于私钥分片和门限签名技术，对消息进行签名，超过 2/3 节点签名的消息被认为通过验证。

PC 网络由 24 个节点组成，这些节点将负责监听链上 [anycall] 合约中的待发消息，并进行签名后，中继到目标链的 [anyExec] 合约。Dapp 通过与 anycall/anyExec 合约交互来实现跨链消息的收发。PC 节点成员不需要质押，且相对固定，AnyCall 的安全建立在对 PC 节点的信任假设基础上。

Multichain 的治理通证 $MULTI 的持有者，可以通过锁仓 $MULTI 获得 veMULTI，用其参与 Anycall 及 Multichain 旗下其他产品的治理，并可以获得 Multichain 的收入分成。

截至 2022 年 9 月，anyCall 支持跨 11 条链的任意消息传递：BNB Chain、Pogon、Ethereum、Optimi、Gnosis Chain、Fantom、Moonriver、IoTeX、Arbitrum、Avalanche、Harmony。明星 DeFi 项目 Curve 集成了 anycall 以支持 Gauge Weights 的跨链计算。

Multichain 文档

5.6.2 Wormhole

Wormhole 是由 Solana 和 Certus One 联合开发的跨链桥，起初是一座连接以太坊和 Solana 的资产桥。但随着后来的发展，Wormhole 已经演变成了一个支持 14 条异构公链之间传送任意消息的通用 AMB 桥，而资产桥的功能将由作为 Wormhole 应用程序的 Portal Bridge 承担。

和 Multichain 相同，Wormhole 的信任层采用 PoA 机制构建，由一组受信任的 Guardians（守护者)）负责链间消息的验证。这些 Guardians 是特定的具有资本背书和声誉背书的主体。目前，Wormhole 中的 Guardians 有 19 个，其中包括 FTX、Everstake 和 Chorus One 等知名大公司。

Wormhole 的结构非常简洁，其跨链消息格式被称为 VAA（Verifiable Action Approval），在 Wormhole 支持的链上部署了一组被称为 Core Bridge Contract 的合约。该合约将来自应用程序的跨链请求处理为 VAA，19 个 Guardians 监听链上生成的新的 VAA，并对其进行签名。然后被称为 Relayer 的角色负责将签名后的 VAA 中继到目标链。目前链上的 Core Bridge Contract 收到签名后的 VAA 之后，验证其签名，然后转交给目标应用程序。

Guardians 对 VAA 的签名是独立的，每个 Guardians 都单独执行该步骤，然后这些签名**组合成一个多重签名。一条 VAA 的批准，需要至少 2/3 的 Guardians 签名。Guardians 的成员是相对固定的，如果需要更换，将通过治理投票来完成。

Relayer 负责传送签名后的 VAA，该动作将在目标链上产生 Gas 费用（包括将消息提交给 Core Bridge Contract 存储的 Gas 费，和目标应用程序执行该消息的 Gas 费），Relayer 将垫付这部分费用。Wormhole 没有设置公共的 Relayer，各应用程序需要自己设计对 Relayer 的激励与相应的用户端收费，或者自行运行 Relayer。

对于 PoW 的以太坊，有个最终性确认的问题。在 Wormhole 中，消息需要等待多少个区块追加才能视为确认，是一个可以自定义的安全参数。

截至 2022 年 9 月，Wormhole 支持 14 条链：Solana、Ethereum、Terra Classic、BNB Chain、Pogon、Avalanche、Oasis、Aurora、Fantom、Karura、Acala、Klaytn、Celo 和 Terra。

2022 年 2 月，Wormhole 遭遇黑客攻击，由于合约编写漏洞，致使攻击者通过伪造签名，在 Portal Bridge 上为自己铸造大量资产。该攻击造成的损失超过 3.2 亿美元。在 Jump Crypto 等主要的资方支持者的帮助下，Wormhole 已经从攻击中恢复。

Wormhole 文档

5.6.3 Gravity Bridge

Gravity bridge 于 2021 年 12 月份启动，其目标是桥接 Coos 和以太坊生态。目前，Gravity 还只是一座资产桥，支持以太坊和 Coos 之间的资产传递，不支持任意消息传递。

结构 

Gravity Bridge 的信任层以 PoS 的方式构建，Gravity Bridge 的 PoS 验证者同时也是 Gravity Chain 的验证者，因此 Gravity Bridge 可以归为共享验证桥。

Gravity Chain 由 5 个部分组成

· Gravity Chain 及其验证者：一个基于 Coos SDK 构建的区块链，其验证者将以 PoS 的方式验证 Gravity Chain 与以太坊之间的跨链消息

· 一个名为 gravity.sol 的以太坊合约：实现以太坊端的 mint-burn/lock-burn 逻辑；

· Gravity Module：实现在 Gravity Chain 端的 mint-burn/lock-burn 逻辑；

· Orchestrator：是 Gravity Chain 上的一串代码，负责向 Gravity Chain 提交交易；

· Relayer：负责向以太坊提交 Gravity Chain 上的交易，并从中获得用户支付的跨链费用。

消息流

要将 Token 从以太坊转移到 Gravity Chain，用户需要调用 sendToCoos 方法。该方法从用户那里接收一定数量的 ERC20 Token 并将它们锁定在 Gravity.sol 中。它还发出一个事件：SendToCoosEvent。Gravity Chain 的每个验证者都运行一个以太坊全节点以监控以太坊的事件，当任意一个验证者监控到 SendToCoosEvent 时，Orchestrator 将向 Gravity Module 提交事件，Gravity Module 将跟踪事件，当该事件被 Gravity Chain 的验证者签名验证并被打包到区块中时，触发 Gravity Module 为目标地址铸造 Token。与 PoA 不同的是，PoS 中，每个验证者的签名权重是不同的，签名权重与他们的质押的 $GRAV 成正比。

如果要将 Token 从 Gravity Chain 转移到以太坊，过程相对简单，只需要 Relayer 将 Gravity Chain 上验证过的 lock 或者 burn 交易，提交到以太坊，gravity.sol 合约将为目标地址铸造 Token。

批处理

由于以太坊上 gas 费用高昂，从 Coos 到以太坊上的交易将会实施批处理。

当用户想要将 Token 从 Coos 发送到以太坊上的地址时，他们会通过 Gravity Module 将 Token lock（原生资产）或是 burn（非原生资产）。Gravity Module 将 lock/burn 交易放入交易池中。交易池存储所有尚未成批的 Coos 到以太坊的交易。（同一批次的交易仅限于一种 Token，不同的 Token 转移会被分配到不同的批次中）

任何人都可以发送请求 Gravity Module 组装一批交易，这往往由希望中继一批 Token 以获取利润的中继者完成。当 Gravity Module 收到此消息时，它会按照以下过程组装批次：

1. 查找该 Token 的所有交易；

2. 选择费用**的 100 笔交易，并将它们放在一起，组成一个批次；

3. 如果中继该批次有利可图，则将该批次放入批次池，若无利可图，则放弃该批次，批次中的交易会回到交易池中，等待组装到其他批次；

4. 进入批次池中的批次，将被验证者签名，并被打包到区块中；

5.Relayer 持续监控批次池中的批次，一旦有批次的签名超过阈值（2/3），就将其提交给以太坊上的 gravity.sol，并支付以太坊上提交和处理该批次的 gas 费用；

6. 批次处理完成后，Gravity.sol 就会发出一个 TransactionBatchExecutedEvent，验证者观察到该事件后，将其提交给 Gravity Module，触发删除该批次。

验证者集的更新 

Gravity.sol 需要了解 Gravity Chain 上的验证者更新，才能判断 Relayer 发送过来的消息或是批次，是否是被正确的验证者集签名。

任何人都可以从 Gravity Chain 发送跨链消息，请求更新 Gravity.sol 中的验证者集。我们在讲原生验证桥时，提到过 PoS 轻客户端掌握**验证者集的方法，Gravity.sol 用到的方法与之相似，但 Gravity.sol 并不是轻客户端，它不会存储 Gravity Chain 的区块头，而是让 Relayer 将验证者集的变更信息快照中继过来，存储为一个检查点。

所有的 PoS 跨链桥，包括我们后文提到的 Axelar、Hyperlane，用的都是类似的办法。

Gravity Bridge 介绍

5.6.4 Axelar

Axelar 发起于 2020 年年底，主要成员来自 Algorand 团队的跨链桥项目，致力于为 Web3 应用提供跨链互操作性。2022 年 2 月 15 日，Axelar 以 10 亿美元估值，完成 3500 万 美元融资，投资方包括 Dragonf Capital、Pochain Capital 等知名机构。

Axelar 基于 PoS 机制构建桥梁的信任层，Axelar 本身也是一个基于 Coos-SDK 创建的 PoS 公链。需要注意的是，Axelar 本身是公链，但它并不是中继链，只是桥接链，这两个概念在本系列第一篇中有过辨析。

结构 

Axelar 由以下部分构成：

· PoS 验证器网络：由 $AXS 驱动，承担双重职责 负责验证网络正在处理的所有跨链活动，这需要验证器运行接入链的节点（可以是全节点，也可以是轻节点）； 负责 Axelar Chain 的交易验证和共识出块；

· **合约（Gateway art Contracts）：部署在每条接入链上，以实现跨链消息收发功能；

· 开发者工具：包括一套软件开发工具包（SDK）和应用程序编程接口（API），借助这些工具，开发人员可以轻松部署跨链 dApp，并使用 Axelar 网络实现跨链任意消息传输。

此外，为了改善用户体验，Axelar 还提供了两组 Relayer 服务和 Gas Reciever 合约。

Relayer 服务：其中一组 Relayer 负责监听源链**合约上发起的跨链消息并提交给 Axelar 网络，另一组 Relayer 负责将被验证过跨链消息提交给目标链的**合约，垫付目标链上存储和执行消息的 Gas 费。Relayer 服务是可选的，用户和应用也可以执行这两组 Relayer 承载的任务。专设一组 Relayer 负责监听源链消息，是为了降低验证者的负荷。

Gas Reciever：用户的跨链操作将产生三笔 Gas 费用，分别是源链上的 Gas 费用，Axelar 验证器网络的费用（$AXS 形式），目标链的 Gas 费用，如果要求用户分别支付这三笔费用，那么用户体验将相当糟糕，Axelar 在源链上提供 Gas Reciever 服务，用户仅需以源链的 Token 支付一笔跨链费用，Gas Reciever 会自动将其中的一部分兑换为 $AXS 和目标链的 Token。

消息流

一旦 dApp 用户发起跨链消息发送请求，其第一站是与源链上的**合约交互，**接收到消息将发出一个事件，Relayer 监听到事件，然后将消息提交给 Axelar 验证器网络。

验证器网络对该消息进行签名，签名权重与他们质押（包含被委托质押）的 $AXS 数量有关。但签名权重与质押的 $AXS 数量并不是线性关系，Axelar 采用的是二次方投票（Quadratic Voting）机制，签名权重将与验证人质押的 $AXS 数量的平方根成正比。需要注意的是，二次方投票仅针对跨链消息的投票，Axelar Chain 自身的交易签名和区块签名仍遵循一 $AXS 一票原则。

消息被签名后，Relayer 将消息提交到目标链 Gateway 合约，并由目标应用程序处理。

Axelar 作为一个基于 Coos-SDK 构建的公链，除了通过验证器网络桥接了一众 EVM 链的跨链以外，还通过 IBC 进行扩展，接入了更多 Coos 链。目前接入 Axelar 的网络已经有 22 个。Axelar 之所以能有现在的成就，与其深度融入 Coos 生态系统有很大关系，Axelar 在开发和治理过程中，有 Coos 社区的积极参与，而且通过将 Terra、Classic、Oosis、Secret Network 和 Jun 等 Coos Zone 连接到 EVM 世界，获得了大量的跨链业务量。

Axelar 文档

5.6.5 Hyperlane（曾用名：Abacus）

Hyperlane 被人所熟知的名字是 Abacus，它拥有一个阵容豪华的创始团队。团队中有 Celo 的首批工程师 Asa Oines 和 Nam Chu Hoai 以及之前共同领导 Galaxy 风险投资业务的 Kol。顾问包括 NFX 的合作伙伴 Morgan Beller、Facebook 的 Stablecoin Diem 的联合创始人，以及 Coos 联合创始人 Zaki Manian。2022 年 9 月 22 日，Hyperlane 宣布完成 1850 万美元融资，加密风投 Variant 领投。

Hyperlane 将致力于提供一组 API 接口，让应用程序通过调用它实现跨链消息的收发。

结构 

Hyperlane 包括以下组成部分：

· 链上负责消息收发处理的合约：分别是 outbox 合约和 inbox 合约，每条接入链上都有一个 outbox 合约，outbox 合约中维护了一个由所有消息作为叶子节点的默克尔树（称为消息树），需要发送的消息将提交到 outbox 合约，作为新的叶子节点插入消息树，使消息树产生一个新的根（称为消息根）。每条接入链上都有（n-1）个 inbox 合约（n 为接入链的数量），inbox 合约将负责接收和验证跨链消息，并将其转交给目标应用程序。

· 多个 PoS 验证者集：每条接入链都有一个验证者集，负责签署从该链发出的消息的默克尔根，PoS 验证者需要在其负责验证的链上抵押 $ABC（可能来自其他用户的委托），签署任何消息根之外的内容都被视为欺诈行为，其抵押金将被削减；

· Relayer：负责传递被签署后的消息根，传递消息以及消息的默克尔路径；

· 瞭望塔（Watchtower）：负责监控和报告验证者的欺诈行为。

消息流

发送和接收跨链消息需要四个步骤：

1.用户通过源应用程序调用源链上的 outbox.dispatch 函数，将消息 M 插入到消息树中；

2.源链的 Hyperlane 验证者签署包含消息 M 的新的消息根；

3.Relayer 聚合验证者的签名，并将新的消息根连同消息原文（含默克尔路径）传送到目标链；

4.目标链上的 inbox 合约用消息根和消息的默克尔路径验证消息，然后将验证后的消息传递给目标应用程序。

失败处理：Relayer 可以配置为在处理失败时重试消息。第一次尝试处理失败的消息将导致 Relayer 以指数退避重试。在达到**重试次数后，Relayer 将不再尝试处理该消息。

Hyperlane 的一大特点是采用消息树结构，这样做的好处有两个：一是验证者不知道消息的具体内容，防止验证者审查消息；二是便于瞭望塔发现欺诈行为，瞭望塔将不需要观察消息本身有没有被篡改，只要被签署的消息根没有篡改，消息就不可能被篡改。

Hyperlane 的另一个特点是每条链上都有独立的验证者集，而不是复用同一个验证者集，这可能导致从不同链发出的消息传递安全性不一致，因此 Hyperlane 为应用程序提供灵活的选择，如果 dApp 项目方认为某个特定链安全性不足，可以选择不集成该链。

费用与激励 

PoS 验证者每个 epoch 可以从网络中获得 $ABC 通胀奖励。

Relayer 可以自定义费用结构，以在源链上接受用户的付款，并用其中的一部分支付目标链上的 Gas。Relayers 将组成一个开放的市场，而发起跨链请求的应用程序用户作为买方，自由选择适合的 Relayer。

「可验证欺诈证明」

Hyperlane 将其核心机制描述为「可验证的欺诈证明」，所有的消息根都存储在 outbox 合约中，PoS 验证者集的工作仅仅是为其附上自己的签名，如果在目标链上发现 PoS 验证者签署了篡改后的消息根，瞭望塔就可以把不正确的签署作为欺诈证明提交到源链上，源链上的合约很容易对欺诈进行验证。

这样的机制与乐观验证颇有相似之处，但 Hyperlane 没有乐观验证窗口期，这意味着瞭望塔报告欺诈行为的时候，很有可能行为的后果已经产生（例如不正确的铸币），我们还是需要相信，每条链上 2/3 以上的验证者是诚实的。因此，我们依旧将 Hyperlane 归为外部验证。

但相比其他类型的 PoS 桥，「可验证的欺诈证明」还是有一些明显的不同：

Axelar 这样的 PoS 桥，尽管也会对恶意的验证人进行 Slash，但对恶意验证人的判定方法是「多数原则」，也就是说，如果个别验证人签署了某个消息，而该消息最终没有被 2/3 以上的投票权验证，那么签署该消息的个别验证人将被认为是恶意的，从而触发 Slash。如果发生「真理掌握在少数人手中」的极端情况，那么系统将产生误判，需要治理流程参与进来进行纠错。Hyperlane 的机制可以保证，只要有一个 WatchTower 是诚实的，即便有 2/3 以上的验证人作恶，且导致传输了错误的跨链消息，系统依然可以自动发现错误并对作为多数派的作恶验证人执行 Slash。

与 Hyperlane 机制比较相似的另一个项目 Nomad，是乐观验证的典型案例，我们将在后文介绍。

截止 2022 年 9 月，Hyperlane 支持 7 个链的任意消息传递：Arbitrum、Avalanche、BNB 链、Celo、以太坊、Optimi 和 Pogon。Hyperlane 以 DAO 的方式治理，$ABC 持有者可以通过治理投票对 Hyperlane 协议进行更改。

Hyperlane 文档

5.6.6 LayerZero

明星团队，加上明星投资者，让 LayerZero 成为 2022 年上半年最火爆的一个跨链项目，跨链底层协议的叙事，再加上迅速上线若干个落地产品的执行力，让 LayerZero 被业界普遍看好。在 LayerZero 的白皮书中，LayerZero 被描述为一个去信任的全链互操作协议，一个功能强大的基础层的通信原语。

结构 

LayerZero 由三个核心组件构成，分别是 Oracle（预言机）、Relayer（中继器）、Endpoint（终端）

来源：LayerZero 白皮书

· Oracle 是一个第三方服务，它提供一种独立于其他 LayerZero 组件的机制，从一个链读取块头并将其发送到另一个链。

· Relayer 是一个脱链服务，其功能类似于预言机，但是它不是获取块头，而是获取指定交易及其默克尔证明。

· 终端 是一系列链上智能合约的组合，LayerZero 会在每个支持的链上部署终端，以支持跨链消息的有效传递。终端分为四个模块：Communicator（通信器）、Validator（验证器）、Network（网络）和 Libraries（库）。

LayerZero 的核心设计思想在于 Relayer（中继者）和 Oracle（预言机）的分离，在 LayerZero 中，Relayer 负责传递消息及消息证明，Oracle 负责根据消息所在区块，按需从源链获取区块头，然后目标链上的终端根据 Oracle 获取的区块头验证 Relayer 传递的交易。

尽管 Layerzero 将其技术方案称为超轻节点（Ultra Light Node），但其方案与轻客户端跨链毫无关系。LayerZero 并不会在支持的链上部署任何链的轻节点，从验证方式来讲，LayerZero 通过 Oracle 提供的区块头来验证 Relayer 提供的交易证明，验证过程在目标链的终端发生，属于原生验证，但是对区块头本身的验证却是由作为外部验证人的第三方 Oracle 网络来完成的，验证过程发生在链下，从本质上讲，LayerZero 采取的方案，依旧属于外部验证。

dApp 责任制 

LayerZero 的定位更多是一个中立的信息总线和传递标准，dApp 才是跨链服务的主体。dApp 有充分的自**，可以自己决定选择哪个 Relayer，以及决定选择哪家预言机。在 LayerZero 当中，Relayer 和 Oracle 都是开放准入的，任何人都可以运行一个 Relayer，任何第三方 Oracle 网络也都可以加入（目前默认的 Oracle 是 Chainlink）。但 LayerZero 期待的理想状态是：每个 dApp 都要运行自己专有的 Relayer。在这种状态下，如果预言机网络想要串通 Relayer 作恶，构建虚假交易并验证它，必须串通控制 Relayer 的主体——dApp 项目方，而 dApp 项目方不太可能做毁灭自己的事情。

此外，即便出现了联合作恶的情况，风险依旧可以限制在 dApp 内部，不会波及其他使用不同 Relayer 的 dApp，这是一种风险隔离措施。

尽管如此，我们认为上述的串通并不是完全不可能，虽说 dApp 项目方大多数时候不会反对自己，但这不排除那些打算 rug-pull 的 dApp 项目方。因此，我们要认识到，LayerZero 并不是像其所宣称的那样，完全去信任化。但与此同时，我们也要看到，Oracle 和 Relayer 分体的设计，和 dApp 责任制的思想，相比单纯的外部验证人网络直接负责消息传递，安全性还是得以大幅提高，LayerZero 的创新是有积极意义的。

消息流 

LayerZero 的另一大特点是模块化的终端，为了理解终端的工作机制，接下来我们来深入看下 LayerZero 的跨链信息流。 

一个跨链信息的传递被分为 13 个步骤，为了让逻辑更加清晰，我们来分组表述。

步骤1-5：是当链 A 上发生一个跨链请求后，链 A 的终端通知 Oracle 和 Relayer，分别从链 A 获取相应信息，具体如下： 

1.用户通过 dApp-X 在链 A 上产生了一笔需要跨链传递到链 B 的交易 T，并向链 A 终端上 Communicator（后简称 Communicator A）发起跨链请求，请求内容为 [t,dst，payload,relayer-args]

温馨提示：如果非技术出身的您，看到代码感觉凌乱，可将后文中所有中括号内的内容置换为「相关参数」，再进行阅读。

2.Communicator A 将跨链请求处理为一个数据包，包含 [packet(dst,payload),t,relayer-args]，发送给 Validator A ； 

3.Validator A 将 [t,dst] 发送给 Network A，通知 Network A 获取当前区块 ID ； 

4.Validator A 将 [packet(dst,payload),t,relayer-args] 发送给 Relayer，通知 Relayer 获取交易证明； 

5.Network A 将区块 ID 发送给 Oracle，通知 Oracle 获取区块头；

步骤6-9: Relayer 和 Oracle 分别获取到对应信息，并提交给链 B 上的 终端，详细如下：

6.Oracle 从链 A 获取到区块头； 

7.Relayer 从链 A 读取到交易 T 及其交易证明 proof(t)，存储到本地； 

8.Oracle 将区块头提交到 Network B ； 

9.Network B 将区块头中的哈希值发送给 Validator B ；

步骤10-11: 由于除了当前跨链请求，在同一区块内，可能还有其他跨链请求，因此 Relayer 会获取区块头，然后将所有该区块相关的跨链请求内容全部获取过来，详细如下： 

10.Validaor B 将区块头哈希发给 Relayer ； 

11.Relayer 收集当前区块内所有跨链请求及相关交易证明 [Packet(dst,payload),t,proof(t)]，返回给 Validator B ；

步骤12-13： 链 B 的终端用区块头验证这些相关的交易，并发给目标应用程序 dApp Y，跨链消息传递完成： 

12.Validator B 用区块头验证接收到的所有交易，验证不通过的交易将被丢弃。验证通过的交易 [packet(dst,payload)] 发送给 Communicator B ； 

13.Communicator B 将验证后的交易 [packet(dst,payload)] 发给 dApp Y。

我们发现，终端各模块的工作方式类似于网络堆栈，在发送端上，消息从 Communicator 到 Validator 再到 Network，在接收端上则刚好反过来。这样的设计是高度通用的，LayerZero 在支持新的接入链时，这三个模块是不用改动的，只需要在 Libarary 中添加关于新链的参数即可，这样的设计使得 LayerZero 十分便于扩展到新的区块链。

在消息流设计方面，LayerZero 会直接一次处理掉同一区块内所有的跨链请求，这样避免不必要的重复工作。

费用与激励

第三方 Oracle 服务有自己的经济模型，与 LayerZero 自身相互独立，第三方 Oracle 也将向使用 LayerZero 的 dApp 收费。

LayerZero 希望 dApp 项目方自己运行 Relayer，当然，dApp 项目方也可以制定一个付费标准，然后将其外包给社区。LayerZero 可以要求 Relayer 质押资金作为安全保障，目前 LayerZero 尚未做这样的要求。根据 LayerZero 的「dApp 责任制」的核心思想，我们推测未来 LayerZero 应该会让 dApp 项目方自己决定是否要质押，质押多少钱，质押越多，对 dApp 自身的用户而言，安全保障越高。

LayerZero 的应用现状 

LayerZero 的生态发展很快，迄今为止，已支持的公链 有 Ethereum、Pogon、BSC、Avalanche、Fantom、DFK、Harmony，还有以太坊二层网络 Arbitrum、Optimi，Avalanche 子链 Swimmer Network、波卡平行链 Moonbeam。

LayerZero 上的生态应用也开始蓬勃发展，除了 LayerZero 自建的跨链 DEX 产品 Stargate，第三方创建的跨链 DEX 产品 Hashflow、Interswap 也陆续启动。跨链 DEX 之外，LayerZero 上**发力的是 NFT 类应用，例如 NFT 收藏品 Gh0st Gh0sts、Tiny Dinos、Yakuza Pandas、跨链 NFT 桥 parakeet.dao，还有 NFT 养猫游戏 Catddle。

此外，面向机构的去中心化借贷项目 Clearpool 也宣布接入 LayerZero 以实现跨链相关功能。

LayerZero 白皮书LayerZero Docs

5.6.7 CCIP（Chainlink）

CCIP 是 Chainlink 于 2021 年底公布，目前还在开发的一个跨链堆栈。

Chainlink 是预言机领域的龙头，拥有非常丰富的节点资源，足以组成一个分布式程度更高的节点委员会、或者说 PoS 验证者集，因此，Chainlink 做跨链桥基础设施应该是水到渠成的事情。

CCIP 的跨链逻辑与 PoS 桥大致相同：

来自源链的应用程序调用 Chainlink 的消息路由器，Chainlink DONs（去中心化预言机网络）将监听到消息并对消息进行共识签名，再由 Relayer 中继到目标链，目标链的消息路由器对消息的签名进行验证并发送到目标应用程序完成执行。

但在这之外，CCIP 还引入了「反欺诈网络」风险管理系统。反欺诈网络与预言机网络相独立，作为一个新的验证层，在系统运行时定期提交心跳检查。如果反欺诈网络停止发送心跳，抑或是报告恶意行为，就会自动触发紧急关停机制。

CCIP 与 LayerZero 的设计有一个相同之处，那就是构建了两个独立的信任层。

Chainlink 目前只发布了一个非常粗略的 CCIP 文档，更细节的资料还有待披露。

CCIP 介绍

5.6.8 pNetwork v2

pNetwork 是有 Provable Things 团队开发的一个跨链桥，pNetwork V1 于 2020 年 3 月推出，是一座 Wrap 桥，Wrap 资产被称为 pTokens，2021 年 10 月，pNetwork V2 发布，该版本将 pNetwork 拓展为了一座 AMB 桥。

pNetwork V2 延续了 V1 的核心特性，那就是使用 TEE 节点组成的 MPC 网络来验证跨链消息。TEE 全称为 Trusted Execute Environment，中文译为可信执行环境，它对于我们的日常生活而言并不陌生，手机上的指纹验证就是在 TEE 中运行的。

TEE 是在给定设备上运行的与主操作系统隔离的计算环境，就像一块飞地（Encalve）。这种隔离是通过硬件强制实现的。在 TEE 中运行程序的过程是隐蔽的，外界不可感知，这减少了 TEE 遭受黑客攻击的可能性。程序在 TEE 中运行完成后，输出的计算结果会被附上一个由设备生成的签名，该签名将被设备供应商远程验证，并生成远程验证证明。远程验证证明能够向外界证实该程序在 TEE 中被完整的执行，没有被篡改和干预。正因为如此，TEE 可以运行具有高安全性要求的应用程序，例如加密密钥管理、生物特征认证、安全支付处理等。

结构

pNetwork V2 主要包括以下部分

· TEE 节点网络：任意拥有 TEE 设备的主体可以质押 200 $PNT（至少 3 个月），即可成为 pNetwork 的 TEE 节点。pNetwork 中的 TEE 节点网络将负责对跨链消息进行共识签名。在初始化时，TEE 节点集需要共同参与秘钥的计算，以生成公钥和私钥碎片，其中公钥只有一个，处于公开状态，私钥碎片则是在本地生成后，存入 TEE 中「密封」。

· Portal：pNetwork 管理跨链消息传输队列的一组链上合约；

· Postman：类似于 Relayer；

· pNetwork DAO：pNetwork 采用 DAO 的方式进行治理，$PNT 持有人可以质押 $PNT，参与治理投票，决定 pNetwork 的费用参数和发展方向。

消息流

1.用户通过源应用程序在源链调用 Portal 合约，发起跨链消息发送请求；

2.TEE 节点监听到请求，将跨链消息放到 TEE 节点中验证（TEE 中需要运行源链的轻节点），并用自己的私钥碎片签名，当签名的私钥碎片数量达到门限（2/3），将合成一个完整的签名，(不会暴露明文私钥)，这代表消息被验证通过；

3.Postman 把验证通过的跨链消息送达目标链的 Portal 合约，Portal 合约在检查签名后转交给目标应用程序。

为什么要用 TEE 节点

2022 年 3 月 23 日，Axie Infinity 的官方跨链桥 Ronin Bridge 被黑客攻击，起因是 9 个多签节点中有 5 个节点的私钥被黑客盗取。我们在该事件中，看到即便多签节点没有主动串谋，外部攻击者还是有可能从物理层面攻破多签节点的设备，窃取私钥，进而攻击跨链桥。

由于多签节点需要用程序来执行对跨链消息的签名，这使得私钥不得不暴露在网络中，极易成为黑客攻击的目标。如果让多签节点使用 TEE 设备来存储私钥、验证和签名交易，那就可以很大程度上规避这个问题，让攻击者很难下手。

pNetwork 支持节点使用不同厂商的 TEE 设备接入网络。不同厂商的 TEE 设备的具体技术方案有可能是不同的，如果众多节点的 TEE 设备来自多元化的厂商，将进一步阻止黑客攻击。因为黑客需要攻破不同的 TEE 设备，才有可能实施攻击。

应用现状

截止 2022 年 9 月份，pNetwork 支持 9 条链的任意消息跨链，包括以太坊、Pogon、Gnosis Chain、Telos、Libre、EOS、BSC、Arbitrum、Algorand，同时支持在这些链上铸造 pBTC。

尽管 pNetwork V2 已经作为任意消息桥发布，但依目前而言，pNetwork 的「主营业务」还是 资产桥，目前尚未有第三方的跨链应用基于 pNetwork V2 搭建。

pNetwork V2 简介

5.6.9 Bool Network

Bool Network 是另一个采用 TEE 节点网络作为外部验证者的 AMB 桥项目。Bool Network 在此基础上做了进一步的创新——增加了 TEE 节点的轮值和匿名机制。这样不仅让外部攻击难上加难，而且几乎可以杜绝内部串谋。

Bool Network 参考 Coos IBC，引入了 Channel 的概念，部署在不同链上的两个应用程序之间可以建立 Channel，以实现二者之间消息的有序传递。每个 Channel 都会对应至少一个 MPC 委员会。该委员会在当前 epoch 内负责对该 Channel 内的跨链消息进行共识签名。这个 MPC 委员会是轮值的，任期只有 1 个 epcoh，每个 epcoh 都会重新选举。

· Bool Network 目前会为每个 Channel 分配两个委员会，互为备份，以提高服务可用性。

任何人都可以通过质押 $BOL 成为候选的 TEE 节点。每个 epoch 开始前，Bool Network 会通过 Ring VRF 算法，为每个 Channel 选举 MPC 委员会。被选为 MPC 委员会成员的节点会获得一个用于通讯的临时身份（公私钥对），用于在共识签名过程中与同一委员会中的其他 TEE 节点通讯。当一个 epoch 结束时，所有的临时身份都会失效，然后网络将重新进行节点选举，选出新的轮值 MPC 委员会，赋予他们新的临时身份。

尽管每个候选的 TEE 节点在注册的时候，需要提供**身份信息（设备编码），但节点在通讯时使用的临时身份并不会暴露**身份信息。换句话说，节点在通讯时是相互匿名的。如果候选节点有 100 个，那么你只能知道与你通讯的节点是这 100 个当中的 1 个，而不知道具体是哪一个。

每个 Channel 的 MPC 委员会需要多少个 TEE 节点，签名的门限是多少，是由 Channel 创建人自定义的。常用的门限数值有 15-of-21、13-of-19、5-of-9。

同一个 Epoch 内，不同 Channel 的 MPC 委员会成员可能会有重叠，也有可能有部分候选节点没有被选入任何一个委员会，而出现闲置的状态。这些情况都是正常的。

我们发现，Bool Network 通过 TEE、轮值机制、匿名机制的组合，构建了一个牢不可破的黑箱。由于签名程序运行在匿名节点的 TEE 中，而且它们之间的通讯内容是 DH 加密的，只要不是闲置状态，TEE 节点的运营者本人都无从知晓自己被选入哪个 Channel 的 MPC 委员会，与哪些节点进行了共识通讯，签名了哪些消息，连「自知」都做不到，更谈不上「知人」。这基本上让节点串谋变的不可能。

从外部攻击者的角度，如果要攻击某个特定的 Channel，攻击者无从知晓当前的 MPC 委员会背后是哪些设备，也无法从通讯中截获这些信息。

无论是内部串谋，还是外部攻击，都只能选择攻破所有候选节点中的大多数，才有可能攻击成功，这无疑代价是巨大的。

Bool Network 是一个仍在开发中的项目，还有些技术细节没有完全确定，我们在本小节中阐述的只是其技术概要。

Bool Network Space 演讲

5.6.10 XCMP（Polkadot）

我们前文提到，波卡的跨链模式可以归结为外部验证中的一个特殊类型：共享验证。波卡的基本模型是分片，这是波卡实现共享安全性的途径。每个平行链是一个分片，平行链没有自己的验证者，而是由中继链分配一个验证者子集作为平行链的验证者集，这种分配是随机的，动态的，每个 epoch 都会重新分配。在任何一个时刻，中继链的验证者集是所有平行链验证者集的并集，这符合共享验证的特征。

但我们要理解波卡的跨链传输机制，还需读懂 XCMP 的细节。XCMP（Cross-Chain Message Passing）是 Polkadot 上的跨链消息传输协议，用于平行链/平行线程之间的跨链通讯，XCMP 还在开发中，目前已经部署的是 HRMP（Horizontal Relay-routed Message Passing）。此外，波卡使用 VMP（包含 UMP\DMP）来实现平行链/线程与中继链之间的消息传递。

HRMP 提供与 XCMP 相同的接口和功能，但跨链消息是放在中继链存储的，这将给中继链带来负荷，因此这是一个过渡方案，后续将被 XCMP 替代。

我们需要了解 XCMP 和 XCM 的区别：Gawin 在一次采访中提到，XCMP 只是波卡跨链解决方案的一半，另外一半是 XCM，XCM 是波卡制定的一个跨共识消息通用格式，其效用是表达消息接收者应该做什么。

本小节的关注点在 XCMP。接下来我们将对 XCMP 的跨链传输模型做一个拆解。

5.6.10.1 主要概念 

Channel

与 Coos IBC 类似，XCMP 当中也有 Channel（通道）的概念，但 XCMP 当中的通道是单向的，两条平行链（A 和 B）之间如果想要双向通讯，就需要建立两条通道（AB Channel，BA Channel）。

Egress 和 Ingress

当平行链 A 与平行链 B 建立 AB Channel 时，平行链 A 上会被创建一个平行链 B 的 egress（出口队列），而平行链 B 上会被创建一个平行链 A 的 ingress（入口队列）。

MR（Message Root）

每一个出口队列里除了存储待发消息队列的原文之外，还需要维护一个 MR 队列（Message Queue Hash Chain）。XCMP 在这里也采用了消息树的结构，所有的待发消息作为叶子节点构成一个默克尔树，树的根值被称为 MR（Massage Root），每有一个新的消息作为叶子节点插入，都会产生一个新的 MR。

5.6.10.2 消息流

（以 AB Channel 为例）

1.Chain A 上用户通过源应用程序发起跨链请求，想要将消息 M 送到 Chain B。该消息会被放入 Chain A 上为 Chain B 专设的出口队列（我们简写为：Egress AB）。该消息将被包含进**的 MR 中。

2.Chain A 的收集者在打包当前区块的时候，会将**的 MR 放入区块头。当区块被中继链分配给 Chain A 的验证者验证后，会被提交到中继链，并被中继链的区块包含。此时，我们认为该 MR 被中继链验证了。

3.Chain B 的收集者会不断轮询所有其他链上为 Chain B 建立的出口队列，这里就包括 Egress A B，Chain B 的收集者将 Egress A B 中的消息原文及 MR 队列放入自己对应的入口队列：Ingress AB。（* 有另一种说法，该过程不是收集者完成，而是验证者完成的，这点的设计在 XCMP 中还没有完全确定，但谁来完成并非 XCMP 设计的关键点，因为这项任务是无信任的，谁来完成都可以）。

4.Chain B 的验证人从中继链获取 Channel AB 的**被中继链验证的 MR，以及该 MR 已经被中继链验证的证明。由于 Chain B 的验证人本就来自于中继链的随机分配，所以这个过程不存在信任问题。

5.Chain B 用该 MR 来判断 Ingress AB 哪些消息已经被包含到中继链中，然后更新这些消息的状态为已验证。

6.已验证的消息可以被目标应用程序执行了。

我们为了表达方便，只描述一个 Channel 的消息流，事实上 XCMP 在处理跨链消息的时候，所有的 Channel 是同时处理的。中继链会维护一个 CST 表格（Channel State table），用于存储所有 Channel 的 MR。

UMP 和 DMP 大致与 XCMP 同理，不再赘述。

XCMP docs

5.6.11 外部验证桥小结

以上我们举了若干个外部验证桥的案例，包括：

两个 PoA 桥，分别是 AnyCall、Wormhole；

五个 PoS 桥，分别是 Axelar、Hyperlane、Gravity Bridge、pNetwork V2、Bool Network；

两个 TEE 桥，分别是 pNetwork V2、Bool Network；

一个采用外部 Oracle 的桥，LayerZero，还有一个预言机服务商亲自建设的桥 CCIP；

两个共享验证桥：分别是 Gravity Bridge 和波卡的 XCMP。

读者可能发现，我们列举的两个 PoA 桥，都遭遇了非常严重的黑客攻击。尽管外部验证桥在安全假设上的确有验证人联合作恶的风险敞口，但事实上，被攻击的原因并非安全假设层面，而是代码实现上的漏洞。而 PoA 桥更容易吸引黑客攻击，恰恰是因为其实现简单，入场较早且发展较快，TVL 很高，成为了黑客眼中的肥肉。因此，我们不会因为某个项目遭遇了黑客攻击，而否认该项目的整体结构设计。关于跨链桥如何提高安全性和防范黑客攻击的话题，我们会有专门的章节。

PoS 桥的实现也并不困难，但守护桥梁的通证需要有较大的市值，才能充分保障网络的安全，否则攻击桥梁的经济成本将会很低。因此，PoS 桥的发展可能会将 PoA 方案作为过度阶段，在 TVL 上升，推高通证价格之后再转 PoS。PoS 桥要面对的一个问题是验证者的不均衡性，例如 Axelar 有 50 个验证者，但想要达到 2/3 的签名阈值，只需要 10 个左右的头部验证者签名就可以了，为了缓解这个问题，Axelar 采用了二次方投票的方案；Hyperlane 则采用「可验证欺诈证明」方案，验证人联合作恶将立即被发现并执行 Slash；pNetwork 和 Bool Network 则直接要求所有节点质押相同数额的 Token。

pNetwork 和 Bool Network 要求 PoS 验证者用 TEE 来存储私钥、执行签名，以防止外部攻击者窃取私钥，攻击跨链桥，Bool Network 还通过 TEE 节点的轮换机制和匿名机制，让内部的节点串谋也变的十分困难。LayerZero 独具特色的构建了两个信任层，一个是外部 Oracle 网络，一个是负责传递消息的 Relayer，只要二者不串通，就可以保证跨链的安全。LayerZero 还通过应用程序负责制，在各应用程序之间实现跨链的风险隔离。CCIP 同样构建了两个信任层，一个是预言机网络，一个是反欺诈网络，此外，Chainlink 丰富的节点资源将为其赋能。

Gravity Bridge 和波卡的 XCMP 都是共享验证的案例，Gravity Bridge 依旧可以用 PoS 桥的范式去理解，只是桥的安全性与 Gravity Chain 的安全性一致，Gravity Bridge 正在计划从 Coos Hub 中租用安全性（这是 Coos 2.0 的新功能），将桥的安全性进一步提升。XCMP 则是基于波卡被深度定制，致力于实现波卡平行链间的同构跨链，与其说跨链，更像是跨分片，我们**以跨分片的视角去理解它。

5.7 本地验证桥

本地验证仅适用于 Swap 桥。目前来看，采用本地验证方案的桥主要是以太坊跨层资产桥，我们已经在本系列第二篇 5.2.3 小节 列举了 cBridge、Connext、StarEx Bridge 三个典型案例。因此本小节不再举例。

5.8 乐观验证桥 

5.8.1 Nomad（前身 Optics）

Nomad 的技术方案脱胎于 Celo 旗下的跨链桥项目 Optics，Nomad 的几名核心成员也来自被 cLabs 收购的 Summa 跨链研究团队。但 Nomad 从一开始就已作为一个通用跨链项目而独立发展，已不再使用 Optics 的基础设施。2022 年 4 月 13 日，Nomad 以 2.25 亿美元估值完成 2200 万 美元种子轮融资，领投方是 Pochian Captical。

Nomad 在试图通过一个全新的方式，解决跨链不可能三角问题。Nomad 意识到轻节点客户端跨链方案在易适配性上的缺陷，也意识到外部验证人跨链方案在安全性上的妥协。于是 Nomad 采用了欺诈证明的方式来验证跨链信息。在 Nomad 中，跨链消息在传递成功后，有一个争议窗口期（30min），如果在争议窗口期，没有人报告欺诈行为，消息将被接收端正式接受。

5.8.1.1 核心概念及结构

Nomad 协议由链上的智能合约和链下**角色两个核心部分组成：

链上智能合约实现了 Nomad 的消息发送和消息接收的逻辑，链上智能合约包括 Home 和 Replica 两部分，其中 ：

· Home 负责处理消息发送逻辑，可以理解为 Nomad 跨链消息的「发件箱」，Home 合约也负责管理 Updater 的保证金（bond）；

· Replica 则负责处理消息接收的逻辑，可以理解为 Nomad 跨链消息的「收件箱」。

需要注意的是，接入 Nomad 的区块链中，每条链上只有一个 Home 合约，但可以有 n-1 个 Replica 合约，n 是接入链的数量。这样的设计与 Hyperlane 似曾相识。

链下**负责以可信的方式传递跨链消息，链下**包括 Updater（更新者）、Watcher（观察者）、Relayer（中继者）、Prosessor（执行者）四个角色。其中：

· 每个 Home 合约会对应一个 Updater，Updater 负责签名 [update]，此处 update 一词被当作名词使用，是 Nomad 语境下的一个专用名词，表示一个特定的数据结构，我们统一加中括号进行表示，一个 [update] 包含上一个消息树的根 _oldroot，和新的消息树的根 _newRoot，被签名后还会包含 Updater 的数字签名。

[ update ] = [ _oldRoot , _newRoot]被 Updater 签名后的 [ update ] = [ _oldRoot , _newRoot，_signature ]

· Watcher 负责观察和报告欺诈行为；

· Relayer 负责在链间传递签名后的 [update] ；

· Prosessor 负责在 [update] 传递成功之后，将对应的跨链消息原文（包括默克尔路径）传递到目标链，并触发目标链 Replica 合约用 [update] 验证跨链消息，然后将验证过的消息发送给最终的目标应用程序执行。

Channel 

在 Nomad 中，一个 Home 合约和一个对应该 Home 合约的 Replica 合约可以组成一个 Channel，这个 Channel 是单向的，如果要进行双向的跨链传输，需要两个成对的 Channel。一个 Home 合约可以对应多个 Replica，因此从一个源链出发，面向多个目标链，会有多个 Channel，这给 Nomad 带来一个新的用例：一对多的消息传输。

5.8.1.2 消息流

我们来看下 Nomad 中的跨链消息传递过程：

1.应用程序调用源链 Home 合约，将需要跨链的消息 T 排入发送队列；

2.源链 Home 合约中在 T 消息之前**的消息根，我们设为 _oldroot，步骤 1 完成后，Home 合约将消息 T 进行格式化处理，作为叶子节点插入消息树，计算出新的消息根 _newRoot，_newRoot 和 oldRoot 唯一的区别就是 _newRoot 包含了消息 T ；

3.Updater 调用 Home 合约中的 update 函数，对 _oldRoot、 _newRoot 进行签名后传回 Home 合约。该行为被称为 update（这里作为动词，我们不加中括号），每有一个新消息根产生，就可以 update 一次，但为了节约成本，updater 也可以在多个新消息根产生后，进行批量 update ；

4.Relayer 将被 Updater 签名后的 [update] 传入目标链，并调用目标链 Replica 合约将传入的 [update] 放入待定池，启动争议窗口期；

5.争议窗口期内，Wactcher 对欺诈行为进行检查，主要是看 Home 合约中被 Updater 签名的 update 和 Relayer 传递到目标链上的 update 是否一致，防止消息根被篡改；

6.计时结束，没有 Watcher 报告欺诈，Prosessor 将从源链获取消息 T 及 T 的默克尔路径，传入目标链，在目标链上调用 Replica 合约，验证 _newRoot 对消息 T 的包含性。证明完成后，Prosessor 将消息移出待定池，发送给目标应用程序。

验证仅需用到 _newRoot，_oldRoot 的作用应该是定序。

Nomad 和 Hyperlane 一样都采用消息树的结构，这样可以防止 Updater 审查消息，还可以方便 Watcher 发现欺诈行为。

欺诈处理流程

以上过程是我们先假设没有欺诈行为发生，如果发生欺诈：

· 源链 Home 合约中的 [update] 与被 Relayer 中继到目标链上的 [update] 不一致，被篡改的 _newRoot 中可能包含了一个把大量资金转给 Updater 的交易。

那么 Watcher 将需要在 30min 内，先向目标链上的 Replica 合约提交欺诈证明，将欺诈的 [update] 标记为不可信状态，然后向源链上的 Home 合约提交欺诈证明，触发 Home 合约 Slash 掉不诚实 Updater 的保证金并停止处理新的待发消息。这意味着从该链向其他链发送消息的 Channel 被关闭。需要注意的是，此时，从其他链向此链发送消息的 Channel 仍是开启状态。

后续 Nomad 将通过治理来擦除错误的 [update]，改选 Updater，重启 Channel。

你可能会疑惑，明明是 Relayer 向目标链上传递了被篡改的消息根，为什么要处罚 Updater？原因很简单：Relayer 无法伪造 Updater 的签名，如果 Relayer 传递了被一个篡改的 [update]，一定是 Updater 签名了这个被篡改的 [update]。作恶的来源只能是 Updater，作恶的 Updater 完全可以自己运行一个 Relayer 服务或者串谋一个 Relayer 来完成作恶行为。

5.8.1.3 深入理解 Nomad 的 4 个链下**

我们看到，Nomad 的链下**有 4 种之多，看起来似乎有些复杂，但这四个角色缺一不可，我们来为它们的职责做一个进一步的辨析。

· Updater 仅仅负责签署 [update]，并传回源链，不负责消息本身的传递；

· Relayer 则仅仅负责在链间传递 [update]，消息原文及默克尔路径的传递则是由 Prosessor 完成；

· Prosessor 是 Nomad 独有的一个链下**角色，为什么要单独增设这么一个角色呢？这是因为欺诈证明完成之前，Relayer 传递到目标链的 [update] 处于待定状态，此时传递消息 T 是没有意义的。Prosessor 要负责在欺诈证明完成后（争议窗口计时结束后），手动去触发目标链结束这种待定状态，此时再将消息 T 传递过去，让 Replica 合约用确定后的 [update] 来验证消息 T。对于常规的外部验证跨链桥，是没有这些过程的，传递到目标链的消息可以直接被处理，因此并不需要 Prosessor 这样一个角色。

· 无论是 Relayer 还是 Prosessor，都是完全无需信任、无需准入的角色，因此 Nomad 并不关心谁去完成它，实践中，它可能是应用程序项目方或者任何第三方。

· Nomad 对 Relayer 并没有任何信任假设，只有活性假设，这是因为 Relayer 无法伪造 Updater 的数字签名（Updater 的公钥已在目标链的 Replica 中注册），只能忠实的履行其职责，Relayer 能对系统造成**的伤害也仅仅是离线，使得跨链服务暂时不可用。正如前文所说，欺诈的来源只能来自于 Updater，不可能是 Relayer。

· 由于信任的基础是至少有一个诚实的 watcher，因此，在 Nomad 中，不需要 Updater 层面的去中心化。事实上，每个 Home 合约只需要对应一个 Updater，并不需要像外部验证方案那样，需要一个足够多元化的验证者集，这有助于降低开销。如果应用程序项目方联合了更加多元化的主体，更好的选择是让他们去做 Watcher。Nomad 没有系统级的 Watcher 集，需要应用程序自定义自己的 Watcher 集。

5.8.1.4 Nomad 的安全特性

我们来回顾下跨链互操作不可能三角：以下三者，最多只能得其二。

· 可扩展性（Extensible）：支持广义跨链计算

· 无需信任（Trustless）：不引入新的信任假设

· 普适性（Generalizable）：能够轻易适配更多区块链

Nomad 在以一个独特的方式破解跨链互操作不可能三角，Nomad 具有外部验证方案的两大优势：可扩展性（Extensible）和普适性（Generalizable），在此基础上，Nomad 使用欺诈证明机制，使得跨链桥的 Trustless 水平接近于原生验证（只需要有一个 Watcher 是诚实的，系统就是安全的）。我们发现，在 Nomad 中，跨链互操作不可能三角的三个条件被神奇的同时满足了！

当然，这不是没有代价的，代价是 30min 以上的延迟，这可能导致某些类型的应用不适合使用 Nomad 实现其跨链功能。

5.8.1.5 Nomad 的应用

Nomad 已经创建了自己的 Swap 桥，并将其与 Connext 集成在同一个界面中。用户可以使用该界面自由的进行跨链资产交换。如果用户要跨链的资金较小，Connext 可以实现更快的速度，如果用户要跨链的资金较大，Nomad 可以提供更低的费率，二者互为补充。我们可以预期，大多数用户都将使用「快速通道」——Connext，而为「快速通道」提供流动性的 LP 则通过「慢速通道」——Nomad 来调节不同链上的流动性。这与以太坊跨层项目中「原始通道」与「快速通道」的配合如出一辙。

资产发行者可以通过 Nomad，让自己的资产变成多链资产。例如，Covalent 将他们的网络质押通证 $CQT 从以太坊迁移到了 Moonbeam ；Hummingbot 将他们的治理通证 $ HBOT 从以太坊迁移到了 Avalanche。

应用开发者可以通过 Nomad 部署多链应用，Nomad 将其称为 xAPP（读作 Zap），xApp 可以调用 Home 合约和 Replica 合约，实现跨链消息的收发。Nomad 的开发者文档里提供了代码示例。

Nomad 与 Gnosis 合作开发了 Zodiac Nomad Module（ZNM），一个专注于跨链治理的通用模块。DAO 可以通过在 Nomad 支持的链上部署 ZNM，实现治理决议在多链同时执行。

截至 2022 年 9 月，Nomad 支持六个链：Ethereum、Moonbeam、Evmos、Milkomeda、Gnosis Chain 和 Avalanche，我们认为 Nomad 跨链桥的设计是有开创意义的。但不幸的是，由于合约代码的漏洞，Nomad 托管合约中的资金遭遇黑客洗劫，损失超过 1.9 亿美元，本文撰写时，Nomad 正在致力于回收损失资金，相关跨链桥功能处于停用状态，我们希望 Nomad 能早日渡过难关，重振旗鼓。

Optimistic Bridges：A New Paradigm for Crosschain Communication

Arjun BhuptaniNomad Docs

5.8.2 Celer IM

Celer 在 2022 年 3 月发表的一篇博客中，提到了一个新的混合框架 Celer IM，该框架将外部验证和乐观验证结合在一起，让应用程序可以自行选择合适的安全模型。我们来看看具体设计：

Celer IM 主要包含以下几个部分

· State Guardian Network（SGN）: 这是一个基于 Coos SDK 开发的 PoS 区块链，具有一组抵押 $CELR 的验证者，负责验证并签署跨链消息；

· Message Bus 合约：部署在接入链上的一组合约，负责管理跨链消息的收发；

· Executor：负责将被验证过的跨链消息中继到目标链。

消息流

1.用户通过应用程序将其需要发送的跨链消息提交给源链上的 Message Bus 合约；

2.SGN 中的验证者监听到消息并对消息进行共识签名；

3.Executor 将跨链消息中继到目标链上的 Message Bus 合约；

4.目标链上的 Message Bus 合约在确认消息签名有效之后默认立即推送给目标应用程序进行执行。

应用程序可以选择不立即处理收到的跨链消息，而是使用双重确认模式。这种模式下，消息被目标链上的 Message Bus 合约一次确认后，会被提交到一个「隔离区」，过了一定的窗口期，才能认为这条消息被二次确认，并推送给目标应用程序。

在窗口期，应用程序可以运行 App Guardian 服务来检查隔离区中消息的真实性，如果发现与源链发出的消息有不一致的情况，可以阻止消息被目标应用程序执行，并在源链报告欺诈行为。

不同于 Nomad，报告欺诈行为并不能自动触发 Slash，因为验证人没有在源链抵押。如果出现欺诈行为，如何对验证者进行惩罚和替换，Celer IM 文档中没有说明，笔者认为，应该需要治理流程的介入。

我们看到 Celer IM 提供了外部验证和乐观验证两种安全模型，前者的信任假设是 SGN 网络中诚实验证者掌握 2/3 以上的投票权，后者的信任假设则是至少有一个诚实的 App Guardian 服务在运行。

双模型的设计给应用程序开发者提供了灵活的选择。例如资产桥应用可以根据跨链的资产价值来触发不同的流程，执行不同的安全模型，这样小额资产跨链可以保持迅速，而大额资产跨链则可以被充分保障安全。

Celer IM 介绍文章

5.8.3 乐观验证小结

乐观验证作为一种全新范式，突破了跨链不可能三角，成为了跨链桥信任层构建的全新选择。乐观验证桥**的弊端是挑战窗口期的延迟，这会给用户体验带来不利的影响。但无论 Nomad 还是 Celer IM，都在尝试弥合这个问题：

· Nomad 与 Connext 合作，为用户提供一条快速通道；

· Celer IM 则将乐观验证与外部验证组合在一起，让应用程序可以根据跨链请求的不同，为用户提供一重验证和双重验证两个不同的选择；

我们看到，乐观验证**的应用场景，似乎是与其他验证方式组合在一起，把安全和效率的权衡，交给用户。这种组合式的信任层构建，或许是跨链桥未来的发展方向之一。

5.9 跨链桥的一般性

行文至此，我们是时候来总结一下跨链桥的一般性了。不同的跨链桥有不同的设计，但基本上有一个通用的结构，我们可以将其分为三层：

· 信任层

· 传输层

· 应用层

5.9.1 信任层

任何跨链桥，首先要解决的都是不同链间传输消息的信任问题。我们根据信任层构建方式的不同，对桥的类型进行了最基本的划分，本篇文章的行文结构也照此进行。

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

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

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

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

5.9.2 传输层

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

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

如何理解跨链消息

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

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

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

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

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

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

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

消息流

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

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

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

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

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

消息队列结构

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

Channel 

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

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

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

包含 Channel 概念的跨链桥有 Coos、XCMP、Nomad，但它们各自的设计又有所不同。在 Comsos 中，Channel 是建立在应用程序之间的（建立在链之间的 Channel 被称为 Connection）而且是双向的，两条链之间建立 Channel 意味着二者可以进行消息的双向传输。但在 XCMP 和 Nomad 中，Channel 是单向的，双向跨链传输需要成对的两个 Channel。在 XCMP 中，一个 Channel 对应一个出口消息队列 Egress ；但在 Nomad 中，多个 Channel 对应一个出口消息队列（Home 合约），这意味着 Nomad 的 Home 合约中管理的是从该链发出的所有消息，不区分目的地（目的地字段在消息正文中），这使得 Nomad 可以支持一对多的消息传输模式。

5.9.3 应用层

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

5.9.4 激励层

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

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

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

激励的方式可能是多种多样的，可以是将用户端的收费直接支付给激励对象，也可以是跨链桥项目方用自身金库或是通胀奖励来补贴激励对象，还有一种情况是，应用层为激励对象制定激励规则，或者应用层直接承担激励对象的职责。

5.9.5 总结

以上，我们通过跨链桥的分类、举例、分析，对跨链桥的构建方式有了更深的认识。这就是 PAKA 跨链研究报告系列的第三篇。我们将在不久后发布第四篇，也就是最终篇。在最终篇当中，我们将着重探讨一些应用层的实现，尤其是 Wrap 桥、Swap 桥以及其

原文标题：《Paka Labs 跨链研报（3/4）| 将孤岛连成大陆：解读 20 座跨链桥及 4 种跨链技术范式》

原文作者：MIDDLE.X，Paka Labs

Paka Labs 跨链研报（1/4）见：《跨链技术及应用形态全景图》

Paka Labs 跨链研报（2/4）见：《BTC 锚定资产与以太坊跨层快速通道》

5.3 跨链的分类维度

根据跨链桥所支持的消息类型，我们可以分为：

· 任意消息桥 ：一般被简称为 AMB，Arbitrary-Message-Briage，支持任意类型消息的跨链传递，在此基础上实现跨链合约调用、跨链计算等复杂功能。

· 资产桥：包括 Wrap 桥和 Swap 桥，前者指资产映射桥，支持跨链资产传递，后者指流动性互换桥，支持跨链资产兑换。

任意消息桥可以作为底层平台，搭载资产桥，从这个意义上讲，资产桥是建构在任意消息桥上的应用之一。事实上，在 LayerZero 推出 Stargate 之后，越来越多的 AMB 桥项目，选择将资产桥剥离出来作为应用层，而非将资产桥的功能内置其中。

对于 Wrap 桥，根据资产的托管方案，还会有更进一步的细分：

· Lock-Mint（包括见证人托管、合约托管）

· Burn-Mint（无托管）

更细致的分类见下图：

不同的资产托管方案，我们已经在 5.1 小节 BTC 锚定资产一节中有充分的探讨。

根据跨链桥的建设目标，我们可以分为：

· 通用桥：以连接尽可能多的链为目标

· 专用桥：为特定的公链、特定资产或是特定应用提供跨链功能

在众多通用桥项目中，有的通用桥项目，颇具野心的提出了 OmniChain（全链）的概念，希望能够连接几乎全部的主流公链，乃至联盟链。通用桥的优势在于可以一站式的满足多链间跨链的需求，专用桥的优势则在于某种意义上的官方背书，在跨链桥的背后，有公链项目方、资产发行方、或是应用程序项目方的安全承诺。

根据桥梁所连接的公链，我们又可以分为：

· 异构跨链桥：旨在连接不同架构的公链

· 同构跨链桥：旨在连接相同架构的公链

其中同构跨链桥往往会辅以一套造链协议，实现对基于该造链协议的公链的被动兼容。不过目前跨链桥项目所面对的往往是异构跨链，区块链在共识机制、通信规范上的创新层出不穷，这导致新的类型的区块链不断涌现。一劳永逸的思路是正确的，但任何项目都不可能甘心将自己禁锢在一个封闭生态内，因此即便是 Polkadot、Coos 这样的以同构跨链为核心的项目，也在积极的推动与其他异构生态的跨链桥接。

以上三个分类维度，各有千秋，但都没有从跨链桥的技术本质切入。我们认为对跨链桥最重要的分类维度，应该是信任层的构建机制。跨链的一个核心问题是要解决：一条链如何感知另一条链。对这个问题更好的问法是：如何可信的感知另一条链。将一条链的消息传递到另一条链并不困难，但核心是如何信任它，换句话说，如何验证它！

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

5.4 跨链的验证方式分类

我们引入 Connext 创始人 Arjun Bhuptani 提出的一个跨链分析框架，这是去年以来，跨链研究领域最重要的理论成果之一。该框架被提出后，迅速被众多跨链相关文章引用。

Arjun Bhuptani 将跨链桥按照消息验证的方式分为三大类别，分别是原生验证、外部验证和本地验证。

5.4.1 原生验证

原生验证指的是在目标链部署源链的轻节点，对源链来的消息进行验证。相比全节点，轻节点是轻量化的节点，它不存储完整区块的序列，而仅存储区块头的序列。尽管区块头体积很小，但它包含了对区块中完整数据的密码学概括，可以对区块内的交易执行 SPV 验证。为了维护目标链上部署的源链轻节点，需要由 Head Relayer 将源链的区块头中继到目标链。

尽管 Head Releyer 作为一个链下角色，是不可或缺的，但原生验证对 Relayer 并没有信任假设，因为部署在目标链上的轻节点程序会对 Head Relayer 提供的区块头进行验证，Head Relayer 无法欺骗轻节点。

对区块头的验证会分为两个部分，分别是有效性验证和最终性验证。

对区块的有效性验证逻辑，取决于共识机制。

对于 PoW 系统，除了验证区块的基本格式外，最核心的验证逻辑是验证区块中包含的工作量证明：

（图片源于 Composable Finance Docs）

如上所示，找到一个满足这个方程的值需要大量的计算，因为哈希函数不能被暴力破解，但是验证这个共识证明相对便宜且快速。

在 PoS 系统中，核心的验证逻辑通常是验证一个随机函数输出：

（图片源于 Composable Finance Docs）

也就是说：验证该块是由一个被随机选中的合法验证人生成的。

然而，区块的有效性不等于最终性。

在中本聪共识中，最终性是概率性的，因此验证最终性的办法是等待该区块后有更多的有效区块被追加。在 BTC 中，一般认为 6 个区块的追加可以让一个区块几乎无法被逆转，这大概需要 1 小时，这就是为什么多数 BTC 跨链衍生品在 mint 时，都需要等待 1 小时左右；在以太坊中，一般认为 25 个区块的追加可以让一个区块几乎无法被逆转，这大约需要 5 分钟左右。

在 BFT 类共识中，则是通过验证一个区块已有 2/3 权重的验证人签名来确认其最终性，因此 BFT 类共识，具有即时最终性。

无论是有效性验证，还是最终性验证，轻客户端对区块头的验证，与其他类型的节点对区块的验证逻辑是完全相同的。因此 Head Relayer 向轻节点合约传递的区块头完全无法造假，原生验证对 Head Relayer 没有信任假设。

5.4.2 外部验证

外部验证则指的是引入一组外部的见证人来负责验证跨链消息，用户必须相信这些见证人是可信的，见证人内部可能有某种机制来达成共识。外部验证者会体现为许多形式，MPC 网络、PoS/PoA 网络、TEE 网络、多签小组、Oracle，本质上都是一回事。

我们需要意识到，在引入外部验证人的同时，引入了新的安全假设。假设 A 链的安全性是 x，B 链的安全性是 y，外部验证者集的安全性是 z，那么在 A 链、B 链之间传递跨链消息的安全性 s = min (x、y、z)，大多数情况下，z 都是其薄弱环节，也就是说 s = z。这是外部验证模式，最被诟病的缺点。

5.4.2.1 共享验证

我们需要考虑外部验证中的两种例外情况：

其一，在由一些由公链项目方直接发起的跨链桥当中，有可能让链的验证者集，直接成为跨链桥的验证者集，在这种情况下，外部验证的安全性 s 提升至 min(x，y)，与原生验证相当。

该结构的典型代表有：

· BTC 侧链 RootStock 的用自身全体验证人作为 RootStack-BTC 桥的验证人

· 由 Compound 开发和维护的 Substrate-based 链 Gateway，则复用全体 Gateway 的验证人，作为 Gateway-以太坊桥的验证人；

· 致力于桥接 Coos 生态与以太坊生态的 Gravity Bridge 使用 Gravity Chain 的全体验证人作为 Gravity Bridge 的验证人。

其二，我们将上述情况，做一个延伸。将 A 链和 B 链的验证者集聚合为一个并集，设立一个中继链 R 链，以该并集作为验证人集，我们便得到了一个更具拓展性的结构。

该结构的典型代表是 Avalanche 和 Polkadot。Polkadot 的中继链为每个平行链随机分配验证者，以此来实现共享安全性，Avalanche 则要求所有子网的验证者必须同时成为三大主网（P 链、C 链、X 链）的验证者，以向子网索取安全性。Polkadot 利用该结构，开发了平行链间的跨链消息传递协议 XCMP，不过 Aclanche 似乎没有利用该结构来实现跨链消息传输。

这两种例外情形，形式上依旧属于外部验证，但其核心特征和适用场景已发生重大变化，在后文我们对各类验证机制的特征对比中，提及到的外部验证将不包含这两种例外。更进一步，我们认为，应该将其命名为一种新的类型，称之为「共享验证」。

5.4.3 本地验证

本地验证也被称为点对点验证，指的是交易对手对交易直接进行验证。典型的范式是基于哈希时间锁的原子交换，在这样的交易过程中，交易双方相互验证对方已经完成了某种行为。由于交易双方的经济利益是对抗的，因此不存在合谋的可能性。大多数采用本地验证方式的跨链项目设计中，为了避免要求交易双方同时在线，都存在一个中间的流动性提供方作为公共的交易对手。

5.4.4 跨链互操作不可能三角

三种验证方式中，原生验证的信任假设最小，理论上只要源链和目标链不发生重组，跨链消息传递就是安全的，但原生验证的多链适配成本是**的。几乎每条链的轻节点方案都要单独设计，更要根据部署环境的某些限制（也就是目标链的情况）进行优化，假如你在 A 链上实现了 B 链的轻节点合约，也只是实现了从 BA 的单向消息传递，如果你要实现一座双向桥，你还需要在 B 链上实现 A 链的轻节点合约，这两项工作是完全独立的，没有可复用性。假如你要适配更多链，那就要付出更多的成本，每接入一条新链，就需要开发一对轻节点合约。因此我们看到，采用原生验证机制的跨链桥项目以专用跨链桥和同构跨链桥居多，异构通用桥很少采用。

外部验证的优势和劣势与原生验证刚好相反，外部验证的多链适配成本较低，其缺点是引入新的信任假设，假设外部验证人通过是 m-of-n 投票机制来达成共识，我们需要恶意串通的验证人数量不能超过 n-m。如果我们想要降低信任假设，那就需要验证人做抵押，这带来的是跨链的成本的增加。

本地验证尽管具备无信任假设、多链适配容易的双重优点，但是其适用范围相对狭窄，只能支持 Swap 桥，无法支持 Wrap 桥，遑论 AMB 桥。

Arjun Bhuptani 在他的文章中，提出了**的跨链互操作性不可能三角（The Interoperability Trilemma），即

任何跨链方案设计，最多只能满足以下三者当中的两者：

· 可扩展性（Extensible）：支持任意消息传传递

· 无需信任（Trustless）：不引入新的信任假设

· 易适配性（Generalizable）：能够轻易适配更多区块链

可以说，各类跨链桥项目都在试图从不同的角度优化乃至破解不可能三角，试图使得综合性能达到**。

5.4.5 乐观验证

乐观验证一般被认为是外部验证方案的优化，但由于其信任假设产生明显变化，我们认为应该将其作为一种独立的验证方案来探讨。乐观验证的基本逻辑是：在外部验证的基础上，设置一批挑战者和一个挑战窗口期，对不正确的验证进行挑战，验证者需要抵押，当其行为不当时，挑战者将提出挑战，并提供欺诈证明。若挑战成功，验证者的抵押金将成为挑战者的赏金。

乐观验证被人所熟知的应用是 Optimistic Rollop，但乐观验证在用于对等跨链，和用于 Op Rollup 时，情形是完全不同的。首先要明确，乐观验证并不是一个可以单独使用的验证机制，因此要使用欺诈证明的前提条件是，有验证欺诈证明的机制。这意味着我们必须有一个可靠的「真相」来源。这个真相端承担着最终裁决的功能。

在对等跨链中，真相就在源链，不正确的状态转换很容易与源链上的「正确答案」进行比对，从而对欺诈证明进行验证。Op Rollups 则比这复杂，Rollups 要求 L2 继承 L1 的安全性，因此只能以 L1 上的真相作为最终裁决的依据，但矛盾的是，L1 并不天然保有 L2 上的状态转换信息，任何从 L2 提交到 L1 的信息都要经过激烈的证明过程，因此需要一个足够长的时间，让异议者能充分参与博弈，大多 Op Rollups 都把这个时间定为 7 天或以上。

在对等跨链中，乐观验证不需要 7 天这么长时间，只需一个足够挑战者进行反应的时间即可，Nomad 将其设定为 30min。乐观验证的信任假设是：至少有一个挑战者是诚实的，且会受到经济激励而忠实的履行职责。这相比外部验证而言，是更小的信任假设，在这样的信任假设下，攻击者无论付出多大的经济代价，都不能保证攻击一定成功。

相比外部验证，乐观验证用几十分钟的延迟换来了信任假设的放宽。乐观验证的机制也可以融入原生验证，用于帮助轻客户端验证区块头。关于乐观验证的更多特点，我们将在后文结合案例来具体说明。

5.5 原生验证桥项目

5.5.1 轻节点合约总论

原生验证桥中最重要的组件便是轻节点合约，为了更好的理解原生验证桥，我们需要先对轻节点合约有一个基本的认识。

轻节点合约，我们也可以称之为轻客户端，它的出现源于人们对于提升区块链去中心化程度的努力。区块链的数据会不断积累，使得全节点的体积不断增大，这使得运行全节点的设备门槛和成本门槛，不断升高，进而将普通用户拒之门外，只留下少数的机构用户运行全节点，区块链的分布式精神遭受挑战。

5.5.1.1 SPV 轻节点

比特币是最早面临这种挑战的区块链，于是中本聪提出了 SPV（简单支付验证）的概念。SPV 轻节点不存储全部的区块数据，而只是存储区块头。尽管 SPV 轻节点没有区块体中的交易数据，但当它需要知道一笔交易是否被包含在链中时，可以从全节点获取该交易的 Merkle 路径，然后用区块头中的 Transaction Root 对该交易进行 SPV 验证。

（蓝色方块的合集，就是黑色方块的默克尔路径）

5.5.1.2 Fclient 超轻节点

超轻节点，是指比 SPV 节点更轻的节点，超轻节点往往可以实现跳跃式的同步新区块头或是不断修剪旧区块头。我们在本系列第一篇中提到过一种超轻节点方案：MMR 超轻节点。在这里，我们需要做一个更正：对 MMR 超轻节点更准确的称呼应该叫 Fclient 超轻节点。MMR 是 Fclient 提出的一种承诺结构。

Fclient 是 2019 年被提出的一个针对 PoW 的超轻节点方案，该方案通过 MMR 实现了「一，即所有」的证明结构，使得**的一个区块头中可以包含所有历史区块头的承诺。与此同时，Fclient 通过一套概率抽查算法，实现了在没有区块头历史的情况下，对区块头最终性的验证。但可惜的是，Fclient 并不适用于跨链场景，迄今为止，也没有任何将 Fclient 应用于跨链桥构建的范例。

原因有两点：

1.Fclient 的 MMR 承诺结构可以让轻节点只保有**的区块头，而不断修剪旧的区块头，虽然可以让链上轻客户端保持较小的体积，但不断同步**区块头还是需要花很多的 Gas，对于链上轻客户端而言，**要做到的是尽可能少的同步区块头，比如说跳跃式的同步区块头，甚至按需同步区块头；

2.Fclient 的抽查算法比较复杂，对于本地 CPU 而言不算什么，但对于链上这样一个计算资源稀缺的环境，显得过于**了，不具备经济可行性。链上轻客户端必须尽可能的节约区块头的验证成本。

对于原生验证桥而言，轻节点合约的性能将直接决定跨链桥的性能。我们在本节对跨链桥项目的举例说明中，将尤其关注项目构建轻节点合约的方法。

5.5.2 BTC Relay

BTC-Relay 是最早的轻节点合约，也是最早的原生验证跨链桥。其工作原理很简单，那就是在以太坊上部署一个 BTC 的 SPV 轻节点，用于对 BTC 链上的交易做 SPV 验证。

（图片源于 BTC Relay 官网）

链下角色「Relayer」负责不断的将 BTC 链的区块头传递到轻节点合约，轻节点合约在对区块头进行有效性验证和最终性验证之后将其正式接受。对区块头的有效性验证是以验证工作量证明为核心，而最终性验证则是等待该区块头后面被追加了 6 个以上的有效区块。正如我们前文所说，这个过程是不需要信任假设的。

Relayer 会向以太坊支付存储和验证区块头的 Gas 费用，与此同时，Relayer 从发起跨链请求的用户那里获得费用作为补偿，并获得适当的利润。任何人都可以成为 Relayer，并自设置每次调用的收费标准，其他人如果想成为 Relayer，可以通过向当前 Relayer 支付一小笔费用，并设置更少的收费标准来取而代之，用户如果担心收费过高，也可以自己运行 Relayer 服务。

需要注意的是，BTC Relay 是一座单向桥，仅仅支持在以太坊上验证 BTC 的信息，不支持相反方向的信息验证。因此 BTC Relay 并没有发行 BTC 的跨链衍生资产，其用例仅限于支持用户使用比特币支付以太坊上的费用。

当然，BTC Relay 可以作为一块积木，作为一个单向信任层，为其他的 BTC 跨链衍生品提供 BTC 以太坊方向上的交易验证服务。

BTC Relay 官网BTC Relay 文档

5.5.3 Waterloo Bridge

WaterLoo Bridge 是由 Kyber Network 开发的一座跨链桥，也是**实现双向原生验证的跨链桥，其实现的是以太坊和 EOS 之间的双向跨链。尽管随着 EOS 的衰落，WaterLoo Bridge 目前鲜有问津，但其技术方案依旧具有代表性。

Waterloo Bridge 通过以太坊智能合约实现了 EOS 的轻客户端，同时也通过 EOS 智能合约实现了以太坊的轻客户端。

由于以太坊出块相对较慢，而 EOS 上的计算和存储资源相对充足，所以 WaterLoo 在 EOS 上建立的以太坊轻节点合约是 SPV 轻节点，与 BTC Relay 原理一致，会将以太坊的区块头逐个的同步到轻节点合约。

但 EOS 出块速度较快，且以太坊上的资源紧张，因此在以太坊上的 EOS 轻节点合约被设计为仅同步 BP 集有变动的区块，而不去逐个的、连续的同步所有区块。但这样的设计需要解决两个问题：

1.如何验证历史区块头：当要验证的交易不在已存储区块当中的时候，轻节点合约需要首先从全节点获取相应区块头。但这里还需要一个验证过程，轻节点合约如何验证这些获取到的区块头？

2.如何验证**区块头：在不掌握区块头完整历史的情况下，如何验证**同步的区块头的最终性？

如何验证历史区块头

轻节点合约需要有能力依据已存储的区块头，验证从全节点获取到的区块头。如何做到这一点呢？我们需要了解，EOS 的共识协议是 DPoS，$EOS 的 Staker 通过投票选出 21 个 BP（Block Producer），这 21 个 BP 以循环方式轮流出块，每生成一个区块，都会由 21 个 BP 进行签名，有 15 个以上 BP 签署的区块被认为具备最终性，这些签名会在区块头中体现。尽管 EOS 出块速度较快，但 BP 集的变动却不会很频繁，轻客户端只要掌握 BP 集的名单（公钥列表），就可以验证该 BP 集任期内的所有区块头。也就是说，从全节点获取的区块头已被相应任期内的 BP 集当中的 15 个签署，就会被轻客户端合约接受。

如何验证**区块头

由于对 BP 集的选举投票发生在链上，投票结果会反映在某个区块 Block{i} 的区块头中，Block{i} 的区块头中会体现该 BP 集的名单，以及他们的任期。在 Block{i} 及其中包含的新 BP 集被生成时，这个新的 BP 集还未生效，Block{i} 会被旧的 BP 集签名。简单来讲，我们也可以这样理解，旧的 BP 集通过签署某个包含新 BP 集选举结果的区块，批准了新的 BP 集。轻客户端只要正确的掌握最初始的 BP 集，并且掌握每次 BP 集发生变化的区块，通过这样一个「批准关系链条」，就可以一路追溯到**的 BP 集。掌握** BP 集，就可以验证**的区块。

我们注意到，这里有个安全假设，那就是轻客户端需要正确掌握初始的 BP 集，如果这个条件不具备，轻节点合约就无**常工作。但对于轻节点合约的部署者而言，这是可以轻易做到的。

所以我们可以明确的是，当 EOS 上有消息需要跨链传递到以太坊，Waterloo Bridge 会：

1. 看消息所在区块的区块头在轻客户端中是否已存在，如果不存在则进行步骤，如果存在则进行步骤 ；

2. Relayer 从全节点获取消息所在区块的区块头，提交给轻客户端，轻客户端根据掌握的** BP 者集来验证该区块头，也就是说，轻客户端通过查看该区块头是否被 2/3 以上的 BP 集签名来判断其是否有效；

3. 用验证通过的区块头，对消息执行 SPV 验证。

EOS 的共识机制属于 BFT 类共识机制，EOS 的轻客户端实现方法，成为了 BFT 类公链轻客户端的典型范式。

WaterLoo Bridge 简介（上）WaterLoo Bridge 简介（下）

5.5.4 Rainbow Bridge

Rainbow bridge 是 Near 开发的连接 Near 生态与以太坊生态的官方跨链桥。Rainbow bridge 文档中提到：Rainbow bridge 的主要设计者是 Anton Bukov，他现在是 1inch 的 CTO，尽管已经不在 Near 全职工作，但他仍然指导着 Rainbow bridge 的发展。

结构与原理

Rainbow Bridge 的核心组成部分是两个链上合约和三个链下**：

链上合约：

· EthOnNearClient：在 Rust 中作为 Near 合约实现的以太坊轻节点

· NearOnEthClient：在 Solidity 中作为以太坊合约实现的 Near 轻节点

链下**：

· Eth2NearRelay：负责将以太坊区块头传递给 EthOnNearClient

· Near2EthRelay：负责将 Near 区块头传递给 NearOnEthClient

· Watchdog：负责向提交无效区块头的 Near2EthRelay 提出挑战，稍后详述

EthOnNearClient 需要跟踪以太坊上的每一个区块头，NearOnEthClient 只需要每个 Epoch 跟踪一个区块头，一个 Epoch 大约是 43,000 个区块，4 小时左右。如果全部同步的话是不现实的，幸运的是，Near 的验证人集每个 Epoch 只会变更一次，每个 Epoch 只有一个包含验证者集改选信息的区块头。NearOnEthClient 的设计很大程度上借鉴了 WaterLoo Bridge 中的 EosOnEthClient，甚至重用了 WaterLoo Bridge 的一部分代码。

但对于 NearOnEthClient，还有个技术难题，那就是以太坊不兼容 Near 所采用的 Ed25519 签名格式，这使得 NearOnEthClient 对 Near 区块头的验证变的很麻烦。因此 Rainbow Bridge 引入了乐观验证的方案。

当 Near2EthRelay 向 NearOnEthClient 提交区块头时，需要在 Near 链上抵押一些 $NEAR，在 4 小时的窗口期内，被称为 Watchdog 的挑战者可以提出挑战，如果所有 Watchdog 都不提出挑战，窗口期结束时，区块头被 NearOnEthClient 正式接纳。如果 Watchdog 提出挑战，并且挑战成功，提交无效区块头的 Near2EthRelay 将付出经济代价，其抵押金的一半将被销毁，剩余的一半将成为提出挑战的 Watchdog 的赏金。

乐观验证的引入，带来了新的信任假设：至少有一个 Watchdog 是忠实的。

在 BTC Relay 中，同一时间，只有一个 Relayer 运行，但在 Rainbow Bridge 中，无论是 Eth2NearRelay，还是 Near2EthRelay，都允许多个同时运行。多个 Relayer 可以相互竞争，尝试同时提交相同的块，每次只有一个成功；多个 Relayer 也可以相互形成备份，如果某个 Relayer 没有及时交块，其他 Relayer 依旧会提交，这样降低了服务不可用的可能性。

激励措施

当前 Rainbow Bridge 没有为转发区块头的两组 Relay 服务提供经济激励，因为 Near 预期运行在 Rainbow Bridge 上的主要应用（例如：$ETH 资产桥、$NEAR 资产桥、ERC20 资产桥、NFT 桥）将自行运行 Relay 服务，并且至少有一对 Relay 服务是由 Near 官方运行的。Rainbow Bridge 的未来版本可能会增加对 Relay 服务的经济激励，并增加相应的对跨链用户/应用的收费机制。

**进展

Near 发布了 EVM 兼容环境 Aurora，目前 Rainbow Bridge 2.0 支持的是以太坊与 Aurora 的跨链，如果需要从以太坊跨链到 Near，需要经过 Aurora 中转。需要注意的是，Aurora 尽管维护了一个独立的账本，有独立的区块链浏览器，但并不是一条独立区块链，而是 Near 上的一个 runtime，Aurora 没有独立的验证者集，Near 与 Aurora 之间的桥不是跨链桥，而是 runtime 之间的桥。

我们还需要留意的是，在本文写作的时候，以太坊刚刚完成 PoS 转型。所以 Rainbow Bridge 和 WaterLoo Bridge 中的针对 PoW 版本 设计的以太坊轻客户端，可能在不久之后被重新设计。

Near 介绍文档

5.5.5 Snowbridge（Snowfork）

SnowBridge 是带有波卡官方性质的跨链桥项目，由 Snowfork 团队开发，其目的是创建波卡生态和以太坊之间的原生验证桥。

Snowbridge 是一个仍在开发中的项目，我们对其的知识源于 SnowBridge 的现行文档，该文档看起来还未完成，有些地方写的还是「coming soon」，我们只能基于现有的材料对 snowbridge 进行分析。

Snowbridge 将有一条自己的平行链，未来将作为一条公益平行链运行，称为 SnowBridge Parachain，由该平行链负责与以太坊建立桥接，其他的平行链将通过 SnowBridge Parachain 与 XCMP，间接与以太坊桥接。这意味着，将在 SnowBridge Parachain 上面运行以太坊的轻节点 Pallet。

* Substrate 当中没有合约的概念，开发者通过添加 Pallet 向链部署应用程序，但其本质与合约是相同的，都是链上的 runtime。 

Snowbridge 将由以下模块构成

部署在以太坊上的合约：

· Polkadot RPC：用于处理以太坊上的跨链请请求

· 波卡及其平行链轻客户端验证器（POLKADOT AND PARACHAIN LIGHT CLIENT VERIFIER）

部署在 Snowbridge Parachain 上的 Pallet ：

· ETHEREUM RPC 用于处理波卡上的跨链请求

· 以太坊轻客户端验证器（ETHEREUM LIGHT CLIENT VERIFIER）

Snowbridge Parachain 上的以太坊轻客户端

根据 Snowbridge 的现行文档（2022.10.14），以太坊轻客户端被设计为了一个 SPV 轻节点，Relayer 将负责逐个的将以太坊的区块头同步过来，轻客户端 Pallet 将检查工作量证明，并遵循最重的分叉。但为了适配转型为 PoS 之后的以太坊，Snowbridge 应该会有新的方案。

以太坊上的波卡轻客户端

需要注意的是，由于 SnowBridge Parachain 的共识是中继链负责的，因此该轻客户端同步的将是中继链的区块头，而非 SnowBridge Parachain 的区块头。为了随时掌握**的验证人集信息，必须同步包含验证者集改选的区块头，这意味着每个 Epoch 至少需要同步一个区块头。当有交易需要验证时，再按需从中继链请求 SnowBridge Parachain 的区块头，并用包含它的中继链区块头验证其最终性。

相比 WaterLoo，Snowfork 要面对一个新问题：EOS 只有 21 个验证人，但波卡有 1000 个左右的验证者，即便刚好有 2/3 的验证人签名了一个区块，在以太坊验证 600 多个签名消耗的 Gas 也高到令人发指。Rainbow Bridge 通过乐观验证机制，绕开了这个问题，而 Snowfork 选择直面它。Snowbridge 的方案是采取一个抽样机制：在获取区块头时，轻客户端从该区块头对应的验证者集中，随机抽取一个子集，轻客户端将仅仅验证这个子集的签名，而不必验证所有的签名。根据 Snowfork 的研究论证，这个子集的验证人数量仅需 ceil(log2(3*N)) 个（N 为验证总数）。如果 N 是 1000，那么只需要抽取 12 个验证人的签名。

BEEFY

Polkadot 为了更好的支持与其他公链的桥接，在 GRANDPA 共识基础上，开发了一个最终性小工具，称为 BEEFY（截止撰文，BEEFY 的代码还在完善中）。当波卡中继链的区块被 GRANDPA 终结之后，还有一个 BEEFY 共识签名环节，在该环节，验证人需要为区块头添加 MMR 根植，然后对区块头进行单独的一轮共识签名。

有了 BEEFY 之后，轻客户端将不需要了解 GRANDPA 的复杂性，只需验证 BEEFY 签名。最重要的是 BEEFY 签名格式完全兼容以太坊，方便在以太坊端进行验证。

激励措施

SnowBridge 分为两个阶段发布，第一个阶段发布的是 Basic Bridge，该阶段已具备跨链桥的基本功能，但没有激励层，对于 Head Relayer 和 Message Relayer 都没有激励措施。如果用户/应用 想要保证自己的消息被中继成功，需要自己运行 Relayer 服务。第二个阶段将过度到 Incentive Bridge，该阶段将设立对 Relayer 的激励措施。

应用层

在 Snowfork 团队的规划中，在 SnowBridge 上线之后，将很快发布三座资产桥，分别是

· DOT 资产桥：支持在以太坊上创建 snowDOT

· ETH 资产桥：支持在波卡端创建 snowETH

· ERC20 资产桥：支持在波卡端创建 ERC20 资产的映射版本，命名格式为：snow-[资产名]。

Snowbridge 文档

5.5.6 LCMP（Darwinia）

LCMP（Light-client Cross-chain Messaging Protocol）是 Darwinia 开发的异构跨链协议，是一个基于轻客户端方案的通用的、开放的跨链传输协议。该协议目前以 SDK 的方式，允许 Dapp 自由集成。

Darwinia 构筑的跨链生态结构中，有 Darwinia Chain、Darwinia Parachain 两条链，其中 Darwinia Parachain 是 Polkadot 的平行链，二者都有相应的金丝雀网络，Crab Chain、Crab Parachain，其中 Crab Parachain 是 Kusama 的平行链。

Darwinia Chain 上被部署了一个 EVM 的兼容环境，称为 Darwinia art Chain，被称为 Chain 是因为 Darwinia art Chain 拥有独立的状态机和浏览器，但它并不是一条独立的区块链。（参见 Aurora 与 Near 的关系）

相应的，Crab Chain 上也有一个 EVM 兼容环境，被称为 Crab art Chain。

5.5.6.1 轻客户端设计

截止撰文，LCMP 已经实现了

· Darwinia Chain 与 以太坊的桥接

· Crab Chain 和 Crab Parachain 的桥接

其中，后者用到的轻客户端方案与 Waterloo 别无二致，我们重点关注 Darwinia Chain 与以太坊的桥接用到的这组轻客户端。

Darwinia Chain Client On Eth

由于 Beefy 还不可用，基于 Substrate 开发的 Darwinia Chain 的区块头签名，不被以太坊兼容。Darwinia 目前采取了一个过渡方案，通过议会的治理选举了一个签名人小组，专门负责签署 Darwinia Chain 的区块头，轻客户端将通过验证该小组的签名来确认区块头是否合法。尽管 Darwinia Chain 上有超过 100 个验证人，但签名人小组不超过 10 人，验证这些签名，在以太坊端的经济成本是可接受的。

Eth Client On Darwinia Chain 

合并之后的以太坊信标链，作为一条 PoS 链，有数十万个验证人，验证他们的签名显然不现实。因此以太坊在一次被称为 Altair 的升级中，增设了一个新的共识环节。Altair 升级后，以太坊链上每 256 epoch（大约 27 小时）就会从验证人中选出一个委员会，该委员会有 512 名验证者，他们将负责对已经终结的区块头进行签名。轻客户端仅需验证委员会当中是否已经有 2/3 签署，就可以验证一个区块头。不过 512 个仍然有些多，因此以太坊还采用 BLS 技术，将委员会的众多签名聚合为一个签名，这进一步降低了轻客户端的验证成本。Darwinia 已经基于 Altair 升级，在 Darwinia Chain 上实现了以太坊的轻客户端，该轻客户端只需每 27 小时同步一个区块头。这应该是基于 PoS 转型后的以太坊实现的第一个链上轻客户端。

5.5.6.2 LCMP 的结构

LCMP 的整体结构设计的非常优雅且清晰。

如上图，LCMP 分为信任层（Truth Layer）、传输层（Message Layer）和应用层（App Layer），其中，信任层由源链和目标链上的轻客户端和 Head Relayer 组成，传输层由一组负责处理消息收发的合约，以及 Message Relayer 组成。图中，没有区分 Head Relayer 和 Message Relayer，但在实际运行中，这是两个不同的服务。

LCMP 的消息传输 

LCMP 的消息发送遵循「三次握手」原则，熟悉 TCP 协议的朋友对此应该不陌生。这意味着消息的发送会经历三个环节

· 消息从源链发出，抵达目标链

· 消息抵达的回执从目标链返回源链

· 回执抵达的消息从源链再被发送到目标链

在完成这三个环节之后，有两个条件被满足

· 源链知道目标链已经收到消息

· 目标链也知道源链知道目标链已经收到消息

这对于应用层的设计将提供很大便利。

消息流

在了解了这一层之后，我们再来看 LCMP 的消息流（Message Lifecycle）

1. send_message 

应用层合约调用 outbound 合约中的 send_message 功能，outbound 合约将存储该消息并发出一个 “MessageAccepted” 事件。消息进入待发列表，初始状态为 ：undelivered（待发送）

2. relay

Relayer 作为一个链下**角色，将消息传送到目标链的 inbound 合约，并生成消息送达的证明 receive_messages_proof()，消息会被 inbound 合约传递给目标应用程序，发出 “MessageDispathed” 事件，此时，消息状态在目标链的 inbound 合约中被标记为 delivered（已送达）。

· 消息所承载的任务将由目标应用程序执行。此处，开发者可以提供一个自定义的过滤器，过滤不需要的消息。

3. confirm (source chain)

Relayer 将 receive_messages_proof 传回源链，并生成 receive_messages_delivery_proof，发出 MessageDelivered 事件，消息在源链 outbound 合约中被标记为 Comfirmed（已确认）状态。

· 源应用程序收到 MessageDelivered 事件，可以去执行开发者自定义的一系列动作。

4. reward 

在源链 outbound 合约中的消息被标记为 Comfirmed 之后，进行费用清算，Relayer 在源链的账户自动获得报酬。

5. comfirm (target chain)

Relayer 将消息在源链 comfirmed 并且 rewarded 的信息传递到目标链，目标链 inbound 合约将消息状态标记为 comfirmed。

· Relayer 可以批量处理该动作，但如果目标链的 inbound 合约中积累的 deliverd（已送达但未确认）消息过多，会导致其停止接收新消息。Relayer 必须定期执行此动作，才能让消息不至于被阻塞。

费用与激励

跨链发起者（可能是用户，也可能是 Dapp）在发送跨链消息时需要支付费用，费用将包含三个部分：

1. 执行源链交易的 Gas 费用。

2. 支付给 Relayer 的费用。

具体定价由市场决定，众多的 Relayer 可以展开价格竞争。

需要注意的是，Relayer 需要支付目标链上的 Gas 费用，Relayer 会在定价中体现这部分成本，也就是说，跨链发起者无需再单独支付目标链上的 Gas 费用。

3. 支付给 Treasure 的费用。

跨链发起者支付的跨链费用中，会有一定比例进入 Darwinia Treasure。Treasure 会有部分资金用于补贴 Head Relayer。

Darwinia Docs以太坊 Altair fork

5.5.7 zkBridge

在撰写本文时，zkBridge 是一个刚启动不久的项目，只完成了少量的开发。但该项目是目前为止，为数不多的将零知识证明技术用于跨链桥构建的项目之一。zkBridge 将 ZK-SNARK 证明用于轻节点的扩容。

目前 zkBridge 已经以 Solidity 在以太坊上实现了一个 Coos Client 的实例，据测试，可以在 2 分钟内生成一个 Coos Zone 区块头的 ZK-SNARK 证明，然后在以太坊端，仅仅花 220k gas 就可以验证它，对比来看，如果不用 ZK-SNARK 证明，这个费用将是 64 Million Gas。

zkBridge 的主要创新是：

· deVirgo：采用分布式的方法来生成 ZK-SNARK 证明，该方法称为 deVirgo，该方法通过将计算工作进行拆分，分配给更多的设备，大幅度提升了在链下生成 ZK-SNARK 证明的时间。

· 递归证明：为了降低链上成本，zkBridge 使用递归证明的方案（生成证明的证明），通过两次递归，将 ZK-SNARK 证明的体积压缩到 131 字节左右

· 批处理：zkBridge 实现了一个区块头的更新合约，它以区块高度为输入，返回相应区块头。但 zkBridge 并不会在每个新区块产生时，调用更新合约，证明者可以先收集 N 个区块头，生成一个单一的证明。N 值可以设置，N 越大，用户等待时间越长但系统运行成本越低。

不得不说，零知识证明技术是一项可以创造奇迹的技术。限制其采用的主要瓶颈在于技术门槛高，开发难度大，但在零知识证明技术的开发上，回报与付出总是相称的。

关于 zkBridge，更多的技术细节还有待披露，我们将保持关注。

zkBridge 推特长文zkbridge 论文：zkBridge: Trustless Cross-chain Bridges Made Practical (arxiv.org) 

5.5.8 MAP Protocol

MAP Protocol 是一个基于轻客户端和中继链的通用异构跨链协议。与前述的众多项目不同，MAP 选择建立一条中继链 MAP Chain，作为跨链消息传递的中转站。接入链之间无需直接建立连接，而是都与 MAP Chain 建立连接，也就是说：每条接入链只需部署 MAP Chain 的轻节点合约，MAP Chain 上部署每条接入链的轻节点合约。

MAP Protocol 的架构分为三层，分别是协议层，跨链服务层、应用层。其中：

· 协议层我们可以理解为信任层，包括 MAP Chain 和各个接入链轻客户端程序；

· 跨链服务层为应用层提供一些通用模块，让应用层不必「重造车轮」，例如一个通用的 Vault 模块，可以替一些资产桥应用程序锁定资金，不过应用程序也可以选择自建 Vault 而不使用该模块。

· 应用层是指使用 MAP protocol 作为跨链消息传输媒介的应用程序。

此外，MAP Protocol 包括三个链下角色

· 维护者（Maintainer）：负责更新各轻节点合约的区块头，可以获得 $MAP 通胀奖励。

· 信使（Messager）：负责传递跨链消息，可以获得用户支付的跨链费用，但需要垫付目标链和中继链上的 Gas 费用。

· MAP Chain 验证者：负责 MAP Chain 共识过程，需要质押 $MAP，可以获得 $MAP 通胀奖励。MAP Chain 目前采用 IBFT-PoS 共识机制。

消息流 

MAP Protocol 的文档中对消息传输机制没有过多着墨，从目前的只言片语中看，消息流应该是这样的：

当源应用程序发起跨链请求时，跨链消息 M 被包含在一笔交易 T1 中，被信使发送到中继链上，中继链收到交易 T1 之后，将交易 T1 及其携带的消息 M，包含在交易 T2 中，信使将 T2 中继到目标链，目标链收到 T2，将其验证之后发给目标应用程序。

尽管 MAP Protocol 是一个 2019 年发起的项目，但由于轻节点合约的不通用性，迄今为止，支持的链也只有 以太坊，BSC 和 Pogon，于「通用」二字，还有所名不副实。

在 MAP Protocol **发布的 Litebook 里提到，MAP 将会采用 ZK-SNARK 技术来提高链上轻节点合约的性能，但我们目前还没有看到与此相关的实例。

MAP Protocol 文档

5.5.9 Coos IBC

IBC 是一个设计非常精巧的同构跨链协议，是 Coos 跨链网络的重要组成部分。

Coos 跨链网络主要由 Hub 和 Zone 组成，Zone 与 Hub 之间通过 IBC（InterBlcokChain）协议建立桥接，Zone 与 Zone 之间以 Hub 为中继建立桥接。Coos 跨链网络还包括 Peg Zone 与异构桥接的部分，不属于 IBC 的范畴。

Hub 和 Zone 都是开放准入的，任何基于 Coos SDK 构建的区块链都可以成为一个 Hub，或成为一个 Zone 并向任意一个 Hub 注册为接入链。不同于波卡的中继链，Coos 的 Hub 不是唯一的。

5.5.9.1 轻客户端

每个向 Hub 注册的 Zone 都需要部署一个 IBC 模块，该模块中包含了 Hub 的轻客户端合约，Hub 当中的 IBC 模块也会集成每个接入的 Zone 的轻客户端合约。

Tendermint 共识机制中没有 epoch 的概念，每个区块都有可能会产生验证者的变动。但 IBC 中的轻客户端合约中有一个 TrustPeriod（信任期）的概念，这是轻客户端在初始化时需要设置的一个参数，在一个 TrustPeriod 内，允许验证者集产生微小的变化，个别验证者可能加入或者退出，但不会有大的变动。

这种微小的变化是可以接受的，因为每次签名几乎不会只有刚好 2/3 的投票权签名，总会有一定的溢出，即便个别验证者加入或者退出，轻客户端按照变化前的验证者集去检查该区块头，大概率还是能观察到 2/3 权重的投票权签了名。

因此 IBC 中的轻客户端合约，只需每个 TrustPeriod 更新一次验证人集的信息即可，这意味着每个 TrustPeriod 只需同步一个区块头。同步区块头的工作将由 Relayer 来执行。

5.5.9.2 核心概念与原理

IBC 构建了三个抽象概念，分别是 Connection（连接）、Channel（信道）、Packet（数据包）。

Connection 

是指两个 Zone 之间的连接，建立 Connection 可以理解为将两个 Zone 进行配对，此时，两个 Zone 向 Hub 请求对方的轻客户端的**区块头。Connection 的建立遵循三次握手原则（握手通讯均由 Relayer 触发），握手完成后，Conenction 开启。此时，可以在 Connection 之上，建立 Channel。

Channel

Connecion 连接的是两个 Zone，而 Channel 连接的则是 分别在两个 Zone 上的一对应用程序（这一对应用程序可能是同一个应用，也可能是不同的应用）。两个应用程序通过三次握手原则建立 Channel（握手通讯由 Relayer 触发），Channel 建立之后，这两个应用程序就可以相互发送 Packet 了。

Channel 是 IBC 中最核心的概念，他让应用程序直接建立连接。作为一个抽象概念，Channel 并不存在一个实体，对于接受端应用程序而言，Channel 定义了发件者，知道消息从哪个 Channel 传过来，就知道消息来自哪个 Zone 上的哪个应用程序，对于发送端应用程序而言，Channel 定义了收件端，想要向哪个应用程序发送消息，就把消息放进对应的 Channel。

Channel 还定义了消息时序，同一个 Channel 当中的消息遵循一个队列，具有严格的时序关系，先发的消息始终先到。不同 Channel 中的消息之间则没有时序关系。

这里需要注意的是，一个应用程序**稳定的使用一个 Channel。例如，一个资产桥应用如果使用多个 Channel 来在目标链创建映射资产，那么多个 Channel 会生成不同的映射资产，这将带来不必要的麻烦。

Packet

Packet 是一个规范的数据结构，是在 Channel 中被允许传送的跨链消息的规定格式。Packet 的传送分为三个步骤：

1.sendPacket：发送端的应用程序在源链上创建一个序号为 N 的 Packet，并加入待发队列；

2.recvPacket：Relayer 将该 Packet 中继到目标链，由接收端的应用程序存储。

3.acknowledgePacket：Relayer 将接收端应用程序已经存储该 Packet 的证明，传回源链，源链在待发队列中删除序号为 N 的 Packet。如果接收端合约长时间没有存储该 Packet，Relay 返回 timeout 的讯息。

需要注意的是，Coos IBC 与 MAP Protocol 不同，Packet 的发送是直接从源 Zone 抵达目标 Zone 的，并不需要在 Hub 中转。这是因为目标 Zone 可以向 Hub 直接 query 源 Zone 的区块头，然后执行对 Packet 的验证。这意味着，Hub 只需中转区块头就可以了。

Hub 上有源 Zone 的轻节点，可以验证源 Zone 的区块头，目标 Zone 上有 Hub 的轻节点，可以验证 Hub 的区块头，当目标 Zone 需要某个源 Zone 区块头 SourceZoneBlockHead{i} 的时候，可以让 Relayer 从 Hub 去获取，目标 Zone 上的轻节点验证 HubBlockHead{i}，并用 HubBlockHead{i} 验证 SourceZoneBlockHead{i} 之后，就可以用 SourceZoneBlockHead{i} 验证源 Zone 的 Packet 了。

费用与激励 

IBC 当中有一个可配置的费用模块，Connection 的发起方可以自定义收费标准及对 Relayer 的支付标准。不过根据我们的观察，Zone 的项目方和应用程序项目方往往都有动力自己运行 Relayer。

Coos IBC DocsCoos IBC 代码分析

5.5.10 原生验证桥小结

以上我们列举了若干个原生验证桥，可以发现大多数原生验证桥，都只连接了 2 个或者略多于 2 个链，这是由于轻客户端的不通用性导致的，随着兼容链的增加，边际成本并不会递减。另外，我们看到，随着以太坊的 PoS 转型，不少连接以太坊的原生验证桥都需要重新开发轻客户端，轻客户端是和源链的共识机制高度相关，往往需要随着链的升级而升级，这是原生验证桥的另一大困扰。由于以上两个原因，导致原生验证桥整体发展较慢，且不少项目还在艰苦的开发过程中。

Coos 则通过 Coos SDK 以及内置于其中的 Tendermint 共识协议，创造了一套开箱即用的造链工具，使得 Coos IBC 能够被动兼容基于 Coos SDK 开发的链。Coos 已成为目前是区块链世界仅次于以太坊的生态网络，刚刚完成 2.0 升级的 Coos，正在继续发力，完善跨链可组合性。

目前来看，在轻客户端方案的设计上，PoW 轻客户端还是以 SPV 轻客户端为主，逐个同步源链的所有区块头，PoS 轻客户端则大多采用跳跃式同步区块头的方案，仅同步验证者集发生变化的区块头，我们只需要让轻客户端在初始化正确的情况下，掌握验证者集的变化，就可以让轻客户端掌握**的验证者集。

实践中，轻客户端的构建还会遇到区块头验证成本过高，签名方案不兼容等问题，不同的项目会采取不同的方法应对，包括乐观验证（RainbowBridge）、验证者集抽样（Snowfork）、链下生成零知识证明（zkBridge），此外，公链为了更好的支持跨链，也有动力对自身进行改造和升级，例如以太坊 Altair 升级和 Polkadot 开发 Beefy 模块。

总之，轻客户端技术依旧处于激烈的演化之中，随着更多研究与探索的进行，未来构建轻客户端的难度会逐步降低。而我们本文所讲的这些案例中提及的方案，过时的速度可能比我们想象的快。

下面的章节，我们将开始一个新的旅程，那就是目前在跨链桥项目中占比**的外部验证桥。

5.6 外部验证桥

外部验证由于开发成本较低，通用性好，可以迅速兼容大部分的公链，成为大多数的跨链桥项目选取的路线。我们将在本文中，挑选几个具有代表性的展开介绍。

在本章中，我们依旧会重点关注跨链桥的信任层构建，因此项目举例会以 AMB 桥为主，资产桥的部分我们后文有专门的章节。

5.6.1 Anycall（Multichain）

Mutichain 是入场较早的跨链桥项目，产品上线于 2020 年 7 月，当时的名字叫 Anyswap。2021 年底融资之后，品牌名称改为了 Multichain，治理通证也从 $ANY 置换为了 $MULTI。在遭遇 2022 年初的合约漏洞事件之前，Mutichain 的业务规模是跨链桥领域无可争议的**，但在漏洞事件造成很多用户的资产损失后，TVL 有所缩减。

现在 Multichain 的业务被规划为三条产品线，分别是

· Swap 桥：Anyswap

· Wrap 桥：Crosschain Router Protocol（CRP）

· 任意消息桥：Anycall

其中 Anycall 是前两者的信任层。

AnyCall 是一个用户交换任意数据的通用跨链传递基础设施，采用 PoA 的方式构建。它由部署在链上的一组智能合约（anycall/anyExec），和一个 PC 网络组成。PC 的含义是安全多方计算（Secure Multi-Party Computation），Anycall 当中的每个 PC 节点独立验证消息，并基于私钥分片和门限签名技术，对消息进行签名，超过 2/3 节点签名的消息被认为通过验证。

PC 网络由 24 个节点组成，这些节点将负责监听链上 [anycall] 合约中的待发消息，并进行签名后，中继到目标链的 [anyExec] 合约。Dapp 通过与 anycall/anyExec 合约交互来实现跨链消息的收发。PC 节点成员不需要质押，且相对固定，AnyCall 的安全建立在对 PC 节点的信任假设基础上。

Multichain 的治理通证 $MULTI 的持有者，可以通过锁仓 $MULTI 获得 veMULTI，用其参与 Anycall 及 Multichain 旗下其他产品的治理，并可以获得 Multichain 的收入分成。

截至 2022 年 9 月，anyCall 支持跨 11 条链的任意消息传递：BNB Chain、Pogon、Ethereum、Optimi、Gnosis Chain、Fantom、Moonriver、IoTeX、Arbitrum、Avalanche、Harmony。明星 DeFi 项目 Curve 集成了 anycall 以支持 Gauge Weights 的跨链计算。

Multichain 文档

5.6.2 Wormhole

Wormhole 是由 Solana 和 Certus One 联合开发的跨链桥，起初是一座连接以太坊和 Solana 的资产桥。但随着后来的发展，Wormhole 已经演变成了一个支持 14 条异构公链之间传送任意消息的通用 AMB 桥，而资产桥的功能将由作为 Wormhole 应用程序的 Portal Bridge 承担。

和 Multichain 相同，Wormhole 的信任层采用 PoA 机制构建，由一组受信任的 Guardians（守护者)）负责链间消息的验证。这些 Guardians 是特定的具有资本背书和声誉背书的主体。目前，Wormhole 中的 Guardians 有 19 个，其中包括 FTX、Everstake 和 Chorus One 等知名大公司。

Wormhole 的结构非常简洁，其跨链消息格式被称为 VAA（Verifiable Action Approval），在 Wormhole 支持的链上部署了一组被称为 Core Bridge Contract 的合约。该合约将来自应用程序的跨链请求处理为 VAA，19 个 Guardians 监听链上生成的新的 VAA，并对其进行签名。然后被称为 Relayer 的角色负责将签名后的 VAA 中继到目标链。目前链上的 Core Bridge Contract 收到签名后的 VAA 之后，验证其签名，然后转交给目标应用程序。

Guardians 对 VAA 的签名是独立的，每个 Guardians 都单独执行该步骤，然后这些签名**组合成一个多重签名。一条 VAA 的批准，需要至少 2/3 的 Guardians 签名。Guardians 的成员是相对固定的，如果需要更换，将通过治理投票来完成。

Relayer 负责传送签名后的 VAA，该动作将在目标链上产生 Gas 费用（包括将消息提交给 Core Bridge Contract 存储的 Gas 费，和目标应用程序执行该消息的 Gas 费），Relayer 将垫付这部分费用。Wormhole 没有设置公共的 Relayer，各应用程序需要自己设计对 Relayer 的激励与相应的用户端收费，或者自行运行 Relayer。

对于 PoW 的以太坊，有个最终性确认的问题。在 Wormhole 中，消息需要等待多少个区块追加才能视为确认，是一个可以自定义的安全参数。

截至 2022 年 9 月，Wormhole 支持 14 条链：Solana、Ethereum、Terra Classic、BNB Chain、Pogon、Avalanche、Oasis、Aurora、Fantom、Karura、Acala、Klaytn、Celo 和 Terra。

2022 年 2 月，Wormhole 遭遇黑客攻击，由于合约编写漏洞，致使攻击者通过伪造签名，在 Portal Bridge 上为自己铸造大量资产。该攻击造成的损失超过 3.2 亿美元。在 Jump Crypto 等主要的资方支持者的帮助下，Wormhole 已经从攻击中恢复。

Wormhole 文档

5.6.3 Gravity Bridge

Gravity bridge 于 2021 年 12 月份启动，其目标是桥接 Coos 和以太坊生态。目前，Gravity 还只是一座资产桥，支持以太坊和 Coos 之间的资产传递，不支持任意消息传递。

结构 

Gravity Bridge 的信任层以 PoS 的方式构建，Gravity Bridge 的 PoS 验证者同时也是 Gravity Chain 的验证者，因此 Gravity Bridge 可以归为共享验证桥。

Gravity Chain 由 5 个部分组成

· Gravity Chain 及其验证者：一个基于 Coos SDK 构建的区块链，其验证者将以 PoS 的方式验证 Gravity Chain 与以太坊之间的跨链消息

· 一个名为 gravity.sol 的以太坊合约：实现以太坊端的 mint-burn/lock-burn 逻辑；

· Gravity Module：实现在 Gravity Chain 端的 mint-burn/lock-burn 逻辑；

· Orchestrator：是 Gravity Chain 上的一串代码，负责向 Gravity Chain 提交交易；

· Relayer：负责向以太坊提交 Gravity Chain 上的交易，并从中获得用户支付的跨链费用。

消息流

要将 Token 从以太坊转移到 Gravity Chain，用户需要调用 sendToCoos 方法。该方法从用户那里接收一定数量的 ERC20 Token 并将它们锁定在 Gravity.sol 中。它还发出一个事件：SendToCoosEvent。Gravity Chain 的每个验证者都运行一个以太坊全节点以监控以太坊的事件，当任意一个验证者监控到 SendToCoosEvent 时，Orchestrator 将向 Gravity Module 提交事件，Gravity Module 将跟踪事件，当该事件被 Gravity Chain 的验证者签名验证并被打包到区块中时，触发 Gravity Module 为目标地址铸造 Token。与 PoA 不同的是，PoS 中，每个验证者的签名权重是不同的，签名权重与他们的质押的 $GRAV 成正比。

如果要将 Token 从 Gravity Chain 转移到以太坊，过程相对简单，只需要 Relayer 将 Gravity Chain 上验证过的 lock 或者 burn 交易，提交到以太坊，gravity.sol 合约将为目标地址铸造 Token。

批处理

由于以太坊上 gas 费用高昂，从 Coos 到以太坊上的交易将会实施批处理。

当用户想要将 Token 从 Coos 发送到以太坊上的地址时，他们会通过 Gravity Module 将 Token lock（原生资产）或是 burn（非原生资产）。Gravity Module 将 lock/burn 交易放入交易池中。交易池存储所有尚未成批的 Coos 到以太坊的交易。（同一批次的交易仅限于一种 Token，不同的 Token 转移会被分配到不同的批次中）

任何人都可以发送请求 Gravity Module 组装一批交易，这往往由希望中继一批 Token 以获取利润的中继者完成。当 Gravity Module 收到此消息时，它会按照以下过程组装批次：

1. 查找该 Token 的所有交易；

2. 选择费用**的 100 笔交易，并将它们放在一起，组成一个批次；

3. 如果中继该批次有利可图，则将该批次放入批次池，若无利可图，则放弃该批次，批次中的交易会回到交易池中，等待组装到其他批次；

4. 进入批次池中的批次，将被验证者签名，并被打包到区块中；

5.Relayer 持续监控批次池中的批次，一旦有批次的签名超过阈值（2/3），就将其提交给以太坊上的 gravity.sol，并支付以太坊上提交和处理该批次的 gas 费用；

6. 批次处理完成后，Gravity.sol 就会发出一个 TransactionBatchExecutedEvent，验证者观察到该事件后，将其提交给 Gravity Module，触发删除该批次。

验证者集的更新 

Gravity.sol 需要了解 Gravity Chain 上的验证者更新，才能判断 Relayer 发送过来的消息或是批次，是否是被正确的验证者集签名。

任何人都可以从 Gravity Chain 发送跨链消息，请求更新 Gravity.sol 中的验证者集。我们在讲原生验证桥时，提到过 PoS 轻客户端掌握**验证者集的方法，Gravity.sol 用到的方法与之相似，但 Gravity.sol 并不是轻客户端，它不会存储 Gravity Chain 的区块头，而是让 Relayer 将验证者集的变更信息快照中继过来，存储为一个检查点。

所有的 PoS 跨链桥，包括我们后文提到的 Axelar、Hyperlane，用的都是类似的办法。

Gravity Bridge 介绍

5.6.4 Axelar

Axelar 发起于 2020 年年底，主要成员来自 Algorand 团队的跨链桥项目，致力于为 Web3 应用提供跨链互操作性。2022 年 2 月 15 日，Axelar 以 10 亿美元估值，完成 3500 万 美元融资，投资方包括 Dragonf Capital、Pochain Capital 等知名机构。

Axelar 基于 PoS 机制构建桥梁的信任层，Axelar 本身也是一个基于 Coos-SDK 创建的 PoS 公链。需要注意的是，Axelar 本身是公链，但它并不是中继链，只是桥接链，这两个概念在本系列第一篇中有过辨析。

结构 

Axelar 由以下部分构成：

· PoS 验证器网络：由 $AXS 驱动，承担双重职责 负责验证网络正在处理的所有跨链活动，这需要验证器运行接入链的节点（可以是全节点，也可以是轻节点）； 负责 Axelar Chain 的交易验证和共识出块；

· **合约（Gateway art Contracts）：部署在每条接入链上，以实现跨链消息收发功能；

· 开发者工具：包括一套软件开发工具包（SDK）和应用程序编程接口（API），借助这些工具，开发人员可以轻松部署跨链 dApp，并使用 Axelar 网络实现跨链任意消息传输。

此外，为了改善用户体验，Axelar 还提供了两组 Relayer 服务和 Gas Reciever 合约。

Relayer 服务：其中一组 Relayer 负责监听源链**合约上发起的跨链消息并提交给 Axelar 网络，另一组 Relayer 负责将被验证过跨链消息提交给目标链的**合约，垫付目标链上存储和执行消息的 Gas 费。Relayer 服务是可选的，用户和应用也可以执行这两组 Relayer 承载的任务。专设一组 Relayer 负责监听源链消息，是为了降低验证者的负荷。

Gas Reciever：用户的跨链操作将产生三笔 Gas 费用，分别是源链上的 Gas 费用，Axelar 验证器网络的费用（$AXS 形式），目标链的 Gas 费用，如果要求用户分别支付这三笔费用，那么用户体验将相当糟糕，Axelar 在源链上提供 Gas Reciever 服务，用户仅需以源链的 Token 支付一笔跨链费用，Gas Reciever 会自动将其中的一部分兑换为 $AXS 和目标链的 Token。

消息流

一旦 dApp 用户发起跨链消息发送请求，其第一站是与源链上的**合约交互，**接收到消息将发出一个事件，Relayer 监听到事件，然后将消息提交给 Axelar 验证器网络。

验证器网络对该消息进行签名，签名权重与他们质押（包含被委托质押）的 $AXS 数量有关。但签名权重与质押的 $AXS 数量并不是线性关系，Axelar 采用的是二次方投票（Quadratic Voting）机制，签名权重将与验证人质押的 $AXS 数量的平方根成正比。需要注意的是，二次方投票仅针对跨链消息的投票，Axelar Chain 自身的交易签名和区块签名仍遵循一 $AXS 一票原则。

消息被签名后，Relayer 将消息提交到目标链 Gateway 合约，并由目标应用程序处理。

Axelar 作为一个基于 Coos-SDK 构建的公链，除了通过验证器网络桥接了一众 EVM 链的跨链以外，还通过 IBC 进行扩展，接入了更多 Coos 链。目前接入 Axelar 的网络已经有 22 个。Axelar 之所以能有现在的成就，与其深度融入 Coos 生态系统有很大关系，Axelar 在开发和治理过程中，有 Coos 社区的积极参与，而且通过将 Terra、Classic、Oosis、Secret Network 和 Jun 等 Coos Zone 连接到 EVM 世界，获得了大量的跨链业务量。

Axelar 文档

5.6.5 Hyperlane（曾用名：Abacus）

Hyperlane 被人所熟知的名字是 Abacus，它拥有一个阵容豪华的创始团队。团队中有 Celo 的首批工程师 Asa Oines 和 Nam Chu Hoai 以及之前共同领导 Galaxy 风险投资业务的 Kol。顾问包括 NFX 的合作伙伴 Morgan Beller、Facebook 的 Stablecoin Diem 的联合创始人，以及 Coos 联合创始人 Zaki Manian。2022 年 9 月 22 日，Hyperlane 宣布完成 1850 万美元融资，加密风投 Variant 领投。

Hyperlane 将致力于提供一组 API 接口，让应用程序通过调用它实现跨链消息的收发。

结构 

Hyperlane 包括以下组成部分：

· 链上负责消息收发处理的合约：分别是 outbox 合约和 inbox 合约，每条接入链上都有一个 outbox 合约，outbox 合约中维护了一个由所有消息作为叶子节点的默克尔树（称为消息树），需要发送的消息将提交到 outbox 合约，作为新的叶子节点插入消息树，使消息树产生一个新的根（称为消息根）。每条接入链上都有（n-1）个 inbox 合约（n 为接入链的数量），inbox 合约将负责接收和验证跨链消息，并将其转交给目标应用程序。

· 多个 PoS 验证者集：每条接入链都有一个验证者集，负责签署从该链发出的消息的默克尔根，PoS 验证者需要在其负责验证的链上抵押 $ABC（可能来自其他用户的委托），签署任何消息根之外的内容都被视为欺诈行为，其抵押金将被削减；

· Relayer：负责传递被签署后的消息根，传递消息以及消息的默克尔路径；

· 瞭望塔（Watchtower）：负责监控和报告验证者的欺诈行为。

消息流

发送和接收跨链消息需要四个步骤：

1.用户通过源应用程序调用源链上的 outbox.dispatch 函数，将消息 M 插入到消息树中；

2.源链的 Hyperlane 验证者签署包含消息 M 的新的消息根；

3.Relayer 聚合验证者的签名，并将新的消息根连同消息原文（含默克尔路径）传送到目标链；

4.目标链上的 inbox 合约用消息根和消息的默克尔路径验证消息，然后将验证后的消息传递给目标应用程序。

失败处理：Relayer 可以配置为在处理失败时重试消息。第一次尝试处理失败的消息将导致 Relayer 以指数退避重试。在达到**重试次数后，Relayer 将不再尝试处理该消息。

Hyperlane 的一大特点是采用消息树结构，这样做的好处有两个：一是验证者不知道消息的具体内容，防止验证者审查消息；二是便于瞭望塔发现欺诈行为，瞭望塔将不需要观察消息本身有没有被篡改，只要被签署的消息根没有篡改，消息就不可能被篡改。

Hyperlane 的另一个特点是每条链上都有独立的验证者集，而不是复用同一个验证者集，这可能导致从不同链发出的消息传递安全性不一致，因此 Hyperlane 为应用程序提供灵活的选择，如果 dApp 项目方认为某个特定链安全性不足，可以选择不集成该链。

费用与激励 

PoS 验证者每个 epoch 可以从网络中获得 $ABC 通胀奖励。

Relayer 可以自定义费用结构，以在源链上接受用户的付款，并用其中的一部分支付目标链上的 Gas。Relayers 将组成一个开放的市场，而发起跨链请求的应用程序用户作为买方，自由选择适合的 Relayer。

「可验证欺诈证明」

Hyperlane 将其核心机制描述为「可验证的欺诈证明」，所有的消息根都存储在 outbox 合约中，PoS 验证者集的工作仅仅是为其附上自己的签名，如果在目标链上发现 PoS 验证者签署了篡改后的消息根，瞭望塔就可以把不正确的签署作为欺诈证明提交到源链上，源链上的合约很容易对欺诈进行验证。

这样的机制与乐观验证颇有相似之处，但 Hyperlane 没有乐观验证窗口期，这意味着瞭望塔报告欺诈行为的时候，很有可能行为的后果已经产生（例如不正确的铸币），我们还是需要相信，每条链上 2/3 以上的验证者是诚实的。因此，我们依旧将 Hyperlane 归为外部验证。

但相比其他类型的 PoS 桥，「可验证的欺诈证明」还是有一些明显的不同：

Axelar 这样的 PoS 桥，尽管也会对恶意的验证人进行 Slash，但对恶意验证人的判定方法是「多数原则」，也就是说，如果个别验证人签署了某个消息，而该消息最终没有被 2/3 以上的投票权验证，那么签署该消息的个别验证人将被认为是恶意的，从而触发 Slash。如果发生「真理掌握在少数人手中」的极端情况，那么系统将产生误判，需要治理流程参与进来进行纠错。Hyperlane 的机制可以保证，只要有一个 WatchTower 是诚实的，即便有 2/3 以上的验证人作恶，且导致传输了错误的跨链消息，系统依然可以自动发现错误并对作为多数派的作恶验证人执行 Slash。

与 Hyperlane 机制比较相似的另一个项目 Nomad，是乐观验证的典型案例，我们将在后文介绍。

截止 2022 年 9 月，Hyperlane 支持 7 个链的任意消息传递：Arbitrum、Avalanche、BNB 链、Celo、以太坊、Optimi 和 Pogon。Hyperlane 以 DAO 的方式治理，$ABC 持有者可以通过治理投票对 Hyperlane 协议进行更改。

Hyperlane 文档

5.6.6 LayerZero

明星团队，加上明星投资者，让 LayerZero 成为 2022 年上半年最火爆的一个跨链项目，跨链底层协议的叙事，再加上迅速上线若干个落地产品的执行力，让 LayerZero 被业界普遍看好。在 LayerZero 的白皮书中，LayerZero 被描述为一个去信任的全链互操作协议，一个功能强大的基础层的通信原语。

结构 

LayerZero 由三个核心组件构成，分别是 Oracle（预言机）、Relayer（中继器）、Endpoint（终端）

来源：LayerZero 白皮书

· Oracle 是一个第三方服务，它提供一种独立于其他 LayerZero 组件的机制，从一个链读取块头并将其发送到另一个链。

· Relayer 是一个脱链服务，其功能类似于预言机，但是它不是获取块头，而是获取指定交易及其默克尔证明。

· 终端 是一系列链上智能合约的组合，LayerZero 会在每个支持的链上部署终端，以支持跨链消息的有效传递。终端分为四个模块：Communicator（通信器）、Validator（验证器）、Network（网络）和 Libraries（库）。

LayerZero 的核心设计思想在于 Relayer（中继者）和 Oracle（预言机）的分离，在 LayerZero 中，Relayer 负责传递消息及消息证明，Oracle 负责根据消息所在区块，按需从源链获取区块头，然后目标链上的终端根据 Oracle 获取的区块头验证 Relayer 传递的交易。

尽管 Layerzero 将其技术方案称为超轻节点（Ultra Light Node），但其方案与轻客户端跨链毫无关系。LayerZero 并不会在支持的链上部署任何链的轻节点，从验证方式来讲，LayerZero 通过 Oracle 提供的区块头来验证 Relayer 提供的交易证明，验证过程在目标链的终端发生，属于原生验证，但是对区块头本身的验证却是由作为外部验证人的第三方 Oracle 网络来完成的，验证过程发生在链下，从本质上讲，LayerZero 采取的方案，依旧属于外部验证。

dApp 责任制 

LayerZero 的定位更多是一个中立的信息总线和传递标准，dApp 才是跨链服务的主体。dApp 有充分的自**，可以自己决定选择哪个 Relayer，以及决定选择哪家预言机。在 LayerZero 当中，Relayer 和 Oracle 都是开放准入的，任何人都可以运行一个 Relayer，任何第三方 Oracle 网络也都可以加入（目前默认的 Oracle 是 Chainlink）。但 LayerZero 期待的理想状态是：每个 dApp 都要运行自己专有的 Relayer。在这种状态下，如果预言机网络想要串通 Relayer 作恶，构建虚假交易并验证它，必须串通控制 Relayer 的主体——dApp 项目方，而 dApp 项目方不太可能做毁灭自己的事情。

此外，即便出现了联合作恶的情况，风险依旧可以限制在 dApp 内部，不会波及其他使用不同 Relayer 的 dApp，这是一种风险隔离措施。

尽管如此，我们认为上述的串通并不是完全不可能，虽说 dApp 项目方大多数时候不会反对自己，但这不排除那些打算 rug-pull 的 dApp 项目方。因此，我们要认识到，LayerZero 并不是像其所宣称的那样，完全去信任化。但与此同时，我们也要看到，Oracle 和 Relayer 分体的设计，和 dApp 责任制的思想，相比单纯的外部验证人网络直接负责消息传递，安全性还是得以大幅提高，LayerZero 的创新是有积极意义的。

消息流 

LayerZero 的另一大特点是模块化的终端，为了理解终端的工作机制，接下来我们来深入看下 LayerZero 的跨链信息流。 

一个跨链信息的传递被分为 13 个步骤，为了让逻辑更加清晰，我们来分组表述。

步骤1-5：是当链 A 上发生一个跨链请求后，链 A 的终端通知 Oracle 和 Relayer，分别从链 A 获取相应信息，具体如下： 

1.用户通过 dApp-X 在链 A 上产生了一笔需要跨链传递到链 B 的交易 T，并向链 A 终端上 Communicator（后简称 Communicator A）发起跨链请求，请求内容为 [t,dst，payload,relayer-args]

温馨提示：如果非技术出身的您，看到代码感觉凌乱，可将后文中所有中括号内的内容置换为「相关参数」，再进行阅读。

2.Communicator A 将跨链请求处理为一个数据包，包含 [packet(dst,payload),t,relayer-args]，发送给 Validator A ； 

3.Validator A 将 [t,dst] 发送给 Network A，通知 Network A 获取当前区块 ID ； 

4.Validator A 将 [packet(dst,payload),t,relayer-args] 发送给 Relayer，通知 Relayer 获取交易证明； 

5.Network A 将区块 ID 发送给 Oracle，通知 Oracle 获取区块头；

步骤6-9: Relayer 和 Oracle 分别获取到对应信息，并提交给链 B 上的 终端，详细如下：

6.Oracle 从链 A 获取到区块头； 

7.Relayer 从链 A 读取到交易 T 及其交易证明 proof(t)，存储到本地； 

8.Oracle 将区块头提交到 Network B ； 

9.Network B 将区块头中的哈希值发送给 Validator B ；

步骤10-11: 由于除了当前跨链请求，在同一区块内，可能还有其他跨链请求，因此 Relayer 会获取区块头，然后将所有该区块相关的跨链请求内容全部获取过来，详细如下： 

10.Validaor B 将区块头哈希发给 Relayer ； 

11.Relayer 收集当前区块内所有跨链请求及相关交易证明 [Packet(dst,payload),t,proof(t)]，返回给 Validator B ；

步骤12-13： 链 B 的终端用区块头验证这些相关的交易，并发给目标应用程序 dApp Y，跨链消息传递完成： 

12.Validator B 用区块头验证接收到的所有交易，验证不通过的交易将被丢弃。验证通过的交易 [packet(dst,payload)] 发送给 Communicator B ； 

13.Communicator B 将验证后的交易 [packet(dst,payload)] 发给 dApp Y。

我们发现，终端各模块的工作方式类似于网络堆栈，在发送端上，消息从 Communicator 到 Validator 再到 Network，在接收端上则刚好反过来。这样的设计是高度通用的，LayerZero 在支持新的接入链时，这三个模块是不用改动的，只需要在 Libarary 中添加关于新链的参数即可，这样的设计使得 LayerZero 十分便于扩展到新的区块链。

在消息流设计方面，LayerZero 会直接一次处理掉同一区块内所有的跨链请求，这样避免不必要的重复工作。

费用与激励

第三方 Oracle 服务有自己的经济模型，与 LayerZero 自身相互独立，第三方 Oracle 也将向使用 LayerZero 的 dApp 收费。

LayerZero 希望 dApp 项目方自己运行 Relayer，当然，dApp 项目方也可以制定一个付费标准，然后将其外包给社区。LayerZero 可以要求 Relayer 质押资金作为安全保障，目前 LayerZero 尚未做这样的要求。根据 LayerZero 的「dApp 责任制」的核心思想，我们推测未来 LayerZero 应该会让 dApp 项目方自己决定是否要质押，质押多少钱，质押越多，对 dApp 自身的用户而言，安全保障越高。

LayerZero 的应用现状 

LayerZero 的生态发展很快，迄今为止，已支持的公链 有 Ethereum、Pogon、BSC、Avalanche、Fantom、DFK、Harmony，还有以太坊二层网络 Arbitrum、Optimi，Avalanche 子链 Swimmer Network、波卡平行链 Moonbeam。

LayerZero 上的生态应用也开始蓬勃发展，除了 LayerZero 自建的跨链 DEX 产品 Stargate，第三方创建的跨链 DEX 产品 Hashflow、Interswap 也陆续启动。跨链 DEX 之外，LayerZero 上**发力的是 NFT 类应用，例如 NFT 收藏品 Gh0st Gh0sts、Tiny Dinos、Yakuza Pandas、跨链 NFT 桥 parakeet.dao，还有 NFT 养猫游戏 Catddle。

此外，面向机构的去中心化借贷项目 Clearpool 也宣布接入 LayerZero 以实现跨链相关功能。

LayerZero 白皮书LayerZero Docs

5.6.7 CCIP（Chainlink）

CCIP 是 Chainlink 于 2021 年底公布，目前还在开发的一个跨链堆栈。

Chainlink 是预言机领域的龙头，拥有非常丰富的节点资源，足以组成一个分布式程度更高的节点委员会、或者说 PoS 验证者集，因此，Chainlink 做跨链桥基础设施应该是水到渠成的事情。

CCIP 的跨链逻辑与 PoS 桥大致相同：

来自源链的应用程序调用 Chainlink 的消息路由器，Chainlink DONs（去中心化预言机网络）将监听到消息并对消息进行共识签名，再由 Relayer 中继到目标链，目标链的消息路由器对消息的签名进行验证并发送到目标应用程序完成执行。

但在这之外，CCIP 还引入了「反欺诈网络」风险管理系统。反欺诈网络与预言机网络相独立，作为一个新的验证层，在系统运行时定期提交心跳检查。如果反欺诈网络停止发送心跳，抑或是报告恶意行为，就会自动触发紧急关停机制。

CCIP 与 LayerZero 的设计有一个相同之处，那就是构建了两个独立的信任层。

Chainlink 目前只发布了一个非常粗略的 CCIP 文档，更细节的资料还有待披露。

CCIP 介绍

5.6.8 pNetwork v2

pNetwork 是有 Provable Things 团队开发的一个跨链桥，pNetwork V1 于 2020 年 3 月推出，是一座 Wrap 桥，Wrap 资产被称为 pTokens，2021 年 10 月，pNetwork V2 发布，该版本将 pNetwork 拓展为了一座 AMB 桥。

pNetwork V2 延续了 V1 的核心特性，那就是使用 TEE 节点组成的 MPC 网络来验证跨链消息。TEE 全称为 Trusted Execute Environment，中文译为可信执行环境，它对于我们的日常生活而言并不陌生，手机上的指纹验证就是在 TEE 中运行的。

TEE 是在给定设备上运行的与主操作系统隔离的计算环境，就像一块飞地（Encalve）。这种隔离是通过硬件强制实现的。在 TEE 中运行程序的过程是隐蔽的，外界不可感知，这减少了 TEE 遭受黑客攻击的可能性。程序在 TEE 中运行完成后，输出的计算结果会被附上一个由设备生成的签名，该签名将被设备供应商远程验证，并生成远程验证证明。远程验证证明能够向外界证实该程序在 TEE 中被完整的执行，没有被篡改和干预。正因为如此，TEE 可以运行具有高安全性要求的应用程序，例如加密密钥管理、生物特征认证、安全支付处理等。

结构

pNetwork V2 主要包括以下部分

· TEE 节点网络：任意拥有 TEE 设备的主体可以质押 200 $PNT（至少 3 个月），即可成为 pNetwork 的 TEE 节点。pNetwork 中的 TEE 节点网络将负责对跨链消息进行共识签名。在初始化时，TEE 节点集需要共同参与秘钥的计算，以生成公钥和私钥碎片，其中公钥只有一个，处于公开状态，私钥碎片则是在本地生成后，存入 TEE 中「密封」。

· Portal：pNetwork 管理跨链消息传输队列的一组链上合约；

· Postman：类似于 Relayer；

· pNetwork DAO：pNetwork 采用 DAO 的方式进行治理，$PNT 持有人可以质押 $PNT，参与治理投票，决定 pNetwork 的费用参数和发展方向。

消息流

1.用户通过源应用程序在源链调用 Portal 合约，发起跨链消息发送请求；

2.TEE 节点监听到请求，将跨链消息放到 TEE 节点中验证（TEE 中需要运行源链的轻节点），并用自己的私钥碎片签名，当签名的私钥碎片数量达到门限（2/3），将合成一个完整的签名，(不会暴露明文私钥)，这代表消息被验证通过；

3.Postman 把验证通过的跨链消息送达目标链的 Portal 合约，Portal 合约在检查签名后转交给目标应用程序。

为什么要用 TEE 节点

2022 年 3 月 23 日，Axie Infinity 的官方跨链桥 Ronin Bridge 被黑客攻击，起因是 9 个多签节点中有 5 个节点的私钥被黑客盗取。我们在该事件中，看到即便多签节点没有主动串谋，外部攻击者还是有可能从物理层面攻破多签节点的设备，窃取私钥，进而攻击跨链桥。

由于多签节点需要用程序来执行对跨链消息的签名，这使得私钥不得不暴露在网络中，极易成为黑客攻击的目标。如果让多签节点使用 TEE 设备来存储私钥、验证和签名交易，那就可以很大程度上规避这个问题，让攻击者很难下手。

pNetwork 支持节点使用不同厂商的 TEE 设备接入网络。不同厂商的 TEE 设备的具体技术方案有可能是不同的，如果众多节点的 TEE 设备来自多元化的厂商，将进一步阻止黑客攻击。因为黑客需要攻破不同的 TEE 设备，才有可能实施攻击。

应用现状

截止 2022 年 9 月份，pNetwork 支持 9 条链的任意消息跨链，包括以太坊、Pogon、Gnosis Chain、Telos、Libre、EOS、BSC、Arbitrum、Algorand，同时支持在这些链上铸造 pBTC。

尽管 pNetwork V2 已经作为任意消息桥发布，但依目前而言，pNetwork 的「主营业务」还是 资产桥，目前尚未有第三方的跨链应用基于 pNetwork V2 搭建。

pNetwork V2 简介

5.6.9 Bool Network

Bool Network 是另一个采用 TEE 节点网络作为外部验证者的 AMB 桥项目。Bool Network 在此基础上做了进一步的创新——增加了 TEE 节点的轮值和匿名机制。这样不仅让外部攻击难上加难，而且几乎可以杜绝内部串谋。

Bool Network 参考 Coos IBC，引入了 Channel 的概念，部署在不同链上的两个应用程序之间可以建立 Channel，以实现二者之间消息的有序传递。每个 Channel 都会对应至少一个 MPC 委员会。该委员会在当前 epoch 内负责对该 Channel 内的跨链消息进行共识签名。这个 MPC 委员会是轮值的，任期只有 1 个 epcoh，每个 epcoh 都会重新选举。

· Bool Network 目前会为每个 Channel 分配两个委员会，互为备份，以提高服务可用性。

任何人都可以通过质押 $BOL 成为候选的 TEE 节点。每个 epoch 开始前，Bool Network 会通过 Ring VRF 算法，为每个 Channel 选举 MPC 委员会。被选为 MPC 委员会成员的节点会获得一个用于通讯的临时身份（公私钥对），用于在共识签名过程中与同一委员会中的其他 TEE 节点通讯。当一个 epoch 结束时，所有的临时身份都会失效，然后网络将重新进行节点选举，选出新的轮值 MPC 委员会，赋予他们新的临时身份。

尽管每个候选的 TEE 节点在注册的时候，需要提供**身份信息（设备编码），但节点在通讯时使用的临时身份并不会暴露**身份信息。换句话说，节点在通讯时是相互匿名的。如果候选节点有 100 个，那么你只能知道与你通讯的节点是这 100 个当中的 1 个，而不知道具体是哪一个。

每个 Channel 的 MPC 委员会需要多少个 TEE 节点，签名的门限是多少，是由 Channel 创建人自定义的。常用的门限数值有 15-of-21、13-of-19、5-of-9。

同一个 Epoch 内，不同 Channel 的 MPC 委员会成员可能会有重叠，也有可能有部分候选节点没有被选入任何一个委员会，而出现闲置的状态。这些情况都是正常的。

我们发现，Bool Network 通过 TEE、轮值机制、匿名机制的组合，构建了一个牢不可破的黑箱。由于签名程序运行在匿名节点的 TEE 中，而且它们之间的通讯内容是 DH 加密的，只要不是闲置状态，TEE 节点的运营者本人都无从知晓自己被选入哪个 Channel 的 MPC 委员会，与哪些节点进行了共识通讯，签名了哪些消息，连「自知」都做不到，更谈不上「知人」。这基本上让节点串谋变的不可能。

从外部攻击者的角度，如果要攻击某个特定的 Channel，攻击者无从知晓当前的 MPC 委员会背后是哪些设备，也无法从通讯中截获这些信息。

无论是内部串谋，还是外部攻击，都只能选择攻破所有候选节点中的大多数，才有可能攻击成功，这无疑代价是巨大的。

Bool Network 是一个仍在开发中的项目，还有些技术细节没有完全确定，我们在本小节中阐述的只是其技术概要。

Bool Network Space 演讲

5.6.10 XCMP（Polkadot）

我们前文提到，波卡的跨链模式可以归结为外部验证中的一个特殊类型：共享验证。波卡的基本模型是分片，这是波卡实现共享安全性的途径。每个平行链是一个分片，平行链没有自己的验证者，而是由中继链分配一个验证者子集作为平行链的验证者集，这种分配是随机的，动态的，每个 epoch 都会重新分配。在任何一个时刻，中继链的验证者集是所有平行链验证者集的并集，这符合共享验证的特征。

但我们要理解波卡的跨链传输机制，还需读懂 XCMP 的细节。XCMP（Cross-Chain Message Passing）是 Polkadot 上的跨链消息传输协议，用于平行链/平行线程之间的跨链通讯，XCMP 还在开发中，目前已经部署的是 HRMP（Horizontal Relay-routed Message Passing）。此外，波卡使用 VMP（包含 UMP\DMP）来实现平行链/线程与中继链之间的消息传递。

HRMP 提供与 XCMP 相同的接口和功能，但跨链消息是放在中继链存储的，这将给中继链带来负荷，因此这是一个过渡方案，后续将被 XCMP 替代。

我们需要了解 XCMP 和 XCM 的区别：Gawin 在一次采访中提到，XCMP 只是波卡跨链解决方案的一半，另外一半是 XCM，XCM 是波卡制定的一个跨共识消息通用格式，其效用是表达消息接收者应该做什么。

本小节的关注点在 XCMP。接下来我们将对 XCMP 的跨链传输模型做一个拆解。

5.6.10.1 主要概念 

Channel

与 Coos IBC 类似，XCMP 当中也有 Channel（通道）的概念，但 XCMP 当中的通道是单向的，两条平行链（A 和 B）之间如果想要双向通讯，就需要建立两条通道（AB Channel，BA Channel）。

Egress 和 Ingress

当平行链 A 与平行链 B 建立 AB Channel 时，平行链 A 上会被创建一个平行链 B 的 egress（出口队列），而平行链 B 上会被创建一个平行链 A 的 ingress（入口队列）。

MR（Message Root）

每一个出口队列里除了存储待发消息队列的原文之外，还需要维护一个 MR 队列（Message Queue Hash Chain）。XCMP 在这里也采用了消息树的结构，所有的待发消息作为叶子节点构成一个默克尔树，树的根值被称为 MR（Massage Root），每有一个新的消息作为叶子节点插入，都会产生一个新的 MR。

5.6.10.2 消息流

（以 AB Channel 为例）

1.Chain A 上用户通过源应用程序发起跨链请求，想要将消息 M 送到 Chain B。该消息会被放入 Chain A 上为 Chain B 专设的出口队列（我们简写为：Egress AB）。该消息将被包含进**的 MR 中。

2.Chain A 的收集者在打包当前区块的时候，会将**的 MR 放入区块头。当区块被中继链分配给 Chain A 的验证者验证后，会被提交到中继链，并被中继链的区块包含。此时，我们认为该 MR 被中继链验证了。

3.Chain B 的收集者会不断轮询所有其他链上为 Chain B 建立的出口队列，这里就包括 Egress A B，Chain B 的收集者将 Egress A B 中的消息原文及 MR 队列放入自己对应的入口队列：Ingress AB。（* 有另一种说法，该过程不是收集者完成，而是验证者完成的，这点的设计在 XCMP 中还没有完全确定，但谁来完成并非 XCMP 设计的关键点，因为这项任务是无信任的，谁来完成都可以）。

4.Chain B 的验证人从中继链获取 Channel AB 的**被中继链验证的 MR，以及该 MR 已经被中继链验证的证明。由于 Chain B 的验证人本就来自于中继链的随机分配，所以这个过程不存在信任问题。

5.Chain B 用该 MR 来判断 Ingress AB 哪些消息已经被包含到中继链中，然后更新这些消息的状态为已验证。

6.已验证的消息可以被目标应用程序执行了。

我们为了表达方便，只描述一个 Channel 的消息流，事实上 XCMP 在处理跨链消息的时候，所有的 Channel 是同时处理的。中继链会维护一个 CST 表格（Channel State table），用于存储所有 Channel 的 MR。

UMP 和 DMP 大致与 XCMP 同理，不再赘述。

XCMP docs

5.6.11 外部验证桥小结

以上我们举了若干个外部验证桥的案例，包括：

两个 PoA 桥，分别是 AnyCall、Wormhole；

五个 PoS 桥，分别是 Axelar、Hyperlane、Gravity Bridge、pNetwork V2、Bool Network；

两个 TEE 桥，分别是 pNetwork V2、Bool Network；

一个采用外部 Oracle 的桥，LayerZero，还有一个预言机服务商亲自建设的桥 CCIP；

两个共享验证桥：分别是 Gravity Bridge 和波卡的 XCMP。

读者可能发现，我们列举的两个 PoA 桥，都遭遇了非常严重的黑客攻击。尽管外部验证桥在安全假设上的确有验证人联合作恶的风险敞口，但事实上，被攻击的原因并非安全假设层面，而是代码实现上的漏洞。而 PoA 桥更容易吸引黑客攻击，恰恰是因为其实现简单，入场较早且发展较快，TVL 很高，成为了黑客眼中的肥肉。因此，我们不会因为某个项目遭遇了黑客攻击，而否认该项目的整体结构设计。关于跨链桥如何提高安全性和防范黑客攻击的话题，我们会有专门的章节。

PoS 桥的实现也并不困难，但守护桥梁的通证需要有较大的市值，才能充分保障网络的安全，否则攻击桥梁的经济成本将会很低。因此，PoS 桥的发展可能会将 PoA 方案作为过度阶段，在 TVL 上升，推高通证价格之后再转 PoS。PoS 桥要面对的一个问题是验证者的不均衡性，例如 Axelar 有 50 个验证者，但想要达到 2/3 的签名阈值，只需要 10 个左右的头部验证者签名就可以了，为了缓解这个问题，Axelar 采用了二次方投票的方案；Hyperlane 则采用「可验证欺诈证明」方案，验证人联合作恶将立即被发现并执行 Slash；pNetwork 和 Bool Network 则直接要求所有节点质押相同数额的 Token。

pNetwork 和 Bool Network 要求 PoS 验证者用 TEE 来存储私钥、执行签名，以防止外部攻击者窃取私钥，攻击跨链桥，Bool Network 还通过 TEE 节点的轮换机制和匿名机制，让内部的节点串谋也变的十分困难。LayerZero 独具特色的构建了两个信任层，一个是外部 Oracle 网络，一个是负责传递消息的 Relayer，只要二者不串通，就可以保证跨链的安全。LayerZero 还通过应用程序负责制，在各应用程序之间实现跨链的风险隔离。CCIP 同样构建了两个信任层，一个是预言机网络，一个是反欺诈网络，此外，Chainlink 丰富的节点资源将为其赋能。

Gravity Bridge 和波卡的 XCMP 都是共享验证的案例，Gravity Bridge 依旧可以用 PoS 桥的范式去理解，只是桥的安全性与 Gravity Chain 的安全性一致，Gravity Bridge 正在计划从 Coos Hub 中租用安全性（这是 Coos 2.0 的新功能），将桥的安全性进一步提升。XCMP 则是基于波卡被深度定制，致力于实现波卡平行链间的同构跨链，与其说跨链，更像是跨分片，我们**以跨分片的视角去理解它。

5.7 本地验证桥

本地验证仅适用于 Swap 桥。目前来看，采用本地验证方案的桥主要是以太坊跨层资产桥，我们已经在本系列第二篇 5.2.3 小节 列举了 cBridge、Connext、StarEx Bridge 三个典型案例。因此本小节不再举例。

5.8 乐观验证桥 

5.8.1 Nomad（前身 Optics）

Nomad 的技术方案脱胎于 Celo 旗下的跨链桥项目 Optics，Nomad 的几名核心成员也来自被 cLabs 收购的 Summa 跨链研究团队。但 Nomad 从一开始就已作为一个通用跨链项目而独立发展，已不再使用 Optics 的基础设施。2022 年 4 月 13 日，Nomad 以 2.25 亿美元估值完成 2200 万 美元种子轮融资，领投方是 Pochian Captical。

Nomad 在试图通过一个全新的方式，解决跨链不可能三角问题。Nomad 意识到轻节点客户端跨链方案在易适配性上的缺陷，也意识到外部验证人跨链方案在安全性上的妥协。于是 Nomad 采用了欺诈证明的方式来验证跨链信息。在 Nomad 中，跨链消息在传递成功后，有一个争议窗口期（30min），如果在争议窗口期，没有人报告欺诈行为，消息将被接收端正式接受。

5.8.1.1 核心概念及结构

Nomad 协议由链上的智能合约和链下**角色两个核心部分组成：

链上智能合约实现了 Nomad 的消息发送和消息接收的逻辑，链上智能合约包括 Home 和 Replica 两部分，其中 ：

· Home 负责处理消息发送逻辑，可以理解为 Nomad 跨链消息的「发件箱」，Home 合约也负责管理 Updater 的保证金（bond）；

· Replica 则负责处理消息接收的逻辑，可以理解为 Nomad 跨链消息的「收件箱」。

需要注意的是，接入 Nomad 的区块链中，每条链上只有一个 Home 合约，但可以有 n-1 个 Replica 合约，n 是接入链的数量。这样的设计与 Hyperlane 似曾相识。

链下**负责以可信的方式传递跨链消息，链下**包括 Updater（更新者）、Watcher（观察者）、Relayer（中继者）、Prosessor（执行者）四个角色。其中：

· 每个 Home 合约会对应一个 Updater，Updater 负责签名 [update]，此处 update 一词被当作名词使用，是 Nomad 语境下的一个专用名词，表示一个特定的数据结构，我们统一加中括号进行表示，一个 [update] 包含上一个消息树的根 _oldroot，和新的消息树的根 _newRoot，被签名后还会包含 Updater 的数字签名。

[ update ] = [ _oldRoot , _newRoot]被 Updater 签名后的 [ update ] = [ _oldRoot , _newRoot，_signature ]

· Watcher 负责观察和报告欺诈行为；

· Relayer 负责在链间传递签名后的 [update] ；

· Prosessor 负责在 [update] 传递成功之后，将对应的跨链消息原文（包括默克尔路径）传递到目标链，并触发目标链 Replica 合约用 [update] 验证跨链消息，然后将验证过的消息发送给最终的目标应用程序执行。

Channel 

在 Nomad 中，一个 Home 合约和一个对应该 Home 合约的 Replica 合约可以组成一个 Channel，这个 Channel 是单向的，如果要进行双向的跨链传输，需要两个成对的 Channel。一个 Home 合约可以对应多个 Replica，因此从一个源链出发，面向多个目标链，会有多个 Channel，这给 Nomad 带来一个新的用例：一对多的消息传输。

5.8.1.2 消息流

我们来看下 Nomad 中的跨链消息传递过程：

1.应用程序调用源链 Home 合约，将需要跨链的消息 T 排入发送队列；

2.源链 Home 合约中在 T 消息之前**的消息根，我们设为 _oldroot，步骤 1 完成后，Home 合约将消息 T 进行格式化处理，作为叶子节点插入消息树，计算出新的消息根 _newRoot，_newRoot 和 oldRoot 唯一的区别就是 _newRoot 包含了消息 T ；

3.Updater 调用 Home 合约中的 update 函数，对 _oldRoot、 _newRoot 进行签名后传回 Home 合约。该行为被称为 update（这里作为动词，我们不加中括号），每有一个新消息根产生，就可以 update 一次，但为了节约成本，updater 也可以在多个新消息根产生后，进行批量 update ；

4.Relayer 将被 Updater 签名后的 [update] 传入目标链，并调用目标链 Replica 合约将传入的 [update] 放入待定池，启动争议窗口期；

5.争议窗口期内，Wactcher 对欺诈行为进行检查，主要是看 Home 合约中被 Updater 签名的 update 和 Relayer 传递到目标链上的 update 是否一致，防止消息根被篡改；

6.计时结束，没有 Watcher 报告欺诈，Prosessor 将从源链获取消息 T 及 T 的默克尔路径，传入目标链，在目标链上调用 Replica 合约，验证 _newRoot 对消息 T 的包含性。证明完成后，Prosessor 将消息移出待定池，发送给目标应用程序。

验证仅需用到 _newRoot，_oldRoot 的作用应该是定序。

Nomad 和 Hyperlane 一样都采用消息树的结构，这样可以防止 Updater 审查消息，还可以方便 Watcher 发现欺诈行为。

欺诈处理流程

以上过程是我们先假设没有欺诈行为发生，如果发生欺诈：

· 源链 Home 合约中的 [update] 与被 Relayer 中继到目标链上的 [update] 不一致，被篡改的 _newRoot 中可能包含了一个把大量资金转给 Updater 的交易。

那么 Watcher 将需要在 30min 内，先向目标链上的 Replica 合约提交欺诈证明，将欺诈的 [update] 标记为不可信状态，然后向源链上的 Home 合约提交欺诈证明，触发 Home 合约 Slash 掉不诚实 Updater 的保证金并停止处理新的待发消息。这意味着从该链向其他链发送消息的 Channel 被关闭。需要注意的是，此时，从其他链向此链发送消息的 Channel 仍是开启状态。

后续 Nomad 将通过治理来擦除错误的 [update]，改选 Updater，重启 Channel。

你可能会疑惑，明明是 Relayer 向目标链上传递了被篡改的消息根，为什么要处罚 Updater？原因很简单：Relayer 无法伪造 Updater 的签名，如果 Relayer 传递了被一个篡改的 [update]，一定是 Updater 签名了这个被篡改的 [update]。作恶的来源只能是 Updater，作恶的 Updater 完全可以自己运行一个 Relayer 服务或者串谋一个 Relayer 来完成作恶行为。

5.8.1.3 深入理解 Nomad 的 4 个链下**

我们看到，Nomad 的链下**有 4 种之多，看起来似乎有些复杂，但这四个角色缺一不可，我们来为它们的职责做一个进一步的辨析。

· Updater 仅仅负责签署 [update]，并传回源链，不负责消息本身的传递；

· Relayer 则仅仅负责在链间传递 [update]，消息原文及默克尔路径的传递则是由 Prosessor 完成；

· Prosessor 是 Nomad 独有的一个链下**角色，为什么要单独增设这么一个角色呢？这是因为欺诈证明完成之前，Relayer 传递到目标链的 [update] 处于待定状态，此时传递消息 T 是没有意义的。Prosessor 要负责在欺诈证明完成后（争议窗口计时结束后），手动去触发目标链结束这种待定状态，此时再将消息 T 传递过去，让 Replica 合约用确定后的 [update] 来验证消息 T。对于常规的外部验证跨链桥，是没有这些过程的，传递到目标链的消息可以直接被处理，因此并不需要 Prosessor 这样一个角色。

· 无论是 Relayer 还是 Prosessor，都是完全无需信任、无需准入的角色，因此 Nomad 并不关心谁去完成它，实践中，它可能是应用程序项目方或者任何第三方。

· Nomad 对 Relayer 并没有任何信任假设，只有活性假设，这是因为 Relayer 无法伪造 Updater 的数字签名（Updater 的公钥已在目标链的 Replica 中注册），只能忠实的履行其职责，Relayer 能对系统造成**的伤害也仅仅是离线，使得跨链服务暂时不可用。正如前文所说，欺诈的来源只能来自于 Updater，不可能是 Relayer。

· 由于信任的基础是至少有一个诚实的 watcher，因此，在 Nomad 中，不需要 Updater 层面的去中心化。事实上，每个 Home 合约只需要对应一个 Updater，并不需要像外部验证方案那样，需要一个足够多元化的验证者集，这有助于降低开销。如果应用程序项目方联合了更加多元化的主体，更好的选择是让他们去做 Watcher。Nomad 没有系统级的 Watcher 集，需要应用程序自定义自己的 Watcher 集。

5.8.1.4 Nomad 的安全特性

我们来回顾下跨链互操作不可能三角：以下三者，最多只能得其二。

· 可扩展性（Extensible）：支持广义跨链计算

· 无需信任（Trustless）：不引入新的信任假设

· 普适性（Generalizable）：能够轻易适配更多区块链

Nomad 在以一个独特的方式破解跨链互操作不可能三角，Nomad 具有外部验证方案的两大优势：可扩展性（Extensible）和普适性（Generalizable），在此基础上，Nomad 使用欺诈证明机制，使得跨链桥的 Trustless 水平接近于原生验证（只需要有一个 Watcher 是诚实的，系统就是安全的）。我们发现，在 Nomad 中，跨链互操作不可能三角的三个条件被神奇的同时满足了！

当然，这不是没有代价的，代价是 30min 以上的延迟，这可能导致某些类型的应用不适合使用 Nomad 实现其跨链功能。

5.8.1.5 Nomad 的应用

Nomad 已经创建了自己的 Swap 桥，并将其与 Connext 集成在同一个界面中。用户可以使用该界面自由的进行跨链资产交换。如果用户要跨链的资金较小，Connext 可以实现更快的速度，如果用户要跨链的资金较大，Nomad 可以提供更低的费率，二者互为补充。我们可以预期，大多数用户都将使用「快速通道」——Connext，而为「快速通道」提供流动性的 LP 则通过「慢速通道」——Nomad 来调节不同链上的流动性。这与以太坊跨层项目中「原始通道」与「快速通道」的配合如出一辙。

资产发行者可以通过 Nomad，让自己的资产变成多链资产。例如，Covalent 将他们的网络质押通证 $CQT 从以太坊迁移到了 Moonbeam ；Hummingbot 将他们的治理通证 $ HBOT 从以太坊迁移到了 Avalanche。

应用开发者可以通过 Nomad 部署多链应用，Nomad 将其称为 xAPP（读作 Zap），xApp 可以调用 Home 合约和 Replica 合约，实现跨链消息的收发。Nomad 的开发者文档里提供了代码示例。

Nomad 与 Gnosis 合作开发了 Zodiac Nomad Module（ZNM），一个专注于跨链治理的通用模块。DAO 可以通过在 Nomad 支持的链上部署 ZNM，实现治理决议在多链同时执行。

截至 2022 年 9 月，Nomad 支持六个链：Ethereum、Moonbeam、Evmos、Milkomeda、Gnosis Chain 和 Avalanche，我们认为 Nomad 跨链桥的设计是有开创意义的。但不幸的是，由于合约代码的漏洞，Nomad 托管合约中的资金遭遇黑客洗劫，损失超过 1.9 亿美元，本文撰写时，Nomad 正在致力于回收损失资金，相关跨链桥功能处于停用状态，我们希望 Nomad 能早日渡过难关，重振旗鼓。

Optimistic Bridges：A New Paradigm for Crosschain Communication

Arjun BhuptaniNomad Docs

5.8.2 Celer IM

Celer 在 2022 年 3 月发表的一篇博客中，提到了一个新的混合框架 Celer IM，该框架将外部验证和乐观验证结合在一起，让应用程序可以自行选择合适的安全模型。我们来看看具体设计：

Celer IM 主要包含以下几个部分

· State Guardian Network（SGN）: 这是一个基于 Coos SDK 开发的 PoS 区块链，具有一组抵押 $CELR 的验证者，负责验证并签署跨链消息；

· Message Bus 合约：部署在接入链上的一组合约，负责管理跨链消息的收发；

· Executor：负责将被验证过的跨链消息中继到目标链。

消息流

1.用户通过应用程序将其需要发送的跨链消息提交给源链上的 Message Bus 合约；

2.SGN 中的验证者监听到消息并对消息进行共识签名；

3.Executor 将跨链消息中继到目标链上的 Message Bus 合约；

4.目标链上的 Message Bus 合约在确认消息签名有效之后默认立即推送给目标应用程序进行执行。

应用程序可以选择不立即处理收到的跨链消息，而是使用双重确认模式。这种模式下，消息被目标链上的 Message Bus 合约一次确认后，会被提交到一个「隔离区」，过了一定的窗口期，才能认为这条消息被二次确认，并推送给目标应用程序。

在窗口期，应用程序可以运行 App Guardian 服务来检查隔离区中消息的真实性，如果发现与源链发出的消息有不一致的情况，可以阻止消息被目标应用程序执行，并在源链报告欺诈行为。

不同于 Nomad，报告欺诈行为并不能自动触发 Slash，因为验证人没有在源链抵押。如果出现欺诈行为，如何对验证者进行惩罚和替换，Celer IM 文档中没有说明，笔者认为，应该需要治理流程的介入。

我们看到 Celer IM 提供了外部验证和乐观验证两种安全模型，前者的信任假设是 SGN 网络中诚实验证者掌握 2/3 以上的投票权，后者的信任假设则是至少有一个诚实的 App Guardian 服务在运行。

双模型的设计给应用程序开发者提供了灵活的选择。例如资产桥应用可以根据跨链的资产价值来触发不同的流程，执行不同的安全模型，这样小额资产跨链可以保持迅速，而大额资产跨链则可以被充分保障安全。

Celer IM 介绍文章

5.8.3 乐观验证小结

乐观验证作为一种全新范式，突破了跨链不可能三角，成为了跨链桥信任层构建的全新选择。乐观验证桥**的弊端是挑战窗口期的延迟，这会给用户体验带来不利的影响。但无论 Nomad 还是 Celer IM，都在尝试弥合这个问题：

· Nomad 与 Connext 合作，为用户提供一条快速通道；

· Celer IM 则将乐观验证与外部验证组合在一起，让应用程序可以根据跨链请求的不同，为用户提供一重验证和双重验证两个不同的选择；

我们看到，乐观验证**的应用场景，似乎是与其他验证方式组合在一起，把安全和效率的权衡，交给用户。这种组合式的信任层构建，或许是跨链桥未来的发展方向之一。

5.9 跨链桥的一般性

行文至此，我们是时候来总结一下跨链桥的一般性了。不同的跨链桥有不同的设计，但基本上有一个通用的结构，我们可以将其分为三层：

· 信任层

· 传输层

· 应用层

5.9.1 信任层

任何跨链桥，首先要解决的都是不同链间传输消息的信任问题。我们根据信任层构建方式的不同，对桥的类型进行了最基本的划分，本篇文章的行文结构也照此进行。

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

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

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

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

5.9.2 传输层

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

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

如何理解跨链消息

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

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

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

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

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

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

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

消息流

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

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

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

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

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

消息队列结构

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

Channel 

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

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

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

包含 Channel 概念的跨链桥有 Coos、XCMP、Nomad，但它们各自的设计又有所不同。在 Comsos 中，Channel 是建立在应用程序之间的（建立在链之间的 Channel 被称为 Connection）而且是双向的，两条链之间建立 Channel 意味着二者可以进行消息的双向传输。但在 XCMP 和 Nomad 中，Channel 是单向的，双向跨链传输需要成对的两个 Channel。在 XCMP 中，一个 Channel 对应一个出口消息队列 Egress ；但在 Nomad 中，多个 Channel 对应一个出口消息队列（Home 合约），这意味着 Nomad 的 Home 合约中管理的是从该链发出的所有消息，不区分目的地（目的地字段在消息正文中），这使得 Nomad 可以支持一对多的消息传输模式。

5.9.3 应用层

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

5.9.4 激励层

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

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

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

激励的方式可能是多种多样的，可以是将用户端的收费直接支付给激励对象，也可以是跨链桥项目方用自身金库或是通胀奖励来补贴激励对象，还有一种情况是，应用层为激励对象制定激励规则，或者应用层直接承担激励对象的职责。

5.9.5 总结

以上，我们通过跨链桥的分类、举例、分析，对跨链桥的构建方式有了更深的认识。这就是 PAKA 跨链研究报告系列的第三篇。我们将在不久后发布第四篇，也就是最终篇。在最终篇当中，我们将着重探讨一些应用层的实现，尤其是 Wrap 桥、Swap 桥以及其他类型的跨链 DeFi 应用，然后进一步讨论一些重要的跨链衍生命题。

他类型的跨链 DeFi 应用，然后进一步讨论一些重要的跨链衍生命题。