The Interblockchain Communication Protocol: An Overview

1. 引言

Interchain GmbH团队Christopher Goes 2020年发表的论文《The Interblockchain Communication Protocol: An Overview》为Cosmos IBC协议。

The interblockchain communication protocol (IBC) 为 end-to-end、connection-oriented、stateful protocol for reliable, ordered, and authenticated communication between modules on separate distributed ledgers。

IBC设计为 对 未知、动态拓扑、不同共识算法和不同state machine 的 不同链之间的互操作。
IBC为payload-agnostic，并可提供cross-ledger asynchronous communication primitive。

若采用分片方案来实现跨链，为了保证全局safety和liveness，以在shards之间正确路由data和code，需要使用“top-down approach”——构建一种特殊的网络拓扑，通常为a single root ledger and a star or tree of shards, and engineering protocol rules and incentives to enforce that topology。相应实现有波卡的XCMP和以太坊2.0的跨shard通讯。

分片方案简单可预测，但存在保证state transition有效性的技术难题，要求所有shard共用一个validator set（或从该validator set中随机选出subset）以及 一个virtual machine，并存在升级困难问题。
此外，分片方案存在一个问题，若超过容错阈值，需协调进行global halt & restart，可能会引起复杂的state transition rollback流程。

受用于interoperability between hosts in packet-switched computer networks 的TCP/IP协议启发，IBC采用的“bottom-up”方案，制定跨账本互操作所需实现的要求、函数、属性，然后定义多个跨链账本互操作的不同方式。
IBC不需要知道任何网络拓扑信息，仅需实现已知的、有限的函数功能。

IBC内的账本定义为light client共识validation functions，然后可扩展为what a “ledger” can be to include single machines and complex consensus algorithms alike。
IBC实现 可与higher-level modules 以及 host ledger上的协议 共存。

支持IBC的ledger必须提供指定的函数，用于：

• consensus transcript verification
• cryptographic commitment proof generation

同时，IBC packet relayers（off-ledger processes）可访问网络协议和物理data-links，以read the state of one ledger and submit data to another。

IBC packet中的data payload对于协议本身来说是透明的。每个ledger的module可定义相互要发送的packet的语义：

• 对于跨链token transfer来说，packet中可包含 fungible token information，资产会在一个链上锁定，在另一个链上mint。
• 对于跨链治理来说，packet中可包含投票信息，使得一个链上的账号可对另一个链上的治理系统进行投票。
• 对于跨链account delegation，packet中可包含交易授权信息，使得一个链上的账号 可被 另一个链上的账号 控制。
• 对于跨链DEX，packet中可包含订单意图信息或交易结算信息，通过临时托管和一系列数据包，不同ledger上的资产可以在不离开其host ledger的情况下进行交换。

2. IBC Scope

IBC定位为，处理authentication, transport, and ordering of opaque data packets relayed between modules on separate ledgers。
这些ledger：

• 可运行在solo machines上。
• 可replicated by many nodes running a consensus algorithm。
• 可constructed by any process whose state can be verified。

IBC为两链module之间的协议，设计为可在任意多链上的任意数量module之间以任意拓扑连接。

IBC位于modules之间，为modules提供一系列函数功能，与同一ledger内不同module之间的函数接口类似：
基于established connection和channel来发送和接收data packet。开关connection和channel，设置packet delivery可选项等。探测connection和channel状态。

IBC要求底层链具有：

• 特定的功能和属性
• primarily finality (or thresholding finality gadgets)
• cheaply-verifiable consensus transcripts (such that a light client algorithm can verify the results of the consensus process with much less computation & storage than a full node)
• simple key/value store functionality

网络层面，IBC仅要求：

• eventual data delivery — no authentication, synchrony, or ordering properties are assumed

3. IBC Operation

IBC的主要目的是：为运行在不同host ledger上的modules提供可靠的、认证的、有序的communication。这就要求IBC中包含以下逻辑操作：

• data relay
• data confidentiality and legibility
• reliability
• flow control
• authentication
• statefulness
• multiplexing

3.1 Data relay

在IBC架构中，模块之间并不直接通过网络架构传输消息，而是通过monitoring “relayer processes” 来讲消息有一个ledger 物理relay到 另一个ledger。

IBC假设存在一组relayer processes，这些relayer processes可访问底层网络协议栈（类似TCP/IP，UDP/IP 或 QUIC/IP）以及物理连接架构。这些relayer processes会监测一组运行IBC协议的链，持续扫描每个链的状态，当outgoing packets commit时，会要求在另一个链上执行交易。
对于两条链之间正确的操作和流程，IBC仅要求存在至少一个正确且活跃的relayer process，可在两条链之间进行relay。

3.2 data confidentiality and legibility

IBC协议仅需要将少量数据以标准化格式序列化后给relayer process，且链可选择将数据仅给指定的relayers。
数据中包含了：

• 共识状态
• client
• connection
• channel
• packet信息
• 以及其他构建某key/value pair是否包含在state的proof 所需的辅助状态信息。

这些数据必须能向另一条链证明所有数据都是合法的，即其是以两条链达成共识的标准格式序列化的。

3.3 Reliability

网络层 和 relayer processes 可表现为任意状态，如dropping、reordering、duplicating packets，试图发送无效交易或以拜占庭形式工作，这些都不会影响IBC的安全和活性——具体实现方法为，为经由IBC channel传输的每个packet都分配一个序列号，基于该序列号，receiving ledger的IBC handler（ledger在实现IBC protocol时，会实现该IBC handler）会验证该序列号，同时，提供了一个method供sender ledger验证receiving ledger确实收到并处理了该packet，然后sender ledger再决定发送发送更多的packets还是采取进一步措施。

使用密码学commitments来防止伪造datagram：

• sending ledger会对outgoing packets进行commit
• receiving ledger会验证这些commitments，因此，若某relayer在传输过程中修改了该datagram，receiving ledger可发现并拒绝该packet。

