跨链桥怎么了？谈跨链桥的风险、现在及未来

• 原文：https://antiape.substack.com/p/whats-wrong-with-bridges-and-whats
• 译文出自：登链翻译计划
• 译者：翻译小组
• 校对：Tiny 熊
• 本文永久链接：learnblockchain.cn/article…

本文从成本、安全和效率三个方面比较了所有主流的跨链桥设计：

• 具有讽刺意味的是，中心化交易所（CEX） 仍然是跨链的最佳选择。
• 资产桥（Asset bridge） 有非原生包裹（non-native wrapping）的致命缺陷。
• 基于Omnichain（全链）的DEX 涉及中间链的流动性锁定，这意味着更多的攻击可能和对节点及流动性提供者更高的补偿费用。

超越资产转移，走向更通用的跨链通信有：

• IBC 是一个通用的协议，没有外部信任假设。IBC是安全和高效的。唯一的缺点是部署成本高。
• Layer Zero 是IBC的一个变种，在Chainlink的帮助下，将部署成本转向按使用付费的可变成本。Layer Zero对不经常使用的情况进行了优化，但在高频通信中的可扩展性较差。

鉴于这种痛苦的权衡，我们相信设计迭代必然会继续。在第四节，会讨论三个想法：

• CLOBs：使跨链流动性池的资本效率更高
• zk-SNARKs：减轻链上验证的成本
• 链上的SDK集成： 消除对中心化外部 中继者的依赖

