In the previous post on our path towards understanding birding, the Polymer, and its ecosystem, we have introduced a definition of Inter-Blockchain Communication. We now know that the IBC can stand for a standard or its implementation, enabling transferring arbitrary data between (IBC-compatible) blockchains. In this post, we will describe how it works in more detail.

How does IBC work?

1. A user on Blockchain A interacts with Application Module A. This module implements application logic, an equivalent of a smart contract in Cosmos terminology.
2. Application Module A invokes IBC Module (on Blockchain A), which implements the IBC protocol and is responsible for preparing an IBC Message and sending it downwards to the blockchain. We can think about it as a smart contract library using Ethereum vocabulary.
3. Then the IBC Message is propagated to Blockchain A, where it is distributed and validated.
4. When the consensus is achieved, and the IBC Message is finalized on Blockchain A, the IBC Relayer injects the IBC Message into Blockchain B.
5. Blockchain B validates the IBC Message and, if correct, adds it to the blockchain, which triggers IBC Module (on Blockchain B).
6. The IBC Module processes the IBC Message and delivers it to Application Module B.
7. Finally, Application Module B settles the action initiated by the user on Blockchain A.

How are the IBC messages relayed?

Now let us go one step deeper and discuss how the IBC messages are relayed. The relaying, as described below, can happen only on IBC-compatible blockchains.

First, an IBC message is added to Block A on blockchain A. The message is read by Module A, which makes a proper state transition (think about a result of a mathematical function, with arguments from the IBC message). The IBC Module splits the IBC message into Commit Message and Packet Message, and both are added to the mempool. The Commitment Message is a footprint (hash) generated from the Packet Message. It is much smaller than the original message and cannot be effectively used to attest any other packet but the original.

The relayer observes what happens on blockchain A and sees that a new Commit Message was generated. He takes the Commit Message and propagates it to Blockchain B.

Then Module B on the blockchain B reads the Commit Message, validates it, and publishes it in Block X. The relayer sees that the Commit Message was added to Block X, grabs the correct Packet Message from Blockchain A, and delivers it to Module B on Blockchain B.

Finally, Module B on the blockchain B receives the Packet Message, validates it, changes its state accordingly, and publishes the message in Block X+1, which finishes the IBC message relaying.

What blockchain needs to be compatible with IBC?

According to the IBC Protocol, any blockchain can be compatible with IBC only if they meet the following requirements:

• Module System: The host ledger 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 controller module or execution environment.
• Key-value Store: The host ledger must provide a key/value store interface allowing values to be read, written, and deleted.
• Consensus State Introspection: Host ledgers must be able to introspect their current block height and consensus state (as utilized by the host ledger’s light client algorithm), as well as a bounded number of recent consensus states (e.g., past headers).
• Timestamp access: Host ledgers must provide a current Unix-style timestamp to support timestamp-based timeouts. Timeouts in subsequent headers must be non-decreasing.
• Port System: Host ledgers must implement a port system where the IBC handler can allow different modules in the host ledger to bind to uniquely named ports.
• Exception/rollback system: Host ledgers must support an exception or rollback system, whereby a transaction can abort execution and revert any previously made state changes (including state changes in other modules happening within the same transaction), excluding gas consumed and fee payments as appropriate.
• Data availability: For deliver-or-timeout safety, host ledgers must have eventual data availability, so relayers can eventually retrieve any key/value pairs.

The list is long, so not all blockchains can meet these requirements. For example, most of the Layer 2 scalability solutions for Ethereum are not meeting on-chain data availability while using rollup or plasma constructions.

Fortunately, the Polymer project is actively working on this compatibility issue with their IBC Rollup design. We will write about this in one or more of the following posts.