IBC Support On Cascade
Inter-Blockchain Communication Protocol (IBC) is a protocol that allows blockchains to talk to each other. It was developed as a key part of the Cosmos ecosystem, allowing the connected blockchains to transfer assets and data between one another, fostering greater interoperability.
We’re excited to announce our latest developments on IBC support for Cascade powered with Eclipse's Solana roll-up technology. Let’s see how it works.
IBC stands out among various blockchain bridging solutions due to its unique features.
Interoperability
IBC enables the communication between heterogeneous blockchains, including those with different consensus algorithms, token models, and state machines, fostering a more connected and efficient ecosystem.
IBC, by design, cannot be “hacked”. IBC just sends and receives packets of data and leaves the interpretation to the blockchains.
No protocol is truly trustless, meaning all protocols rely on some level of trust, like the underlying technology or the individuals or entities who participate in the network. As far as you trust the security of the chains you’re using, you can trust IBC.
It does this by allowing for the verification of proofs and data from other chains without relying on any middlemen like trusted third parties or validators.
We’ll see this in more detail soon.
IBC allows for horizontal scaling by enabling communication between multiple parallel chains, distributing the workload, and mitigating congestion on individual chains.
Each blockchain connected through IBC retains its own consensus and governance mechanisms, ensuring the preservation of its sovereignty and autonomy.
Before we look at how IBC is being implemented for Cascade, it's important to understand how IBC works in general.
A general diagram of an IBC transaction life-cycle transaction. Source: Ignite docs
IBC requires both chains to have these four main components to communicate:
- Core Protocol: The IBC protocol itself, which defines the rules and methods for communication, including data formats, validation, and transaction protocols.
- Light Clients: Programs running on one blockchain that can understand and verify the state of another blockchain. This is necessary for blockchains to trust the data they receive from each other. Light clients include only a “summary” of the data present on a chain, unlike full nodes. This is done to reduce computational load.
- Modules: These are specific implementations of the IBC protocol that define how to encode, decode, and validate application-specific information. An example might be a cross-chain token transfer(ICS20) or NFT transfers(ICS721).
- Relayer: A relayer is an off-chain process that reads the state of both chains and submits appropriate transactions to each, effectively acting as the "messenger" between the two chains. This can include, for example, the process of submitting proofs of packet receipt to the originating chain.
Suppose Cascade wants to communicate with ‘Chain X’ using IBC; here’s how the process would work.
Cascade wants to establish communication with Chain X. Both chains create a light client of themselves on the opposite chain. Cascade’s light client will be on Chain X and vice versa, which can validate the data(”client state”) and consensus mechanism(”consensus agreement”) of the other blockchain.
Once the client has been created, the next step is to establish a connection. A connection represents a link between two different chains.
This involves a handshake protocol, which is initiated by one blockchain and must be confirmed by the other with modules bound to a specific port. One module can bind to multiple ports. Once the connection is open, it can be used by any number of channels.
A channel is a line of communication between two modules on different chains, represented by their ports.
Connection Establishment
For every connection, each chain uses a specific client to communicate with its counterparty chain. The same client can be used with multiple connections.
Channel Close
With channels established, packets of information can be sent from Cascade to Blockchain X. Packets can contain any kind of data, and it's up to the application layer (the part of the software stack where user interactions occur) to decide how to interpret the packet.
Packet Delivery
The relayer monitors both chains and passes information between them. When a packet is sent from Casacade to Blockchain X, the relayer submits a proof of this packet to Blockchain X. Blockchain X, through its IBC light client, can verify this proof against its own consensus state and accept the packet.
Relayers
Once the packet has been processed, an acknowledgment is created and sent back to the original blockchain. This is again facilitated by the relayer and lets the original blockchain know that the packet was successfully processed.
Cascade is an Eclipse rollup chain running the Solana VM environment. Since the Eclipse environment is not built from the Cosmos SDK, IBC support must be added.
The current implementation of IBC contains the following parts:
- Interface for Solana VM clients: We add a new IBC native program that handles any IBC messages, including connection and channel creation and packet messages. This native program also implements ICS 26: Routing Module and will later contain a way for approved modules to bind ports.
- Due to limitations in Solana’s transaction size, some transactions need to be split into multiple parts by temporarily storing transaction data in an account. This change is in progress.
- Relayer: We have a barebones CLI called
eclipse-ibcthat can read chain state between two Eclipse chains and act as a poor man’s relayer. Our plan is to take this work and integrate it into the relayer.
Here is a demo showing the establishment of an IBC connection between two Eclipse chains:
.gif?alt=media&token=f61275ed-c963-4d89-9399-df1d5bbf0cff)
IBC connection between two chains