# 关于跨链

By [ForestBear](https://paragraph.com/@virweb3) · 2023-01-20

---

跨链的需求：

区块链就是一张全球共享的大表。既然是大表，就不可能只有一张，因为要做到高性能和复杂度的系统的话，一定是有很多张表的。仅仅依赖以太的话，做不了多复杂的事情。

跨链的价值:

第一点\*\*应用会有跨链的需求。\*\*应用肯定愿意把生意做到每一条链上，越广泛越好。

第二点，\*\*用户不希望自己的资产只能在一条链上。\*\*用户想要玩转各个链上的一些 DeFi 应用或其他类型应用的话，他也需要让自己的资产去多个链中流通、套利，去享受多条链上不同类型的服务。

第三点，**公链自身也有跨链的需求。**

第四点，站在用户的角度：链多了以后，虽然应用会更加繁荣，但它对用户增加了复杂度，也增加了用户认知的压力。所以**需要有筛选功能的工具帮用户降低认知压力，跨链应用就是一个很好的工具**。反过来说，帮用户降低认知负担，就是跨链最大的价值。

而依照工作原理，目前市面上的跨链桥大致可以分为以下两种：

1.  通过锁定原生资产，铸造和销毁映射资产完成跨链。从A链跨到B链时，A链上的资产被跨链协议锁定在其智能合约地址中，并通过预言机通知B链上的智能合约后在B链上铸造等量映射资产。当用户需要跨回A链时，再通过智能合约将B链上的映射资产销毁，以赎回A链上的原生资产。
    
2.  通过挖矿激励的方式聚合流动性，在A、B链分别建立并使用流动性池作为跨链资产储备，同时利用锁定和争议机制，确保参与的节点无法转移用户资产。
    

跨链的不可能三角：

安全性，扩展性(交易的扩展性，资产池的扩展性)，去中心化

**安全性**

当我们讨论跨链桥的安全性时，我们想问的问题其实是：每一笔跨链交易的真实性是由谁来验证的？破坏它的成本和可能性又是多少？

上文提及的两种跨链桥工作模式都存在对应的风险。第一种桥涉及超发风险和节点作恶风险。由于跨链请求、原生代币锁定、映射代币铸造等数据信息由第三方验证节点提供，因此用户或流动性提供者资金的安全性高度依赖这些验证器的准确性，而非源链或目标链的安全性。而验证器破坏安全性的代价和成本则取决于其所质押的资产，跨链协议应该确保抵押资产始终大于验证金额以防止作恶风险。

第二种流动性网络的跨链方案，由于用户在B链使用的资产已非跨链桥铸造的映射代币，而是在B链上部署原生代币智能合约的、普适性的代币，所以跨链后的资产已脱离跨链桥的背书支持。这类非托管方案，由于普适性代币崩盘可能性小于映射代币，安全性较之前有了巨大的提升。然而仍然高度依赖中间共识层，一旦共识层去中心化程度不足，资产依旧有被盗取的风险。因此，网络需要包含尽可能多的节点，同时设置合理经济激励以防止节点运行者作恶，以确保安全性最大化。

**去中心化**

去中心化程度最直接的评判标准就是参与验证的节点数量。数量越多，节点集体作恶的难度也就越高，相应地去中心化程度也就越高。下面的表格里罗列了目前市面上常见的跨链桥及其所支持的资产和区块链数量，以及各自的节点数。

**可扩展性**

可扩展性分为资产池的可扩展性与交易的可扩展性。交易的可扩展性受制于源链和目标链的出块速度和安全性，而资产池的可扩展性则取决于流动性激励或质押的资产总数。

交易的可扩展性可以类比Dex，而Dex里可扩展性最好的要数Uniswap。无需许可，任何ERC20代币一旦部署了流动性，任何人都可以自由地在上面进行交易。ChainSwap引入的无许可一键跨链部署功能，只要支付一定的费用就可以通过其门户桥接交换代币。然而，为了确保该功能的流畅度，ChainSwap选择采用了较为中心化的PoA共识机制，牺牲了一部分安全性以确保其可扩展性。也正是因此，ChainSwap曾多次遭到攻击。

资产池的可扩展性仅适用于前文提到的第二种流动性池模式，需要足够的激励保证流动性始终保持充裕。然而，虽然安全性相对第一种模式有所提高，其架构层面也更为复杂，部署难度的提升意味着需要更多的开发时间，也将导致可扩展性降低。

IBC和Layerzero
-------------

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

跨链的三个关键步骤：

*   **监控和通知**：系统必须收到信号后才能开始处理通信请求。
    
    _在 Web 2_中，一个典型的实现是“ **监听器代码**”，服务器不断地（每毫秒循环一次）检查其门户网站的网络请求。这种范式对于 Web 3 来说是不可能的，因为让区块链循环高频计算的成本太高。
    
    _在 Web 3_中，自我运行的智能合约需要被通知有事情发生。目前的解决方案依赖于需要验证两条链的节点--“**中继者**”。
    
*   **数据**：关于交易的详细数据（称为 “有效载荷（payload）”）必须在系统之间进行交流。
    
    \_在 Web 2\_，这个问题是微不足道的。谷歌可以通过物理互联网基础设施向 Facebook 发送任何东西。
    
    \_在 web 3\_，人们关注的是节约计算。幸运的是，由于一些聪明的以太坊设计，我们不必发送整个区块：要描述一个交易并证明它发生在一个以太坊区块上，只需要发送尺寸小于一个以太坊区块 0.1%的数据。(见：Patricia-tree\[33\]）在 IBC 和 Layer Zero 中，**中继者**负责转发数据。
    
*   **验证**：接收方需要确信数据是由正确的发起人的授权的转账
    
    _在 Web 2_中，这个问题同样简单明了。Facebook 使用既定的协议（如 HTTPS）来验证谷歌的服务器签名和解密签名的信息。
    
    _在 Web 3_中，仅仅知道一个交易和它的区块 XYZ（数据）是不够的，但接收的智能合约需要知道区块 XYZ 包含在源链上。确认是很难的，因为即使在一个区块被验证和签署之后，也会发生区块重组。如何做到这一点是 IBC 和 Layer Zero 的主要区别。
    

### IBC：中继者 + 轻型客户端

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

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

![](https://storage.googleapis.com/papyrus_images/a87b77f35d8636407b9fb8eb3fa2cade03b0a18de9945a7ef7630bd629def3bc.png)

### LayerZero： 中继者 + 预言机

![](https://storage.googleapis.com/papyrus_images/1752fc7414cd3b99d0569f25568c8fdca1ef58ffc481564f40ea94d75e20072e.png)

*   LayerZero 与 IBC 相比有两个主要区别：
    
    **工作流程：**
    
    > 具有 merkle root 0xbbcc 的 Terra 区块 129634 是否在你的完整 Terra 账本版本中，并且至少有 X 个子块
    
    同时，**数据**部分则表示：
    
    > 这是一个地址为 0x1927 的 Terra 交易，向智能合约地址 0x7878 发送 10LUNA。这笔交易包含在 merkle 根 0xbbcc 的区块中，这里是区块包含的 merkle 路径证明。
    
    把两块放在一起，我们将同时拥有 `数据`和 `验证`来证明一笔交易在另一条链上发生。
    
    **设计选择讨论：**
    
    *   引入了额外的协议依赖性和智能合约风险
        
    *   调用 Chainlink 的合约而不是检查链上数据会引入额外的延迟和 Gas 成本
        
    *   与完全在链上的轻客户端相比，使用 Chainlink 牺牲了一些安全性和运行时间的延迟。
        
    *   **监控和激活+交易数据 -- 中继者**：与 IBC 相同。
        
    *   **验证 -- 预言机**：LayerZero 使用 Chainlink 的去中心化 Oracle 网络来检查区块承诺。例如，Layer Zero 智能合约会询问 Chainlink。
        
    *   **部署的形式**： Layer Zero 是 IBC 的智能合约实现（所以它可以在 EVM 和 Solana 等链上原生工作）
        
        > 注：IBC 从 2022 年 3 月起只在 Cosmos 链上上线。
        
    *   **取代了昂贵的轻客户端**：它不需要每个链上的智能合约来同步所有其他连接的链的块头，而是将交易执行检查外包给 Chainlink。
        
    *   Cosmos 通过自定义链的设计解决了 IBC 的 Gas 问题：让 IBC 成为链级模块。Cosmos 要求验证者在链级而不是智能合约级维护 Cosmos Hub 轻客户端。--计算成本隐含地由验证者承担，而不是由特定的智能合约账户承担。
        
    *   IBC 的运行依赖于链外的**中继者**，他们在 A 链和 B 链上运行轻客户端。IBC 中继者软件是开源的，没有权限，所以任何人都可以加入。**他们不需要信任安全**，因为链上智能合约将验证所有交易。**中继者的冗余只是为了服务的可用性**。
        
    *   链上验证在像 ETH 这样的高 Gas 链上可能成本很高，因为 ETH 上的 IBC 合约需要不断从其他链上保存新的区块头以维持实时验证。
        
        > ......\[轻客户端的成本\]: 根据 Layer Zero 的说法，在以太坊上每条成对的链每天要花费数千万美元。
        
    *   **监控和激活+交易数据 -- 中继者**：如前所述，中继者是一组可以在同一台物理机器上验证两个链的节点。中继者使用廉价的云计算能力来扫描 A 链的网络请求。如果它发现了 A-->B 的交互请求，就会向 B 链提交交易。
        
    *   **验证 -- 轻型客户端**：IBC 还需要部署一个链上轻客户端（见定义）。B 链上的智能合约可以独立验证链上交易是否在源链上被正确执行，这是 IBC 认可交易前的最后一步。
        
*   这是一个固定成本与可变成本的权衡
    
    *   轻型客户机在一些高 Gas 链上有很高的固定成本（需要更新以保持有效性，无论使用情况如何），但每次使用的可变成本很少或没有。
        
    *   预言机网络的每次使用成本略有增加， 因为预言机网络变得拥挤些。
        

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

IBC 适用于以下使用情况：

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

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

### 前面还有更多的复杂问题

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

**二层 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\[34\]提供中心化限价订单簿的做法，在费用、最终性和延迟方面提供不同的设计选择。另外，如果 Serum 的发展速度足够快，它本身也可以有一个尝试。

**ZK-SNARKs**

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

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

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

*   在目的链上进行 O(log n)简洁的计算来进行验证
    
*   进一步优化 IBC 轻客户端成本和链上数据成本
    

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

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

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

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

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

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

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

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

![](https://storage.googleapis.com/papyrus_images/595150f34f3930ae513d255ffa329456bdb1d5c78b1d59f4f747be09d45096e6.png)

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

---

*Originally published on [ForestBear](https://paragraph.com/@virweb3/KMiZzQAaq1U48vkHWyW1)*