概述
本规范定义了托管区块间通信协议实现的状态机必须满足的最小属性集合。IBC 依赖可证明的键值存储来实现跨链通信。在本规范的第 2 版中，预期的键值存储将仅用于与数据包处理相关的键。动机
IBC 旨在成为由多种区块链和状态机共同托管的通用标准，因此必须清晰定义宿主的要求。定义
期望属性
IBC 应尽可能只要求底层状态机提供简单接口，以最大化正确实现的便利性。技术规范
模块系统
宿主状态机必须支持模块系统，使自包含且可能彼此不信任的代码包能够在同一账本上安全执行，控制其允许其他模块与之通信的方式和时机，并能够被“主模块”或执行环境识别和操作。 ICS-4 中定义的 IBC 核心处理器必须具有路径、标识符、分隔符
Identifier 是一个字节串，用作存储在状态中的对象键，例如数据包承诺、确认或回执。
标识符 MUST 为非空（长度为正整数）。
标识符 MUST 仅由以下类别中的字符组成：
- 字母数字字符
.,_,+,-,#[,],<,>
Path 是一个字节串，用作存储在状态中的对象键。路径 MUST 仅包含标识符、常量字节串以及分隔符 "/"。
标识符不应成为有价值的资源。为防止名称抢注，可以实现最小长度要求或伪随机生成，但本规范不施加特定限制。
分隔符 "/" 用于分隔并拼接两个标识符，或一个标识符与一个常量字节串。标识符 MUST NOT 包含 "/" 字符，以避免歧义。
默认情况下，标识符的最小和最大字符长度如下：
| Port 标识符 | Client 标识符 |
|---|---|
| 2 - 128 | 2 - 64 |
键值存储
宿主状态机 MUST 提供一个键值存储接口， 并包含三个按标准方式运行的函数：queryProof 将返回 Membership 证明；如果该路径没有存储值，则返回 NonMembership 证明。
宿主状态机 SHOULD 也提供一个从键值存储中删除
某个 Path 的接口，但这不是必需的：
Path 的定义如上。Value 是某个特定数据结构的任意字节串编码。需要写入可证明存储的具体 Path 和 Value 定义见 ICS-4。
这些函数 MUST 仅授权给 IBC 数据包处理模块（其实现见 ICS-4），因此只有 IBC 处理模块能够对可被 get 读取的路径执行 set 或 delete。
在大多数情况下，这会作为整个状态机所使用的大型键值存储中的一个子存储（带前缀的键空间）来实现。这就是为什么 ICS-2 定义了与客户端关联的 counterpartyCommitmentPrefix。IBC 处理器会在依据客户端中的 ConsensusState 进行证明验证之前，将 counterpartyCommitmentPrefix 添加到 ICS-4 标准化路径前。
可证明路径空间
IBC/TAO 实现 MUST 按照以下精确格式为provableStore 实现这些路径。这是因为对手方 IBC/TAO 实现会根据本规范构造路径，并将其发送给轻客户端，以验证存储在 IBC 指定路径下的 IBC 指定值。
未来协议版本可能会使用新的路径，因此可证明存储中的整个键空间 MUST 为 IBC 处理器保留。
| 值 | 路径格式 |
|---|---|
| 数据包承诺 | 0x1 |
| 数据包回执 | 0x2 |
| 确认承诺 | 0x3 |
MembershipProof。它还 MUST 能够为存储中不存在的键提供 NonMembership 证明。
如果状态机不支持 NonMembership 证明，客户端可以通过将 SENTINEL_ABSENCE_VALUE 关联为“该键不存在”的含义来绕过这一限制，并将带有 SENTINEL_ABSENCE_VALUE 的 MembershipProof 视为 NonMembershipProof。在这种情况下，状态机有责任确保存在一种方式，能够将 SENTINEL_ABSENCE_VALUE 写入 IBC 需要证明不存在性的键，并且 MUST 确保参与者不会意外地直接将 SENTINEL_ABSENCE_VALUE 设到某个键上。这些要求及其实现方式不在本规范范围内，仍由定制化 IBC 实现负责。
最终性
状态机 MUST 顺序执行更新，使所有状态更新按顺序发生，并且能够按该顺序与唯一的Height 关联。高度 h 上的每次状态更新 MUST 最终在某个有限时间戳 t 被最终确定，使得从初始状态到 h 的状态更新顺序在时间 t 之后永远不会再改变。
IBC 处理器只会接受来自已被视为最终确定的状态更新的数据包流消息。在最终性属性仅能以概率方式保证的情况下，这种概率性保证必须在 ICS-2 客户端内部处理，以便为 ICS-4 数据包处理器提供远端状态机的最终视图。
时间
随着状态更新随时间应用到状态机，状态更新算法自身 MUST 能够安全访问当前正在应用该状态更新时的时间戳。这是 IBC 处理器正确处理超时所必需的。 如果状态机更新机制本身不会向状态机处理器提供时间戳，那么状态机更新本身中必须包含时间预言机更新。在这种情况下，IBC 的安全模型也将包含该时间预言机的安全模型。 某次状态更新的这个时间戳 MUST 单调递增，并且 MUST 大于或等于对手方客户端针对与该状态更新相关联的ConsensusState 返回的时间戳。
向后兼容性
不适用。向前兼容性
在单个宿主状态机的运行过程中，键值存储功能和共识状态类型不太可能发生变化。submitDatagram 可以随时间变化，因为中继者应能够更新其流程。
实现示例
历史
2024 年 8 月 21 日 - 初始草案版权
本文所有内容均采用 Apache 2.0 许可。Synopsis
This specification defines the minimal set of properties which must be fulfilled by a state machine hosting an implementation of the interblockchain communication protocol. IBC relies on a key-value provable store for cross-chain communication. In version 2 of the specification, the expected key-value storage will only be for the keys that are relevant for packet processing.Motivation
IBC is designed to be a common standard which will be hosted by a variety of blockchains & state machines and must clearly define the requirements of the host.Definitions
Desired Properties
IBC should require as simple an interface from the underlying state machine as possible to maximise the ease of correct implementation.Technical Specification
Module system
The host state machine must support a module system, whereby self-contained, potentially mutually distrusted packages of code can safely execute on the same ledger, control how and when they allow other modules to communicate with them, and be identified and manipulated by a “master module” or execution environment. The IBC core handlers as defined in ICS-4 must havePaths, identifiers, separators
AnIdentifier is a bytestring used as a key for an object stored in state, such as a packet commitment, acknowledgement, or receipt.
Identifiers MUST be non-empty (of positive integer length).
Identifiers MUST consist of characters in one of the following categories only:
- Alphanumeric
.,_,+,-,#[,],<,>
Path is a bytestring used as the key for an object stored in state. Paths MUST contain only identifiers, constant bytestrings, and the separator "/".
Identifiers are not intended to be valuable resources — to prevent name squatting, minimum length requirements or pseudorandom generation MAY be implemented, but particular restrictions are not imposed by this specification.
The separator "/" is used to separate and concatenate two identifiers or an identifier and a constant bytestring. Identifiers MUST NOT contain the "/" character, which prevents ambiguity.
By default, identifiers have the following minimum and maximum lengths in characters:
| Port identifier | Client identifier |
|---|---|
| 2 - 128 | 2 - 64 |
Key/value Store
The host state machine MUST provide a key/value store interface with three functions that behave in the standard way:queryProof will return a Membership proof if there exists a value for that path in the key/value store and a NonMembership proof if there is no value stored for the path.
The host state machine SHOULD provide an interface for deleting
a Path from the key/value store as well though it is not required:
Path is as defined above. Value is an arbitrary bytestring encoding of a particular data structure. The specific Path and Values required to be written to the provable store are defined in ICS-4.
These functions MUST be permissioned to the IBC packet handler module (the implementation of which is described in ICS-4) only, so only the IBC handler module can set or delete the paths that can be read by get.
In most cases, this will be implemented as a sub-store (prefixed key-space) of a larger key/value store used by the entire state machine. This is why ICS-2 defines a counterpartyCommitmentPrefix that is associated with the client. The IBC handler will prefix the counterpartyCommitmentPrefix to the ICS-4 standardized path before proof verification against a ConsensusState in the client.
Provable Path-space
IBC/TAO implementations MUST implement the following paths for theprovableStore in the exact format specified. This is because counterparty IBC/TAO implementations will construct the paths according to this specification and send it to the light client to verify the IBC specified value stored under the IBC specified path.
Future paths may be used in future versions of the protocol, so the entire key-space in the provable store MUST be reserved for the IBC handler.
| Value | Path format |
|---|---|
| Packet Commitment | 0x1 |
| Packet Receipt | 0x2 |
| Acknowledgement Commitment | 0x3 |
MembershipProof for a key/value pair that exists in the store. It MUST also be capable of providing a NonMembership proof for a key that does not exist in the store.
In the case, the state machine does not support NonMembership proofs; a client may get around this restriction by associating a SENTINEL_ABSENCE_VALUE with meaning the key does not exist and treating a MembershipProof with a SENTINEL_ABSENCE_VALUE as a NonMembershipProof. In this case, the state machine is responsible for ensuring that there is a way to write a SENTINEL_ABSENCE_VALUE to the keys that IBC needs to prove nonmembership for and it MUST ensure that an actor cannot set the SENTINEL_ABSENCE_VALUE directly for a key accidentally. These requirements and how to implement them are outside the scope of this specification and remain the responsibility of the bespoke IBC implementation.
Finality
The state machine MUST make updates sequentially so that all state updates happen in order and can be associated with a uniqueHeight in that order. Each state update at a height h MUST be eventually finalized at a finite timestamp t such that the order of state updates from the initial state up to h will never change after time t.
IBC handlers will only accept packet-flow messages from state updates which are already deemed to be finalized. In cases where the finality property is probabilistically guaranteed, this probabilitic guarantee must be handled within the ICS-2 client in order to provide a final view of the remote state machine for the ICS-4 packet handler.
Time
As the state updates are applied to the state machine over time, the state update algorithm MUST itself have secure access to the current timestamp at which the state update is being applied. This is needed for IBC handlers to process timeouts correctly. If the state machine update mechanism does not itself provide a timestamp to the state machine handler, then there must be a time oracle updates as part of the state machine update itself. In this case, the security model of IBC will also include the security model of the time oracle. This timestamp for a state update MUST be monotonically increasing and it MUST be the greater than or equal to the timestamp that the counterparty client will return for theConsensusState associated with that state update.
Backwards Compatibility
Not applicable.Forwards Compatibility
Key/value store functionality and consensus state type are unlikely to change during operation of a single host state machine.submitDatagram can change over time as relayers should be able to update their processes.