本文最早作为《 PAKA跨链研报 》的 5.3-5.4 章发布。

作者：MiddleX

与我交流：

• Twitter：@middlex0

• VX：xuezhijie156

---

随着 LayerZero、Axelar 等跨链桥项目的大额融资，跨链赛道再次热门起来。但几乎所有的跨链项目都明里暗里宣称自己是跨链的终极解决方案，并避重就轻的谈及自身的优势而不谈缺点。再加上跨链桥本身逻辑复杂、概念繁多，导致我们对跨链桥的理解难上加难、迷雾重重。

为了拨云见日，我们将从跨链桥的分类入手，总结出几种跨链桥的典型技术范式。我们认为尽管市面上有上百个跨链桥项目，但都在五种技术范式的框架内。

---

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

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

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

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

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

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

• Burn-Mint（无托管）

更细致的分类见下图：

对于跨链桥中的资产托管方案，这篇文章已经分析的比较彻底。

---

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

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

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

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

---

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

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

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

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

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

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

---

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

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

---

原生验证

原生验证指的是在目标链部署源链的轻客户端，对源链来的消息进行验证。如果要实现双向跨链，就需要在两条链上互相部署对方链的轻节点合约。

轻客户端，也称轻节点，在链上往往以智能合约的形式呈现。相比全节点，轻节点是轻量化的节点，它不存储完整区块的序列，而仅存储区块头的序列。尽管区块头体积很小，但它包含了对区块中完整数据的密码学概括。当轻节点需要知道某个交易是否被包含在链中时，可以通过该交易所在区块的区块头及该交易的 Merkle 路径，对该交易执行 SPV 验证。

为了维护目标链上部署的源链轻节点，需要由链下代理（一般被称为 Relayer）将源链的区块头不断同步到目标链。轻节点合约对负责同步区块头的链下代理并没有信任假设。因为轻节点合约会对其同步的区块头执行验证，链下代理无法欺骗轻节点。

轻节点验证区块头的逻辑，与全节点、矿工节点别无二致，分为有效性验证和最终性验证两部分。

对于 PoW 链来说，有效性验证主要是指验证区块的工作量证明，最终性验证则是看该区块后面有没有更多的有效区块被追加（在 BTC 链中，一般认为 6 个区块的追加可以确认一个区块的最终性，在以太坊中，则一般认为 25 个区块的追加可以确认一个区块的最终性）。

对于 PoS 链而言，有效性验证是指验证该区块是否由被随机选中的出块人生成，最终性验证则是看该区块是否被 2/3 以上投票权重的验证人签名。但 PoS 的轻节点并不需要验证有效性，只需要验证最终性。因为PoS链中，终结的区块一定有效，PoW 链则未必。

在原生验证跨链桥中，轻客户端的设计是重中之重。与链下运行的轻客户端不同。链上实现的轻客户端必须考虑到链上存储资源和计算资源的限制。

---

外部验证

外部验证指的是引入一组外部的见证人（Notary）来负责验证跨链消息，见证人内部可能有某种机制来达成共识。外部验证者会体现为许多形式：

• 基于 PoA 的 MPC 网络 （Multichain、Wormhle）

• 基于 PoS 的 MPC 网络（Axelar、Hyperlane）

• Oracle(LayerZero、CCIP)

• TEE网络（pNetwork、Bool Network)

本质上都是一回事。

由于外部验证桥实现成本较低，且可以比较轻松的进行多链适配，目前它是大多数的异构跨链桥项目采用的方案。

但我们意识到，跨链桥在引入外部验证人的同时，引入了新的安全假设，我们必须相信外部验证者是诚实的。如果：

• A 链的安全性是 x

• B 链的安全性是 y

• 外部验证者集的安全性是 z

那么在 A 链、B 链之间传递跨链消息的安全性 s = min (x、y、z)

大多数情况下，z 都是其薄弱环节，也就是说 s = z 。这是外部验证模式，最被诟病的缺点。

---

共享验证

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

其一，在由一些由公链项目方直接发起的跨链桥当中，有可能让链的验证者集，直接成为跨链桥的验证者集，在这种情况下，外部验证的安全性 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 似乎没有利用该结构来实现跨链消息传输。

这两种例外情形，形式上依旧属于外部验证，但其核心特征和适用场景已发生重大变化。更进一步，我们认为，应该将其命名为一种新的类型， 称之为「共享验证」。

---

本地验证

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

---

跨链互操作不可能三角

三种验证方式中，原生验证的信任假设最小，理论上只要源链和目标链不发生重组，跨链消息传递就是安全的，但由于轻客户端的不可重用性，原生验证的多链适配成本是最高的。

• 几乎每条链的轻节点方案都要单独设计，更要根据部署环境（也就是目标链的情况）进行优化。假如你要适配更多链，那就要付出更多的成本，每接入一条新链，就需要开发一对轻节点合约。不同链的轻客户端不能重用。

• 假如你在 A 链上实现了 B 链的轻节点合约，也只是实现了从 B→A 的单向消息传递，如果你要实现一座双向桥，你还需要在 B 链上实现 A 链的轻节点合约，这两项工作是完全独立的，不能重用。

• 如果轻节点合约所部署的链有重大的更新和变化，那么轻客户端也可能需要重新开发。例如以太坊在转型PoS后，所有支持以太坊的原生验证桥，都需要重新开发以太坊轻客户端。

因此我们看到，采用原生验证机制的跨链桥项目以专用跨链桥和同构跨链桥居多，异构通用桥很少采用。

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

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

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

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

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

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

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

---

乐观验证

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

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

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

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

相比外部验证，乐观验证在满足易适配特性的同时，其 Trustless 水平几乎与原生验证相当。代价是几十分钟的延迟。

---

正如100多年前，孙文先生将西方的三权分立的政治学理论，拓展为了五权宪法。本文中，我们在 Arjun Bhuptani 对跨链桥分类方法的基础上进行了拓展，我们将跨链的技术范式总结为五种，分别是原生验证、外部验证、共享验证、本地验证、乐观验证。我们认为，五分法比三分法，能更好的帮助我们理解跨链桥的技术实质。

如果您想了解五种技术范式下跨链桥的具体项目案例，请查看完整报告。