Blog

The Interchain Stack is a powerful set of tools and protocols designed to build customized appchains and products. At the heart of this stack is the Inter-Blockchain Communication Protocol (IBC), a standard that allows different blockchain networks to interoperate with one another.

This article aims to provide an overview of IBC and its main implementations, ibc-go and ibc-rs, as well as other components of the Interchain stack, namely CometBFT and the Cosmos SDK. Towards the end of this piece, we discuss technical considerations that may influence your choice of tech stack.

The Inter-Blockchain Communication Protocol (IBC) is is a blockchain interoperability protocol used by 100+ chains. It enables secure, permissionless, feature-rich cross-chain interactions. Chains that use IBC can share any type of data as long as it's encoded in bytes.

Unlike other interoperability protocols, IBC uses no trusted third parties. This means that if you trust two particular chains to use the functions they provide (and by default their consensus mechanisms), then there are no additional trust assumptions needed while using IBC to interact between said chains.

IBC is able to achieve this degree of trust-minimization by leveraging light clients. A light client is a lightweight representation of a blockchain. Unlike a full node, light clients do not download and execute every single transaction. Instead, they connect to a full node and verify block headers. This allows light clients to be efficient in terms of storage and computation.

Two independent blockchains A and B interacting over IBC have light clients of the counterparty chain. This means that A has a light client on its state machine which acts as a lightweight representation of B. And vice versa.

When A wishes to communicate a certain message X with B, it sends the block header in which that message exists, a Merkle proof, as well as the message itself to B. Note that a block header contains the Merkle root of A’s current state. The Merkle proof is used to verify the presence or absence of X having been committed to A’s state machine. Using the Merkle root, the proof, and the actual message bytes, B cryptographically verifies that A did indeed commit X. 

It is this use of light clients in IBC that allows blockchains to exchange messages with one another without the need for a trusted third party.

The security configuration of light clients can be tailored to meet your blockchain's requirements through parameters like TrustLevel and TrustingPeriod. IBC also supports a client type called the solo machine client that can interact with standalone machines and not just blockchains. The solo machine client simply verifies a public/private key pair without needing to track block headers and verify Merkle proofs. Learn more about the solo machine client here.

The original vision laid out in the Cosmos whitepaper was to build a network of sovereign, interoperable blockchains. To bring this vision to life, the Cosmos SDK was designed to provide a framework to build customizable blockchains. And in order to interconnect chains built using this framework, ibc-go, the Go implementation of the IBC protocol was designed as a Go module within the Cosmos SDK. 

The majority of Cosmos SDK chains employ the CometBFT consensus engine, whose instant finality property is advantageous for IBC, ensuring that finalized transactions are irreversible.

Currently, ibc-go is tightly integrated with the Cosmos SDK. However, one of our objectives for this year is to decouple ibc-go from the Cosmos SDK, transforming it into a standalone library.

Previously called ‘Tendermint Core’, CometBFT is a Byzantine Fault Tolerant (BFT) consensus algorithm for securely and consistently replicating an application on many machines. It is often used in conjunction with IBC to ensure secure and reliable communication between blockchains.

CometBFT is composed of two main elements: 1) a consensus mechanism and 2) an application interface. 

The consensus mechanism is based on the Tendermint algorithm and is responsible for ensuring that all participating nodes record transactions in an identical sequence. On the other hand, the Application Blockchain Interface (ABCI) serves as an API between the consensus engine and the state machine i.e. the application.

Note that IBC can be used with any consensus algorithm and not just CometBFT. The Interchain stack was designed in such a way that developers can pick and choose different state machines and consensus algorithms as long as they adhere to the common ABCI interface.

The Cosmos SDK is an open-source framework for building Proof-of-Stake (PoS) or Proof-of-Authority (PoA) blockchains. 

It serves as a robust framework designed to empower developers to construct custom blockchains from the ground up, all while ensuring seamless interoperability with other blockchain networks via IBC. Think of it as the blockchain world's equivalent to npm, built to work harmoniously with CometBFT. 

The SDK is modular by design, allowing developers to piece together their blockchains using a variety of open-source modules that are readily accessible.

ibc-go is one such module that you get out of the box while using the Cosmos SDK. This means that every chain built using the Cosmos SDK has native interoperability with each other over IBC.

