How Cosmos’s IBC Works to Achieve Interoperability Between Blockchains
As the commercialization of products and services built with blockchain technology progresses, there is a soaring demand for blockchain interoperability. There are a couple of ways to connect multiple blockchains, and IBC, Inter-Blockchain Communication, is one of them.
Datachain has worked on researched and developed modules and frameworks that make it possible for multiple heterogeneous blockchains to connect to each other via IBC. We have contributed part of the modules to Hyperledger, and it is now called “YUI.”
So, what is IBC? How does IBC allow interoperability between blockchains? In this article, I will go through the architecture and primary components of IBC, including IBC/TAO and IBC/APP. Finally, I will explain how to realize cross-chain token transfer as an example.
[update: August 2022]
We unveiled a new product, LCP, which is a proxy middleware for light client verification to realize trust-minimized and gas-efficient cross-chain bridges that support the IBC protocol. Find out more from the link below.
IBC Overview
IBC is a protocol for interoperability between different ledgers. It is being designed and implemented as a core component of the Cosmos network, where multiple tendermint based or non-tendermint based ledgers connect to each other. Theoretically, any blockchains can connect to and communicate with each other via IBC. IBC is standardized as the Inter-chain standard (ICS) at https://github.com/cosmos/ibc.
IBC Architecture
IBC is a layered protocol that consists of the following two layers:
- the lower transport, authentication and ordering layer (IBC/TAO)
- the upper application layers built on top of TAO (IBC/APP)
Most of the hard work in implementing IBC exists in the TAO layer. Once a TAO layer is implemented for a target ledger, different APP layer protocols can be easily implemented on top of it.
IBC/TAO
IBC/TAO is a layer for relaying packets between two blockchains in a reliable, ordered and authenticated manner.
“Reliable” means that only a packet that is exactly sent by a source chain is received by a destination chain exactly once *with no need to trust any third party*. In fact, blockchains themselves never communicate with other blockchains. Thus a “relayer” is needed to relay packets from one to another, but the role of relayer is permissionless; that is, anyone can run relayers.
“Ordered” means that a destination chain receives packets in the same order in which a source chain sends the packets.
“Authenticated” means that IBC uses “channel” abstraction described later when relaying packets and that each end of a channel is exclusively assigned to a specific smart contract. Thus, if a packet is received by a destination chain via a channel, it proves that a specific smart contract assigned to the channel on a source chain sent the packet and that any other smart contracts can never use the channel to send packets.
IBC/TAO is implemented as smart contracts that operate on both blockchains connected to each other via IBC, and the smart contracts are called “IBC/TAO modules.” IBC/TAO module consists of the following components:
- On-chain light client
- Connection abstraction
- Channel abstraction
The on-chain light client is a basis for IBC/TAO, which verifies that presented states actually exist on an opposite blockchain without relying on any trusted third parties. On top of that, connection abstraction and channel abstract are defined and used to connect two smart contracts on two blockchains and to relay packets between them.
On-Chain Light Client
Syntax and semantics of on-chain light clients in IBC/TAO are standardized in ICS-2. The following is an overview of this component.
Whenever a new block header is appended to an opposite blockchain, a relayer queries for the header and submits it to the IBC/TAO module on a local blockchain. Then the IBC/TAO module executes the light client protocol according to the opposite blockchain to check whether the block header is valid or not and updates its *ClientState* mirroring the opposite blockchain only if the block header is valid.
Once *ClientState* is updated to have the latest block header of the opposite blockchain, the IBC/TAO module can check if a presented state is stored in the opposite blockchain. For example, if the opposite blockchain uses a merkle tree to store its world state and includes the root hash of the merkle tree in each block header (like Ethereum), the smart contract states in the tree can be proved and verified to exist on the blockchain using merkle proof.
Connection abstraction
Syntax and semantics of connections in IBC/TAO are specified in ICS-3. Basically, a “connection” in the context of IBC represents a connected pair of two *ClientState*’s on different blockchains. Before starting to relay packets using “channel” abstraction described later, the IBC/TAO modules on both blockchains need to determine and authenticate *ClientState* to communicate with. The connection abstraction is used for this purpose. A connection between blockchains is established through a mechanism like the 3-way handshake of TCP.
Connection Handshake
Connection states transition as follows. All the operations are kicked by transactions sent by relayers.
- (connOpenInit) A new connection in INIT status is created and stored on an initiating blockchain.
- (connOpenTry) A new connection in TRYOPEN status is created and stored on an opposite blockchain if it is verified that the connection in INIT status was created on the initiating chain.
- (connOpenAck) The state of the connection is updated from INIT to OPEN on the initiating chain if it is verified that the connection in TRYOPEN status was created on the opposite chain.
- (connOpenConfirm) The state of the connection is updated from TRYOPEN to OPEN on the opposite chain if it is verified that the state of the connection transitioned from INIT to OPEN on the initiating chain.
Channel abstraction
Syntax and semantics of channels in IBC/TAO are specified in ICS-4. Channel abstraction in IBC is used to represent a connected pair of two smart contracts on different blockchains. A channel is established through the handshake mechanism that is almost the same as connection abstraction. Once established, the channel can relay packets repeatedly between the blockchains. The packet relay itself is also done by a 3-way handshake mechanism similar to that of TCP.
Channel handshake
Channel states transition as follows. All the operations are kicked by transactions sent by elayers.
- (chanOpenInit) A new channel in INIT status is created and stored on an initiating blockchain.
- (chanOpenTry) A new channel in TRYOPEN status is created and stored on an opposite blockchain if it is verified that the channel in INIT status was created on the initiating chain.
- (chanOpenAck) The state of the channel is updated from INIT to OPEN on the initiating chain if it is verified that the channel in TRYOPEN status was created on the opposite chain.
- (chanOpenConfirm) The state of the channel is updated from TRYOPEN to OPEN on the opposite chain if it is verified that the state of the channel transitioned from INIT to OPEN on the initiating chain.
Relaying Packets
With an established channel, two smart contracts can transmit and receive packets (=arbitrary bytes sequences) as follows.
- (sendPacket) A new packet with sequence number N = *nextSequenceNumber* is created and stored in a source chain. Then *nextSequenceSend* is incremented.
- (recvPacket) A new packet with sequence number N is created and stored in a destination chain if it is verified that the source chain exactly sent (created) the packet.
- (acknowledgePacket) The packet with sequence number N is deleted.
There is an important difference from other operations. *recvPacket* and *acknowledgePacket* are directly kicked by relayers in the same way as handshake operations of connection and channel, but *sendPacket* is not kicked directly from an entity external to blockchains and is kicked by an application smart contract. An example is given in the next section.
IBC/APP
The single and simple mechanism for relaying packets (IBC/TAO) enables arbitrary cross-chain protocols. Application protocols built on top of IBC/TAO are called IBC/APP collectively.
Example: Cross-chain token transfer
ICS-20 is a good example of IBC/APP protocols, which enables cross-chain token transfer. There is no need for IBC/APP implementers to design or implement entire blockchain interoperability mechanisms. They only need to implement plugins called along with *sendPacket*, *recvPacket* and *acknowledgePacket*.
For example, tokens are transferred via ICS-20 from ChainA to ChainB as follows.
- ChainA executes the following operations atomically:
▹ Locking tokens in the ICS-20 module
▹ Then executing a *sendPacket* operation for a packet that specifies the amount and denomination of the locked tokens - ChainB executes the following operations atomically:
▹ Executing *recvPacket* operation for the packet
▹ Then minting voucher tokens that is equivalent to the locked tokens in the ICS-20 module - ChainA executes *acknowledgePacket* as normal.
Tokens are transferred back from ChainB to ChainA as follows.
- ChainB executes the following operations atomically:
▹ Burning voucher tokens in the ICS-20 module
▹ Then executing a *sendPacket* operation for a packet that specifies the amount and denomination of the burned vouchers - ChainA executes the following operation atomically:
▹ Executing *recvPacket* operation for the packet
▹ Then unlocking tokens that is equivalent to the burned vouchers in the ICS-20 module - ChainB executes *acknowledgePacket* as normal.
The aforementioned ICS-20 module only has the following functions. As you can see, given IBC/TAO implemented, it is straightforward to implement ICS-20 for each blockchain platform.
- Locking and unlocking tokens
- Minting and burning vouchers
Final Thoughts
Since Bitcoin was invented, many different paradigms of blockchains have been proposed and various blockchain platforms are being operated today. Especially in the context of enterprise blockchains, as different companies and industries have different needs and relationships among them, it is unthinkable that they all run their blockchain applications on the same unified blockchain platform. Interoperability is already and will be more and more important technology in this industry.
IBC is a simple and general-purpose technology to make these heterogeneous blockchains interoperable. It is backed by the community which consists of members from various backgrounds including us. We will contribute to the development of IBC through the YUI project.
[update: August 2022]
We unveiled a new product, LCP, which is a proxy middleware for light client verification to realize trust-minimized and gas-efficient cross-chain bridges that support the IBC protocol. Find out more from the link below.
