详解 Adaptive IBC 异构链跨链技术路线

由 Cosmos 提出的 IBC 协议，采用链上原生轻客户端/ light client 来验证跨链消息，即跨链双方都在自己的链上维护一个原生的、对侧链的轻客户端，从而最大限度地确保跨链数据的安全。

Cosmos SDK 为所有基于 tendermint 共识的区块链提供了 tendermint 轻客户端实现，所以 Cosmos 链之间的跨链体验丝滑，但非 tendermint 共识的区块链，也就是所谓的「异构链」，因为没有对应轻客户端的工程实现，所以 IBC 扩展到异构链的旅程举步维艰。

2023年12月17日，章鱼网络开发的第二个异构链 IBC —— NEAR-IBC 正式投入使用，从立项开发、到第三方审计直至正式上线，整个过程不足一年，这背后的功臣就是章鱼网络团队提出的 Adaptive IBC 异构链跨链技术路线：通过对 IBC 技术架构的创新，弥补了 IBC 协议在异构链跨链的缺陷，极大地拓展了 IBC 协议的适应性：

1. 各种不同的共识机制的区块链都可以采用 Adaptive IBC 技术路线，比如 Ethereum、NEAR Protocol 和 Polkadot 等等。
   
   
2. 极大降低了跨链成本，解决了 IBC 协议延伸到异构链最大的问题。
   
   
3. 可以适应各类验证技术的进步，比如 ZK 技术一旦成熟，可以很方便的将代理客户端升级为 ZK 验证器。

Adaptive IBC 技术演进里程碑详见文末附录

IBC 协议的基本原理及其优势

1、分层架构：

IBC 将跨链拆分为「应用层/ Application」和「通讯层/ Channel」，其简洁性和灵活性堪称区块链的 TCP/IP 协议，就如 IBC 官网自述：IBC 从构建互联网的底层协议 TCP/IP 汲取了灵感。

图1：IBC 是区块链的 TCP/IP 协议

• 应用层是面向最终用户的跨链互操作接口：包括 token 转账、链间账户和链间查询等多个独立的应用协议，这些应用协议具备可组合性，随着应用协议的增加，跨链能力可以指数级的提高。
• 通讯层定义了数据跨链发送于接收，包括传输、验证和排序，且传输数据内容是不可见。这其中，在源链的状态机内的轻客户端，是通讯层的关键，也成为了 IBC 的精髓所在。
  

链 A 在自己的状态机内有一个代表链 B 的轻客户端，链 B 也有一个链 A 的轻客户端，轻客户端通过验证区块头和 Merkle 证明来跟踪对方区块链的共识数据，从而验证跨链交互的合法性。

跨链双方之间有一个 Relayer，负责监视两侧区块链产生的 Event，一旦收到 IBC Event 就会把它转换为实际的 IBC message，传递到对面的链上。

简单说，就是 IBC 协议首先建立两个区块链之间的安全通道，然后传递数据包/ Data Packets，轻客户端验证对方区块链的共识信息，保证转移的一致性和安全性。所以，只要通讯层建立起来，整个 IBC 的跨链就是安全的。

2、技术开源

任何人都可以使用 IBC 协议，并且为其做出贡献，IBC 协议内没有抽佣或者隐藏费用。

跨链桥之所以安全问题频发，说到底是因为用单一团队的安全能力无法对抗整个黑客群体。只有使用共同的跨链开放协议，以开源的方式，借助开放社区共同的力量来持续迭代升级，才能让整个行业的跨链安全能力持续进化。

Louis

Founder of Octopus Network

截至2024年1月15日，IBC 协议已经在107个区块链上启动，过去30天总交易量 $40+ 亿，安全跨链交互800+万次。当然，目前绝大多数跨链发生在 Cosmos SDK 区块链之间。

与此同时，许多团队正在努力将 IBC 协议延伸到其他生态系统，希望可以通过 IBC 实现与异构链的跨链交互，包括以太坊、波卡、NEAR Protocol Avalanche、Solana 和 Celestia rollups。

IBC 扩展到异构链的难点

IBC 协议的架构基于轻客户端，所以无需引入第三方的验证服务，实现了无信任/ Trustless 跨链。尤其是在 Cosmos 链之间取得了安全性、成本和速度的极佳平衡，但是在延伸到异构链时，很多团队都是肉眼可见的进展缓慢。

IBC 和  Tendermint 共识机制都是 Cosmos 团队提出，所以 Cosmos SDK 从设计之初就对轻客户端做了非常好的支持。

如果要在 Cosmos 链和非 Cosmos 链之间实现 IBC 协议，就需要在 Cosmos 链上实现对侧的非 Cosmos 链的轻客户端，并且在非 Cosmos 链上实现 tendermint 轻客户端。因为异构链共识机制的不同，在实现过程中需要做大量兼容性工作，并引入相应的技术风险。

这也就让异构链 IBC 在实现过程中面临很多技术挑战：

第一，异构链对跨链消息的验证，成本高且会有计算资源限制/gas Limitation：