Some of the prominent chains using the Cosmos SDK include Osmosis, Cosmos Hub, dYdX v4, Crypto.com, Cronos, Celestia, BNB chain, and many more.

CosmWasm is a smart contracting platform built for the Cosmos ecosystem, and it serves as another integral component of the Interchain Stack. 

Designed to be highly secure and modular, CosmWasm enables developers to write smart contracts in Rust and deploy them on Cosmos SDK-based blockchains. By providing a WebAssembly runtime, CosmWasm allows for greater flexibility and interoperability, making it easier for developers to create complex applications that can interact seamlessly with other components of the Interchain Stack.

Now, we'll dive into the main IBC implementations.

ibc-go is the reference implementation of the IBC protocol, written in Go. It's currently in use by 100+ chains. The core IBC logic in ibc-go handles the transport layer, and includes various applications like ICS-20 token transfers and ICS-27 interchain accounts, where ICS stands for Interchain Standards.

The ibc-go repository, along with the ibc spec repository, is managed by Interchain GmbH, a subsidiary of the Interchain Foundation (ICF). Additional contributors to IBC development include teams from Informal Systems, Polymer Labs, Strangelove, Confio, Osmosis, Datachain, Notional, Bianjie, and others.

ibc-rs is the Rust implementation of the IBC protocol, offering an alternative for developers who prefer to work using the Rust programming language. This robust library aims to broaden the reach of IBC across various blockchains - irrespective of their underlying consensus mechanisms - such as Polkadot, Solana, Near, Anoma, and Namada. Its design focuses on abstracting away complexities such as transaction formats and system-specific elements, to ensure seamless integration with IBC's native functionalities.

Managed by the ibc-rs team at Informal Systems, the project is under active development with a commitment to continuous improvement. It provides out-of-the-box support for key IBC applications like ICS-20 token transfers and is designed to allow developers to create new applications as separate, self-contained crates. Similar to ibc-go, this library is also versatile enough to support a wide range of light clients, thanks to its decoupling of validation and execution logic.

Developed by Datachain, ibc-solidity is the Solidity implementation of IBC. It is currently in the pre-beta stage and does not yet have full feature parity with ibc-go. Support for ICS-20 token transfers was added to ibc-solidity this year. Datachain has also built a demo to showcase interoperability between Cosmos chains and Ethereum Mainnet using a combination of ibc-solidity and LCP (Light Client Proxy).

If you plan to build using IBC, here are tech stack considerations:

• Programming language: If you use an execution framework (the toolkit used to build your blockchain’s state machine) that is written in Golang, such as the Cosmos SDK, then you get native ibc-go support. If your blockchain is written in Rust then you can use ibc-rs. See Figure 1 for a decision tree on IBC integration based on your tech stack.

• Execution framework: Your choice of execution framework might vary based on what purpose your blockchain serves. For example, a gaming app might opt for a runtime that supports parallel execution, while a highly customizable app could benefit from a more generic framework like the Cosmos SDK. Execution frameworks such as the Cosmos SDK or Substrate offer native IBC support. We have ongoing work to add IBC to other frameworks such as Rollkit, Ethereum Mainnet, OP stack, and more.

• Consensus algorithm: At the core of IBC are light clients. And light clients effectively keep track of a counterparty’s consensus. Therefore, your choice of consensus algorithm has an impact on how you use IBC. We currently support Tendermint and the GRANDPA consensus algorithms, with support for Gasper (Ethereum), Doomslug (NEAR), and support for shared sequencers such as Astria in the works. IBC also supports a solo machine client implemented in both Go and Rust.

• Interoperability needs: Your chain’s interoperability needs might vary based on factors like security, cost, latency, generalizability, and extensibility. With IBC you get a secure, generalizable, low-cost, and low-latency solution. The only costs associated with using IBC are relayer costs since relayers have to pay gas to execute a message on the destination chain. IBC itself has no fees and therefore charges a 0% take rate. As of writing, relayer costs are not borne by end-users but we’ve developed the fee middleware that brings in-protocol relayer incentivisation. You can read more about that here.

The Interchain stack, with its core components of IBC, CometBFT, and the Cosmos SDK, offers a robust and flexible framework for building interoperable blockchain networks. 

By leveraging the Interchain stack, developers can focus on what matters most: creating impactful blockchain solutions that can easily communicate and transact with each other.