同时，IBC还提供了unordered channels，不再强调接收packet的顺序与发送packet的顺序一致，但是仍然遵循一个packet只传输一次的原则。

3.4 Flow control

IBC协议并不提供compute-level或economic-level的flow control。底层的ledger可自己维护计算吞吐量有限的设备和对gas market的flow control。
应用级别的economic flow control，如根据内容限制特定packet的内容，可能有助于保证安全，但可能对拜占庭容错有害。

举例：
某应用通过IBC channel来传递价值，可限制单个block传递的价值rate，从而减少对潜在拜占庭行为的危害。

IBC为modules提供了机制来拒绝packets，一些特殊功能可由上层应用协议实现。

3.5 Authentication

所有通过IBC的数据都是经过认证的：
由sending ledger经共识算法固化的block，必须通过密码学commitment算法commit到outgoing packet中，而receiving ledger的IBC handler必须对接收到的数据验证其consensus transcript以及相应的密码学commitment proof，验证通过后才会对接收到的数据进行处理。

3.6 Statefulness

以上介绍的reliability、flow control和authentication，要求IBC每个datastream初始化并维护特定的状态信息。这些状态信息主要分为3大类：

• clients的信息：包括对方ledger的共识状态信息。
• connections的信息：包括双方ledger在handshake protocol中达成共识的identifier pair信息。
• channels的信息：针对的一个module pair，包含了达成共识的encoding、multiple选项、状态和序列号。

当2个module想要相互通讯，首先找到2个ledger之间已有的connection和channel，若没有，则初始化新的connection和channel。
初始化connection和channel需要多步handshake，一旦完成，可确保2个ledger链接成功。对于初始化connection来说，当handshake完成后，可确保2个module链接成功，与channel类似，后续relay的数据将按要求进行认证、编码、编序号。

3.7 Multiplexing

为了支持单一host ledger的多个module同时使用IBC connection，IBC支持在单一connection中包含任意多个channels。
每个channel唯一标识a datastream，通过该datastream，data packet可有序传输（对于ordered channel），且尽可传输一次，到receiving ledger的目标module。

channel通常关联每个ledger的一个module，但是一对多、多对一的channel也可能存在。

每个connection中包含的channel数是无上限限制的，并发容量仅受限于底层ledger的单一connection的吞吐量，且client pair需跟踪共识信息（对consensus transcript的verification cost可分摊到connection内的所有channel）。

4. Host ledger要求

Host ledger需满足以下要求：

• 1）Module system
• 2）Key/value Store
• 3）Consensus state introspection共识状态自省
• 4）Timestamp access
• 5）Port system
• 6）Exception/rollback system
• 7）Data availability

4.1 Module system

host ledger 必须支持module system，使得相互不信任的代码包可运行在同一ledger之上，控制何时何种方式允许其他module与其通讯，可由controller module或execution environment来标记和操控。

4.2 Key/value Store

host ledger必须提供key/value store接口，支持数据的读、写和删除。

这些函数必须仅许可由IBC handler调用，使得仅有IBC handler module可写 或 删除 特定的path subset。可实现为整个ledger的一个子集。

host ledger必须为该接口提供可证明的示例，使得host ledger的light client算法可验证特定key-value pair的存在或不存在。

该接口不要求特定的storage backend或backend data layout。ledger可根据自身需要配置使用storage backend，只要实现了指定的接口并提供commitment proofs即可。

4.3 Consensus state introspection

host ledger必须提供自查当前height、当前共识状态（host ledger的light client会使用该接口）、最近的一定数量的共识状态（如past headers）。

这些信息可防止 与其他ledger建立connection时握手过程中的中间人攻击。每个ledger需验证对方ledger的认证数据确实使用的是其共识状态。

4.4 Timestamp access

为了支持timestamp-based timeouts，host ledger必须提供当前的Unix格式的timestamp。后续headers的timeout必须是non-decreasing的。

4.5 Port system

host ledger必须实现port system，使得IBC handler可支持host ledger中不同module绑定唯一不同的port。port由identifier标识，且必须是permissioned（许可的）：

• 一旦某module绑定了某port，除非其主动释放，否则其他module将不可绑定该port。
• 一个module可绑定多个port。
• port的分配原则是先到先得。
• 已知module的保留port，在ledger首次启动时会绑定。

以上许可限制可通过每个port的唯一references（object capabilities）、基于源的认证信息（类似以太坊合约中的msg.sender）或 其他访问控制方法来实现，具体取决于host ledger。

port通常为人类不可读标识符-正如特定应用程序的DNS名称解析和标准化端口号一样，可从TCP/IP用户中抽象出IP地址和端口的详细信息。
为了抽象掉具体的ledger identification和port selection，可为特定应用创建ledger name resolution和标准化端口。
可在IBC上很容易构建类似的addressing system，使得通过IBC与该addressing system的initial connection就可name resolution for subsequent connections to other ledger and applications。

4.6 Exception/rollback system

host ledger必须支持exception system或rollback system，使得交易可终止执行并回退到之前的状态（包含同一交易在其他module的状态回退），但是已消耗的gas和支付的交易费不回退。

4.7 Data availability

为了deliver-or-timeout safety，host ledger必须具有eventual data availability，使得状态中的任意key/value pair都最终可由relayer 检索。
为了exactly-once safety，则不要求data availability。

为了保证packet relay的liveness，host ledger必须具有bounded transactional liveness，使得incoming transactions被确认在某block height中，或timestamp bound中（特别地，less than the timeouts assigned to the packets）。

IBC packet data，以及其它依赖relayers而不以Merkle tree 存储的state data，必须对relayer processes可访问且可高效计算。

5. IBC protocol结构

IBC protocol中包含的结构有：

• 1）clients
• 2）connections
• 3）channels
• 4）relayers

5.1 IBC clients

client抽象封装了可实现跨链通信协议的ledger共识算法属性。这些属性是在higher-level协议抽象中高效、安全验证状态的必要条件。
IBC 中用于验证consensus transcript和对方ledger sub-components state 的算法称为“validity predicate”，与Verifier认为正确的状态一起，可形成“light client”（简称为“client”）。

