IBC Light Client
A short primer on IBC
Here is a primer on the key aspects of the Inter-blockchain Communication (IBC) protocol:
- Standard protocol for blockchain networks to communicate
- Allows transfer of data and value between heterogeneous chains
- Developed by Cosmos but blockchain agnostic
- Light clients verify state proofs from other chains
- Allow verifying transactions without running a full node
- Establishes a verified link between two chain's clients
- Enables creation of channels
- Unidirectional data pipes between chains
- Facilitate asynchronous, ordered packet passing
- Forward packets between chains along opened channels
- Can be nodes or external processes
- Asset tracking maintains fungibility across zones
- Escrow, transfer and mint/burn allows cross-chain atomicity
- Token transfers (liquidity, arbitrage)
- Atomic swaps
- Cross-chain smart contracts
- Decentralized bridges
- Oracle interoperation
- Interoperability between blockchain networks
- Expanded liquidity and composability
- Trust minimization between counterparties
- Censorship resistance via decoupling
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.
- 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.
- 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.
- 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.
- 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.
- 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.