区块链技术的世界不断发展,不同链之间无缝通信的需求变得至关重要。这就是 IBC(Inter-Blockchain Communication Protocol)的用武之地,它是一种开创性协议,可以在任意两个区块链之间传输数据。
本文将深入探讨 IBC 的关键组件、工作原理、相对于其他通信解决方案的独特优势以及其最近在 Cascade 上实现等内容。
IBC 的关键组件
从根本上说,IBC 定义了一套标准来管理两个链之间数据认证和传输。使用 IBC 进行成功通信需要以下组件:
- 每条链都必须实现IBC核心通信协议
- 每条链都必须有另一条链的轻客户端,可以验证块完整性和共识信息
- 一个称为中继器(relayer) 的离线程序负责查询每个链接口上的 IBC 消息,并在必要时向另一个链接口发送相应的 IBC 消息
IBC 如何工作
使用 IBC 在两个区块链之间启动通信需要建立连接和 channel。
此过程涉及四个步骤,类似于 TLS 握手:open-init(A)
、open-try(B)
、open-ack(A)
和 open-confirm(B)
,其中 A 和 B 代表所涉及到的各自区块。
例如:Cascade IBC 连接
一旦打开 channel,一个链上的应用程序就可以通过两个步骤(send(A)
和ack(B)
)将消息作为数据包发送到另一个链上。
可替代令牌转移(例如 ERC-20 或 SPL 令牌)是在通用数据包发送接口之上实现的附加协议,并在 ICS20 中指定。传输的每一侧都会验证该令牌转移是否有效,然后在发送方销毁代币以使其在接收方可用。
IBC 与其他通信解决方案有何不同?
IBC 的安全模型使其与其他通信解决方案区别开来。
对 IBC 的信任完全取决于每个链接口正确实施核心协议和轻客户端准确验证数据。即使是负责链间消息传递的中继器也无需进行额外的信任假设。
这与 Hyperlane 或 Wormhole 所依赖于相互连接桥梁操作员守护网络进行正确保护防止黑客攻击等情形不同。
但是,IBC 的安全性需要付出代价:要在两个链之间实现 IBC 通信更耗时费力,因为每对链都需要编写并验证两个相应的轻客户端以确保其正确性和安全性。
换句话说,IBC 就像 Uniswap 对 Coinbase 那样:IBC 更加去中心化,除了实施之外不需要任何信任假设,但正确实现可能具有挑战性,类似于智能合约的一般情况。
IBC 在 Cascade 上是如何工作的?
Injective 和 Eclipse 开发的第一个跨链SVM Rollup——Cascade,将 IBC 集成推向了新高度。
通过使 Solana 开发人员能够轻松地将其合约和 dApp 部署到 Injective 上,Cascade 扩展了跨链通信的可能性。
尽管 Eclipse 不是基于 Cosmos SDK 构建的,但已经添加了 IBC 支持以释放这个跨链 Rollup 的全部潜力。
我们计划通过为每个包含原始 Rollup 上每个块 Merklized IBC 状态的 Eclipse Rollup 启动一个权威证明(POA)Tendermint 链来使现有的 IBC 中继器与Eclipse Rollups一起工作。
这使得现有的 Tendermint 轻客户端可以无缝地与 Eclipse Rollups 协同工作。
未来,我们将分散每个 Tendermint 链的验证器集合,以便多样化组合验证者可以确认状态转换是否被正确计算。
Cascade 现在已经在 Injective 测试网上线,并计划在不久后迁移到主网。渴望探索 Cascade 功能深度并想要深入研究它们能力强大而全面文档资料可从以下链接获取:
https://docs.cascadehq.xyz/cascade-docs/cascade-developer-documentation
关于 Eclipse:
Eclipse 是一个可定制化 Rollup 提供者,允许开发人员“挑选和选择”所需的最佳区块链技术方面来创建独特的去中心化应用程序,而不必进行技术妥协。
加入我们的社群:https://linktr.ee/eclipsefnd
关于 Injective:
Injective 是一个快速互操作性一层区块链,专为构建 Web3 金融首选应用程序而优化。Injective 为开发人员提供了强大的即插即用模块,以创建无与伦比的 dApps。INJ 是驱动 Injective 及其快速增长生态系统的本地资产。Injective 由 Binance 孵化,并得到 Jump Crypto、Pantera 和 Mark Cuban 等知名投资者支持。
所有评论