5.1.1 client设计动机

IBC协议中的actor，可为终端用户、链下进程、ledger，需要验证对方ledger的状态更新，该状态更新经由对方ledger的共识算法达成，任何对方ledger共识算法未达成的状态更新都将拒绝。

light client具有该算法即可实现actor功能。

抽象为client可 将接口和需求形式化，便于IBC protocol集成运行新共识算法的新ledger，而light client端算法仅需实现所要求的接口即可。

client通常不会验证状态编号的逻辑，但在特殊情况下，可选择验证部分状态变化，且如果效率允许的话（如通过SNARK压缩）可验证整个状态变更。

此外，IBC light client使用的verification function必须具有finality，使得验证的block一经验证通过，不会被revert。

IBC协议的高层抽象以及上层应用的安全性都依赖于finality属性。

为了兼容比特币使用的PoW共识，client可作为thresholding views of internal, non-finalising client。
此时，采用IBC protocol的module可与probabilistic-finality共识算法交互，针对不同的应用需要不同的finality阈值。

client protocol设计为支持第三方介绍，如：Alice（ledger A的module），想要给Bob（ledger B的module，Alice和Bob相互认识）介绍Carol（ledger C的module，Alice认识Carol，但Bob不认识Carol）。
Alice可利用与Bob已有的channel，发送关于Carol的canonically-serialisable validity predicate，这样Bob就可open a connection and channel with Carol，使得Bob和Carol可直接对话。若有必要，Alice也可将Bob的validity predicate提前告知Carol，这样Carol就知道要接受Bob发来的请求。

client接口支持自定义的runtime validation logic，只要底层ledger可提供合适的gas metering mechanism来charge for compute and storage。
如在支持WASM的host ledger，可在client instance创建时，以WASM函数的形式提供validity predicate和equivocation predicate。

5.1.2 client定义

1）“validity predicate”：为一种透明函数，有client type定义，基于当前共识状态来验证headers。
validity predicate的计算效率应优于 replaying the full consensus算法和state machine for the given parent header and the list of network messages。

2）“consensus state”共识状态：为透明类型，表示a validity predicate的状态。

light client的validity predicate算法 + 特定的共识状态，可用于验证所关联的共识算法达成的状态更新。
共识状态必须以经典方式序列化，使得ledger可验证 对方ledger 确实存储了该特定状态。同时，对方ledger也可自查，查询其自身过去某height的共识状态与另一ledger的client存储的共识状态进行对比。

3）“commitment root”：为inexpensive way for downstream logic to verify whether key/value pairs are present or absent in a state at a particular height。通常将Merkle tree root作为commitment root。

4）“header”：为透明数据结构，由client type定义，提供了更新共识状态所需的信息。可将headers提交给关联的client来更新存储的共识状态。
“header”中通常包含：

• a height
• a proof
• a new commitment root
• 对validity predicate可能的更新

5）“misbehaviour predicate”：为透明函数，由client type定义，用于验证数据中包含了违背共识协议的信息。可为同一高度，2个具有不同state root的签名header，或签名header中包含了无效的状态变更，或其它共识算法中定义的非法行为。

5.1.3 client所需属性

light client必须提供安全算法，使用现有的共识状态来验证其它ledger的经典headers。进一步抽样为，可通过共识状态中存储的commitment root来验证sub-components of the state，commitment root由其他ledger共识算法commit。

validity predicate可反映全节点的行为。全节点会运行相应的共识算法。
已知共识状态和一组消息，若全节点接受了新header，则light client也必须接受，若全节点拒绝，则light client也必须拒绝。

light client并不会replay整个message transcript，因此，当存在共识misbehaviour时，light client的行为可能不同于全节点的。此时，需要生成misbehaviour proof来证明validity predicate和全节点之间的差异，并将misbehaviour proof提交到ledger，使得ledger可以安全地停用light client，使之前的state root失效，并等待更高级别的干预

validity predicate的有效性取决于共识算法的安全模型。如具有a trusted operator set的BFT PoA共识，或 具有a tokenholder set的BFT PoS共识，二者可分别定义不同的阈值，从而导致不同的拜占庭行为。

Client可能有time-sensitive validity predicate，若在指定时间内无header过来（如PoS系统中3周的unbonding周期），则不再可更新该client。

5.1.4 client 验证state

client type必须定义client所跟踪的ledger的内部认证状态。内部实现可能不同（如loopback client可简单直接读取状态，不需要proof）。对外client将需要验签 或 vector commitment proofs。

5.1.5 client实例化举例

client可实现为如下形式：

• 1）Loopback client：本地ledger的loopback client仅直接访问读取本地状态。类似于TCP/IP中的localhost或127.0.0.1。
• 2）Simple signatures client：solo machine的client可 running a non-replicated ledger with a known public key checks signatures on messages sent by that local machine。此时，多签或门限签名都可以。
• 3）Proxy client：验证 another (proxy) ledger’s verification of the target ledger, by including in the proof first a proof of the client state on the proxy ledger, and then a secondary proof of the sub-state of the target ledger with respect to the client state on the proxy ledger。这样proxy client可不用存储和跟踪target ledger的共识状态，代价是，需要增加proxy ledger正确性的安全假设。
• 4）BFT consensus and verifiable state client：最常用最有用的client类型。如采用BFT共识算法的Tendermint、GRANPA、HotStuff，ledger可使用Merklized state tree如IAVL+ tree 或 Merkle Patricia tree。此时，The client algorithm for such instances will utilise the BFT consensus algorithm’s light client validity predicate and treat at minimum consensus
  equivocation (double-signing) as misbehaviour, along with other possible misbehaviour types specific to the proof-ofauthority or proof-of-stake system involved.

5.1.6 client生命周期

client生命周期有：

