概述

本文档描述了标准 IBC 实现(称为 IBC 处理器)向同一状态机内模块暴露的接口,以及 IBC 处理器对该接口的实现方式。

动机

IBC 是一种模块间通信协议,旨在促进位于不同区块链上的模块之间进行可靠且经过认证的消息传递。模块应能够理解其所交互的接口,以及为了安全使用该接口必须遵守的要求。

定义

相关定义在所引用的先前标准中已有说明(这些函数亦定义于其中),适用时以其为准。

期望属性

  • 客户端、连接和通道的创建应尽可能无需许可。
  • 模块集合应当是动态的:链应能够自由添加和销毁模块,而模块自身也应能够在持久化 IBC 处理器存在的情况下,自由绑定到端口或解除端口绑定。
  • 模块应能够在 IBC 之上编写自身更复杂的抽象,以提供额外的语义或保证。

技术规范

注意:如果宿主状态机使用对象能力认证(参见 ICS 005),则所有使用端口的函数都需要额外接收一个 capability key 参数。

客户端生命周期管理

默认情况下,客户端不归任何模块所有:任何模块都可以创建新客户端、查询任何现有客户端、更新任何现有客户端,并删除任何未被使用的现有客户端。 处理器接口暴露了 ICS 2 中定义的 createClient、updateClient、queryConsensusState、queryClientState 和 submitMisbehaviourToClient。

连接生命周期管理

处理器接口暴露了 ICS 3 中定义的 connOpenInit、connOpenTry、connOpenAck、connOpenConfirm 和 queryConnection。 默认 IBC 路由模块 SHALL 允许对 connOpenTry、connOpenAck 和 connOpenConfirm 的外部调用。

通道生命周期管理

默认情况下,通道归创建它的端口所有,这意味着只有绑定到该端口的模块才被允许检查、关闭该通道,或通过该通道发送消息。一个模块可以使用同一个端口创建任意数量的通道。 处理器接口暴露了 ICS 4 中定义的 chanOpenInit、chanOpenTry、chanOpenAck、chanOpenConfirm、chanCloseInit、chanCloseConfirm 和 queryChannel。 默认 IBC 路由模块 SHALL 允许对 chanOpenTry、chanOpenAck、chanOpenConfirm 和 chanCloseConfirm 的外部调用。

数据包中继

数据包的权限由通道控制(只有拥有某个通道的端口才能在该通道上发送或接收数据包)。 处理器接口暴露了 ICS 4 中定义的 sendPacket、recvPacket、acknowledgePacket、timeoutPacket 和 timeoutOnClose。 默认 IBC 路由模块 SHALL 允许对 sendPacket、recvPacket、acknowledgePacket、timeoutPacket 和 timeoutOnClose 的外部调用。

属性与不变量

此处定义的 IBC 处理器模块接口继承了其对应规范中所定义函数的属性。

向后兼容性

不适用。

向前兼容性

只要语义保持不变,该接口在新链上实现时(或现有链升级时)MAY 发生变化。

示例实现

即将提供。

历史

2019 年 6 月 9 日 - 草案撰写完成 2019 年 8 月 24 日 - 修订与清理

版权

本文全部内容采用 Apache 2.0 许可。

Synopsis

This document describes the interface exposed by the standard IBC implementation (referred to as the IBC handler) to modules within the same state machine, and the implementation of that interface by the IBC handler.

Motivation

IBC is an inter-module communication protocol, designed to facilitate reliable, authenticated message passing between modules on separate blockchains. Modules should be able to reason about the interface they interact with and the requirements they must adhere to in order to utilise the interface safely.

Definitions

Associated definitions are as defined in referenced prior standards (where the functions are defined), where appropriate.

Desired Properties

  • Creation of clients, connections, and channels should be as permissionless as possible.
  • The module set should be dynamic: chains should be able to add and destroy modules, which can themselves bind to and unbind from ports, at will with a persistent IBC handler.
  • Modules should be able to write their own more complex abstractions on top of IBC to provide additional semantics or guarantees.

Technical Specification

Note: If the host state machine is utilising object capability authentication (see ICS 005), all functions utilising ports take an additional capability key parameter.

Client lifecycle management

By default, clients are unowned: any module may create a new client, query any existing client, update any existing client, and delete any existing client not in use. The handler interface exposes createClient, updateClient, queryConsensusState, queryClientState, and submitMisbehaviourToClient as defined in ICS 2.

Connection lifecycle management

The handler interface exposes connOpenInit, connOpenTry, connOpenAck, connOpenConfirm, and queryConnection, as defined in ICS 3. The default IBC routing module SHALL allow external calls to connOpenTry, connOpenAck, and connOpenConfirm.

Channel lifecycle management

By default, channels are owned by the creating port, meaning only the module bound to that port is allowed to inspect, close, or send on the channel. A module can create any number of channels utilising the same port. The handler interface exposes chanOpenInit, chanOpenTry, chanOpenAck, chanOpenConfirm, chanCloseInit, chanCloseConfirm, and queryChannel, as defined in ICS 4. The default IBC routing module SHALL allow external calls to chanOpenTry, chanOpenAck, chanOpenConfirm, and chanCloseConfirm.

Packet relay

Packets are permissioned by channel (only a port which owns a channel can send or receive on it). The handler interface exposes sendPacket, recvPacket, acknowledgePacket, timeoutPacket, and timeoutOnClose as defined in ICS 4. The default IBC routing module SHALL allow external calls to sendPacket, recvPacket, acknowledgePacket, timeoutPacket, and timeoutOnClose.

Properties & Invariants

The IBC handler module interface as defined here inherits properties of functions as defined in their associated specifications.

Backwards Compatibility

Not applicable.

Forwards Compatibility

This interface MAY change when implemented on new chains (or upgrades to an existing chain) as long as the semantics remain the same.

Example Implementations

Coming soon.

History

Jun 9, 2019 - Draft written Aug 24, 2019 - Revisions, cleanup All content herein is licensed under Apache 2.0.