本文最早作为《 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 对跨链桥分类方法的基础上进行了拓展,我们将跨链的技术范式总结为五种,分别是原生验证、外部验证、共享验证、本地验证、乐观验证。我们认为,五分法比三分法,能更好的帮助我们理解跨链桥的技术实质。
如果您想了解五种技术范式下跨链桥的具体项目案例,请查看完整报告。