• 1）creation：Clients can be created permissionlessly by anyone at any time by specifying an identifier, client type, and initial consensus state。
• 2）update：通过提交新的header来更新client，当 a new header is verified with the stored client state’s validity predicate and consensus state, the client will update its internal state accordingly, possibly finalising commitment roots and updating the signature authority logic in the stored consensus state。
  若client不可更新（如超过了unbonding period），则不再允许通过connection和channel给该client发送packet，或将在途的packet都timeout（自此，目标ledger的height和timestamp将不可验证）。必须通过手工干预来重置client state或将connection和channel迁移至另一client。该过程无法自动完成，但是实现了IBC的ledger可支持通过治理机制来执行以上操作（如可为per-client/connection/channel with a controlling multi-signature or contract）。
• 3）misbehaviour：若client发现了misbehaviour证据，该client可采取合适的措施，如使之前的commitment root失效，防止未来的update。具体何为misbehaviour取决于共识算法，validate predicate将验证共识算法输出的有效性。

5.2 IBC connections

“connection”：包含了2个stateful objects（“connection ends”），每个分别对应一个ledger的light client，二者一起可促进跨链sub-state verification 和 通过channel的packet relay。在未知动态拓扑中，使用handshake subprotocol，可安全建立connection。

5.2.1 IBC connection动机

IBC协议为packets提供了授权和排序语义：

• 授权：保证了packet在sending ledger上已commit（根据执行的状态变更，如托管tokens）。
  授权语义由“connection”和“client”定义。
• 排序：保证了在特定顺序中，该packet仅被commit了一次，且以同一序号仅传输了一次。
  排序语义由channel提供。

5.2.2 IBC connection定义

"connection end"为connection一段的ledger的状态跟踪。定义为：

enum ConnectionState {
INIT,
TRYOPEN,
OPEN,
}
interface ConnectionEnd {
state: ConnectionState //描述了connection end的当前状态
counterpartyConnectionIdentifier: Identifier //该connection中对手ledger的connection end identifier 
counterpartyPrefix: CommitmentPrefix //该connection中，用于验证对手ledger状态的前缀
clientIdentifier: Identifier //该connection对应的client identifier
counterpartyClientIdentifier: Identifier //该connection中对手ledger的client identifier
version: string //用于确定该channel中的编码 或 channel协议 或 packet规则。
}

5.2.3 IBC connection opening handshake

opening handshake自协议允许ledger验证connection中另一端ledger的identifier，支持每个ledger的module reason about 另一ledger的reference。

opening handshake中包含了4个datagram：

• ConnOpenInit
• ConnOpenTry
• ConnOpenAck
• ConnOpenConfirm

ledger A和B之间，opening handshake时正确的connection state变化为：（状态格式为$(A,B)$）

opening handshake执行完成后， 以下属性成立：

• 每个ledger都有双方正确的共识状态，由初始发起方指定。
• 每个ledger都知道且认可对方ledger的identifier。
• 每个ledger都知道对方ledger认可相同的数据。

connection handshake可在permissionlessly, modulo anti-spam measures (paying gas) ledger之间安全运行。

• ConnOpenInit：在ledger A上运行。由ledger A初始化a connection attempt，指定a pair of identifiers for the connection on both ledgers，以及a pair of identifiers for exiting light clients (one for each ledger)。ledger A在其state中存储了一个connection end object。
• ConnOpenTry：在ledger B上运行。ledger B验证这些identifiers有效、验证版本兼容、验证a proof that ledger A使用的light client具有ledger B正确的共识状态。ledger A在其state中存储了一个connection end object。
• ConnOpenAck：在ledger A上运行。ledger A验证版本兼容、验证a proof that ledger B存储了与ledger A相同的identifier、验证a proof that ledger B使用的light client具有ledger A正确的共识状态。
• ConnOpenConfirm：在ledger B上运行。ledger B简单验证ledger A已执行ConnOpenAck 且 将connection标记为OPEN，然后ledger B将其connection end标记为OPEN.
  执行完ConnOpenConfirm之后，connection open完成，可立即使用。

5.2.4 IBC connection versioning

在handshake过程中，connection两端 对所关联的version bytestring达成共识。
此时，该version bytestring内容对IBC核心协议是透明的。
未来，可能可用该version bytestring来判定哪种类型的channel可使用该connection。

host ledger使用version data来协商与IBC之上构建自定义逻辑相关的 encodings、优先级、或connection-specific metadata。

host ledger也可直接忽略version data，或者设置为空string。

5.3 IBC channels

“channel”提供了跨链通讯协议传输消息的3种方式：

• ordering 有序消息传输模式
• exactly-once delivery 消息只传输一次模式
• module permissioning 消息只传输给许可的module模式

channel是ledger A module与ledger B module之间传输packet的管道，保证packet仅执行一次，如有必要可按发送顺序有序接收，且仅发送给目标ledger上拥有该channel end的module。

每个channel关联某一特定的connection，每个connection可有任意多个channel，可使用common identifiers，将header verification的开销在使用同一connection和light client的所有channel间进行分摊。

channel为payload不可知的，发送和接收IBC packet的module决定如何构建packet data，如何应对incoming packet data，且必须使用其自己的应用逻辑来决定哪些state transaction对应packet中的哪些数据。

5.3.1 IBC channel 动机

跨链通讯协议使用cross-ledger message passing模式。

IBC packets由外部relayer processes，由ledger A转发到ledger B。
ledger A和ledger B各自独立确认新区块，且packet可能延迟、审查、或以任意顺序重排。

packets对relayer是可见的，可由任意relayer process从ledger读取然后提交到另一ledger。

IBC protocol必须为ordered channel 提供顺序保证，以及只传输一次保证，以支持application来reason about the combined state of connected modules on two ledgers。
如，某应用想要某token资产在多个链之间相互传输，同时保持替代性和供应守恒。使得应用在ledger A上冻结资产，在ledger B上mint资产。
ordering 顺序保证 + 正确的应用逻辑，可保证2 ledger的总供应量不变。

