Polkadot Cross-Consensus Messaging Format (XCM)

What is a Cross-Chain Bridge?

To understand what XCM is and how it works, we need to look into what a cross-chain bridge is and why it is important in the blockchain industry. As the name implies, a cross-chain bridge enables the transfer of assets across different blockchains. These chains may be composed of different protocols and operating models, but the bridge ensures interoperability and fluidity between them by enabling token transfer, data exchange, and feedback flow between the independent platforms.

Interoperability has been an important component of the financial system. The advent of blockchain technology made it more prominent, and Decentralized Finance — DeFi created a more pressing need for it since there is more demand for asset transfer across chains. As such, having a bridge to make this possible is inevitable. For example, if you have KSM on the Kusama network but want to spend it on the Parallel Heiko network, you can transfer it to Heiko using a bridge.

Overall, a cross-chain bridge serves as a neutral zone that enables users to deploy assets for fast and easy transactions irrespective of blockchain and reduces operational difficulties by allowing access to multiple blockchains through the same network.

Now, to better understand how the Cross-Chain bridge works, we need to dive into what a Cross-Consensus Messaging (XCM) format is. This will help us understand its importance in parsing information across different chains and ensuring interoperability across different protocols.

Cross Consensus Messaging (XCM) Format

Cross-Consensus Messaging (XCM) Format was first mentioned in Polkadot’s documentation and, by extension, Kusama. It evolved from Cross-Chain Messaging Format to become a robust architectural style of message transfer for more than chains but also pallets, smart contracts, bridges, and sharded enclaves.

XCM is not a protocol. As such, it cannot parse messages across consensus by itself. Rather, it is a format for how message transfer should be performed and a language for ideas between consensus systems. The architecture of Polkadot and Kusama allows the interoperability of parachains, enabling the cross-chain transfer of assets and data. To achieve this, an XCM format defines the language around how the message between two chains should be parsed.

XCM has the following properties:

• Generic, extensible and customizable: Although it was first mentioned in the Polkadot documentation, XCM is not specific to it. It aims to be a generic, extensible, and customizable language format between different consensus for use with free and gas-metered parachains, their relay chain, smart contract platforms, and more.
• Interacting with a system whose transaction format is unknown: XCM is well-defined, abstract, and versatile and can be used to provide a long-lasting transaction format for wallets to create many common transactions.
• It is highly efficient to operate in a tightly constrained and metered environment, as with many chains.

XCM Transport Protocols

Polkadot and Kusama implement two types of cross-consensus transport protocols for acting on XCM formats between their constituent parachains, Heiko being one of them. They include:

• VMP (Vertical Message Passing): VMP protocol is responsible for message transfer between relaychains and parachains, and it is further divided into two:
• UPM (Upward Message Passing): This allows parachains like Heiko to send messages to their relaychain (Kusama).
• DMP (Downward Message Passing): It allows relaychains, e.g., Kusama, to pass messages down to their parachains, e.g., Heiko.

Parallel Heiko Cross-Chain bridge currently implements a DMP protocol, and we plan to integrate other XCM transport protocols in the future.

• XCMP (Cross-Chain Message Passing): This transport protocol allows transferring messages and data between parachains on the same relaychain. It resolves cross-chain transactions using a simple queuing mechanism based on the Merkle tree to ensure fidelity. Here, relaychain validators are saddled with the responsibility of moving transactions on the output queue of one parachain into the input queue of the destination parachain. Only the metadata of the transaction is hashed and stored in the relaychain.

The input and output queues are sometimes referred to in the relaychain codebase and associated documentation as ingress and egress messages.

While XCMP is being developed, Polkadot has a stop-gap protocol referred to as Horizontal Relay-routed Message Passing (HRMP) in its place. Messages transferred by this protocol are stored and read from the relaychain.

XCM Token Transfer Models

XCM can request recipient system-specific operations or optionally include gas fee payments for requested operations on a target network. However, here are some of the identified transfer models and common use-cases of XCM:

• Asset Teleporting: involves the movement of an asset from one chain to another, e.g Kusama to Parallel, by destroying the amount being transferred in the origin chain and creating a clone (same amount as destroyed) on the target chain. This is similar to how Parallel Heiko Cross-Chain Bridge operates. It creates a clone of the KSM from the relaychain (same amount and value) on Heiko and destroys that amount from the relaychain to be utilizable by the user on Heiko (we plan to include other models in the future).
• Remote Transfers — involves asset movement from one chain to another via an intermediate account in the origin chain that is trustlessly owned by the target chain. The XCM execution in the target chain mints a derivative of the assets representing a target address. The derivative asset is always interchangeable with the native asset 1:1. Parachains like Moonbeam support remote transfers.

More information about XCM can be found in the Polkadot Wiki.