互操作性的三难困境

为什么桥接以太坊的网域之间如此的困难 ?

Connext | 中文社区
10 min readDec 18, 2021

原文标题 : The Interoperability Trilemma ( AKA Why Bridging Ethereum Domains is So Damn Difficult )

原文作者 : Arjun Bhuptani

原文链接 :

几天前,我们发布了 NXTP,这是我们的协议,用于在兼容以太坊的域之间( 即链接不同区块练以及 L2 之间)实现完全無需信任的传输和合约调用。

这篇文章将试图解释为什么实现以太坊网域之间的互操作性很困难,并从中说明为什么我们认为 NXTP 代表了生态系统真正长期解决方案的开始。

对无需信任的以太坊互操作性的需求

多链/L2 以太坊就在这里,而且会一直存在。 随着项目争先恐后地为 DeFi 启用此功能,这促使创建了数十个新的桥和互操作性协议。

不出所料,这也带来了一些高调的黑客和骗局:

  1. Thorchain多个攻击事件
  2. PolyNetwork 被骇
  3. 纯粹的骗局

尽管有这些例子,但每个跨链系统都将自己标榜为无需信任安全和去中心(即使事实并非如此)。这意味着开发人员和用户现在面临的巨大挑战是,“我如何确定哪些桥接机制实际上在加密经济上是安全的?”

换句话说,用户如何区分不同类型的桥,以确定在链之间转移资金时他们該信任谁?

“无需信任 ( Trustless )”在密码经济学中究竟意味着什么?

在研究界,当我们谈论加密经济安全和无需信任的属性时,我们实际上是在问一个非常具体的问题:

谁在验证系统,破坏它们需要多少成本?

如果我们的目标是建立真正去中心化、抗审查的公共产品,那么我们必须考虑到我们的系统可能会受到非常强大的对手的攻击,例如流氓主权国家、大型企业或自大狂的邪恶天才。

如果您的威胁模型不包括贝索斯 (亚马逊创始人),最终转向邪恶一方的假设,那么您不会成功

最大化安全性意味着使系统中验证者(验证者、矿工等)的数量和多样性最大化,这通常意味着需要尽最大努力拥有一个完全由以太坊验证者集验证的系统。 这是 L2 和以太坊可扩展性方法背后的核心思想。

旁白:大多数人没有意识到这一点,但可扩展性研究就是互操作性研究。 我们已经知道我们可以通过移动到多个网域来扩展多年,问题一直是如何实现与这些网域的无需信任的通信。 这就是为什么 John Adler 关于 optimistic rollups的开创性论文的标题是“Trustless Two-Way Bridges With Sidechains By Halting”。

如果我们在网域 ( Domains )之间添加新的验证器会发生什么?

让我们将上面学到的关于加密经济安全的知识应用到桥中。

考虑一个您在 Arbitrum 上拥有资金的场景。 你特别选择使用这个网域,因为它是一个 rollup,这意味着(在一些合理的假设下)你的资金由以太坊的底层验证者完全保护。 换句话说,您的资金在加密经济上与区块链生态系统中可能一样安全。

现在想象一下,您决定使用桥将您的资金便宜且快速地转移到 Optimism, Optimism 也是无需信任的,因此您可以放心将资金放在那里,因为您知道它们将与 Arbitrum 共享相同级别的安全性(以太坊的安全性)。

但是,您使用的跨鏈协议使用它自己的一组外部验证器。虽然这最初看起来没什么大不了的,但你的资金现在不再由以太坊担保,而是由桥的验证者担保

  1. 如果这是一个锁定/鑄币的桥,创建封裝 ( Wrapped )资产,那么桥的验证者现在可以单方面串通来窃取您的所有资金。
  2. 如果这是一个使用流动性池的桥梁,桥的验证者可以类似地串通从流动性提供者中窃取所有的池资金。

尽管我们都为安全和无需信任的 L2 等待了数年,但您现在的情况可能与使用可信任侧链或 L1 架构时的情况相同。😱

关键要点是,加密经济系统的安全性取决于其最薄弱的环节。当您使用不安全的桥接时,您的链或 L2 的安全性不再重要。而且,类似于 L1 和 L2 的安全性,这一切都完全归结为一个问题:谁在验证系统?

互操作性协议分类

我们可以根据验证者将所有互操作性协议分解为三种总体类型:

原生验证 ( Natively Verified )

原生验证协议是指链之间传递的数据的协议都由所有底层链验证者自身完成验证。通常,这是通过在另一条链的虚拟机 ( VM )中运行一条链的轻客户端来完成的,反之亦然。

示例包括 Cosmos IBC 和 Near RainbowBridge。rollup 入口/出口也是这种特殊形式!

好处:

  • 是最无需信任的互操作性形式,因为底层验证者直接负责桥接。
  • 启用网域之间完全通用的消息传递。

缺点:

  • 依赖网域的底层信任和/或共识机制来运行,因此必须为每种类型的网域个别定制构建

以太坊生态系统是高度异构的:我们拥有从 zk/optimistic 到侧链到运行各种共识算法的基础链的所有网域:ETH-PoW、Nakamoto-PoW、Tendermint-PoS、Snowball-PoS、PoA,和许多其他人。这些域中的每一个都需要一个独特的策略来实现一个本机验证的互操作性系统。

外部验证 ( Externally Verified )

外部验证协议是使用一组外部验证器在链之间中继数据的协议。这通常表示为 安全多方计算( MPC ) 系统、预言机( Oracle )网络或门限多重签名( threshold multisig ),所有这些实际上是同一件事。

示例包括 Thorchain、Anyswap、Biconomy、Synapse、PolyNetwork、EvoDeFi 等等。

好处:

  • 允许在不同网域之间进行完全通用的消息传递。
  • 可以轻松扩展到以太坊生态系统中的任何网域。

缺点:

  • 用户和/或流动性提供者完全信任外部验证者的资金/数据。这意味着该模型在加密经济方面的安全性从根本上就低于底层网域的水准(类似于我们上面的 Arbitrum to Optimism 示例)。

在某些情况下,项目会使用额外的 staking 或绑定机制来尝试为用户增加安全性。然而,这通常没有很大的经济意义。为了使系统无需信任,用户必须抵押可以最高补偿风险发生时的资产,而且该抵押 必须 由验证者自己提供。这不仅显着增加了系统所需的资本,而且首先违背了拥有铸造资产或流动性池的全部初衷。

本地验证 ( Locally Verified )

本地验证协议是指只有参与特定跨网域交互的各方才会验证该交互协议。本地验证协议将复杂的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 是一个经过本地验证 ( locally verified )的系统,专门设计为与底层网域一样安全,同时仍可在任何网域上使用

那么通用性呢?与以太坊生态系统中的可扩展性类似,我们可以通过在NXTP之上插入本地验证的协议(作为我们互操作网络的“第 2 层”!)来增加通用性。这样,用户和开发人员可以在任何网域中获得一致的界面,并且可以“升级”他们的连接以在该功能可用的情况下实现通用性。

这就是为什么我们说 NXTP 是我们互操作性网络的基础协议 ( base protocol )。整个网络将由一系列协议组成,其中包括 NXTP、特定于一对域的通用跨链桥以及将它们连接到一个无缝系统的协议。🌐

非常感谢 James Prestwich、Eli Krenzke、Dmitriy Berenzon 以及更广泛的 L2 研究社区在过去几年中对本文中的想法做出贡献的许多对话,以及校正我愚蠢的错别字。😄

想参与?

关于 Connext

Connext 是以太坊与 Layer2 之间的互操作性协议。

Website | Documentation | Twitter | Discord | Github | Blog

--

--