5.3.2 IBC channel定义

“channel”为：s a pipeline for exactly-once packet delivery between specific modules on separate ledgers, which has at least one end capable of sending packets and one end capable of receiving packets。

ordered channel：packet的传输顺序与发送顺序完全一致。
unordered channel：packet可以任意顺序传输，与发送顺序无关。

所有channel都提供exactly-once packet delivery，意味着channel中一端的packet仅传输一次到另一端。

“channel end”：为存储参与ledger channel相关的metadata。

interface ChannelEnd {
state: ChannelState //为chanel end的当前state
ordering: ChannelOrder //标记该channel是ordered还是unordered。此处为枚举类型而不是布尔类型。以便未来支持更多的类型。
counterpartyPortIdentifier: Identifier //该channel end对方ledger的port
counterpartyChannelIdentifier: Identifier //该channel end对方ledger的identifier
nextSequenceSend: uint64 //分开存储，跟踪将发送的下一个packet的序列号
nextSequenceRecv: uint64 //分开存储，跟踪将收到的下一个packet的序列号
nextSequenceAck: uint64 //分开存储，跟踪以下将要acknowledge的packet的序列号
connectionHops: [Identifier] //按顺序存储一组connection identifiers，以及经由此channel的packet传输路径。此时，list length必须为1。未来可能将支持multi-hop channels。
version: string //存储了透明的channel version，在handshake中达成了共识。可决定module级别 的配置，如该channel使用哪种packet编码方式。该verion并不用于IBC core协议中。
}

channel end具有的状态为：

enum ChannelState {
INIT, //刚开始opening handshake时。
TRYOPEN, //对方ledger相应handshake时
OPEN,//完成handshake，可开始收发packet
CLOSED, //关闭，不再用于收发packet
}

packet为由一个module，通过channel，传输至另一module的透明数据，特定的接口定义为：

interface Packet {
sequence: uint64 //对应为发送和接收顺序。具有更早序列号的packet 必须在 具有更晚序列号的packet 之前发送和接收
timeoutHeight: uint64 //表示目标ledger的共识高度，packet处理时间不能超过该高度，否则会标记为time-out
timeoutTimestamp: uint64 //表示目标ledger的timestamp，packet处理时间不能超过该timestamp，否则会标记为time-out
sourcePort: Identifier //sending ledger的port
sourceChannel: Identifier //sending ledger的channel end
destPort: Identifier //receiving ledger的port
destChannel: Identifier //receiving ledger的channel end
data: bytes //为透明值，由相关module定义application 逻辑
}

5.3.3 IBC channel属性

IBC channel具有如下属性：

