<aside> 📘 IBC
IBC | Getting Started With IBC: Understanding the Interchain Stack and the Main IBC Implementations
</aside>
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.
Figure 1: High-level overview of how IBC works
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.