Overview

​

概述

​

什么是跨链通信协议（IBC）？

IBC 应用程序必须编写为自包含模块。

• 绑定一个或多个端口。
• 定义你的数据包数据。
• 使用 core IBC 提供的默认确认结构体，或根据需要定义自定义确认结构体。
• 为数据包数据制定标准化编码。
• 实现 IBCModule 接口。
• 实现 UpgradableModule 接口（可选）。

​

组件概览

​

客户端

• Solo Machine 轻客户端：手机、浏览器或笔记本电脑等设备。
• Tendermint 轻客户端：基于 Cosmos SDK 的链的默认选择。
• Wasm 客户端：一种代理客户端，适用于运行使用可编译为 Wasm 的语言编写的轻客户端。
• Localhost（回环）客户端：适用于测试、模拟，以及将数据包中继到同一应用内的模块。

​

IBC 客户端高度

type Height struct {
    RevisionNumber uint64
  RevisionHeight uint64
}

Height{
    RevisionNumber: 3,
    RevisionHeight: 0
} > Height{
    RevisionNumber: 2,
    RevisionHeight: 100000000000
}

• 升级前 chainID：gaiamainnet-3
• 升级后 chainID：gaiamainnet-4

​

连接

1. 链 A 发送 ConnectionOpenInit 消息，表示尝试与链 B 初始化连接。
2. 链 B 发送 ConnectionOpenTry 消息，尝试在链 A 上打开连接。
3. 链 A 发送 ConnectionOpenAck 消息，将其连接端状态标记为打开。
4. 链 B 发送 ConnectionOpenConfirm 消息，将其连接端状态标记为打开。

​

延时连接

• 07-tendermint
• 08-wasm（传递给合约）

​

证明 与 路径

• 所有 IBC 实现提交 IBC 消息时必须使用的路径定义在 ICS-24 Host 状态机要求中。
• 所有实现都必须能够生成和验证的证明格式定义在 ICS-23 Proofs 实现中。

​

端口

​

通道

1. 链 A 发送 ChanOpenInit 消息，表示尝试与链 B 初始化通道。
2. 链 B 发送 ChanOpenTry 消息，尝试在链 A 上打开该通道。
3. 链 A 发送 ChanOpenAck 消息，将其通道端状态标记为打开。
4. 链 B 发送 ChanOpenConfirm 消息，将其通道端状态标记为打开。

​

关闭通道

• 通道存在且尚未关闭；
• 其所在连接为 OPEN；
• IBC 模块回调 OnChanCloseInit 返回 nil。

• 通道存在且尚未关闭；
• 通道所在连接为 OPEN；
• 执行链成功验证对手方通道已关闭；
• IBC 模块回调 OnChanCloseConfirm 返回 nil。

​

数据包

​

回执与超时

• timeoutHeight 表示目标链上的一个共识高度，超过该高度后，数据包将不再被处理，而是被视为已超时。
• timeoutTimestamp 表示目标链上的一个时间戳，超过该时间点后，数据包将不再被处理，而是被视为已超时。

• 在 ORDERED 通道中，通道内任意一个数据包的超时都会导致通道关闭。
  • 如果序号为 n 的数据包超时，那么序号为 k > n 的数据包将无法被接收，否则就会违反 ORDERED 通道“数据包按发送顺序处理”的约定。
  • 由于 ORDERED 通道强制这一不变式，因此只要证明序号 n 在数据包 n 指定的超时时间前未在目标链上被接收，就足以使数据包 n 超时并关闭该通道。
• 在 UNORDERED 通道中，只会对该数据包应用应用特定的超时逻辑，通道不会被关闭。
  • 数据包可以按任意顺序接收。
  • IBC 会为 UNORDERED 通道中每个已接收的序号写入一条数据包回执。该回执不包含信息；它只是一个标记，用于表示 UNORDERED 通道已经接收了指定序号的数据包。
  • 要使 UNORDERED 通道上的数据包超时，需要证明在指定超时时间前，该数据包序号对应的数据包回执不存在。

​

确认

• 同步地在 OnRecvPacket 中完成，如果模块在从 IBC 模块接收到数据包后立即处理该数据包。
• 异步完成，如果模块是在接收到数据包后的稍晚某个时间点再处理该数据包。