• 高效性：channel本身并不进行flow control，因此packet的传输和确认速度仅受限于底层ledger的速度。
• 仅传输一次：IBC packet由channel end一端传输至另一端，仅传输一次。其安全性不依赖于网络同步。若一个或2个ledger都halt，packet可能传输次数少于一，但是一旦ledger恢复，该packet会再次传输。
• 有序性：在ordered channel中，packet的收发顺序一致。在unordered channel中，packet的收发顺序可任意。unordered packets，与ordered packets类似，具有独立的timeout标识——以目标ledger的height或timestamp来表示。
• 许可性：channel为对一端某module进行许可操作，在handshake阶段确定，后续不可更改（(higher-level logic could tokenise channel ownership by tokenising ownership of the port）。仅有拥有关联该channel end port的module才可在该channel进行收发。

5.3.4 IBC channel生命周期管理

IBC channel的生命周期动作有：

• 1）Opening handshake
• 2）versioning
• 3）closing handshake

5.3.4.1 IBC channel Opening handshake

ledger A和ledger B之间的channel opening handshake流程为：（状态格式为$(A,B)$）

• ChanOpenInit：在ledger A上运行。由ledger A上的某module发起 对ledger B上某module的channel opening handshake。提供local channel identifier、local port、remote channel identifier、remote port。ledger A会在其状态中存储一个channel end object。
• ChanOpenTry：在ledger B上运行。ledger B会验证ledger A存储了其所声称的identifiers，查找拥有目标port的module，调用该module以检查version是否兼容，并在其状态中存储一个channel end object。
• ChanOpenAck：在ledger A上运行。ledger A会验证a proof that ledger B存储了其所声称的channel metadata，并将该channel end标记为OPEN。
• ChanOpenConfirm：在ledger B上运行。ledger B简单地验证ledger A运行了ChanOpenAck，并将该channel标记为OPEN。至此，channel两端都标记为了OPEN，可立即使用。

当opening handshake完成后，发起handshake的module将在host ledger上锁创建的channel end，另一个ledger拥有对方ledger所创建的channel end。
一旦channel创建完成，仅能通过更改所关联port的所有权来更改所有权。

5.3.4.2 IBC channel versioning

在handshake过程中，2个channel end对该channel相关的version bytestring达成共识。version bytestring的内容对IBC core protocol来说是透明的。

host ledger可利用version data来表达所支持的应用层协议，对packet编码格式，或协商基于IBC之上自定义逻辑相关的channel-related metadata。
host ledger也可安全地忽略该version data 或 将其设为空值。

5.3.4.3 IBC channel closing handshake

ledger A与ledger B之间的channel closing handshake流程为：（状态格式为$(A,B)$）

• ChanCloseInit：运行在ledger A上，关闭ledger A上的channel end。
• ChanCloseConfirm：运行在ledger B上，简单验证ledger A上的channel end已关闭，然后关闭ledger B上channel end。

一旦channel 关闭，channel 中正在传输的packets将timed-out。

channel一旦关闭，不可再重新开启，identifiers也不可复用。禁止identifier复用是为了防止将之前发送的packet进行replay攻击。（ The replay problem is analogous to using sequence numbers with signed messages, except where the light client algorithm “signs” the messages (IBC packets), and the replay prevention sequence is the combination of port identifier, channel identifier, and packet sequence — hence we cannot allow the same port identifier and channel identifier to be reused again with a sequence reset to zero, since this might allow packets to be replayed.）
未来如果支持强制要求timeout of 某特定最大高度或time以及跟踪这些timeout，则可安全复用identifiers。IBC未来协议升级可能会支持。

5.3.5 IBC channel Sending packets

module调用sendPacket函数在该module拥有的channel end上发送IBC packet 到 对方ledger的相应module。

发起module在调用sendPacket的同时，必须配套运行应用相关逻辑。

IBC handler按顺序执行以下操作：

• 1）验证发送packet所需的channel和connection已open。
• 2）验证发起module拥有该sending port。
• 3）验证packet metadata与channel和connection信息匹配。
• 4）验证所设置的timeout height在目标ledger上未过期。
• 5）增加与该channel相关的发送序列号（对于ordered channel需要）。
• 6）在packet data和packet timeout中存储constant-size commitment。

注意，full packet并不存储在ledger state中，仅在ledger state中存储a short hash-commitment to the data and timeout value。packet data可根据交易执行计算，且可以log 输出由relayers index。

5.3.6 IBC channel Receiving packets

为了接收和处理对方ledger在相应channel end上发来的IBC packet，module需要调用recvPacket函数。

接收module在调用recvPacket函数的同时，必须配套自动执行应用逻辑，类似于之前计算的acknowledgement value。

IBC handler必须按顺序执行以下操作：

• 1）验证接收的packet所需的channel和connection已open。
• 2）验证接收module拥有该receiving port。
• 3）验证packet metadata与channel和connection信息匹配。
• 4）对于ordered channel来说，需验证所接收packet的序号为该channel end所期待收到的下一序号。
• 5）验证接收packet中所设置的timeout height未过期。
• 6）验证发送ledger的状态中包含了相应的packet data commitment。（inclusion proof）
• 7）设置 the opaque acknowledgement value at a store path unique to the packet (if the acknowledgement is non-empty or the channel is unordered)。
• 8）对于ordered channel来说，增加该channel end的packet receiving sequence。

在第7）步中，接收module会调用acknowledgePacket函数来处理packet acknowledgement，同时，会清理该packet commitment——由于该packet已接收并处理，不再需要了。
与此同时，接收module会自动执行合适的应用acknowledgement-handling逻辑。

acknowledgement时，IBC handler必须按如下顺序执行：

• 1）验证acknowledge packet所需的channel和connection已open。
• 2）验证调用module拥有该sending port。
• 3）验证packet metadata与channel和connection信息匹配。
• 4）验证该packet确实在channel上已发送。
• 5）对于ordered channel来说，需验证该packet的序号为该channel end所期待收到的下一序号。
• 6）验证接收ledger的状态中包含了相应的packet acknowledgement data 。（inclusion proof）
• 7）删除该packet commitment（清除状态并防止重放攻击）
• 8）对于ordered channel来说，增加next acknowledgement sequence。

5.3.7 IBC channel timeouts

应用语义中可能需要一些timeout：如等待某交易多久，就可判定为存在错误。
由于2个ledger具有不同的local clocks，存在双花问题：
攻击者可推迟the relay of the receipt or wait to send the packet until right after the timeout，因此应用层本身无法安全执行其本地的timeout逻辑。

为了避免可能的双花攻击，timeout算法中要求目标ledger为正在运行且可访问的。timeout必须在接收ledger上可证明，而不是简单的仅针对sending ledger。

IBC channel timeouts需考虑的场景有：

• 1）sending end
• 2）Timing-out on close
• 3）cleaning up

5.3.7.1 IBC channel timeouts——sending end

发起module在尝试发送packet到对方module时，会调用timeoutPacket函数，在packet未commit的情况下，当超过对方ledger的timeout height或timeout timestamp时，用于证明该packet不再可运行，使calling module可安全的执行合适的状态变更。

在调用timeoutPacket函数的同时，calling module可自动执行应用层相关的timeout-handling逻辑。

相应的IBC handler按如下顺序执行：

• 1）验证timeout packet所需的channel和connection已open。
• 2）验证调用module拥有该sending port。
• 3）验证packet metadata与channel和connection信息匹配。
• 4）验证该packet确实在channel上已发送。
• 5）验证a proof that 该packet未在目标ledger上确认。
• 6）验证a proof that 目标ledger已超过相应的timeout height或timeout timestamp。
• 7）删除该packet commitment（清除状态并防止重放攻击）。

对于ordered channel，若某packet超时，timeoutPacket将额外关闭该channel。
对于unordered channel，遇到time-out packets时，channel仍将正常运行。

5.3.7.2 IBC channel timeouts——Timing-out on close

若channel关闭了，在途的packet将永远接收不到，因此可安全地timed-out。

module将调用timeoutOnClose函数来证明，未接收到的packet相应的channel已关闭，该packet将永远接收不到（即使当前未超过timeoutHeight或timeoutTimestamp值）。应用相关逻辑也可安全运行。

5.3.7.3 IBC channel timeouts——cleaning up

若acknowledgement未写（处理acknowledgement时将清理状态），module可调用cleanupPacket来移除存储中的received packet commitment。该receiving end必须已处理完该packet（无论是正常处理 还是 超时）。

对于ordered channel，cleanupPacket会通过证明receive sequence已超过该packet sequence 的方式来清理ordered channel中的packet，
对于unordered channel，cleanupPacket通过证明相应的acknowledgement已写来清理unordered channel中的packet。

5.4 IBC relayers

relayer算法为IBC的“物理”连接层——为链下进程，负责在运行IBC协议的2个ledger之间转发数据，实现方式为分别扫描每个ledger的state，构建合适的datagrams，并在对方ledger上执行。

5.4.1 IBC relayer 动机

在IBC协议中，ledger A仅记录发送特定data到ledger B的动机——并不直接访问网络传输层。

physical datagram必须由可访问传输层（如TCP/IP）的链下基础设施来转发。该标准定义了relayer算法，可在链下进程中运行，可访问链上状态，并进行数据转发。

relayer为链下进程，具有读取链上state的能力，同时利用IBC协议将交易提交到其它链。

5.4.2 IBC relayer属性

IBC relayer具有如下属性：

• IBC的exactly-once 和 deliver-or-timeout safety属性不依赖于relayer的行为（假设relayer为拜占庭容错的）
• IBC packet relay liveness属性 仅依赖于 招收存在一个正确的、活跃的relayer。
• relay为公开无需许可的，所有验证都由ledger自身进行。
• IBC user与relayer之间的通讯需求为最小化的。
• 在core protocol中未规定relayer激励，但在应用层可能需要考虑relayer激励。

5.4.3 IBC relayer基础relayer算法

实现了IBC protocol的多个ledger之间的relayer算法：
每个relayer并不需要可读写所有ledger的datagram（特别是针对许可或私有链）——不同的relayers可在不同的ledger subsets之间进行relay。

每隔一段时间，尽管频率不超过每个ledger的一个block频度，基于2个ledger的状态，relayer会计算所有valid datagrams set，将该set由一个ledger relay到另一个ledger。

relayer必须提前知道关于 what subset of the IBC protocol is implemented by the ledgers in the set for which they are relaying 的信息（如通过读取源代码）。

datagrams可作为单笔交易单独或自动提交。

不同的relayers可在不同的ledgers之间进行relay——只要每组ledger至少具有一个正确活跃的relayer且ledger也保持活跃，通过网络在ledger之间传输的packets最终都将被relay。

5.4.4 IBC relayer中的packets，acknowledgements和timeouts

5.4.4.1 在ordered channel中relay packets

在ordered channel中的packets，必须以event-based 或 query-based的方式转发。

• event-based转发：relayer需监听源ledger释放的packet发送的events，然后利用event log中的数据来组装packet。
• query-based转发：relayer需定期查询源ledger的send sequence，并维护最后转发的序列号，使得二者之间的差异即为需要查询和转发的packet。

无论是哪种转发方式，relayer都需要检查目标ledger的receiving sequence来判定哪些packet未收到，然后转发相应的packet。

5.4.4.2 在unordered channel中relay packets

对于unordered channel，以event-based转发更容易。
relayer需监听源ledger中packet sent释放的event，然后利用event log中的数据组装packet。

随后，relayer将检查目标ledger上 是否已存在该packet的序列号对应的acknowledgement来 判定是否已接收了该packet，若不存在该packet序列号的acknowledgement，则转发该packet。

5.4.4.3 relaying acknowledgements

对于acknowledgement，以event-based转发更容易。
relayer需监听目标ledger 接收packet所释放的event 以及 写acknowledgement时释放的event，然后使用event log中的数据来组装acknowledgement，检查在源ledger上是否仍存在该packet commitment（当acknowledgement转发后，将删除该packet commitment），若packet commitment存在，则将该acknowledgement relay到源ledger上。

5.4.4.4 relaying timeouts

timeout relay稍微更复杂点，因为packet timeout时，不会释放特定的event。由于已超过目标ledger上的timeout height 或 timeout timestamp，此时，该packet将不再被转发。
relayer进程必须选择跟踪一组packets（通过扫描event logs来构建），一旦这组跟踪的packet已超过了目标ledger的height或timestamp，则relayer会检查源ledger上的packet commitment是否仍存在（当timeout转发后，这些packet commitment必须立即删除），若存在，则将该timeout转发到源ledger。

5.4.4.5 ordering constraints

relayer进程中存在潜在的ordering constraints，以决定提交的datagrams的顺序。

如，为了固化所存储的共识状态，需先提交a header。在转发packet之前，必须先提交light client中特定高度的commitment root。

relayer进程会负责定期查询其负责relay的ledgers的状态，以此来决定何时转发何物。

5.4.4.6 bundling

如果host ledger支持，relayer进程可将多个datagrams打包为一笔交易，在该交易中，各datagram会顺序执行，并分摊任何开销（如验签所支付的手续费等）。

5.4.4.7 race conditions

对同一组modules和ledgers进行转发的多个relayer可能会同时尝试转发同一packet（或提交同一header）。若有2个relayer同时转发同一packet，则第一笔交易将成功，第二笔交易将失败。

relayer必须能处理这种 relayers或actors（发送原始packets）之间带外协调。

5.4.4.8 incentivisation

relay进程必须能访问2个ledger的账号，并具有足够的金额来支付交易费。relayer必须采用应用层办法来收回这些费用，如在packet data中包含一部分给自身的费用。

任意数量的relayer进程可安全地并行运行（事实上，希望不同的relayers为多ledger网络中的不同子集服务）。但是，若对同一proof提交多次，这将导致消耗不必要的费用，因此需要一些最小化协调（给特定的relayers分配特定的packets，或扫描mempools来获取pending交易）。

6. IBC应用模式

6.1 call receiver

IBC handler为对运行在同一ledger上的其它module的功能接口，使得其可接受发送packet请求，以及将incoming packets路由到特定module。

IBC handler接口应尽可能小，从而减少host ledger的实现复杂度。

为此，核心的IBC逻辑采用receive-only call模式，不同于直观的dataflow模式。

modules调用IBC handler来创建connections/channels，以及发送packets。

若需接收来自另一ledger的packet、选择或调用其它合适的module时，module本身必须调用IBC handler的recvPackect函数（类似于接受channel creation handshakes）。
当recvPacket被调用，IBC handler将检查calling module已获得授权来接收和处理该packet（基于included proof和known state of connections/channels），执行合适的状态更新（增加序列号来防止重放攻击），返回control to the module或throw on error。

IBC hanlder永远不会直接调用module。 这尽管有点反直觉，但是具有如下明显的优势：

• 1）将host ledger的要求降至最低，由于IBC handler不需要理解如何调用其它module，也不需要任何对其它module的引用。
• 2）避免了在handler state中管理module lookup table。
• 3）避免了对module返回的数据或错误的处理。若某module不想要接收packet（或者需要额外授权），其仅需要永远不调用recvPacket即可。若路由逻辑在IBC handler中实现，则handler需处理module故障，这将很难解释。

同时，具有一个明显的缺点：
没有额外的抽象，relayer logic变得更复杂，因为链下relayer进程需要跟踪多个module的状态，以决定何时提交packets。

基于以上缺点，ledger可额外实现一个IBC “routing module”，来提供a call dispatch interface。

6.2 call dispatch

对于通用转发模式，“IBC routing module”中将维护a module dispatch table，从而简化relayers的工作。

在call dispatch模式下，datagrams（其中包含了host ledger定义的交易类型）将直接转发到routing module，然后routing module会查询合适的module（拥有datagram中指定的channel和port） 并 调用合适的函数（该函数必须提前注册到routing module中）。这种方式可避免module直接处理datagrams，使得收发packet时，atoic状态变更执行出现意外错误的概率更低（因为module永远不直接处理packets，而是提供可由routing module调用的函数接口）。

此外，routing module可实现default logic for handshake datagram handling （代表module来接受incoming handshake），对于module来说，其不再需要自己实现相应的自定义逻辑。

7. IBC应用层module示例

本节定义了通过不同ledger的2个module之间的IBC channel进行fungible token传输所需的packet数据结构和状态机处理逻辑。

状态机逻辑支持通过公开无需许可的open channel进行安全的多链token转移。该逻辑中包含了a “fungible token transfer bridge module”，连接 IBC routing module 和 host ledger上的现有资产跟踪module。

7.1 fungible token跨链转移动机

用户想在ledger B上使用ledger A上的某资产。ledger A和ledger B通过IBC protocol连接。可：

• preserves asset fungibility
• preserves asset ownership
• limits the impact of Byzantine faults
• requires no additional permissioning

7.2 fungible token跨链转移属性

fungible token跨链转移 需 满足如下属性：

• Preservation of fungibility (two-way peg)
• Preservation of total supply (constant or inflationary on a single source ledger and module)
• Permissionless token transfers, no need to whitelist connections, modules, or denominations
• Symmetric (all ledgers implement the same logic)
• Fault containment: prevents Byzantine-inflation of tokens originating on ledger A, as a result of ledger B’s Byzantine behaviour (though any users who sent tokens to ledger B may be at risk)

7.3 fungible token跨链转移 packet 定义

仅有一种packet数据类型：FungibleTokenPacketData，定义了denomination、数量、发送account、接收account、sending ledger是否为该资产源：

interface FungibleTokenPacketData {
denomination: string
amount: uint256
sender: string
receiver: string
}

acknowledgement数据类型描述了转移是否成功，（若失败）以及失败的原因：

interface FungibleTokenPacketAcknowledgement {
success: boolean
error: Maybe<string>
}

7.4 fungible token跨链转移 packet处理语义

协议逻辑是堆成的，发起ledger上的denomination可转换为另一ledger上的凭证，反之亦然：

• 对于源ledger，bridge module会托管send ledger本地现有资产denomination，并在receiving ledger上mint相应的代币券。
• 对于sink ledger，bridge module将销毁send ledger本地的代币券，然后解托管receiving ledger上的本地资产denomination。
• 当packet time-out时，sender的本地资产将解托管，或，mint出的券将返回给sender。
• acknowledgement数据用于处理故障，如无效的denomination或无效的目标账号。返回故障acknowledgement可终止交易，因为send ledger可基于返回的故障信息采取合适的动作。

以上实现保留了fungibility和supply。

若token已发送到对方ledger，等额token可赎回至源ledger。两个ledger上未锁定token的总额是保持为常量的，因为每组send-receive pair都会lock和mint相同的数量。

7.5 fungible token跨链转移 fault containment

fungible token跨链转移 应具有一定的容错机制。

可能存在2种故障方式：

• 运行共识算法的全节点 与 light client 背离
• ledger状态机的托管&代币券逻辑可能实现得不对（无论是偶发 还是 有意的）

共识背离最终将作为misbehaviour证据，用于冻结client，但是不会立刻生效（因为无法证据会在更多packets之前提交），因此从协议目标的角度来看，需要以相同的方式来隔离故障。

无法保证资产可恢复性——用户选择将资产转移出ledger，就要承担目标ledger失败的风险。但是在接口层面可实现容错逻辑，通过跟踪每种资产的incoming supply和outgoing supply，保证任一ledger都无法赎回超过其托管的金额。

本质上，特定的channel可看做是账号，channel一端的module不可花费超过其受到的金额。

由于isolated Byzantine sub-graphs of a multi-ledger fungible token transfer system will be unable to transfer out any more tokens than they had initially received, this prevents any supply inflation of source assets, and ensures that users only take on the consensus risk of ledgers they intentionally connect to.

7.6 fungible token跨链转移 多链转移path

协议本身并不直接处理“diamond problem”——用户将token由ledger A发送到ledger B，然后再到ledger D，然后经由path D->C->A 返回，由于supply由ledger B跟踪（代币denomination将为“{portD}/{channelD}/{portB}/{channelB}/denom"）。
由于以上容错机制要求，ledger C不可作为中介。

赎回路径越长，复杂度也随之增加，可能会在网络拓扑中出现central ledgers 或者 自动做市商来交换不同赎回路径的资产。

为了跟踪ledger网络中不同路径上的所有denomination，因此对于某特定ledger，可实现一个注册表来跟踪每个denomination的“global” source ledger。

终端用户服务提供商（如钱包），可继承这种注册表 或自己维护经典的源ledger和人类可读名称，以提升用户体验。

8. IBC测试及部署

在Cosmos SDK中以Go语言实现了完整版本的跨链协议。

采用IBC并不要求连接Cosmos Hub，可使用任何token，或者任何Cosmos软件，IBC可在其它状态机架构（如Substrate）上实现，或任何独立的ledger采用自定义逻辑来实现。