Cosmos IBC

Posted mutourend

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Cosmos IBC相关的知识，希望对你有一定的参考价值。

1. 引言

IBC（Inter-Blockchain Communication）协议用于链之间 以及 rollup之间 通讯。
IBC协议是Cosmos中最核心的接口协议，能够实现区块链间跨链消息的可信、可靠转发，并有效进行流量控制、多路复用等功能。
在Cosmos中，每个功能都是高度模块化的，每个功能通过加载不同的模块来实现。

IBC为 an interoperability protocol for communicating arbitrary data between arbitrary state machines。
IBC提供了an end-to-end, connection-oriented, stateful protocol for reliable, ordered, and authenticated communication between heterogeneous blockchains or off-chain protocols (rollups), and can accomodate for both known and dynamic validator topologies。

Cosmos中的IBC module，定义了how packets and messages are constructed to be interpreted by the sending and receiving blockchain。
IBC relayer let you connect between sets of IBC-enabled chains。

IBC可用于构建跨链应用，包括但不限于：

  • token transfers
  • interchain accounts (delegate calls between two chains)
  • non-fungible token transfers
  • oracle data feeds

IBC协议安全需要共识算法的最终性来防止双花，不同共识算法的最终性表现不一样：

  • Tendermint和PBFT类共识算法满足即时最终性（最理想）
  • 以太坊的Casper FFG共识算法提供快速最终性
  • 比特币类共识算法（PoW, Tezos）提供概率最终性，需要应用层选择安全阈值

IBC是属于Cosmos-SDK中一个特殊模块。之所以特殊，主要体现在IBC提供了区块链之间的跨链能力。
如果A链上的Alice需要发送10个ATOM代币到B链上的Bob上，会经过下面4个步骤：

  • 1）Tracking：A链上的IBC模块会不断的同步B链上的区块头信息，B链上的IBC同理。通过这种方式，双方能够实现跟踪对方区块链上的验证者集合的变化，本质上来说，就是A链、B链相互维护了一个对方的轻节点。

  • 2）Bonding；当使用IBC初始化一笔跨链转账之后，A链上的10个ATOM事实上处于锁定的状态。

  • 3）Proof中继：一份证明A链上已经锁定10 ATOM的“证据”会被路由到B链上的IBC模块。

  • 4）Verify：B链结合A链的轻节点信息，对这份“证据”验证通过之后，B链上会“铸造”10份ATOM Voucher（抵用券），这些Voucher可进行后续的流通使用。这些Voucher也可以通过统一的跨链方式返回到A链，A链上的ATOM代币相应执行解锁的操作。

以一次完整IBC协议的握手和通信流程为：

以 token transfer为例，其token packet生命周期为：

IBC的目标是在两个独立的七层网络之间传递应用信息，所以需要链外的relayer把数据包在链A和链B的网络之间做中继。链B收到链A的数据后必须能独立验证它所包含的证明信息，该证明代表了链A上的某个状态（及其对应操作）的真实性。为了让IBC协议能够工作，必须依赖基础的信任机制，要相信链A和链B里各自的共识算法，也要相信轻客户端验证，通过对区块头信息的验证，证明在区块链上曾经发生过的事情。

（1）Connection连接的生命周期

  • 1.1 建立连接
    在两条链之间首先要建立“连接”，也就是彼此的初始信任关系；在连接建立的那一瞬间两条链要交换基础的信任数据（信任根）-- 对PoS网络来说就是两条链的验证人公钥集，信任根必须是可以由第三方独立验真的。
  • 1.2 保持连接
    在整个连接期间要持续不断获得对方的新区块头，基于信任根和连续的区块头，可以从连接建立时对方的区块高度，连续验证后续任意高度区块头的正确性；这些区块头是验证IBC数据包的信任基础。
  • 1.3 断开连接
    当出现分叉或安全事件的时候，要及时关闭连接；这可以通过链上治理或自动作弊检测来触发。

IBC会处理如下信息：

  • 1）基于connection，处理the creation of a handshake。
  • 2）authentication、transport、ordering（TAO）of opaque data packets relayed between modules on separate ledgers。

Ledgers：

  • 可运行在solo machine上
  • 可通过共识算法replicated by many nodes
  • 可constructed by any process whose state can be verified。

IBC协议设计为，可在任意多数量的module之间、以任意拓扑连接的任意数量的账本之间，进行安全仿真。

核心IBC逻辑相关实现有：

a module想要interact over IBC，需要满足以下要求：

  • Bind to one or more ports
  • Define the packet data
  • Define optional acknowledgement structures and methods to encode and decode them
  • Implement the IBCModule interface

