ELI5: What is IBC?
The birth of Bitcoin led to a Cambrian explosion of blockchains with different design decisions and use cases. While these distributed ledgers serve different purposes, they existed (and still exist to a certain degree) as silos with limited meaningful interaction.
Similar to the Internet which facilitates different types of computers in different parts of the world to communicate with one another, a similar technology that acts as the connective tissue between blockchains is necessary for true value accrual. The Inter-Blockchain Communication (IBC) protocol aims to serve this purpose.
IBC is a universal interoperability protocol that allows two different blockchains to communicate with one another. IBC guarantees reliable, ordered, and authenticated communication.
Perhaps one of the most important properties of IBC is trust-minimization. In blockchains, the property of trust-minimization is inherently linked to security. No distributed system is entirely ‘trustless’. Therefore, the question of security boils down to who or what is trusted, and how can that trust be violated i.e., what does it take for the trusted entity to be corrupted?
In this sense, and unlike most bridging solutions, 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 is no additional trust assumption required while using IBC to interact between said chains.
IBC is also more than just a bridge that facilitates token transfers. It is a general-purpose message passing protocol. This means that any form of data can be communicated over IBC.
How does IBC work?
In order to understand how IBC works, it is important to separate the two different layers of IBC — 1) the transport layer and 2) the application layer.
Transport Layer
Messages communicated over IBC are transported within data packets. And the transport layer is responsible for transporting, authenticating, and ordering these data packets.
The transport layer does not specify anything about what the data in the packets should be or how they should be interpreted by a receiving chain. From the transport layer’s point of view, information within data packets are just random bytes.
The key components of the transport layer are light clients, relayers, connections, and channels.
A light client is a lightweight representation of a blockchain. Unlike a full node, light clients do not store the entire history of all the messages contained in a blockchain. Neither do they execute transactions. Rather, light clients are designed to connect to a full node, and verify block headers (a summary of the data contained within a block). 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 blockchain which acts as a lightweight representation of B’s blockchain. When A wants to communicate a certain message ‘X’ with B, it sends the header of the block in which that message exists, along with a commitment proof of that message to B. The commitment proof is used to verify the presence or absence of a particular message on A. Using the block header and proof, B cryptographically verifies that A did indeed perform X. It is this use of light clients in IBC that allow blockchains to exchange messages with one another without the need for a trusted third party.
But A and B do not directly send these messages/data packets between each other. Instead, when A wishes to send a message to B, it commits or stores a hash of a data packet containing the message in its state machine. Relayers, which are off-chain processes, constantly observe for such messages. When they see that A has committed a message intended for B in its state machine, they simply pick up this message and pass it onto B. Note that relayers are permissionless and therefore can be run by anyone.
Connections are responsible for connecting light clients on two different chains. And channels are conduits for transferring packets between modules on these different chains. Therefore, while connections are chain-specific, channels are module-specific. Each channel end has a unique channel ID (and a port ID) that is used to accurately route packets between two modules.
Application Layer
The application layer is what end-users interact with. It consists of various applications that use the transport layer to build on top. The transport layer does not specify how data packets need to be interpreted. This role is performed by the application layer.
IBC supports a variety of applications such as fungible/non-fungible token transfers, cross-chain oracle feeds, Interchain Accounts, Interchain Queries, Fee middleware (to incentivise relayers), etc.
For example, the IBC-level application for token transfers — termed Interchain Standard 20 (ICS 20) — specifies how data packets should be structured and how they are to be interpreted by receiving chains. In the case of fungible token transfers, data packets contain information regarding the sender, receiver, amount, and denomination (IBC denom). The denom field traces the path that a particular token has gone through to reach a certain chain. Logic regarding how the packets are to be acted upon are also specified by ICS 20.
A simple analogy that can be helpful in understanding IBC is that of the mail delivery system. When you send a letter to someone, you send it through a postal service that collects the envelope containing the letter from you and deposits it into the recipient’s mailbox. The recipient then opens said envelope and reads your letter. The transport layer of IBC can be thought of as the postal service. The postal service does not tell you what the contents of the letter should be, or how the recipient should interpret your message.
Neither do they know what the contents of the envelope are. It only performs the action of collecting the envelope from point A and sending it to point B. The envelope itself can be thought of as IBC packets that are sent from one chain to another. And on this envelope, you would specify the address of the recipient. This is similar to how IBC packets contain information regarding who sent the packet (specified by the channel ID) and to whom it is intended for (specified by the counterparty channel ID). In the end, it is the receiver (application) that is responsible for opening the envelope (data packet) and interpreting the contents of the letter.
What can IBC be used for?
Apart from fungible token transfers, two other IBC-level applications include Interchain Accounts, and Interchain Security.
Interchain Accounts facilitate chain to chain interaction while remaining on a single interface. This effectively means that any action such as transfers, staking, or voting on governance proposals which can be performed on B (called the ‘host chain’), can be performed from A (called the ‘controller chain’). Interchain Accounts significantly increases composability within the Interchain by improving user-experience.
Interchain Security is the Cosmos Ecosystem’s version of shared security. It enables a blockchain to lease security from another chain in a completely opt-in manner. This is especially useful for new chains that can choose to tap into the security offered by an already established network such as the Cosmos Hub. Interchain Security removes the need for chains to bootstrap their own validator set.
The scope of applications that can be performed using IBC as a core primitive is consistently growing. Cross-chain NFT transfers and Interchain Queries (where one chain can read state from another chain) are currently being developed and will soon be production ready.
What problem does IBC solve?
In a sentence, IBC solves the problem of blockchains existing as silos with limited interaction. Interoperability between blockchains is necessary for maximal value accrual.
Each blockchain caters to one or more specialized use cases. If these use cases cannot be leveraged across multiple blockchains, it severely handicaps their utility. The breakthrough that the internet provided is that information can easily flow across different parts of the world with ease. Similarly, the utility of different blockchains need to be freely accessible across multiple platforms.
For example, users might want to use stablecoins from one blockchain, to generate yield through a liquidity pool (LP) on a decentralized exchange (DEX) that exists on another blockchain. Or they might want to leverage the privacy preserving properties that a different blockchain provides. Interoperability between chains are required to realize these use cases and more.
IBC not only solves the problem of interoperability, but it does so in a trust-minimized, secure, extensible, and general purpose manner.
How can I as an application developer use IBC?
The modular nature of the Cosmos SDK prevents developers from having to concern themselves with some of the layers of abstractions such as light clients, connections, proof verification, etc. For developers, the most relevant requirements and functions to familiarize with are channels and ports. For more detailed information on IBC, you can refer to our developer portal.
If you are building your blockchain using the Cosmos SDK, the necessary steps to enable IBC for an SDK module are detailed here. You can also apply to the Interchain Builders Program, an ICF initiative, to get support building in Cosmos.
About the author: this post was written by Adi Ravi Raj, IBC Protocol Analyst at Interchain GmbH.
