IBC overview#

What is IBC?#

    IBC, short for Inter-blockchain communication, was developed by Tendermint, Interchain Foundation, Agoric Systems and others, represents a portion of the broader Cosmos network ecosystem. The purpose of IBC is to help connect different blockchains all together with the simplest method possible. Currently speaking, some of the most popular blockchains-like Bitcoin or Ethereum-function on their own "islands", isolated from each other and the outside world. The IBC protocol comes in to solve this issue, acting as a social networking system for these blockchains, providing a means for them to communicate, exchange tokens and info with each other.

    IBC is somewhat similar to the TCP protocol. Before the advent of TCP, the internet was a collection of individual computer networks, all lacking the means to effectively communicate with each other. But along with IP, TCP/IP was able to standardize the method of sending and routing data between separate computer networks, resulting in the seamless sharing of info on the modern internet we’ve all learned to enjoy. On that same note, IBC has done the same with the blockchain, hence why Cosmos is often referred to as "the internet of the blockchain".

    The following are some of the common solutions used in regards to cross-chaining:

• Notary schemes: In essence, this is when two parties entrust a third party to validate and relay cross-chain data or interactions between the two parties. This method works well for supporting heterogeneous blockchains, but is considered a centralized method.
• Hash locking: first used in Bitcoin’s Lighting Network, hash locking is a combination of hash lock and time lock in order to protect Inter-blockchain asset transactions. Time lock is a time restriction set on transactions, cancelling out expired transactions; however, this method can only support asset trading but not transfers.
• Side chains: simply put, side chains are new chains built on existing chains, potentially different but still reliant on the original chains. Side chains work in tandem with their original chains, making up for areas in which the other chain lacks, thereby facilitating the transfer of assets between the two chains.

IBC core principles#

    IBC is a combination of the notary scheme and side chain mechanisms, with a framework based on the multi-chain and multi-layer development of the relay chain. IBC’s protocol is similar to that of TCP’s, applying the layering design, as shown in the chart below:

• Client: Every chain has a corresponding client who is responsible for recording the info of the peer chain.

• Connection: Two client ends can create a connection.

• Port: In simple terms, a port is a specific application, such as token or NFT transferring.

• Channel: One port to another represents a channel, and one connection may contain many channels.

• Packet: a business data packet used for carrying business data, for example, cross-chain token transference data.

Handshake#

    As the chart below shows, IBC’s connecting mechanism is similar to TCP’s three-way handshake, but one major difference between the two is that while the TCP/IP handshake is a direct end-to-end data interaction between two directly connected parties, IBC’s connecting mechanism is done through a third party component called the relayer. The relayer conducts additional relay control and is different than TCP/IP in that IBC’s connection/channel layer (chart above) needs to go through an additional connection creating process.

Client layer protocol#

    The client layer is IBC protocol’s initial state and lowest layer, responsible for storing its peer network’s metadata. The connection creating process of the client layer is as shown in the chart below:

    In the client layer, IBC contains 4 different message types, as shown in the chart below:

    The chart below shows the client’s recorded metadata:

Connection layer protocol#

    Connection is the upper layer protocol of client and IBC protocol’s transitional state. Connection layers connection creating process is similar to that of client’s, both containing certain timed out sends which are reliant on relayer. Connection layer’s connection structure is as shown in the chart below:

There are 4 different message categories in the connection layer, and each category’s logic is described in the chart below:

Channel layer protocol#

    Channel layer is an application layer protocol, and all business developments can be found in this dimension. Taking place after the connection is created and reliant on relayer, a chart of channel layer protocol’s connection structure is as shown below:

    Below are 4 kinds of message categories in the channel layer and their corresponding logic’s:

Relaying#

• The core component of the IBC protocol is relayer, which plays a sort of porter-like role in the protocol, relaying every transmitted message in IBC; in this protocol, the host chain never actively interacts with the peer chain, only ever passively receiving.

• Cosmos has officially implemented relayers in 3 different languages

  • go version
  • rust verison
  • ts version

IBC security guarantee#

• Client activity verification

       There is a validity period field in the metadata of the client, which ensures that both clients are active and valid at the time. When the transaction is not active, in order to guarantee the client won’t expire, there often will be regular updating intervals set up in the backend and program, as shown in the chart below:

       For each business request received by IBC, it must ensure that its lower layer client is valid, and only when it is in the active state will it receive transactions for business logic processing.

• Proof of hash

       After the relayer relays the data packet, the peer chain needs to verify the validity of the data packet, which is achieved through proof.

       The proof of IBC uses the ICS23 library, which is also the hash proof implemented by the Merkle tree. The calculation method is to start from the leaf node and calculate the root hash layer by layer, so that even a change in a portion of leaf nodes will affect the hash calculations of the overall data, thus avoiding the malicious tampering of data.

• Security verification of light nodes

       The two chains connected through the IBC protocol will maintain the light node information of the peer chain on their respective chains, with the security of the light node being equivalent to the security of the IBC protocol.

       When the relayer relays data packets, it also carries an UpdateClient message, which is used to update the light node consensus information. Conceptually speaking, the IBC protocol contains two key data structures, ClientState and ConsensusState, which separately store the metadata of the peer chain and consensus security information.

       When the node receives the message, the consensus layer will perform a double verification

  • 2/3 consensus

        IBC still mainly relies on the Tendermint consensus, which means that one of the core conditions is that the voting information of the header information in the light node must contain the signature information of 2/3 of the validators.

  • Trusted nodes>= 1/3

        In IBC, another core concept is TrustValidators, which are trusted nodes. After obtaining 2/3 consensus, 1/3 of the validator nodes must be TrustValidators before the light nodes data can be updated.

    Note: theoretically speaking, 1/3 is considered insecure, because when the original 1/3 nodes go offline, the peer chain does not update the header information of the host chain in time, so if the original 1/3 nodes re-send the header information, the peer chain can still pass the verification.

Basic example#

Users on the Cosmos chain making asset transfers to the OKTC chain:

1. User A initiates an IBC transfer directed at the Cosmos chain. After Cosmos receives the transaction, it locks the corresponding balance in the A account, and generates a certificate, which is stored locally.

2. The relayer polls the transaction execution result from the Cosmos chain and packets it into RecvPacket.

3. The relayer sends the RecvPacket transaction to OKTC chain. After OKTC chain receives it, the respective minted token amount is given to the respective OKTC account, and an ack certificate is stored locally.

4. The relayer polls the RecvPacket transaction execution result from OKTC chain and packets it into Acknowledgemnt.

5. The relayer sends the Acknowledgemnt transaction to Cosmos chain. After that, Cosmos receives it and confirms if the OKTC chain execution is normal or not, if not, a refund is executed.

In conclusion, the entire process of token transference is as shown below:

• Handshake and create a connection (Client=> Connection => Channel)
• Transfer tokens
• Wait for relayer to relay data packet

The only step in the entire process that requires the user to participate is "Initiate a transfer".

OKTC and IBC#

     The bottom layer of OKTC is the early cosmos-sdk (v0.39), while IBC involves the code of v0.40+, and there are major code changes from 39 to 40. After the version upgrade, OKTC now not only supports the EVM system, but also supports IBC.

OKTC-ERC-20#

     Cross-chain native tokens are considered to have no commercial value on OKTC, and so after the arrival of cross-chain transferring of native tokens to OKTC, through the hooks function of IBC’s application layer, the logic sunk down into the EVM layer. With ERC-20, contracts were able to automatically generate the mapping of corresponding tokens, which caused everyone in the industry to focus on this one aspect. But finally, the barrier between Cosmos and EVM was broken down and a bridge between the two was built.