由 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 验证器。

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

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

Cosmos 团队提出的 IBC（Inter-Blockchain Communication）协议是一个完全开源、通用的区块链跨链互操作协议。跨链技术方案的关键，在于其「互操作能力」和「安全性」。IBC 协议的「分层架构」和「开源策略」，让 IBC 可以支持功能丰富、无需信任的跨链互操作，成为当之无愧的跨链协议的黄金标准。

1、分层架构：

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

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

• 应用层是面向最终用户的跨链互操作接口：包括 token 转账、链间账户和链间查询等多个独立的应用协议，这些应用协议具备可组合性，随着应用协议的增加，跨链能力可以指数级的提高。

• 通讯层定义了数据跨链发送于接收，包括传输、验证和排序，且传输数据内容是不可见。这其中，在源链的状态机内的轻客户端，是通讯层的关键，也成为了 IBC 的精髓所在。

图2：IBC 技术架构

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

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

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

2、技术开源

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

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

Louis

Founder of Octopus Network

图3：IBC 跨链数据数据来源：mapofzones.com

截至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 的原理和优势

AdaptiveIBC异构链跨链技术路线的关键，在于将 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 上，所以这种方式既保证了去中心化和公开可验证，也保证了验证代理和整个跨链系统的安全性。

图5：跨链安全的两种视角

只要跨链双方有一条链的攻击成本/ 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 验证器。只需要通过社区治理进行投票，即可无缝切换进行升级，不影响应用层的使用和技术演进。

Adaptive IBC 是站在巨人的肩膀上，进一步发扬「分层架构」的优势，设计了应用层、通讯层和验证层的三层架构，让验证层可以单独地去演进，不但能够适应更多的区块链的共识机制，而且可以随着验证技术的发展而拥抱可用的最好技术，适应未来逐步进化。

附录

1、2020年，章鱼网络前身 Cdot 团队获得 Interchain 基金的 grant，开发 Substrate-IBC，即 ICS10。

2、2022年，Substrate-IBC 开发完成，成为全世界第一个在非 Cosmos 区块链上实现 IBC 的团队。

3、2022年10月，提出 Adaptive IBC 异构链跨链技术路线，并且启动 NEAR-IBC 的开发。

4、2023年10月， NEAR-IBC 开发完成，并且由第三方安全团队 Blocksec 完成审计。

5、2023年12月，Cosmos SDK 区块链 Ottochain 采用$NEAR Rstaking 共享安全服务，正式启动运行。NEAR-IBC 作为其中的关键技术，验证了 Adaptive IBC 异构链跨链技术路线的可行性和科学性。

6、2024年第一季度，隐私协议 Secret Network 将使用基于 Adaptive IBC 的NEAR-IBC，实现与 NEAR Protocol 之间的资产跨链。随后，Octopus Network 将会与 Secret Network 继续探索消息跨链技术，让 NEAR 的智能合约可以直接调用 Secret Network 的隐私计算能力。

7、2024年，计划启动基于 Adaptive IBC 的 ETH-IBC 开发，目标是在以太坊和其他支持 IBC 的区块链之间，成为第一个为用户提供可负担得起的 IBC 跨链体验的团队。

参考资料

《The IBC Protocol 2023 Year in Review》Mary McGilvray《Adaptive IBC ：异构链互操作性的颠覆者》Louis《NEAR-IBC 介绍｜如何使用智能合约实现 IBC 协议》杨镇《NEAR will be a Cosmos zone SOON》Louis

免责声明：本文仅供参考，不得被用作法律、税务、投资、理财或任何其他建议。