文章中提到的项目有： 以太坊 2.0, Cosmos, IBC, Layer Zero, Solana, Serum, Optimistic Roll-ups, StarkNet , [Terra] (https://www.terra. money/), THORChain, Osmosis, Anyswap, Wormhole, Ronin Bridge, Terra Bridge, Avalanche Bridge, [Ren Bridge, ] (https://bridge.renproject.io/welcome) [Axie Infinity] (https://axieinfinity.com/)

第一节：跨链通信的现状

在本节中，将介绍：

• 多链的现实将继续存在
• 跨链基础设施的价值和使用情况
• 跨链和L1战争之间的爱恨情仇
• 跨链协议的价值获取：为什么它是（而且应该是）瘦协议

跨链设计

在中短期内，我们将有更多的链上，而不是更少：

• 技术在不断迭代：当下没有最终成熟的可扩展性技术解决方案。可扩展性的设计选择迭代必然会继续。
• 资本在抢夺土地：在顶级生态系统背后投入大量资金意味着土地掠夺不会很快结束。
• 协议想要发行L1代币：实际上，发行第一层代币的诱人利益空间意味着成功的应用层协议有动力推出应用场景链（例如：Axie Infinity 和 Ronin）。

跨链互操作性是一个重要设计领域：

• 货币的互操作性：对于用户来说，没有连接的钱只是商店的积分。创造互操作性可以增加资产价值。

• 数据的互操作性：脸书和谷歌已经成为世界上最有价值的企业，因为他们在其他未连接的数据中获取了价值。类似的数据现在被浪费在孤立的区块链数据库中。

  互操作性使用场景：认证、信用评分、元宇宙身份、协议奖励用户在另一条链上的行为。

对于那些对L1战争感兴趣的人来说，跨链通信与区块链可扩展性也有很深的联系：

• 竞争性：如果跨链通信变得足够顺畅，它可能会将L1抽象化。毕竟，只要它能让我们与朋友无界限地交流，谁会在乎Facebook服务器的标准呢？在边际上，一个更顺畅的跨链体验可能会有利于较小的后起之秀与成熟的生态系统竞争。
• 协同性(Synbiotic)：就像联合国和SWIFT不能脱离主权国家一样，跨链协议设计及标准很大程度上取决于L1的设计选择。鉴于L1设计范式的多样（高TPS、Sharding、Rollups、Sidechain、App chains......），跨链空间的最关键参数仍未确定。现在说什么都还为时过早。

投资案例

一个有价值的跨链协议应该是一个非提取式的（non-extractive）、无状态的、几乎无需防御的瘦协议。就像互联网的IP层。在我们看来，一些常见的建立协议护城河的方式是次优的，或者对跨链价值效用破坏。

• 锁定流动性 → 碎片化、摩擦和成本
• 统一流动资金池 → 巨大的攻击面和资本效率低下
• 包裹用户资产 → 系统性金融风险
• 信任链外中继者 → 提防跑路、垄断和审查

直接影响：跨链基础设施的主要投资驱动力可能是生态系统基金和风险投资的既得利益。每个链可以将跨链作为一种基本功能。在这种情况下，可信的中立性成为一种罕见的美德 -- 这是一个单独的话题，我们将不在此展开讨论。

因此，我们对跨链的结构重要性的讨论并不一定意味着它们的代币有相应的投资价值。

第二节：资产跨链 - 可信赖的中介机构

在本节中，将介绍：

• 中心化交易所
• 资产桥
• Omnichain DEX

代币是最突出的Web 3 原语之一。它们构成了大多数跨链使用场景。

历史上的比喻：人们发现银行可以帮助促进两个原本孤立的主权国家之间进行价值转移。

中心化交易所（CEX）

它就像一个在许多国家拥有货币储备的商业银行。如果人们能够访问CEX，他仍能以简单、直观的方式很好地服务于顶级使用场景。

优点:

• 简单的使用体验(UI/UX)
• 最小的成本 -- 大多数交易所仅对简单的转账收取Gas费用 -- 没有复杂的链上计算。

不足：

• 需要KYC和交税（部分） -- 许多人无法使用

• 获准上架 -- 大多数时候，人们只能转让CEX上架的代币。

• 对手方风险：我们不是在信任智能合约，而是相信币安的IT及其诚信 -- 尽管只是暂时的。币安暂停dogecoin提款

• 没有智能合约的可合成性。

资产桥

资产桥的资产就像旅行者的支票（如果有人老到知道那是什么的话），是一种在Web 3中包裹资产（wrap）的信用工具。

项目案例：Wormhole, Ronin Bridge, Terra Bridge, Avalanche Bridge, Ren Bridge

它是如何工作的？

• 资产桥在两条链上部署智能合约，锁定原生资产，并在信用链上发行自定义包裹的资产。

  例如，在以太坊上锁定100ETH-->在Solana上铸造100 wormhole-wETH

• 理论上说，这些被包裹的资产是由另一条链上的锁定资产1:1支持的。

• 这种跨链桥有白名单的链外验证者。在Wormhole（虫洞）的案例中，在 守护者网络中有19个验证者，其中大部分是顶级的Solana验证者，验证者会观察A链上的原始资产锁定情况。

优点:

• 比CEX低的进入门槛 -- 无KYC
• 具有智能合约的可组合性
• 因为有包裹，所以不需要外部流动性锁定
• 由于大多数计算是在链外进行的，因此几乎没有额外的Gas。

不足：

1. 依赖对联合验证者的信任假设，容易受到攻击或跑路。

• 2022年2月，ETH-SOL虫洞桥被黑，被黑价值3.25亿美元以上
• 2022年3月，ETH-RON桥被黑，被黑价值6亿多美元

1. 与链下的联合验证器的交互引入了额外的网络层和智能合约漏洞。
2. 包裹资产流动性的碎片化（wETH/ETH/xyzETH是不同的代币），特别是如果多个跨链桥要竞争。包裹资产在去中心化（许多桥）和流动性效率之间产生了不理想的权衡。
3. 被包裹的资产（如SOL上的wETH），依赖协议信用发行，永远暴露在黑客和脱钩风险之下，限制了被包裹资产的信心和使用情况，增加了系统性金融风险。
4. 资产清单仍然由资产桥协议许可。

Omnichain（全链） DEX

我们可以将商业银行去中心化吗？

是的，有专门做 DEX 链的实现。

案例项目：THORChain, Osmosis, Anyswap

它是如何工作的？

• Omnichain DEX 引入了流动性提供者，以实现多条链上的本地流动性。

• Omnichain DEX引入了专属代币（$RUNE，$OSMO，......）来连接流动性：协议将所有资产兑换两次（ETH-RUNE-SOL）以促进长尾资产的交换。

• 通常情况下，Omnichain DEX 会推出一个特殊用途的链，用于DEX计算（虽然不是必须的）。

优点：

• 比中心化交易所更低的准入门槛——不需要KYC

• 具有智能合约的可组合性。

• 统一的流动性：所有链都使用相同的XXX-RUNE流动性资金池。

  即，BNB/ETH/LUNA - SOL都从同一个RUNE-SOL池的流动性。

• 全部是原生资产：一旦交换完成，就不用再信任DEX的正直的假设。从本质上讲，DEX将脱钩风险转移给流动性提供者，而不是用户。

• 开放的资产列表：任何人都可以向DEX添加流动性，以允许新的资产对。

不足：

• 没有即时的最终性（fanality）：由于有可能从多个链上同时调用同一个RUNE-XXX流动性池，所以在提交时不能保证交易能以特定的价格通过。这就引入回退/退款的额外摩擦。Stargate声称已经解决了这个问题。

• 中间的专用链是一个潜在单点故障。

• 多层的费用和滑点：THOR和OSMO发行本地代币作为交易的一方（也就是说，所有的交易对都是THOR/XXX）。原生代币通常是维持运营专用链的经济激励所必需的。

• XXX-THORChain的桥梁和中继者仍然是中心化的。

总结一下：各方案的比较

我们不喜欢资产桥，被包裹的资产不是原生链主权资产，它们是协议的非流动性欠条，容易受到攻击。

对于那些有能访问的人（满足 KYC，税收，以及希望转移的资产），中心化交易所仍然是最简单和最便宜的选择，只有短暂的对手方风险。

在CEX之外，人们只能使用Omnichain DEX，它们具有原生资产和统一的流动性。用户将不得不为多层协议成本买单：流动性成本、中间链验证成本或中继者喂价成本、交易滑点等等。

第三节：通用的跨链 - 信任但验证

在本节中，将介绍：

• IBC是第一个通用的跨链通信协议。最大的创新是：通过维护链上的轻型客户，它可以原生地验证对手链上的交易。
• Layer Zero 试图缓解IBC的最大问题：链上验证的高Gas。Layer Zero 进入了Chainlink，在信任、固定成本和可变成本方面做出了一系列不同的设计选择。

跨链通信的下一个阶段涉及到通用跨链通信。不难看出为什么通用通信在结构上是有价值的：

• 随着Web 3 原语的成熟，比可替代的代币转账更多的使用场景需要使用跨链通信，如NFT、游戏、治理、认证、原生多链dApps。
• 作为一个基础设施/API层，让更多的终端用户应用基于omnichain DEX 设计上建立和迭代。

退一步说：系统间通信的高层设计

跨链通信的难题有三个部分：

一些更多的细节和讨论，如果不懂技术，可以略过:

• 监控和通知：系统必须收到信号后才能开始处理通信请求。

  在Web 2中，一个典型的实现是“ 监听器代码”，服务器不断地（每毫秒循环一次）检查其门户网站的网络请求。这种范式对于Web 3来说是不可能的，因为让区块链循环高频计算的成本太高。

  在Web 3中，自我运行的智能合约需要被通知有事情发生。目前的解决方案依赖于需要验证两条链的节点--“中继者”。我们将在下一节讨论它们的作用。

• 数据：关于交易的详细数据（称为 “有效载荷（payload）”）必须在系统之间进行交流。

  在Web 2，这个问题是微不足道的。谷歌可以通过物理互联网基础设施向Facebook发送任何东西。

  在web 3，人们关注的是节约计算。幸运的是，由于一些聪明的以太坊设计，我们不必发送整个区块：要描述一个交易并证明它发生在一个以太坊区块上，只需要发送尺寸小于一个以太坊区块0.1%的数据。(见：Patricia-tree）在IBC和Layer Zero中，中继者负责转发数据。

• 验证：接收方需要确信数据是由正确的发起人的授权的转账

  在Web 2中，这个问题同样简单明了。Facebook使用既定的协议（如HTTPS）来验证谷歌的服务器签名和解密签名的信息。

  在Web 3中，仅仅知道一个交易和它的区块XYZ（数据）是不够的，但接收的智能合约需要知道区块XYZ包含在源链上。确认是很难的，因为即使在一个区块被验证和签署之后，也会发生区块重组。如何做到这一点是IBC和Layer Zero的主要区别。

  IBC：中继者 + 轻型客户端

  IBC 使用了中继者和链上轻客户端来承接以上三个要素：

  工作流程：

  • 监控和激活+交易数据 -- 中继者：如前所述，中继者是一组可以在同一台物理机器上验证两个链的节点。中继者使用廉价的云计算能力来扫描A链的网络请求。如果它发现了A-->B的交互请求，就会向B链提交交易。
  • 验证 -- 轻型客户端：IBC还需要部署一个链上轻客户端（见定义）。B链上的智能合约可以独立验证链上交易是否在源链上被正确执行，这是IBC认可交易前的最后一步。

  （定义）链上轻客户端: 链上轻客户端是部署在A链上的程序，观察并记录B链的最新区块头（即最长的链）。

  关键设计选择讨论：

  • IBC的运行依赖于链外的中继者，他们在A链和B链上运行轻客户端。IBC中继者软件是开源的，没有权限，所以任何人都可以加入。他们不需要信任安全，因为链上智能合约将验证所有交易。中继者的冗余只是为了服务的可用性。

  • 链上验证在像ETH这样的高Gas链上可能成本很高，因为ETH上的IBC合约需要不断从其他链上保存新的区块头以维持实时验证。

  ......[轻客户端的成本]: 根据Layer Zero的说法，在以太坊上每条成对的链每天要花费数千万美元。

  

  • Cosmos通过自定义链的设计解决了IBC的Gas问题：让IBC成为链级模块。Cosmos要求验证者在链级而不是智能合约级维护Cosmos Hub轻客户端。--计算成本隐含地由验证者承担，而不是由特定的智能合约账户承担。

  LayerZero： 中继者 + 预言机

  LayerZero与IBC相比有两个主要区别：

  • 部署的形式： Layer Zero是IBC的智能合约实现（所以它可以在EVM和Solana等链上原生工作）

  注：IBC从2022年3月起只在Cosmos链上上线。

  • 取代了昂贵的轻客户端：它不需要每个链上的智能合约来同步所有其他连接的链的块头，而是将交易执行检查外包给Chainlink。

  工作流程：

  • 监控和激活+交易数据 -- 中继者：与IBC相同。
  • 验证 -- 预言机：LayerZero使用Chainlink的去中心化Oracle网络来检查区块承诺。例如，Layer Zero智能合约会询问Chainlink。

  具有merkle root 0xbbcc的Terra区块129634是否在你的完整Terra账本版本中，并且至少有X个子块

  同时，数据部分则表示：

  这是一个地址为0x1927的Terra交易，向智能合约地址0x7878发送10LUNA。这笔交易包含在merkle根0xbbcc的区块中，这里是区块包含的merkle路径证明。

  把两块放在一起，我们将同时拥有 数据和 验证来证明一笔交易在另一条链上发生。

  设计选择讨论：

  • 与完全在链上的轻客户端相比，使用Chainlink牺牲了一些安全性和运行时间的延迟。

  • 引入了额外的协议依赖性和智能合约风险

  • 调用Chainlink的合约而不是检查链上数据会引入额外的延迟和Gas成本

    

  • 这是一个固定成本与可变成本的权衡

  • 轻型客户机在一些高Gas链上有很高的固定成本（需要更新以保持有效性，无论使用情况如何），但每次使用的可变成本很少或没有。

  • 预言机网络的每次使用成本略有增加， 因为预言机网络变得拥挤些。

  鉴于差异化的优化，我们期望IBC和LayerZero能共存。

  IBC适用于以下使用情况：

  • 原生环境和经济性优化较好的环境：Cosmos生态系统内的链
  • 低GAS链：BSC, Solana,...
  • 高频通信（以充分稀释固定成本）：也许是Polygon-以太坊跨链通道，或成对的链。

  相反，Layer Zero可以很好地连接高Gas链（ETH）和低频率链。

第四节：展望未来

本节中，将介绍：

• 二层网络和分片链的复杂性将使跨链通信问题更加复杂
• 我们对未来发展的猜测：
  • CLOBs - 中心化限价订单簿 - 以提高资本效率
  • 使用zk-SNARKs优化链上验证。
  • 出现链级SDK，实现完全去中心化

前面还有更多的复杂问题

这里我们只讨论了简单主权一层网络之间的链间通信。对于更复杂的区块链设计的互操作性解决方案，设计空间仍然是开放的。这里有一些例子：

二层Rollup：由于二层的结算是在以太坊上，以太坊1层可能需要参与证明最终性。

• 乐观（Optimistic） Rollup：OR的致命缺陷，即欺诈检测的漫长的7天锁定期，将可能加剧一方与OR的互操作性的难度。

分片区块链：截至2022年3月，以太坊基金会还没有对ETH2的设计选择下定决心。我们正在关注两件事。

• 以太坊基金会何时发布分片设计选择：数据分片， 执行分片，ZK-SNARK ...，以及它们可能给其他L1链与ETH2交互的影响。
• ETH2分片之间的内部通信协议，如果设计成相互之间的通信。

我们心中的一些猜测

中心化限价订单簿（CLOBs）

CLOB CEX可以作为 AMM DEX提供了一个更开放但昂贵的替代方案，如今omnichain DEX最重要的痛点是资金效率低。

也许omnichain DEX可以借鉴Serum提供中心化限价订单簿的做法，在费用、最终性和延迟方面提供不同的设计选择。另外，如果Serum的发展速度足够快，它本身也可以有一个尝试。

ZK-SNARKs

零知识Rollup的设计问题与我们的非常相似：

如何最终证明某件事在另一条链上发生过？

虽然没有时间在这里深入研究ZK数学，但我们会很高兴看到ZK和跨链通信之间的结合带来以下一些或全部特新:

• 在目的链上进行O(log n)简洁的计算来进行验证

• 进一步优化IBC轻客户端成本和链上数据成本

  链上SDK标准化，实现完全去中心化。

  目前所有的跨链解决方案都涉及到中继者。正如我们所讨论的，跨链效用的经济性差意味着中继者几乎都是生态系统的重量级参与者。他们有共同的利益，必要时可以串通一气--在极端情况下构成了中心化的巨大风险。

  那么，一个完全去中心化的跨链桥在技术上是可以实现的吗？我们认为是的：

通过部署链上轻客户端，绿色的两个元素已经可以去中心化了：

轻客户端协议的目的是让低容量环境中的用户（嵌入式智能设备、智能手机、浏览器插件、一些台式机等）对以太坊状态的某些特定部分的当前状态（或验证交易的执行）有高安全性保证。

light-client-protocol

去中心化的最后一步：监控和通知

天真的解决方案：一个天真的解决方案将要求B链扫描A链的整个区块，以发现是否有任何要求跨链通信的交易。如果想象以太坊扫描Solana，方案是不可能的，很天真。

SDK整合：考虑一个方案：A链强制要求在其区块中提供一个专用空间，甚至每几个区块提供一次。A链要求（规则）矿工将所有跨链请求放在该区块空间（“networking bytes”）中。那么B链只需要扫描networking bytes的新请求。这种设计可以减少B链的扫描工作量，类似于轻客户端比全节点轻2500倍的情况。(这是因为轻客户端只同步非常有限的元数据)，如下图：

区块空间格式的建议绝不是一个疯狂的想法。Cosmos已经在其Tendermint SDK中加入了。Solana也有类似的块空间格式规则，不是为了跨链通信，而是为了优化并行执行，见SeaLevel。毋庸置疑，接下来还有进一步优化的可能。

祝贺你! 谢谢你读完这篇长长的文章。跨链设计空间还很年轻，而且雄心勃勃。让我们继续关注并共同建设。我们对一个完全去中心化的、无鲸鱼的跨链通信协议的前景感到兴奋。

我们随时欢迎留言。

• Twitter @TheAntiApe
• Email: theantiape@gmail.com

本翻译由 Duet Protocol 赞助支持。