IBC中包含的主要元素有：

  • 1）Clients
  • 2）Connections
  • 3）Proofs and Paths
  • 4）Capabilities
  • 5）Ports
  • 6）Channels
  • 7）Packets
  • 8）Receipts and Timeouts
  • 9）Acknowledgements

1.1 Clients

Clients：IBC clients为light client，具有唯一的client id。IBC clients会跟踪其他链的consensus state，也会跟踪其他链的proof specs，这些proof specs可properly verify proofs against the client’s consensus state。

a client可be associated with any number of connections to multiple chains。当前支持IBC的clients分类有：

当前的IBC client的开源实现主要有：

IBC client 针对联盟链企业应用场景的实现有：

1.2 Connections

Connections：Connections中为2个不同链封装了2个ConnectionEnd对象。每个ConnectionEnd对象关联对方链的一个client。connection握手会负责验证每个链上的light client are correct for their respective counterparties。Connection一旦建立，将负责所有跨链IBC state的验证。每个Connection可关联任意多个channels。

1.3 Proofs and Paths

Proofs和Paths：IBC中，链之间并不会通过网络直接进行消息传输：

  • 1）为了通讯，链A需commit some state to a precisely defined path reserved for a specific message type and a specific counterparty（如链B）。如，链A中存储了a specific connectionEnd as part of a handshake or a packet intended to be relayed to a module on the counterparty chain。
  • 2）relayer进程会监控这些paths的更新，并relay messages by submitting the data stored under the path along with a proof of that data to the counterparty chain。
    3）所有IBC实现的paths必须支持ICS-24 host requirements中定义的committing IBC messages。
    4）所实现的proof format需遵循ICS-23 implementation。

1.4 Capabilities

Capabilities：IBC设计的运行环境为，模块之间无需相互信任。IBC必须鉴定module actions on ports and channels，使得仅有合适权限的模块可使用相应的channels。
其安全性通过dynamic capabilities来实现。
通过为某模块绑定一个端口 或 创建一个channel，IBC会返回a dynamic capability that the module must claim to use that port or channel。绑定策略可防止其它模块使用该端口，channel策略可保证其它模块不具有合适的capability。
对于IBC应用开发者来说，其仅需要关注这些port和channel即可。可将IBC applications作为self-contained modules。链A上的模块可与链B上的模块之间，可通过以(channelID, protID)唯一标识的channels，发送、接收、确认packets。
可将IBC modules看成是电脑上的internet app。将channel抽象为IP connection，IBC portID抽象为IP port，IBC channelID抽象为IP address。A single instance of an IBC module can communicate on the same port with any number of other modules and IBC correctly routes all packets to the relevant module using the (channelID, portID) tuple. An IBC module can also communicate with another IBC module over multiple ports by sending each (portID<->portID) packet stream on a different unique channel.

1.5 Ports

Ports：一个IBC module可绑定任意多个ports。每个port必须以portID唯一标识。由于IBC设计为同一账本之上 相互不信任的模块间通讯仍是安全的。绑定端口会返回the dynamic object capability。为了在指定端口上take action，如open a channel with its portID，模块必须给IBC handler提供相应的dynamic object capability。这样可防止malicious module为其不拥有的port开启channel 。
IBC modules are responsible for claiming the capability that is returned on BindPort.

1.6 Channels

Channels：可在2个IBC ports之间建立IBC channel。A port is exclusively owned by a single module。IBC packets通过channel传输。与IP packets中 包含目标IP地址、目标IP port、源IP地址、源IP port类似，IBC packets中包含了 目标portID、目标channelID、源portID、源channelID。IBC packets这种格式设计，可保证IBC可正确地将这些packets路由到目标module，同时使得接收module知道该packet的sender module。

  • channel可设置为是ORDERED有序的，即the packets from a sending module must be processed by the receiving module in the order they were sent。
  • 推荐将channel设置为UNORDERED，使得packets from a sending module are processed in the order they arrive, which may not be the order the packets were sent。

Modules可选择其想要通讯的channels。IBC希望modules实现callbacks that are during the channel handshake。这些回调函数可实现一些channel initialization logic。
若返回错误，则channel握手失败。在回调函数中返回错误，modules可programmatically reject and accept channels。

channel握手分为4步。比如，链A想要 基于已建立的connection 与 链B 开通一个channel：

  • 1）链A发送ChanOpenInit消息来signal a channel initialization attempt with 链B。
  • 2）链B发送ChanOpenTry消息来try opening the channel on 链A。
  • 3）链A发送ChanOpenAck消息来mark its channel end status as open。
  • 4）链B发送ChanOpenConfirm消息来mark its channel end status as open。

