<aside> 📘 IBC
IBC | Getting Started With IBC: Understanding the Interchain Stack and the Main IBC Implementations
</aside>
https://github.com/cosmos/ibc-go
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.
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.
High-level depiction of IBC packet flow between two blockchains
High-level depiction of IBC packet flow between two blockchains
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.