IBC and XCMP: Enabling Interoperability in the Inter-chain World
Introduction
The notion of the multi-chain crypto ecosystem is not new; projects like Cosmos and Polkadot have been building with a vision for the multi-chain world from Day 1. As a result, they have taken a bottom-up approach toward cross-chain communication and interoperability with hub & spoke architectures.
Cosmos and Polkadot ecosystems differ drastically from how the EVM ecosystem has matured over the years. Blockchains exist in all three ecosystems, but how they communicate with each other is very different. The reason comes down to the vision of how these ecosystems have been developed:
Cosmos and Polkadot began with a vision to create highly interconnected blockchains that can communicate with each other reliably and securely.
The EVM ecosystem had no uniform vision and should be seen as a mix of blockchains with different rules, governance, and tokens but with the shared technical benefits of using the Ethereum Virtual Machine.
As a result, in the EVM ecosystem, we need bridges to establish Point-to-Point connections between different blockchains, whereas Cosmos and Polkadot come with their own unique protocols called Inter Blockchain Communication (IBC) and Cross-Chain Message Passing protocol (XCMP) that enable Hub & Spoke connections.
The Hub & Spoke architecture has many benefits for inter-blockchain communication. Cosmos and Polkadot are benefitting from this architecture to make their vision of an inter-chain world a reality using IBC and XCMP, respectively.
While the purpose of both IBC and XCMP is the same (to enable inter-chain communication), there are many differences in how they function. Let’s take a closer look at both of them!
IBC and XCMP: Overview
What is IBC?
IBC is a Cosmos protocol that enables independently developed blockchains to communicate by sending arbitrary data such as tokens in a trust-minimized manner. IBC is a core piece of Cosmos’ roadmap and offers a general purpose, permissionless, and secure solution for connecting the different blockchains within the ecosystem.
What is XCMP?
XCMP is a protocol that enables communication between the different parachains on Polkadot. It is a transport layer that builds on the Cross-Consensus Message Format (XCM), which provides the format for how message transfer should be performed. Thus, XCM provides the message that needs to be conveyed, and XCMP transports that message across Parachains.
XCMP is still under development.in the meantime, Polkadot is using Horizontal Relay-routed Message Passing (HRMP) as a stop-gap protocol. HRMP offers the same functionality as XCMP but isn’t scalable as it requires more resources because it stores all the messages in Relay Chain storage. The team plans to deprecate HRMP once XCMP is implemented (potential date?).
IBC and XCMP: Comparison
IBC and XCMP have been built specifically to cater to the needs of the Cosmos and Polkadot vision and needs. As a result, they have fundamentally different characteristics influenced by the design of their underlying blockchain protocols, consensus mechanisms, and approaches toward shared security.
How They Work
IBC – Let’s consider a scenario where assets are being transferred from Chain A to Chain B.
Users' assets are locked in a smart contract on Chain A.
Relayers sends a message, and the light client proof to Chain B in data packets from one smart contract to another via a specified channel – When a data packet is sent via a channel, it proves that the data has been sent from a specific smart contract related to the blockchain sender.
The light client proof is then forwarded, along with the block headers, to the light clients on Chain B.
On‐chain light client on Chain B trustlessly verifies that the state sent by the blockchain actually exists and executes and unlocks the assets.
XCMP – Let’s consider a scenario where assets are being transferred from Parachain A to Parachain B.
Users' assets are locked in a smart contract on Parachain A.
The smart contract on Parachain A routes a message to Parachain B.
The collator node on Parachain A adds this message to a public “outgoing” queue.
The collator on Parachain B sees this message and adds it into its own inbound queue for processing into the next block.
Validators on both Parachains verify the message transmission and include this block for Parachain B into the Relay Chain.
Security
IBC does not add any trust assumptions while enabling communication between two blockchains. IBC’s security depends on the two blockchains it is connecting and the security properties of its light clients. Thus, when using IBC, users only need to trust the two blockchains being connected, whereas the connected chains need to trust each other’s security models (receiving chains must trust the security of a message's origin as the two chains do not share state).
XCMP relies on the Relay Chain’s shared security model to deliver messages across parachains in a trust-minimized manner. All parachains share state and rely on Polkadot’s consensus, and, as a result, all messages passed through XCMP are trustless. When using XCMP, users do not have to trust different validator sets of blockchains and instead can just rely on the validator set of the Relay Chain.
However, XCMP adds a trust assumption of having at least one honest collator. Collators are full nodes of parachains and full nodes of the Relay Chain. They play a key role in message passing as they are responsible for sending and receiving messages between Parachains. Thus, it is theoretically possible for collators to censor messages.
Generalizability and Extensibility
Both IBC and XCMP have been designed as general purpose message passing protocols that are highly generalizable and extensible.
Generalizability – Both IBC and XCMP are highly generalizable, i.e., the ability to handle arbitrary cross-chain data. IBC can send any form of arbitrary data such as tokens, NFTs, contract calls, etc. Whereas XCMP can send arbitrary messages between any consensus system, which enables unique use cases such as cross-chain contract calls, inter-shard communication, etc.
Extensibility – Both IBC and XCMP are designed to be consensus agnostic and are extensible with any type of consensus algorithm. As a result, IBC can connect with any type of blockchain and even solo machines (systems that do not have a consensus mechanism). Whereas XCMP can facilitate interactions between parachains, parachains and the relay chain, and other heterogenous blockchains.
IBC extensibility is even expanding Polkadot’s interoperability as it allows chains connected with IBC to interact with Polkadot, Kusama, and their Parachains.
Closing Thoughts
IBC and XCMP offer similar functionality but are fundamentally different in how they are built since their development is highly influenced by the design of Cosmos and Polkadot, respectively. Both protocols provide enormous benefits and play a significant role in enabling Cosmos and Polkadot to achieve their visions of an inter-chain ecosystem.
To learn more about IBC and XCMP, check out:
Get Started with LI.FI Today
To learn more about us,
Head to our link portal at links.li.fi
Read our SDK ‘quick start’ at docs.li.fi
Join the official Discord server
Follow our Telegram Newsletter
or try our any-2-any swaps NOW at transferto.xyz