Deep Dive into Cosmos Inter Blockchain Communication Protocol

Before the advent of bridges, blockchains were isolated networks of nodes that could not directly communicate with each other. The evolution of the crypto industry allowed bridges to connect different blockchains, enabling interoperability. In this context, to interoperate means to leverage a permissionless method of exchanging data about transactions that occurred on another blockchain.

Given these precedents, the Inter-Blockchain Communication Protocol (IBC) is a communication protocol comprising a set of rules and standards to be followed to achieve interoperability, rather than a specific tool, such as bridges, which are directly responsible for performing the necessary functions to establish cross-chain communication. By implementing this standardised protocol, blockchains can share information about their actual state or a desired set of transactions.

Furthermore, although the IBC is part of the Interchain Stack, the set of tools developed by Interchain to facilitate blockchain developments, its use is not limited to the Cosmos Ecosystem's boundaries. Any blockchain meeting certain requirements, which will be detailed throughout this article, can implement the IBC to establish a secure and straightforward means to exchange information.

This article aims to provide a detailed insight into what the IBC is, how it works, the blockchains that can implement it and the benefits it offers to those that adopt it. The article concludes by outlining two issues currently facing the IBC protocol, specifically the concept of verification cost and the concept of extensibility.

What is the IBC?

The IBC is a set of rules and conventions that allow blockchains, regardless of their consensus type, to communicate with each other by exchanging any data in a reliable, ordered and trust-minimised manner. Among the vast range of bridges built to facilitate communication between blockchains, the IBC has two unique characteristics.

First, the IBC can facilitate communication between blockchains that achieve their consensus through entirely different mechanisms. In this context, two blockchains that reach their consensus through the Proof of Work and Proof of State mechanisms could seamlessly exchange information permissionlessly if both follow the rules and conventions the IBC establishes.

Secondly, the trust-minimised feature of the IBC sets it apart from other interoperability solutions. This trust minimisation is achieved by not relying on third parties to achieve cross-chain communication. While some bridges tend to require a layer of validators, usually known as notaries, to verify and send information between blockchains, as mentioned in our The Implications of Cross-Chain Bridges under MiCA article, the IBC does not involve third parties to achieve cross-chain communication. By delving into its architecture and functionality, it is possible to understand that if a user trusts the consensus mechanism that two blockchains have, they can also trust the IBC communication between them.

As one of the pieces that compose the Interchain Stack, the IBC is a central component to achieving the Cosmos Ecosystem's primary purpose of building a network of interoperable and decentralised application-focused blockchains. By implementing the IBC protocol, which comes as part of the Cosmos SDK – a standardised software developer kit used to create new application chains in the Cosmos Ecosystem –blockchain developers can derive their efforts to customise the application layer of their chain. By achieving cross-chain communication between chains designed for particular use cases, the potential for horizontal scalability is enabled by adding more appchains focused on new use cases. Additionally, as a trust-minimised protocol, cross-chain transactions in the context of the IBC do not involve additional tools to be processed, as bridges do, which would incur extra costs. In this sense, the IBC addresses notable blockchain problems, such as high cross-chain transaction costs, network throughput capacity, and transaction irreversibility.[1]

However, it is essential to underscore that the IBC is not solely restricted to blockchains that have been built within the Cosmos Ecosystem, by leveraging the Cosmos SDK. As will be explored later, the IBC can be implemented by any blockchain that meets pre-established requirements. To better understand how the IBC works, the following section provides a thorough overview of its architecture.

IBC Architecture

The IBC is often defined as a layered protocol. This means that its architecture can be dissected into two distinct layers that provide the IBC with its complete set of functionalities by interacting with each other. The most important of these is the transport layer (TAO). This layer provides the infrastructure to build secure connections and authenticate data packets between blockchains. The TAO comprises the IBC's Light Clients, Relayers, Connections, and Channels to address these functionalities.

The second layer, known as the Application Layer, is built on top of the TAO and specifies how the data packets must be bundled and interpreted by the chains involved in cross-chain communication.

The Transport Layer (TAO)

As mentioned, cross-chain communication through the IBC occurs via information or messages delivered in data packets, which the TAO is responsible for transporting, authenticating, and ordering. One interesting concept often highlighted is that arbitrary data can flow through the IBC. This feature is achieved because the TAO does not specify what kind of data can be shared between blockchains. For the TAO, the information contained within data packets is nothing more than a series of random bytes.

The main components of the TAO can be summarised as follows:

IBC Light Clients.[2] Two types of clients, commonly known as nodes, are usually found within blockchain infrastructure: Full Clients and Light Clients. The first type is in charge of verifying each transaction and storing the entire information of the blockchain it belongs to. Whereas, Light Clients are designed to connect to a Full Client and verify block headers, which represent a summary of the information contained in a block and, in some cases, a pre-defined set of transactions.
There are six different types of IBC Light Clients (ICS-2, 6, 7, 8, 9, 10), each adapted to diverse types of networks. All of them, consist of two components: the client and the consensus state. The client contains all the parameters needed to verify cross-chain transactions, while the consensus state contains block headers of the counterparty blockchains.
Blockchains that have implemented the IBC protocol have Light Clients in counterparty chains. In simple words, chains that interact through the IBC have a lightweight representation of other IBC-compatible blockchains. Therefore, the role of IBC Light Clients is to track and verify the relevant state of counterparty chains and to check the instructions in transactions emitted for sending and receiving packets on the source and destination chains, respectively.

IBC Relayers.[3] Blockchains adopting the IBC rely on Relayers, ICS-18, to communicate with each other. In essence, IBC Relayers represent the "physical" connection of the IBC. Their primary purpose is to monitor for updates on IBC Light Clients and relay messages by submitting the information along with a "data proof" to a counterparty chain.
Even though Relayers execute their process in an off-chain environment, it is fair to conclude that the IBC does not rely on third parties to achieve cross-chain communications because relayers "scan" the state of each chain involved and just submit the data. However, the verification proof is done when committing transactions, a process in which Relayers do not participate. Additionally, it should be noted that Relayers are permissionless, meaning that anyone is able to deploy one.[4]

IBC Connection.[5] In the context of IBC, Connections, also known as the Interchain Standard (ICS) number 3 (ICS-3), are responsible for connecting IBC Light Clients among different chains, facilitating cross-chain verifications. By doing so, Connections establishes the identity of a counterparty chain while preventing a malicious entity from sending incorrect information pretending to be an IBC chain.
Establishing a Connection between two chains is a process that occurs through four messages, known as "handshakes". First, a message to start the communication will be sent, the OpenInit message, in which the chain trying to initiate the communication sends its information and expresses the intention to open a Connection. Subsequently, with the OpenTry message, the destination chain will reply by sending its information and confirming the source chain data by checking its own Light Client of the source chain. As a third step, the OpenACK message is sent by the source chain, which confirms the information of the destination chain by checking its Light Client, and the data is trying to communicate. Finally, once the destination chain receives this message, it will confirm that the Connection is open by sending the OpenConfirm message. Once a Connection is opened, information can permissionlessly flow through it.
IBC Connections are deployed on-chain, as they are built on top of IBC Light Clients. This means that no off-chain or third-party process is required to establish the counterparty blockchain's identity, which enhances IBC's level of security.
IBC Channels.[6] Channels, also known as ICS-4, are built on top of Connections. Channels have an ID number that uniquely identifies them, and a port ID used to specify which application or module the IBC Channel carries information about. Consequently, while Connections establish the communication between two chains, Channels establish communications between applications or modules of IBC-compatible chains.[7] All in all, they are in charge of transferring data packets between modules on these different chains, such as the token transfer application module, which allows the sending of ICS-20 tokens.
Similarly to Connections, Channels are established by a four-step messaging process known as a "handshake". Once the Channel is open, data packets can flow permissionlessly through it.

The Application Layer

As mentioned, the Application Layer, built on top of the TAO, is in charge of defining how data packets sent through the TAO components must be bundled and interpreted by the blockchains involved in an IBC cross-chain communication. Fundamentally, the Application Layer comprises applications with which IBC-compatible blockchain users interact when performing cross-chain transactions.

IBC applications can be divided into two groups: IBC modules and IBC middleware. The former are stand-alone applications that allow sending and receiving packets from other IBC-enabled networks. IBC modules relieve developers of the burden of managing the low-level details of IBC Light Clients, Connections and proof verification. IBC middleware applications, on the other hand, can be defined as modules that sit between the IBC core and an underlying IBC application, allowing developers to customise low-level packet management.

There are several key applications built on the Application Layer, notable examples include: fungible and non-fungible token transfers, Interchain Accounts, Interchain Queries, Cross-chain Oracle Feeds, and the Fee middleware, destined to incentivise IBC Relayers.[8] For the context of this article, we will delve into two of the more relevant applications to achieve successful communication between two chains:

