详解 Adaptive IBC 异构链跨链技术路线
由 Cosmos 提出的 IBC 协议，采用链上原生轻客户端/ light client 来验证跨链消息，即跨链双方都在自己的链上维护一个原生的、对侧链的轻客户端，从而最大限度地确保跨链数据的安全。
Cosmos SDK 为所有基于 tendermint 共识的区块链提供了 tendermint 轻客户端实现，所以 Cosmos 链之间的跨链体验丝滑，但非 tendermint 共识的区块链，也就是所谓的「异构链」，因为没有对应轻客户端的工程实现，所以 IBC 扩展到异构链的旅程举步维艰。
2023年12月17日，章鱼网络开发的第二个异构链 IBC —— NEAR-IBC 正式投入使用，从立项开发、到第三方审计直至正式上线，整个过程不足一年，这背后的功臣就是章鱼网络团队提出的 Adaptive IBC 异构链跨链技术路线：通过对 IBC 技术架构的创新，弥补了 IBC 协议在异构链跨链的缺陷，极大地拓展了 IBC 协议的适应性：
各种不同的共识机制的区块链都可以采用 Adaptive IBC 技术路线，比如 Ethereum、NEAR Protocol 和 Polkadot 等等。
极大降低了跨链成本，解决了 IBC 协议延伸到异构链最大的问题。
可以适应各类验证技术的进步，比如 ZK 技术一旦成熟，可以很方便的将代理客户端升级为 ZK 验证器。
Adaptive IBC 技术演进里程碑详见文末附录
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 的原理和优势
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 上，所以这种方式既保证了去中心化和公开可验证，也保证了验证代理和整个跨链系统的安全性。
图5：跨链安全的两种视角
只要跨链双方有一条链的攻击成本/ Attacking Cost 低于公链 ICP，验证代理的引入就不会因为信任集合/ Trust Set 扩大而损害安全性。相比多签或者其他各种外部验证的跨链桥，安全等级都高得多。
由此可见，Adaptive IBC 的验证代理架弥补了 IBC 协议在异构链跨链场景下的缺陷，并且从三个方面，极大地拓展了 IBC 协议的适应性：
极大地降低跨链成本：从验证对方链区块头的几十个上百个的全部签名，变成只对验证代理的1个签名进行验证，解决了 IBC 异构链跨链的最大痛点，即「验证成本高且会有计算资源限制」的问题。
可兼容各种共识机制：验证代理架构对跨链双方不存在依赖关系，可以被各种不同共识机制的区块链采用，比如 Ethereum、NEAR Protocol 和 Polkadot 等等，是名副其实的异构链跨链技术方案。
可适应验证技术发展：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
免责声明：本文仅供参考，不得被用作法律、税务、投资、理财或任何其他建议。