若以上动作都成功，则channel is open on both sides。在以上握手的每一步中，关联ChannelEnd的module都会执行该步中的回调函数。如ChanOpenInit时，链A上的module会执行其回调函数OnChanOpenInit。

dynamic capabilities中包含了ports信息，channel初始化时会返回a dynamic capability that the module must claim so that they can pass in a capability to authenticate channel actions like sending packets。The channel capability is passed into the callback on the first parts of the handshake: OnChanOpenInit on the initializing chain or OnChanOpenTry on the other chain。

1.7 Packets

module之间通过相互发送packets over IBC channels来通讯。
所有的IBC packets中包含了：

  • 目标portID
  • 目标channelID
  • 源portID
  • 源channelID

以上信息可让module知道某packet对应的sender module。

此外，IBC packets中还包含了：

  • A sequence to optionally enforce ordering
  • TimeoutTimestamp and TimeoutHeight
    若为非零值，则timeout values会determine the deadline before which the receiving module must process a packet。若the timeout passes without the packet being successfully received, the sending module can timeout the packet and take appropriate actions。

Modules相互发送custom application data inside the Data []byte field of the IBC packet。对于IBC handlers来说，Packet data是完全透明的。sender module 必须将其 application-specific packet information encode到packets中的Data field。receiver module必须将该Data field decode back to the original application data。

1.8 Receipts and Timeouts

由于IBC运行在分布式网络中，可能需要依赖faulty relayers来relay messages between ledger，IBC必须能处理 a packet does not get sent to its destination in a timely manner or at all。Packets中必须设置timeout height 或 timeout timestamp，若超过该timeout值，则该packet不再可successfully received on the destination chain。

若超时，则a proof-of-packet timeout必须提交到源链，然后源链可perform application-specific logic to timeout the packet, perhaps by rolling back the packet send changes (refunding senders any locked funds, and so on)。

  • 对于ORDERED channels：若channel中的某个packet超时，则该channel会关闭。若第 n n n个packet time out，则第 k > n k>n k>n的packet都不可successfully received without violating the contract of ORDERED channels that packets are processed in the order that they are sent。
    由于ORDERED channels强化了该不变量，a proof that sequence n n n hasn’t been received on the destination chain by packet n n n's specified timeout is sufficient to timeout packet n n n and close the channel。
  • 对于UNORDERED channels：packets可以任意顺序接收。IBC为其收到的每个sequence写a packet receipt。该receipt中不包含任何信息，仅仅作为a marker intended to signify that the UNORDERED channel has received a packet at the specified sequence。若UNORDERED channel内某个packet超时了，会触发the application specific timeout logic for that packet，并不会关闭该channel。
    因此，大多数modules都推荐使用UNORDERED channels，因为其require less liveness guarantees to function effectively for users of that channel。

1.9 Acknowledgements

当处理a packet时，modules还会写application-specific acknowledgements。

acknowledgements有2种方式：

  • 1）Synchronously on OnRecvPacket：若module一收到来自IBC module的packet，就对该packet进行处理时。
  • 2）Asynchronously：若module收到packet后，会稍晚再对该packet进行处理。

与packet中的Data类似，acknowledgement data对于IBC来说也是透明的。IBC会将acknowledgement data当成简单的byte string []byte。receiver modules 必须 encode their acknowledgement 使得 sender module can decode it correctly。具体对acknowledgement 的encode方式可在channel handshake时沟通确定。

acknowledgement中encode了如下信息：

  • 该packet是否处理成功或失败；
  • 额外的信息，使得sender module可take appropriate action。

当receiving chain写完acknowledgement之后，relayer可将该acknowledgement relay back到原始的sender module，然后原始的sender module可executes application-specific acknowledgment logic using the contents of the acknowledgement。该acknowledgement 可包含 rolling back packet-send changes in the case of a failed acknowledgement (refunding senders)。

当原始sender chain成功收到该acknowledgement之后，IBC module会将相应的packet commitment删除，因为不再需要该packet commitment了。

2. Relayer

现有的Cosmos relayer拓扑可查看：

在IBC架构中，区块链之间并不会通过网络架构相互直接发送消息，而是，创建要发送的消息，然后将该消息通过通过monitoring “relayer processes”，由一个ledger 物理转发 relay到 另一个ledger。

IBC假设有一组relayers，这些relayer可访问底层网络协议栈（类似TCP/IP, UDP/IP 或 QUIC/IP），并且这些relayers是物理网路相连的架构。

这些relayers可持续扫描实现了IBC协议的账本状态，当有packets时，会relay这些packets。当relayed outgoing packets被committed之后，相应的交易会在连接的账本上执行。