Fungible Token Transfer - ICS-20:[9] The ability to seamlessly and permissionlessly transfer tokens between chains is undeniably one of the main benefits blockchains and their users obtain from the IBC implementation. Therefore, the Interchain Standard 20, commonly known as ICS-20, is one of the most used and disseminated applications developed on top of the TAO.
This standard defines the rules and conventions that allow users to send tokens via IBC-enabled chains. For instance, the data packet parameters related to ICS-20 tokens include data on the sender, the recipient, the amount and the IBC denomination, also known as IBC denom, all of which are defined by this standard. It is important to note that an IBC denom plays an essential role as a hash determining the path a particular token has followed to reach its destination chain. In addition, the logic related to the interpretation of this information is also specified in the ICS-20.
Interchain Accounts - ICS-27:[10] The Interchain standard number 27 defines how accounts should be created on IBC chains and how they should be managed on each chain to achieve cross-chain compatibility. Within this context, blockchains that have enabled the ICS-27 can create accounts on other ICS-27-enabled chains. One feature of these accounts is that the address from the source chain that created it controls the new account through IBC transactions instead of having to sign its transactions with a private key created on the counterparty chain. All in all, ICS-27 accounts retain all the capabilities of a regular account, such as staking, sending tokens, and voting on-chain proposals, with the particularity that they are managed from an account hosted on another network through the IBC.

How does the IBC Work? A Practical Example

To fully comprehend how the IBC works, let's unite all its components explained above and observe how they operate when a user wants to send, for example, OSMO from Osmosis to the Cosmos Hub blockchain. In this example, the user will start by performing a transaction on the source chain – Osmosis. The user initiating the transfer on Osmosis will express their desire to send OSMO to an address on the Cosmos Hub. This transaction will be committed or stored in an Osmosis block as a hash representing the data package. In practice, the OSMOs to be sent to Cosmos hub, are sent to an escrow address on Osmosis. Escrow addresses are established on each side of a Channel communicating two IBC Transfer modules, to perform the following actions:

Lock the native tokens departing from the source chain.
Mint the non-native tokens that are sent to the destination chain.
Burn the non-native assets departing the destination chain.
Release the native tokens sent back to the source chain.

Subsequently, IBC Relayers, which are constantly monitoring for this type of specific message/transaction, will detect it, reconstruct the data package from the hash stored on Osmosis, and carry this message to the Cosmos Hub. This transaction will be transported as a data package through the Channel that connects the IBC Transfer module of Osmosis with Cosmos Hub. If the Connection between blockchains or the Channel between its modules is not yet open, this message will play the role of the OpenInit message that triggers the four-step handshake process.

Once Cosmos Hub receives the data package and a commitment proof of the message stored on Osmosis, it will verify all the information on its own Osmosis Light Client. Once this verification succeeds, the OSMOs are minted on the Cosmos Hub chain, and a confirmation receipt, also known as an acknowledgement, is sent back to Osmosis. This confirmation acknowledgement will let Osmosis understand that the tokens must remain escrowed and that they were minted in Cosmos Hub.

If a problem arises once the Cosmos Hub verifies the message or if the data package gets Timeout before arriving, a concept to be explained in the following section, the communication will fail and the OSMOs will not be minted on Cosmos Hub. Then, Osmosis will be notified, and the OSMO will be released to the user.

Which Type of Blockchains can implement the IBC?

The IBC is a protocol that any consensus algorithm can implement to provide a low-cost, verifiable finality by leveraging any state machine capable of supporting vector commitments. Therefore, to support and successfully implement the IBC, blockchains must meet three requirements, which we will deconstruct further to understand their meaning.

In the context of blockchain consensus algorithms, finality means that transactions, or blocks, are irreversible and perpetually confirmed. This means that a blockchain must achieve block finality at low costs to be IBC-compatible.

We refer to state machines as a computational concept comprising a system that transitions from one state to another based on inputs. Within a blockchain, we can understand this concept as how the state of a blockchain is modified after each user transaction or interaction. A clear example of how blockchains move from one state to another can be the following:

A Cosmos developer creates a new smart contract (SC) on Cosmos Hub, which allows users to deposit ATOM. The contract's initial state will be an account balance of 0 ATOM.
Then, a user calls a SC's specific function and deposits 3 ATOM.
The state machine, in this case, Cosmos Hub, will transition to a new state after processing the transaction, updating this SC to have an account balance of 3 ATOM.

The last concept mentioned in the definition of blockchains that can implement the IBC is related to the adaptability of this communication protocol. A blockchain capable of supporting vector commitments can employ cryptographic techniques to commit multiple values simultaneously, allowing for efficient verification. A practical example is blockchains, which store their data in a Merkle tree organisation. There, each "leaf" of the Merkle tree represents a single piece of data, which can be a transaction. The traditional Merkle tree commitment would provide a root hash that serves as the commitment of all its stored data. However, when blockchain supports vector commitments, a vector or a list of leaf nodes in the tree can be committed. Then, users who want to prove that a set of transactions is part of the Merkle tree without revealing the entire dataset can do so by using a proof that includes the Merkle path, in this case, the branches of the tree, to authenticate the presence of each transaction in the vector. Since anyone can prove that a specific set of transactions is part of the tree without revealing all transactions, vector commitment allows for scalability and simplicity in the verification process of a blockchain. By applying this technique, blockchains can support IBC Light Clients to verify transactions and proof of verification of counterparty blockchains.[11]

