Introduction: XCM (the “message format”) vs. XCMP (a “specialized protocol”)
In order to understand XCMP, it must be differentiated from XCM. When referring to XCM (i.e. “Cross-Consensus Messaging”), we refer to the general format in which XCMP (“Cross-Chain Message Passing”) is written. The primary stated goal of XCM is to flexibly communicate various types of information sent not only between chains, but also between dApps located on different chains using XCM-based smart contracts. XCM is made to be adjustable to almost all communication scenarios within the Polkadot ecosysem, as well as well-versioned enough to stand the test of time as the ecosystem scales.
In effect, the objective of XCM is to provide a common language for communication between systems that may have very different applications or operate at different developmental levels within Polkdadot. Fundamentally, this language should be general enough to be broadly applicable, extensible enough to be future-proof and forward-compatible, and efficient enough to be run on-chain to ensure maximum shared security between communicating entities.
Overview: The Polkadot Ecosystem and Beyond
In order to understand the benefit provided by this message-passing format and protocol, it will be helpful to discuss the way Polkadot operates. The architecture of Polkadot can be understood through its constituent modules and layers using the Substrate toolkit, including the Relay Chain (Polkadot/DOT), parachains, para-objects (a catch-all term for non-native Relay Chain participants), parathreads, and bridges.
At first glance, this may seem similar to the Cosmos SDK and IBC, but a key differentiator is a network’s ability to participate in consensus at varying levels of commitment and development through native parachain integration or non-native functionality as a para-object.
The Setup: XCVM, The “Cross-Consensus Virtual Machine”
An XCM message is simply a program (or set of XCM instructions) that runs on the XCVM. The way a XCM message is implemented is by running it through the Cross-Consensus Virtual Machine, known as XCVM. XCVM is a high-level, non-Turing complete virtual machine. It is register-based rather than stack-based, and has several dedicated registers, most of which hold highly structured data. This results in a highly secure mechanism for data modification, preventing any possibility of loops and arbitrary value changes to on-chain data.
Coordinating Communication: Three General Types of XCM Message Passing
There are three different types of message formats that can allow connected networks to communicate at the modular level (not including various tools at the bridge or contract levels):
VMP – Vertical Message Passing: Allows messages to be passed between the Relay Chain and parachains, including:
Upward Message Passing (UMP)
Example: When tokens representing DOT leave the sender’s account on a parachain and are transferred into an account on the Relay Chain, the Relay Chain mints a corresponding amount of tokens and deposits into the corresponding account.
Downward Message Passing (DMP)
Example: When DOT tokens leave the sender’s account on the Relay Chain and are transferred into an account on a parachain, the parachain mints a corresponding amount of tokens on the parachain.
XCMP – (Horizontal) Cross-Chain Message Passing (Coming Soon)
Allows the parachains to send messages between themselves. Currently, Polkadot uses HRMP (“Horizontal Relay-routed Message Passing”) through the parachain Statemine to accomplish the role of XCMP until it is activated, but is much more demanding on resources since all messages must pass through the Relay Chain. Once XCMP is active, HRMP will be phased out. For a more detailed technical explanation of how to implement HRMP, check out this link.
Understanding XCMP: Bringing Chains Together
Given a broad understanding of XCM it is now easier to understand XCMP, which structurally resembles an L2 rollup of data between parachains that would then be memorialized on the Relay Chain as a metadata hash. Currently the stop-gap protocol called HRMP (known as “XCMP-lite”) is being used to offer the same cross-consensus functionality, but with all data being entered directly into the Relay Chain until XCMP is rolled out and can provide these services with less demand on network resources. XCMP’s guarantees include:
- Guaranteed Message Delivery: A receiving chain will receive the message as long as it keeps producing blocks;
- Trustless Delivery: Polkadot’s shared security ensures the correctness of message delivery and authenticity as long as we trust the code that produces and consumes them; and
- Ordered Delivery: Messages arrive in a well-defined order.
The current stop-gap solution, HRMP, is overly-taxing because data security is exclusively provided by blockspace on the Relay Chain (the half-circle in the graphic below) and secured by validators (highlighted below), which process transactions and add them to the Relay Chain. This naturally limits the ability of the network to spread this data to multiple sources and prevent congestion. In the following example, we will describe how XCMP will work, and refer to Parachain A as the “Sender” and Parachain B as the “Recipient.”
With XCMP, in order for a parachain or para-object (“parachain” refers to both simultaneously here) to send a message directly to another lateral parachain, the message/transaction from the Sender will be collected first by a Collator Node (highlighted below).
These messages collected by Collator Nodes are only transmissible between parachains if the Sender and Recipient are connected via a one-way XCMP channel between the parachains (highlighted below).
The message collected by the Sender parachain’s Collator Node is then “gossipped” between the light and full nodes on the Relay Chain before reaching the Recipient parachain.
This data must contain at a minimum the destination address and a timestamp, which uniquely identifies each message.
The message will eventually make its way to the Recipient parachain, where Collator Nodes have been actively querying data destined for their parachain. Collator Nodes act as full nodes for the parachain, and are also in constant contact with the parachain’s full nodes participating in the Relay Chain.
After processing and verifying the message, the Recipient parachain’s Collator Node adds the message to a new proposed block for the Relay Chain, which includes the Sender parachain’s message.
Once the proposed block is created by the Collator and submitted to the Validator, the Validator begins validating the new block. If accepted, this block is compressed into a hash and placed onto the Relay Chain.
At this point, the data has been successfully sent from the Sender, Parachain A, to the Recipient, Parachain B, and has been officially added to the Relay Chain.
To participate in XCMP, Substrate chains will be able to participate natively, while projects that are already running as “solochains” or in isolated environments will be able to participate in consensus as “para-objects,” a catch-all term for objects running in parallel to the network that are “plugged-in” to the consensus mechanism without native Substrate integration.
The Big Picture: XCMP Will Help Polkadot Meet Networks in the Middle
Whereas other chains have tried to lure protocols closer to their core ecosystem and standard toolkit (such as IBC), Polkadot is trying to foster a modular interchain future. XCMP allows collaboration between participant networks while allowing them to maintain their own sovereignty and participate at their own voluntary levels of commitment through a flexible and simple shared messaging language. This modularity is even being explored across other cross-chain solutions, with IBC integration expected in the future to bring Cosmos chains to additional levels of interconnectivity. Other projects, such as Statemine/Statemint, will allow interaction with the Relay Chain beyond the main assets of DOT and KSM, and the creation of any number of sovereign assets participating through these parachains. In Polkadot’s eyes, the future will be not just interchain, but also modular and flexible, with Polkadot’s approach leading the way.
