IBC and XCMP: A Comparison of Interoperability Protocols
The inevitability of a multi-chain ecosystem is upon us. By definition, the multi-chain precipitates a need for interchain communication. While bridges perform one specific function within the broader interoperability scheme — namely token transfers — they are inadequate for the requirements of an interchain ecosystem with nuanced use cases. The series of bridge hacks witnessed over the past few years have consistently proven that third-party bridge implementations that are custodial in nature do not provide for secure and reliable asset bridging.
The need of the hour is for a general purpose, permissionless, secure, and expansive technology that can act as the connective tissue between blockchains while remaining fault-tolerant. Inter-Blockchain Communication (IBC) and Cross-Chain Message Passing (XCMP) are two of the protocols that aim to manifest this vision of an interchain world.
This piece aims to provide a comprehensive overview of both the aforementioned cross-chain communication protocols. For readers unfamiliar with IBC and XCMP, a brief description of the two will be laid out in the next section. After building a foundation, this piece juxtaposes the two protocols to understand the similarities, differences, and the advantages or disadvantages one has over the other.
The characteristics for comparison will be based on the level of security, generalizability, extensibility, user experience, and developer tooling. Finally, we conclude by summarizing some of the highlights from this piece.
What is IBC?
IBC is a protocol that allows heterogeneous blockchains to communicate arbitrary data in a reliable, ordered, and trust-minimized way.
The fundamentals of IBC are light clients and relayers. Chains A and B communicating over IBC possess light clients of the counterparty ledger. Chain A, without the need for a trusted third party, can arrive at consensus about the state of chain B by verifying block headers. Chains interacting over IBC (specifically modules) do not beam messages to one another. Instead, chain A commits some message in a data packet to its state. Permissionless off-ledger processes termed ‘relayers’ then observe for such packets and carry them across to the counterparty.
On a high level, IBC can be differentiated into two layers. The IBC TAO (transport, ordering, and authentication) and the application layer.
IBC TAO assumes nothing about the information contained within data packets sent over it, and is entirely un-opinionated about how these packets should be structured. It is only responsible for ensuring reliable, ordered and authenticated communication. It is the application layer i.e., the modules that decide how packets should be interpreted.
IBC can be implemented right off the bat for any blockchain using the Tendermint and Cosmos SDK stack. It can also be integrated with other blockchains which might be of a UTXO or Account-Based model, with probabilistic finality such as Bitcoin or Ethereum.
IBC serves as the backbone for the ‘Internet of Blockchains’ vision that Cosmos adheres to. In this sense, the design choices of IBC were influenced by the TCP/IP specification. Similar to how TCP/IP lays out the standard for computers to communicate, IBC specifies a general set of abstractions that, when implemented, allows blockchains to communicate. Just as TCP/IP is unopinionated about the contents of data packets relayed over the network, so too is IBC. And similarly to how application protocols such as HTTP and SMTP are built on top of TCP/IP, the same can be said for IBC where applications such as fungible/non-fungible token transfers or cross-chain smart contract calls use the protocol as a foundational layer to build upon.
What is XCMP?
XCMP is Polkadot’s version of cross-chain communication. It is a protocol based on a simple queuing mechanism that allows a parachain to speak to another parachain. XCMP is characterized by guaranteed, trust-minimized, and ordered message delivery. It is a transport layer that uses the Cross-Consensus Message Format (XCM). As the name suggests, XCM provides a format for the arbitrary data that XCMP can transfer between arbitrary systems. In other words, XCM is the message conveyed between chains and XCMP is how that message is conveyed.
Parachain A wishing to communicate with parachain B opens a bidirectional channel (or two unidirectional channels) that uniquely identifies the counterparty parachain. Parachain A initiates a cross-chain message which is picked up by a collator node of A and placed within A’s outgoing message queue. Collators are essentially authority nodes that maintain full nodes of both the relay chain and their assigned parachain. A collator node on parachain B scans for any incoming messages. When it observes the message from A, it places that message into its incoming queue. This message is then processed and included in a new proposed block by that collator node and sent to the relay chain for verification. Once the parachain block is successfully verified by the validators, a hash of this block is included in the relay chain.
Similar to IBC, XCMP guarantees trust-minimized message delivery without specifying how those messages should be interpreted by the receiving chain. The role of executing code/interpreting logic is performed by SPREE modules. Shared Protected Runtime Execution Enclaves (SPREE) are blobs of WebAssembly code that are uploaded to the relay chain through a governance proposal. Parachains can decide to opt-in to the logic performed by a SPREE module. SPREE plays an important role in complementing XCMP in the sense that XCMP guarantees message delivery while SPREE guarantees message execution.
Apart from XCMP, Polkadot also features two different transport mechanisms that use the XCM format. Namely Upwards Message Passing (UMP) and Downwards Message Passing (DMP). The former is responsible for passing messages from the parachain to the relay chain while the latter passes messages from the relay chain to a parachain. UMP and DMP fall under the umbrella category of Vertical Message Passing (VMP).
It is important to note that XCMP is currently in development (although XCM is live). Instead, a stop-gap protocol termed Horizontal Relay-routed Message Passing (HRMP) has been implemented. HRMP is fundamentally unsustainable due to the fact that all cross-chain messages have to be stored on the relay chain, making it highly resource intensive in terms of storage and cost. Polkadot plans to phase out HRMP once XCMP is battle-tested and ready to ship.
In contrast, IBC has been live since April 2021. And during this period, it has witnessed significant adoption. As of writing, 46 chains are interconnected over the protocol with a 30-day volume of 5 billion USD worth of transfers flowing through the IBC pipelines.
The first mover advantage of IBC and the fact that XCMP is under development does not discard the scope for a comparison between these two protocols. This is primarily due to the fact that the architecture and design choices of XCMP — despite not being live — have already been established.
Comparing IBC and XCMP
This section discusses the advantages/disadvantages, as well as the differences and similarities between IBC and XCMP. The following properties are taken into consideration while comparing the two standards:
- Security
- Generalizability
- Extensibility
- User experience
- Developer tooling
Given that both protocols aim to achieve the same goal of interoperability, there exists a handful of commonalities between the two. But since the underlying architectures of the Cosmos and Polkadot ecosystems are fundamentally different from one another, and given that certain properties of IBC and XCMP are the properties imposed by their respective protocol architecture, there are a number of crucial differences between them.
Note that because of Polkadot’s interoperability design, some of the above-mentioned properties will be applicable more to XCM rather than XCMP. In such cases, the differentiation will be clearly defined. In a sense, the IBC TAO layer maps to XCMP while the application layer of IBC maps to XCM. Hence, a comparison of IBC with XCMP is not complete without discussing XCM.
Security
IBC
In distributed systems, the property of security is inherently linked to the property of being trust-minimized. Therefore, understanding a blockchain’s degree of security implies understanding its degree of trust-minimization.
In the Cosmos Ecosystem of application-specific blockchains, networks secure themselves. Each chain has its own validator set and therefore its own security model. As mentioned in the previous section, the authentication and ordering of data packets in IBC are performed by light clients. From IBC’s point of view, two ledgers communicating over the protocol, boils down to the light clients on either side maintaining and updating state of its counterparty. As a result, the security properties of IBC boils down to the security properties of the light clients. In short, IBC portrays interaction between the consensus algorithms of different blockchains through their light client implementations.
This means that if you trust two particular chains to use the functions they provide (and by default their consensus algorithms), then there is no additional trust assumption required while using IBC to interact between said chains. Hence the term trust-minimized.
It is noteworthy that IBC will play an important role in enabling Interchain Security — the Cosmos Ecosystem’s version of shared security. Once this feature is rolled out, blockchains within the ecosystem will have the option to either secure their own chain, rent security from the Cosmos Hub, or do both (termed Layered Security).
XCMP
By way of Polkadot’s shared security model, all parachains derive the economic security of the relay chain. As soon as a parachain secures a slot for itself on Polkadot and connects to the relay chain, the validator set securing the relay chain also secures the parachain. This means that the cost of corrupting a parachain is equivalent to the cost of corrupting any other chain in the ecosystem, including the relay chain. From an operational standpoint, parachains need only maintain collators that convey state transition proofs to the validators.
XCMP derives its property of trust-minimization from this shared security model, where the correctness of message delivery and its authenticity are guaranteed by the security properties of the relay chain, without the need for a trusted third party. Since the same validator set secures all parachains, cross-chain communication over XCMP does not require two different validator sets to be trusted. Rather just one.
But this does not entirely mean that XCMP does not impose additional trust assumptions. Since collators are responsible for sending and receiving messages between parachains, it is theoretically possible for them to censor messages. For example, collators can receive messages but choose to not deliver them. Therefore, XCMP imposes the additional trust assumption of there being at least one honest collator.
Generalizability
IBC
IBC is designed as a general-purpose message passing protocol. Which means that any form of arbitrary data (fungible and non-fungible token transfer, governance votes, smart contract calls, etc.) can be communicated over IBC.
Data packets relayed over IBC can contain different information depending on the application it serves. For token transfers, packets contain information pertaining to the token denomination, amount, sender and receiver addresses. For cross-ledger governance — where an account on chain A can cast its vote for a proposal on chain B — the packets contain vote information. And for cross-chain account management (aka Interchain Accounts), packets contain information regarding the type of message to be passed. Packets sent over IBC can also contain information regarding the composition of a certain validator set and their voting power. This is one of the functions performed by IBC for Interchain Security (the specific IBC-level protocol used for Interchain Security is termed ‘Cross-Chain Validation’).
Nearly all of the above mentioned applications of IBC have been implemented by various Interchain native products that IBC has opened the gateways for. For example, Osmosis and the Crescent network both have decentralized exchanges (DEXs) that leverage IBC for interchain token transfers. The Quicksilver Protocol is an example of a Cosmos zone implementing Interchain Accounts to vote on proposals that exist on different chains while remaining on a single platform. Osmosis and Quicksilver are also poised to become the first chains to make use of Interchain Security.
XCM and XCMP
Given that XCMP acts as the transport layer that passes messages of the XCM format (although it can use any other proposed format), XCMP’s generalizability is closely linked to the general purpose nature of XCM.
XCM is designed to facilitate the transport of arbitrary information between different consensus systems. One of the primary goals of XCM is to abstract the low-level details of cross-consensus communication. This creates use cases such as interaction between two smart contracts on different blockchains, cross-chain communication over bridges, or inter-shard communication.
As of now, some of the use-cases slated for XCM are:
- Teleporting: token transfers in the form of burning an asset on one chain and minting an equivalent amount on another chain. Reverse-Based Transfers also make use of the token transfer application.
- Remote transfers: similar to Interchain Accounts where an account on a ‘local chain’ can control an account on a ‘remote chain’. XCM messages in this case will contain the local and remote account information along with the action to be performed by the local chain on the remote chain.
- Platform-specific functions: XCM is also intended to allow for a parachain (or any Substrate-based chain) to dispatch a remote call to one of its numerous pallets to leverage a specific feature or functionality.
Extensibility
IBC
For interoperability protocols, the property of being extensible means whether or not it can be deployed on different domains (which are not limited to blockchains).
While the instant finality guarantees of Tendermint and the modularity offered by the Cosmos SDK are certainly desirable for a ledger to implement IBC, they are by no means necessary requirements. IBC is designed to be consensus agnostic and extensible with current and any future iterations of consensus algorithms that might be invented. To connect blockchains with probabilistic finality such as Ethereum, a unique proxy-chain called a peg-zone is utilized. Peg zones are IBC-enabled due to their instant finality and serve to establish finality guarantees for the chain it connects with (Ethereum in this case). The Gravity Bridge is an example of a chain using such a peg-zone to interoperate Ethereum and the Cosmos ecosystems.
Development is currently ongoing to interconnect Substrate-based chains using IBC. This would allow parachains on Polkadot and Kusama (Polkadot’s canary network) to communicate with other chains connected over IBC. The team at Composable Finance contributing to the development of the Substrate IBC pallet is also actively working to bring IBC to the NEAR protocol. An integral part of the range of interoperability tools that Composable Finance offers is the Cross-Chain Virtual Machine (XCVM). XCVM is a platform for developers to deploy smart contracts that can communicate with other smart contracts on different platforms. It uses IBC and XCM as the transport layer to facilitate native interoperability between dapps.
Not only can IBC be used to interconnect blockchains with disparate consensus algorithms, but can also connect with solo machines (systems without consensus algorithms). For example, using an IBC solo machine, one can issue IBC-enabled native tokens on the Crypto.org chain without the need to build a blockchain that connects with IBC.
XCM and XCMP
Similar to the property of generalizability, XCMP’s extensibility is connected to XCM’s degree of extensibility. XCM is built to create general purpose message formats that can be understood across arbitrary consensus systems. One of its design goals is to be future-proof and forwards compatible. Consensus-agnosticity is yet another key property of XCM. This means that its scope goes beyond parachains speaking to the relay chain or inter-parachain communication. It can also, in theory, facilitate interaction between entirely heterogeneous blockchains that adopt this messaging format.
To comment on the architecture that exists today, and as previously mentioned, there exists three main transport protocols that employ XCM — XCMP, UMP, and DMP. None, in their current form, are capable of facilitating interoperability between Polkadot and another standalone blockchain. At the moment, being interoperable using XCMP, UMP, or DMP implies being a parachain. Nevertheless, it is conceivable that a transport protocol leveraging XCM, which can indeed enable communication between Polkadot and other independent blockchains may exist in the future.
User experience
IBC
From an end-user’s point of view, IBC transactions are seamless. While there are multiple platforms through which IBC transfers can be initiated, consider the example of an IBC transaction through the Crescent DEX. If user Alice wants to provide liquidity to a pool using her ATOM tokens, or swap them for other tokens, she can connect her Keplr wallet on the DEX and perform these functions instantly.
Sending her ATOMs from the Hub to the Crescent DEX is an IBC transfer given the funds are moving across two different blockchains — Cosmos Hub and Crescent DEX. And yet Alice does not need to know what an IBC transfer is or how to initiate one. While depositing her tokens on the DEX, the UI automatically fills in her Crescent public address as shown below.
IBC transfers — a deposit from the Hub to Crescent in this case — are fast, cheap, and easy to verify. The transaction shown below only took a few seconds to execute, as indicated by the timestamps in the minstcan block explorer.
The property of instant finality offered by Tendermint ensures that any function a user might want to perform using IBC is cost-efficient. The transaction in this example was merely a few cents.
Osmosis is another IBC-enabled zone that entirely abstracts away the concept of inter-chain transfers from end-users. The Osmosis DEX provides a sleek and easy to navigate interface for users to swap, stake, provide liquidity, or participate in governance.
Interchain Accounts use IBC to further simplify the Interchain UX. It allows an account on blockchain A (controller chain) to control an account on blockchain B (host chain). In the most broad sense, this means that anything Alice can do on her chain B account (vote, stake, transfers) can be performed from her chain A account. This works by bundling a transaction to be executed within an IBC packet, which is then sent from the controller to the host chain. The message is then unbundled on the host chain and executed as a local transaction. Using Interchain Accounts drastically reduces the need to platform hop, as well as the time it takes to perform a certain function.
XCM and XCMP
XCM went live on May 4, but as of writing this, no XCMP channels for cross-parachain communication are currently available. Nevertheless, users can still get a feel for how XCMP transfers would work by sending assets between Moonbeam and Acala over HRMP. Moonbeam is vanilla Ethereum deployed as a parachain. And Acala is another parachain that aims to serve as the DeFi Hub for Polkadot where users can stake, swap, lend and borrow assets.
Active development is ongoing within the Polkadot ecosystem to integrate XCM with all parachains. The first XCM integration on Moonbeam was recently deployed. Users on Moonbeam can now transfer their native DOT tokens from the relay chain to Moonbeam and use them on EVM compatible dapps within the ecosystem.
Another currently live XCM capability is fungible token transfers between the relay chain and Acala. With Acala launching their liquid staking product offering, users can now send their DOT from the relay chain to Acala and liquid stake those tokens. The Acala platform features an intuitive and simple user interface for bridging tokens, participating in governance, LP-ing, and liquid staking.
After connecting your Polkadot{.js} wallet on the platform, moving DOT from the relay chain to Acala will auto-fill your destination address on the UI. Transfers enabled through XCM are executed within a few seconds and usually costs less than a dollar.
Developer tooling
IBC
Software tools available to individuals building in the Cosmos Ecosystem span from a high-throughput BFT consensus engine (Tendermint Core), a modular framework to build a state machine (Cosmos SDK), and the means to boundlessly interconnect a blockchain with other datasystems through IBC. All of which have, over time, been made available as a series of public goods from 2017 onwards. Since their initial releases, each of these public goods have continuously been iterated upon based on the feedback shared by teams using them.
If you’re building an application using the Cosmos SDK, enabling IBC is as simple as importing the IBC module and making a few changes to your codebase as detailed here. You can also create your own custom IBC application module.
On the side of light clients and relayers, the Tendermint light client implementations in Golang and Rust, as well the Solo Machine light client are in production. Light clients for EVM and Substrate-based chains are currently under development. For relayers, implementations in Golang and Rust are active.
Apart from the tools necessary to implement IBC, the Cosmos Ecosystem offers a broad suite of products for developers to build their own sovereign blockchains. For example, Ignite CLI — built using the Cosmos SDK — helps spin up production-ready blockchains within minutes, connect with other IBC-enabled chains using a built-in relayer, and more.
As a result of the quality and accessibility of the tools available, development activity on Cosmos has outperformed other ecosystems over the past few years (as shown by the chart from Messari below). According to a recent report published by chaindebrief, developer growth from 2020 to 2021 was 72% in the Cosmos Ecosystem as opposed to 47% at Polkadot.
XCMP
Substrate and Cumulus form the SDK — or PDK (Parachain Development Kit) — available for developers to build parachains or parathreads. Similar to the Cosmos SDK, the PDK substantially reduces the time and energy it takes to spin up a new blockchain. Building a Substrate-based chain allows for seamless integration within the Polkadot ecosystem and interaction with other parachains, while being secured by the relay chain.
Developing a chain using the Substrate application provides a number of useful features out of the box, like the P2P networking, consensus layer, and storage. But it does not provide direct compatibility with Polkadot. For this purpose, Cumulus, which acts as an extension to Substrate, can be used to build parachains that can connect with their counterparts as well as the relay chain. It provides the necessary tooling needed to implement the fundamental aspects of a parachain such as the state-transition function and collators. Implementing XCMP will also be possible in the future using Cumulus.
Aside from the PDK, Polkadot also offers a range of useful tools for developers such as an XCM simulator, a Substrate contracts pallet which supports WebAssembly smart contracts with its own native programming language ink!, a CLI tool for the Polkadot API, and an XCM testnet Rococo where parachains can interact with one another by routing messages via the relay chain.
Conclusion
The economist Thomas Sowell famously wrote that “there are no solutions, only trade-offs”. This holds especially true for designing distributed systems. There is no one correct solution to building an interoperability standard, only trade-offs. In this sense, Cosmos and Polkadot have opted for two very different kinds of tradeoffs through their respective design decisions.
The primary differences between IBC and XCMP are highly influenced by the underlying protocol design as well as the respective consensus algorithms. Polkadot’s shared security model introduces a high degree of dependency between the relay chain and parachains. It also imposes a number of resource constraints. For example, there exists a cap on the number of XCMP channels that a parachain can open with its counterparts along with an economic cost associated with channel opening.
Having said that, the advantages of shared security cannot be overlooked. Parachains have the benefit of being secured by the relay chain from day one. In contrast, Cosmos zones are more vulnerable to an attack during their early stages since they need to bootstrap their own validator set. Upon launch, Interchain Security addresses this issue.
But on the other hand, securing your own chain adds to the absolute sovereignty that Cosmos zones enjoy. This allows users and builders to decide the fate of their network without being beholden to a central authority whose interests may not always be aligned with the interests of others.
While IBC is not without its limitations, the channel-specific drawbacks and the resource constraints that characterize XCMP is non-existential on IBC. An ecosystem of application-specific chains interconnected over IBC impose no dependencies among one another. The very nature of the Cosmos design allows for independent chains to fail without affecting other chains.
This property of fault-tolerance in an interoperability standard cannot be overstated. Recent events at Terra have been an example. Terra is one of the blockchains that is IBC-enabled. Despite the chain coming to a halt, and its stablecoin losing almost all of its value, the fact that Terra was interconnected with other chains created no risk because of IBC itself. Amidst the crisis, IBC showed no compromises in security, reliability, or performance.
Cosmos and Polkadot envision a world where blockchains mutually share and compound value. To achieve said vision, both networks have chosen approaches that are technically and philosophically different from one another. Nevertheless, it is important that both ecosystems continue to build and create value in order to bring the Interchain to fruition.
About the author: this post was written by Aditya Ravi Raj, Protocol Analyst at IBC