Security on the IBC

Regarding security, four important concepts interact with each other to provide a secure environment for cross-chain communications. Let's take a closer look at them.

Timeouts

Timeouts consist of an interval after which a packet sent through an IBC Channel is invalid. The default IBC timeout is 10 minutes, although it can be customised. For instance, when a user intends to send a token to another IBC chain, its tokens will be escrowed on the destination chain. However, if the transaction data packet is not processed before the time set in the Timeout, the transaction will fail, and the tokens will be returned to their owner. Examples of situations where timeouts will occur are when Channels are closed or when, due to network congestion, Relayers fail to handle cross-chain messages in time.

IBC Light Clients Parameters

When it comes to the consensus state of IBC Light Clients, they can establish their parameters which consider a block from a counterparty blockchain valid or invalid. In this context, for a block to be considered valid according to these parameters 2/3 of the validators must agree on that block. However, the customisation of IBC Light Clients parameters provides application-chain developers with the flexibility to customise this parameter according to the situation.

In this context, a situation could take place where a validator tricks an IBC Light Client into believing that a block was created when, in reality, it was not. There is a procedure known as the Misbehaviour Process established to handle this issue. According to this process, if a valid block was built at a determined height and another one, done by malicious validators, was committed at the same height, the Light Client can stop validating and verifying blocks until the situation is clarified. Another defensive alternative is to delay data packets until the situation is clarified, which, in this context, means that the chain consensus must define on top of which of the blocks the blockchain should be built. While the conflict remains unresolved, communication with the corrupted blockchain can be halted permanently.

Follow the Conventions and Trust the Consensus

To start communicating through the IBC, blockchains need to first recognise each other by establishing a Connection between them. Once the Connection is established, they must create a Channel through which data packets belonging to specific applications or modules defined in IBC's Application Layer can be sent.

This singular design, where security measures are established and evaluated independently on each Connection and Channel, allows for more detailed and comprehensive data exchange control. In this sense, scalability is enhanced, as security measures followed in specific modules take fewer hardware resources than checking the entire network when cross-chain communications occur.

IBC's Application Layer provides a set of rules and conventions related to each module to ensure that communication will fail if they are not followed. As mentioned, this process does not involve trusted third parties. If a chain consensus is trusted by checking its IBC Light Client, the communication will be scrutinised at the Channel level, saving time and resources and fostering an interoperable and secure environment.

Relayers and the Byzantine Resistance of the IBC

Byzantine resilience can be succinctly defined as the ability of a system to continue to function safely when some of its participants behave maliciously. As mentioned in the architecture section, Relayers monitor specific messages committed to a particular path on the IBC blockchain state. Once they detect one of these messages, they will submit it to the appropriate destination chain along with their verification proof.

This is an IBC highlight in terms of security. Even if a Relayer does not act in a trustable way, users do not need to trust Relayers because the verification proof was created by the source chain and will be verified by the IBC Light Client on the destination chain.

If Relayers decide to go rogue and send data packets with faulty or incorrect verification proofs, they will get rejected once received by the destination chain and contrasted with its own Light Client. This design choice underscores the compromise of the IBC with prioritising security over liveness. In simple terms, the IBC prefers to interrupt the transaction flow if security measures are not matched. Additionally, as relaying is permissionless, anyone can implement a Relayer to start forwarding packets with the correct proof.

IBC Implementations Beyond Cosmos

Although most implementations of the IBC take place within the Cosmos Ecosystem, by the appchains within it, the IBC is a blockchain-agnostic protocol. This means that the IBC was also developed to be adopted by blockchains not created by leveraging the Interchain Stack tools. However, to achieve this broader compatibility, the Team behind the IBC had to create different versions of the IBC core and one of its essential components, the IBC Light Clients.[12]

The Developments

The core logic of the IBC was created in a programming language known as Golang.[13] The reason behind this design choice is that blockchains built with the Cosmos SDK are written in the same language, and the IBC comes as a module in the Cosmos SDK. Therefore, to broaden the IBC landscape beyond the boundaries of Cosmos, the core IBC logic was also written in Solidity to enable interoperability with EVM chains and in Rust to be compatible with blockchains such as Solana or Polkadot and Kusama Parachains, among others.

