不同的跨链、跨 L2 桥底层逻辑究竟是什么?优劣各有哪些?
撰文:
Arjun Bhuptani
,
Connext
联合创始人
编译:Perry Wang
几天前,Connext 推出了 NXTP ,这个底层协议,用于在兼容 以太坊 的域之间实现完全无需信任的传输和合约调用 ,即链接不同区块链及第二层 /L2 项目。
我希望通过这篇文章,解释一下为什么以太坊生态系统中实现互操作性非常困难,并说明为什么我们认为:NXTP 代表了生态系统真正长期解决方案的开端。
对无需信任的互操作性的需求
多链 /L2 以太坊已经成为事实,并且将继续存在。协议和应用都已将发展战略改为向多个域迁移,用户现在不得不应对每天在各层之间进行移动、或移动到其他 L1 系统 / 侧链的难题。各家项目争先恐后地为 DeFi 启用这一迁移功能,催生出数十个新的「桥」和互操作性协议。
不出所料,这也带来了一些引人注目的黑客攻击和骗局:
•
跨链交易协议
THORChain
被攻击
;
•
PolyNetwork 被黑
;
•
纯粹的骗局
。
尽管有这些例子,但每个「桥」系统都将自己标榜为无需信任、安全和去中心化——即使事实并非如此。这意味着开发者和用户现在面临的巨大挑战是:「我如何确定哪些桥机制在加密经济上是真正安全的」?
换句话说,在链之间转移资金时,用户如何区分「桥」类型,以确定该信任谁?
「无需信任」在密码经济学中究竟意味着什么?
在研究界,当我们谈论加密经济的安全和无需信任属性时,我们实际上是在问一个非常具体的问题: 谁在验证系统,破坏它们的成本是多少?
如果我们的目标是建立真正去中心化、不可审查的公共产品,我们必须考虑到:我们的系统可能会受到非常强大的对手的攻击,例如:主权国家、大型企业或自大狂型的邪恶天才。
如果您的威胁模型不包括(亚马逊创始人)贝索斯最终转向邪恶一方的假设,那么您不会成功。
安全性最大化意味着要对系统中验证器(验证者、矿工等)的数量和多样性实现最大化,这通常意味着尽最大努力拥有一个完全由以太坊验证者集进行验证的系统——这是 L2 和以太坊扩展性方案背后的核心思想。
旁白:大多数人没有意识到这一点,但扩展性研究是互操作性研究。多年来我们一直很清楚,可以通过移动到多个域来扩展,问题一直是:如何实现这些域之间的无需信任通信。这就是为什么 John Adler 关于 optimistic rollups 的 开创性论文 的标题是「Trustless Two-Way Bridges With Sidechains By Halting」。
如果我们在域之间添加新的验证器会发生什么?
我们将上面学到的关于加密经济安全的知识应用到「桥」中。
考虑一个场景:假设您在 Arbitrum 上拥有资金,您特别选择使用这个域,因为它是一个 rollup,这意味着(在一些合理的假设下)您的资金完全由以太坊的底层验证者保护。换句话说,您的资金在加密经济上与区块链生态系统中可能一样安全。
现在想象一下,您决定使用「桥」,将您的资金廉价且快速地转移到 Optimism 。Optimism 也是无需信任的,因此您可以放心将资金放在那里,因为您知道它们将共享与 Arbitrum 相同级别的安全性(以太坊的安全性)。
但是,您使用的「桥」协议使用它自己的一组外部验证器。虽然这最初看起来没什么大不了的,但您的资金现在不再由以太坊保障安全,而是由「桥」的验证器保障安全:
• 如果这是一个资产锁定 / 铸币「桥」,创建打包资产,意味着「桥」验证器现在可以单方面串通来窃取您的所有资金;
• 如果这是一个使用流动性池的「桥」,「桥」验证器可以以类似手段串通从流动性提供者(LP)窃取所有的池资金。
尽管大家已经为安全、无需信任的 L2 等待了数年,但您现在的情况与使用可信侧链或可信 L1 架构时的情况相同。
关键要点是,加密经济系统的安全性取决于其最薄弱的环节,当你使用了不安全的「桥」,您的链或 L2 的安全性都也都没有了意义。而且,类似于 L1 和 L2 的安全性,这一切都完全归结为一个问题:由谁验证系统?
互操作性协议分类
我们可以根据验证者类型,将所有互操作性协议分为三种类型:
第一种类型:原生验证
原生验证协议是:对于链之间传递的数据,完全由底层链自己的验证者验证的协议。通常是通过在另一条链的以太坊虚拟机(VM)中运行一条链的轻客户端来完成的,反之亦然。
实例包括 Cosmos IBC 和 NEAR RainbowBridge。Rollup 入口 / 出口也是其中的特殊形式!
优势:
• 无需信任程度最高的互操作性形式,因为底层验证者直接负责「桥」的安全;
• 实现域之间完全通用的消息传递。
劣势:
• 依赖域的底层信任和 / 或共识机制来运行,因此必须针对每种类型的域进行定制构建。
以太坊生态系统是高度异构的:我们拥有众多域,从 zk/optimistic rollups 到侧链,再到运行各种共识算法的基础链:ETH-PoW、Nakamoto-PoW、Tendermint-PoS、Snowball-PoS、PoA,还有很多很多共识机制。这些域中的每一个都需要一个独特的策略,来实现一个原生验证的互操作性系统。
第二种类型:外部验证
外部验证协议是使用一组外部验证器在链之间中继数据的协议。这通常表现为 安全多方计算 (MPC)系统、预言机网络,或门限签名(所有这些实际上是同一件事)。
实例包括 THORChain、 Anyswap 、 Biconomy 、Synapse、PolyNetwork、EvoDeFi,以及其它很多很多项目。
优势:
• 允许在域之间进行完全通用的消息传递;
• 可以轻松扩展到以太坊生态系统中的任何域。
劣势:
• 用户和 / 或 LP 完全信任外部验证器的资金 / 数据。这意味着该模型在加密经济方面的安全性上,基本上低于底层域的水准(类似于上面提到的 Arbitrum 与 Optimism 之间的比较)。
在某些情况下,项目会使用额外的质押(staking)或 bonding 机制,来尝试为用户增加安全性。不过这通常在经济上效率低下。为了使系统无需信任,用户必须以抵押资产覆盖可能的最高额损失,而且这些抵押资产必须由验证者自己提供。这不仅显著增加了系统所需的资本,而且首先违背了铸造资产或流动性池的全部初衷。
第三种类型:本地验证
本地验证协议是只有参与特定跨域交互的各方验证交互信息的协议。 本地验证协议将复杂的 n 方验证问题转变为一组简单得多的二方交互,其中每一方仅验证其交易对手。只要双方在经济利益上是对抗的,这种模式就有效——也就是说,双方无法通过串通而从整个链中获取资金。
实例包括 Connext、Hop、 Celer 以及其它简单的原子交换系统。
优势:
• 本地验证的系统是无需信任的——它们的安全性由底层链提供支持,因为 rollups 共享了一些合理的保证(例如,该链的审查时间不能超过 X 天);
• 它们也很容易向其他域扩展。
注意:并非每个本地验证的系统都是无需信任的。有些项目采取一定程度上牺牲无需信任的取舍,来改善用户体验或添加额外的功能。
例如,Hop 通过在系统中需要一个快速的 arbitrary-messaging-bridge (AMB) 来添加一些信任假设:该协议在 1 天内解锁 Bonder 的流动性,而不是在退出 rollup 时等待整整 7 天。 如果给定域不存在 AMB,该协议还需要依赖外部验证的「桥」。
劣势:
本地验证的系统不能支持链之间的广义数据传递(generalized data passing)。
上面的意思有点微妙,可能归结为许可:本地验证的系统可以实现跨域合约调用,但前提是被调用的函数具有某种形式的逻辑上的所有者。例如,可以跨链无需信任地调用 Uniswap 代币互换函数,因为任何拥有可交换代币的人都可以调用该函数。然而这一方式无法跨链无需信任地锁定和铸造 NFT——这是因为目标链上铸造(mint)函数的逻辑所有者应该是源链上的锁定(lock)合约,而在本地验证系统中这无法得到体现。
互操作性困局
现在我们进入本文的主题,以及应该推动用户和开发者围绕「桥」的选择做出决策的心理模型。
与
扩容性不可能三角
类似,在以太坊生态系统中也存在一个互操作性不可能三角。互操作协议只能拥有以下三种特性中的两种:
• 无需信任: 拥有与底层域相同的安全性;
• 可扩展性: 任何域都可以支持;
• 信息通用性 : 能够处理任意的跨域数据。
Connext 和 NXTP 如何契合这一点?
我们无法找到简单的方法,来获得所有三个互操作性属性的理想结果。不过我们已经意识到,可以采用与以太坊解决扩容性不可能三角问题相同的方法,来解决互操作性不可能三角问题。
以太坊 L1 以可扩容性为代价,优化了安全性和去中心化。这背后的基本原理是,这些属性可能对区块链的寿命和实用性最重要。不过,以太坊通过 L2/ 分片,作为现有安全和去中心化主干之上的一层,来增强扩容性。
在 Connext,我们坚信在以太坊生态系统中,具有最长寿命、最强实用性和可采用性的互操作性系统,将是一个最大限度地无需信任和可扩展的系统。出于这个原因,NXTP 被设计成一个本地验证的系统,专门设计为与底层域一样安全,同时可在任何域上使用。
那么信息的通用性呢?与以太坊生态系统中的扩容性解决方案类似,我们通过在 NXTP 之上插入原生验证的协议(作为我们互操作网络的 L2!)来增加信息的通用性。这样,用户和开发者就可以在任何域中获得一致的交互界面,并且可以「升级」他们的连接,以便在该功能可用的情况下实现信息的通用化。
这就是为什么我们说 NXTP 是我们互操作性网络的底层协议。我们的整个网络将由一系列协议组成,其中包括 NXTP、特定于一对域的通用跨链桥,以及将它们连接到一个无缝系统中的协议。
非常感谢与 James Prestwich、Eli Krenzke、Dmitriy Berenzon 以及更广泛的 L2 研究社区在过去几年中的对话,帮助催生了本文中的很多想法,并校对了我愚蠢的错别字。