IBC 验证跨链消息需要先验证区块头，验证区块头通常要验证几十上百个签名，在链上用智能合约做这些计算成本非常高。另一方面，无论是以太坊、NEAR 乃至其他区块链，都会对智能合约的可用计算量进行限制和规范。这就让 IBC 在做验证时容易遇到验证签名 gas 不够的问题。

最近出现的零知识证明跨链，把很多签名转换成一个 ZK 证明，验证 ZK 证明等效于验证区块头的所有签名，从而节省验证成本。

第二，链上资产管理/ On-chain Asset Management 机制不同

Cosmos SDK 可以通过协议对链上资产进行注册和操作，但在智能合约区块链上不行，Fungible Token 数据都是由单独的智能合约管理。

第三，虚拟机的沙盒限制/Sandbox Limitation

当前的智能合约区块链都基于虚拟机，这种封闭可控的环境访问宿主链的能力有限，比如智能合约就无法获取链上共识状态，又比如 NEAR 是异步链，共识状态变化可能出现在智能合约调用的多个块，更为复杂。

第四，链上存储/ On Chain Storage 数据的规则不一样

IBC 协议需要有较严格的存储键值规则/Path Rule，再去链上获取基于规则生成的存储键值对应的密码学的证明/Proof。

以上难点乃至更多的差异，开发团队都要做额外的工程处理，势必会极大地增加复杂度和 Bug 风险。

Adaptive IBC 的原理和优势

Adaptive IBC 异构链跨链技术路线的关键，在于将 IBC 协议的分层架构进行了创新，进一步拆分出「验证层」，即引入「验证代理/ Verification Proxy」部署在代理链（ICP）上，这样跨链双方只需要验证「验证代理」产生的 Proof，无需直接验证对方链的区块头和全部签名。

图4：基于 Adaptive IBC 的 NEAR-IBC 架构

以 NEAR-IBC 为例：在代理链/ Proxy Chain 上部署了 Cosmos 和 NEAR 的验证代理，维护对应链的共识，然后在跨链双方再部署一个对方共识机制的代理客户端，替换 IBC 原来的轻客户端。

以 Cosmos 向 NEAR 跨链为例，当 Cosmos 向 NEAR 传递消息时，代理链上的 Cosmos 验证代理/ Tendermint Verification Proxy 会验证跨链消息，对它进行签名生成一个 Proof，然后 NEAR 这一边的 Cosmos 代理客户端/ Tendermint Proxy Client 只需要验证这个 Proof，就可以完成跨链的验证。

图5：跨链技术的安全性与拓展性

在安全性方面，虽然引入的验证代理属于外部验证/ External Verification 方案，理论上安全性是略低于原生轻客户端验证的，但值得注意的是，相较原生轻客户端验证，总体安全性并没有显著降低。

因为 Adaptive IBC 建议将验证代理部署在公链上，例如 NEAR-IBC 就是部署在公链 ICP 上，所以这种方式既保证了去中心化和公开可验证，也保证了验证代理和整个跨链系统的安全性。

只要跨链双方有一条链的攻击成本/ Attacking Cost 低于公链 ICP，验证代理的引入就不会因为信任集合/ Trust Set 扩大而损害安全性。相比多签或者其他各种外部验证的跨链桥，安全等级都高得多。

由此可见，Adaptive IBC 的验证代理架弥补了 IBC 协议在异构链跨链场景下的缺陷，并且从三个方面，极大地拓展了 IBC 协议的适应性：

1. 极大地降低跨链成本：从验证对方链区块头的几十个上百个的全部签名，变成只对验证代理的1个签名进行验证，解决了 IBC 异构链跨链的最大痛点，即「验证成本高且会有计算资源限制」的问题。
   
   
2. 可兼容各种共识机制：验证代理架构对跨链双方不存在依赖关系，可以被各种不同共识机制的区块链采用，比如 Ethereum、NEAR Protocol 和 Polkadot 等等，是名副其实的异构链跨链技术方案。
   
   
3. 可适应验证技术发展：Adaptive IBC 从通讯层中，进一步拆分了「验证层」并演化出验证代理方案。分层架构的优势之一就是降低整个系统互相之间的依赖，所以 Adaptive IBC 可以适应各类验证技术的进步。
   
   
   • Cosmos 如果能支持聚合签名，或者 NEAR 支持了 ED25519 签名的 Precompile，将大幅降低 NEAR Protocol 上直接验证的成本，就可以把代理客户端再次升级成真正可用的轻客户端
     
     
   • ZK 跨链技术一旦成熟，就可以把验证代理换成ZK证明器，把代理客户端升级为 ZK 验证器。只需要通过社区治理进行投票，即可无缝切换进行升级，不影响应用层的使用和技术演进。

附录

参考资料

作者：Web3；来自链得得内容开放平台“得得号”，本文仅代表作者观点，不代表链得得官方立场凡“得得号”文章，原创性和内容的真实性由投稿人保证，如果稿件因抄袭、作假等行为导致的法律后果，由投稿人本人负责得得号平台发布文章，如有侵权、违规及其他不当言论内容，请广大读者监督，一经证实，平台会立即下线。如遇文章内容问题，请联系微信：chaindd123