Relayers无法修改IBC packets，因为receiving chain的light-clients会在commit之前，验证每个IBC packet。任何人都可运行relayers，并可获得一小部分交易费作为激励，具体比率取决于不同的账本。

当前的relayers实现主要有：

2.1 Events

当base application在处理每笔交易时，会释放events，以反应clients可能关心的逻辑运行。当relaying IBC packets时，这些events尤其重要。任何使用IBC的消息都将 emit events for the corresponding TAO logic executed。

在Cosmos SDK中，为每个消息释放的event中包含了：

  • 1）type message
  • 2）attribute key action
  • 3）attribute value：代表 the type of message sent （channel_open_init would be the attribute value for MsgChannelOpenInit）。若a relayer queries for transaction events, it can split message events using this event Type/Attribute Key pair。

对于单一message，由于application callbacks的原因，Event Type message + Attribute Key module可能会释放多次。可认为any TAO logic executed will result in a module event emission with the attribute value ibc_<submodulename> (02-client emits ibc_client)。

3. Governance Proposals

特殊情况下，高净值client可能会由于不可控隐私冻结。该高净值client可能有数百个激活在用的channel，这些channel内可能有大量的locked tokens used for ICS 20。

若该高净值client所在链上，有多于1/3的validator勾结，这些勾结的validator可对2个valid但有冲突的header进行签名，这2个valid但有冲突的header 各自分别由1/3忠诚的validator签名。此时，light client可在同一height更新这2个有效但有冲突的header。light client 不知道哪个 header is trustworthy and therefore evidence of such misbehaviour is likely to be submitted resulting in a frozen light client。

冻结的light client在任何情况下都无法更新，除非通过治理提案。一定数量的validator可对任意state roots进行签名，治理提案可降低解冻的复杂性。

若trusting period passed since their last update，Tendermint light clients可能会过期。原因是relayers停止submitting headers to update the clients。

对手链计划外的升级也可能导致client过期。An unplanned upgrade by the counterparty chain may also result in expired clients. If the counterparty chain undergoes an unplanned upgrade, there may be no commitment to that upgrade signed by the validator set before the chain-id changes. In this situation, the validator set of the last valid update for the light client is never expected to produce another valid header since the chain-id has changed, which will ultimately lead the on-chain light client to become expired.

当高净值client冻结、过期、或无法正常更新，可提交提案来更新该client——又名subject client。该提案中包含了：

  • the client identifier for the subject
  • the client identifier for a substitute client
  • an initial height to reference the substitute client from

light client可实现自定义的更新逻辑，但大多数情况下，若提案通过，subject的更新信息来自于substitute client。当subject on trial时，substitute clients会作为“stand in”。因此，实际操作时，最好在subject冻结之后创建substitute client，以避免substitute client也被冻结。active substitute client支持在投票期间提交headers，以防止accidental expiry once the proposal passes。

4. IBC应用

IBC当前的应用案例主要有：

  • 1）ICS20-Fungible Token Transfers：ibc-go, cw20。
  • 2）ICS27-Interchain Accounts：encode then execute a transaction from blockchain A on blockchain B in ibc-go。
  • 3）ICS29-Fee Middleware：激励ibc-go中的packet relaying。
  • 4）Cross Chain Validation：将以下PoS state machine功能逻辑的全部或部分运行在一条或多条链上。一条或多条链可 通过IBC跨链 接收并relay与PoS相关的信息（如validator set更新，proofs-of-misbehaviour等等）。
    将PoS state machine的功能切分为：
    • picking validator sets
    • tracking validators
    • tracking delegations
    • locking collateral
    • disbursing rewards
    • punishing misbehaviour等等。
  • 5）Oracle Data Module （由Band Protocol实现）：该协议支持其他兼容IBC的链从BandChain请求数据。
  • 6）TIBC（许可/企业 IBC）NFT Module（由Bianjie实现）：在协议允许在支持TIBC的链之间进行NFT传输。

参考资料

[1] IBC Overview
[2] IBC Protocol
[3] 跨链协议IBC概述
[4] Inter-Blockchain Communication: Basics

以上是关于Cosmos IBC的主要内容，如果未能解决你的问题，请参考以下文章

跨链Cosmos之“跨链交互协议IBC”前言

跨链Cosmos之“跨链交互协议IBC”

interlay： IBC bridge BTC to Cosmos

跨链Cosmos同构跨链交易流程

[活动预告] Substrate 中的 IBC 跨链模块技术分享 Substrate-ibc

跨链跨链双雄Cosmos“系统框架”