跨链桥的五种技术范式

本文最早作为《 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 对跨链桥分类方法的基础上进行了拓展,我们将跨链的技术范式总结为五种,分别是原生验证、外部验证、共享验证、本地验证、乐观验证。我们认为,五分法比三分法,能更好的帮助我们理解跨链桥的技术实质。

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

Subscribe to 0xmiddle
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.