5.3 跨链的分类维度

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

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

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

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

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

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

· Burn-Mint（无托管）

更细致的分类见下图：

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

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

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

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

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

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

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

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

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

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

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

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-以太坊桥的验证人；

· 致力于桥接 Cosmos 生态与以太坊生态的 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 Flyclient 超轻节点

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

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

原因有两点：

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

2.Flyclient 的抽查算法比较复杂，对于本地 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 以太坊方向上的交易验证服务。

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 类公链轻客户端的典型范式。

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 版本 设计的以太坊轻客户端，可能在不久之后被重新设计。

5.5.5 Snowbridge（Snowfork）

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

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

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

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-[资产名]。

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 Smart Chain，被称为 Chain 是因为 Darwinia Smart Chain 拥有独立的状态机和浏览器，但它并不是一条独立的区块链。（参见 Aurora 与 Near 的关系）

相应的，Crab Chain 上也有一个 EVM 兼容环境，被称为 Crab Smart 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。

5.5.7 zkBridge

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

目前 zkBridge 已经以 Solidity 在以太坊上实现了一个 Cosmos Client 的实例，据测试，可以在 2 分钟内生成一个 Cosmos 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，更多的技术细节还有待披露，我们将保持关注。

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，将其验证之后发给目标应用