• 确认失败后，可以回滚数据包发送时的变更（例如，在 ICS 20 中向发送者退款）。
• 当原始链上的发送方成功接收到确认后，对应的数据包承诺会被删除，因为它已不再需要。

​

进一步阅读与规范

• IBC 规范概览

​

Synopsis

​

What is the Inter-Blockchain Communication Protocol (IBC)?

IBC applications must be written as self-contained modules.

• Bind to a port or ports.
• Define your packet data.
• Use the default acknowledgment struct provided by core IBC or optionally define a custom acknowledgment struct.
• Standardize an encoding of the packet data.
• Implement the IBCModule interface.
• Implement the UpgradableModule interface (optional).

​

Components overview

​

Clients

• Solo Machine light client: Devices such as phones, browsers, or laptops.
• Tendermint light client: The default for Cosmos SDK-based chains.
• Wasm client: Proxy client useful for running light clients written in a Wasm-compilable language.
• Localhost (loopback) client: Useful for testing, simulation, and relaying packets to modules on the same application.

​

IBC client heights

type Height struct {
    RevisionNumber uint64
  RevisionHeight uint64
}

Height{
    RevisionNumber: 3,
    RevisionHeight: 0
} > Height{
    RevisionNumber: 2,
    RevisionHeight: 100000000000
}

• Before upgrade chainID: gaiamainnet-3
• After upgrade chainID: gaiamainnet-4

​

Connections

1. chain A sends a ConnectionOpenInit message to signal a connection initialization attempt with chain B.
2. chain B sends a ConnectionOpenTry message to try opening the connection on chain A.
3. chain A sends a ConnectionOpenAck message to mark its connection end state as open.
4. chain B sends a ConnectionOpenConfirm message to mark its connection end state as open.

​

Time delayed connections

• 07-tendermint
• 08-wasm (passed to the contact)

​

Proofs and paths

• The paths that all IBC implementations must use for committing IBC messages is defined in ICS-24 Host State Machine Requirements.
• The proof format that all implementations must be able to produce and verify is defined in ICS-23 Proofs implementation.

​

Ports

​

Channels

1. chain A sends a ChanOpenInit message to signal a channel initialization attempt with chain B.
2. chain B sends a ChanOpenTry message to try opening the channel on chain A.
3. chain A sends a ChanOpenAck message to mark its channel end status as open.
4. chain B sends a ChanOpenConfirm message to mark its channel end status as open.

​

Closing channels

• the channel exists and it is not already closed,
• the connection it exists upon is OPEN,
• the IBC module callback OnChanCloseInit returns nil.

• the channel exists and is not already closed,
• the connection the channel exists upon is OPEN,
• the executing chain successfully verifies that the counterparty channel has been closed
• the IBC module callback OnChanCloseConfirm returns nil.

​

Packets

​

Receipts and timeouts

• The timeoutHeight indicates a consensus height on the destination chain after which the packet is no longer to be processed, and instead counts as having timed-out.
• The timeoutTimestamp indicates a timestamp on the destination chain after which the packet is no longer to be processed, and instead counts as having timed-out.

• In ORDERED channels, a timeout of a single packet in the channel causes the channel to close.
  • If packet sequence n times out, then a packet at sequence k > n cannot be received without violating the contract of ORDERED channels that packets are processed in the order that they are sent.
  • Since ORDERED channels enforce this invariant, a proof that sequence n has not been received on the destination chain by the specified timeout of packet n is sufficient to timeout packet n and close the channel.
• In UNORDERED channels, the application-specific timeout logic for that packet is applied and the channel is not closed.
  • Packets can be received in any order.
  • IBC writes a packet receipt for each sequence received in the UNORDERED channel. This receipt does not contain information; it is simply a marker intended to signify that the UNORDERED channel has received a packet at the specified sequence.
  • To timeout a packet on an UNORDERED channel, a proof is required that a packet receipt does not exist for the packet’s sequence by the specified timeout.

​

Acknowledgments

• Synchronously on OnRecvPacket if the module processes packets as soon as they are received from IBC module.
• Asynchronously if module processes packets at some later point after receiving the packet.

• After an acknowledgement fails, packet-send changes can be rolled back (for example, refunding senders in ICS 20).
• After an acknowledgment is received successfully on the original sender on the chain, the corresponding packet commitment is deleted since it is no longer needed.

​

Further readings and specs

• IBC specification overview