Secondly, further developments were required to adapt IBC Light Clients to not-Cosmos blockchains. While it was mentioned that they could be implemented on any blockchain that supports their use, the first implementation of IBC Light Clients was compatible with Tendermint (ICS-2). In this context, new ICSs were built to extend IBC compatibility. ICS 6, 7, 8, 9 and 10 are examples of IBC Light Clients intended to serve blockchains not created with the Cosmos SDK, such as EVM chains and Polkadot and Kusama Parachains.

Proof of this progress materialised during 2023 by the Composable Finance team. Following their cross-chain development efforts, the IBC was implemented for the first time to communicate two blockchains that do not belong to the Cosmos Ecosystem. Communication was established between Kusama via Picasso's Parachain and Polkadot through the Composable Parachain.[14] Additionally, through Trustless, a Composable Finance product, Polkadot and Cosmos chains are now connected leveraging the IBC. Following this landmark, Composable is still working to establish IBC communications on Solana, EVM blockchains and Near.[15]

The Challenges Ahead

Along with the challenges related to the adaptability of some IBC components, which are already being addressed, there are more hurdles to be overcome to extend the scope of the IBC further. Among these hurdles, two stand out: verification cost and extensibility.

The first relates to the fact that the cost of verifying data packets transported through IBC components depends on the blockchains' consensus and their ability to support the cryptographic proofs needed to verify these packets. Ethereum is an example where the cost of verifying data packets that pass through the IBC is exceptionally high, making such an implementation pointless.

The extensibility issue is related to the number of IBC Light Clients each blockchain has to implement to communicate permissionlessly with each blockchain that implements the IBC. While having a few IBC Light Clients represents a manageable burden, implementing hundreds of them would cause some problems.

Fortunately, for IBC supporters, both problems are being addressed right now. One solution is known as Light Client Proxy (LCP). LCP acts as a proxy that performs Light Client verification on IBC chains on behalf of another IBC chain. The main concern is to provide this service in a way that minimises trust, which is achieved by implementing this service in a Trusted Execution Environment (TEE), which is a secure and isolated area within a computer system, in this case, an environment isolated from the rest of the IBC context and from potential attackers, which provides a trusted environment for executing code and handling delicate data.

Another development worth mentioning is Zero Knowledge-IBC, which Electron Labs and Polymer Labs are developing. As the name suggests, ZK-IBC aims to create a ZK-proof signature to validate and verify proofs of transactions in EVM chains, addressing the abovementioned problems.

Conclusion

As a protocol designed to allow blockchains to communicate with each other, the IBC offers many advantages over purpose-built tools such as bridges. By following the set of rules and conventions provided by the Application Layer and adopting the infrastructure detailed in the TAO, IBC chains can establish secure and straightforward connections. However, as mentioned above, adopting this protocol comes with its own burdens. While solutions to these limitations are being developed, the first examples of blockchains outside the Cosmos Ecosystem implementing IBC are beginning to appear.

Despite what may be a resource-intensive implementation, the fact that the IBC achieves inter-chain communication without relying on third parties is one of its unique features, as operating in a way that minimises trust has been one of the main purposes of the blockchain space since the advent of Bitcoin.

In addition to its essential role in driving the "Internet of Blockchains" pursued by Cosmos, the Team behind the IBC never lost sight of a more ambitious goal. By continuously increasing the set of tools to expand the implementation of the IBC beyond its initial boundaries, the IBC aims to connect and integrate Cosmos chains with other Ecosystems such as EVMs, Solana, Polkadot and Near blockchains. While the first steps have already been taken and tools are being refined, the full scope of the IBC is yet to be discovered.

---

[1] https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html

[2] https://github.com/cosmos/ibc/tree/main/spec/client

[3] https://github.com/cosmos/ibc/tree/main/spec/relayer/ics-018-relayer-algorithms

[4] https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html#

[5] https://github.com/cosmos/ibc/tree/main/spec/core/ics-003-connection-semantics

[6] https://github.com/cosmos/ibc/tree/main/spec/core/ics-004-channel-and-packet-semantics

[7] https://github.com/cosmos/ibc/tree/main/spec/core/ics-005-port-allocation

[8] https://github.com/cosmos/ibc/tree/main/spec/app

[9] https://github.com/cosmos/ibc/tree/main/spec/app/ics-020-fungible-token-transfer

[10] https://github.com/cosmos/ibc/tree/main/spec/app/ics-027-interchain-accounts

[11] https://github.com/cosmos/ibc/tree/main/spec/core/ics-023-vector-commitments