The Inter-Blockchain Communication (IBC) protocol is a standard communication protocol that enables blockchain networks to interoperate with each other. It allows different blockchain networks to communicate and transfer value in a secure manner, creating a truly decentralized and interconnected ecosystem. For the Cosmos ecosystem, IBC is a critical component that enables Cosmos chains to connect and interact with each other, enabling new use cases and expanding the reach of the ecosystem. With IBC, Cosmos chains can seamlessly transfer assets, data, and logic across different chains, opening up new possibilities for decentralized applications and enabling greater network effects.

Additionally, IBC is not limited to only Cosmos chains. With the emergence of multi-chain ecosystems such as Polkadot and Ethereum 2.0, the ability to communicate and transfer value between different chains will become increasingly important for users. IBC provides a standardized protocol for cross-chain communication, allowing for interoperability between chains regardless of their underlying technology or consensus mechanism. This opens up a wide range of possibilities for users, such as accessing decentralized applications and assets on different chains or taking advantage of unique features and capabilities of different ecosystems.

Clients

This shows:

Chains establish IBC connection handshake
Each chain sends header and commit proofs to the other
The receiving chain verifies the proof using the IBC client
This allows each chain to verify proofs from the other without running a full node
When sending IBC packets, the destination chain can use its light client to verify packet proofs from the source chain

So the IBC clients allow trustlessly verifying proofs and packet data to facilitate cross-chain interoperation without the overhead of running full nodes.

Connection Handshake

Explanation:

The connection handshake allows two chains to establish a secure, verified link between their respective IBC clients.
Chain A's client creates a connection handshake packet to start the process. This contains data like Chain A's client ID, desired connection version and parameters, proofs, and signatures.
Chain A relays this packet to Chain B via an IBC relayer.
Chain B's client verifies the handshake packet - the signatures match Chain A's client, the proof can be validated, and the parameters are acceptable.
Chain B stores details like Chain A's client ID and consensus state to retain connection information.
Chain B constructs its own handshake packet to respond to Chain A, containing symmetric proofs and details.
Chain B relays its handshake response packet back to Chain A.
Chain A verifies Chain B's handshake response, stores the connection info, and sends a confirmation to complete the handshake.
This establishes an authenticated, verified link between both clients.
Now the chains can construct channels over this connection to pass application data.

So the two-way handshake allows the clients to verify each other's proofs and signatures to establish trust required for further cross-chain interactions like creating channels.

Channels

Explanation:

IBC channels are unidirectional data pipelines allowing asynchronous cross-chain communication.
Chain A endpoint module sends an IBC data packet destined for Chain B.
Relayer picks up and forwards the packet to Chain B.
Chain B receives the packet on its endpoint module and processes it.
Chain B sends back an acknowledgement to Chain A to confirm receipt.
Relayer forwards this acknowledgement back to Chain A.
Chain A receives confirmation that the packet was processed on Chain B.
Channels have ordering guarantees so packets are processed in order.
Multiple channels can exist between chains for different applications.
Channels are separate data pipes allowing modular communication between chains.

So in summary, IBC channels provide ordered, unidirectional data flow between chains facilitated by relayers. This allows modular cross-chain communication.

Relayers

Explanation:

IBC relayers forward packets between blockchains along opened IBC channels.
Chain A sends an IBC packet destined to Chain B to a relayer.
The relayer stores the packet temporarily until it can be forwarded.
The relayer then forwards the packet to Chain B along the channel.
Chain B sends back an acknowledgement that is picked up by the relayer.
The relayer completes the loop by relaying the acknowledgement back to Chain A.
Relayers can be blockchain nodes or external validator processes dedicated to packet relaying.
There can be multiple relayers to prevent single points of failure.

So in summary, relayers provide the key role of forwarding IBC packets and acknowledgements between blockchains to facilitate cross-chain communication.

Transferring Value

Explanation:

IBC enables cross-chain atomic token transfers between chains.
On Chain A, the sender escrows tokens into the IBC module. This locks the tokens.
Chain A relays a packet to Chain B to transfer the escrowed tokens.
Chain B verifies the packet data then mints new tokens to the receiver.
Chain B confirms successful minting back to Chain A.
Finally, Chain A releases the tokens from escrow by burning them.
The escrow mechanism ensures the tokens are not double-spent across zones.
Minting/burning allows transfer of fungible value while maintaining total supply.

So IBC enables atomic cross-chain token transfers while tracking assets across zones to maintain fungibility.

PreviousLandslide EVM NextRelayer Operator Guide

Last updated 2 months ago