Skip to main content

XCM Transport Methods (XCMP, HRMP, VMP)

XCM Documentation

For a more practical approach to utilizing XCM, refer to the XCM Docs. Please keep in mind that XCM is under active development.

With the XCM format established, common patterns for protocols of these messages are needed. Bitzal implements two message passing protocols for acting on XCM messages between its constituent synochains.

There are three primary methods for message passing, one of which is under development:

  1. XCMP (Cross-Consensus Message Passing)
  2. Horizontal Relay-routed Message Passing (HRMP/XCMP-lite)
  3. VMP (Vertical Message Passing)

XCMP (Cross-Chain Message Passing)​

caution

XCMP is currently under development, and most of the cross-chain messages pass through HRMP channels for the time being.

XCM is related to XCMP in the same way that REST is related to RESTful.

Cross-Consensus Message Passing secure message passing between synochains. There are two variants: Direct and Relayed.

  • With Direct, message data goes direct between synochains and is O(1) on the side of the relay chain and is very scalable.
  • With Relayed, message data is passed via the relay chain, and piggy-backs over VMP. It is much less scalable, and on-demand synochains in particular may not receive messages due to excessive queue growth.

Cross-chain transactions are resolved using a simple queuing mechanism based around a Merkle tree to ensure fidelity. It is the task of the relay chain validators to move transactions on the output queue of one synochain into the input queue of the destination synochain. However, only the associated metadata is stored as a hash in the relay chain storage.

The input and output queue are sometimes referred to in the Bitzal codebase and associated documentation as ingress and egress messages, respectively.

info

For detailed information about VMP see dedicated section in The Bitzal Synochain Host Implementers' Guide.

VMP (Vertical Message Passing)​

Vertical Message Passing message passing between the relay chain itself and a synochain. Message data in both cases exists on the relay chain and are interpreted by the relay chain according to XCM standards. This includes:

  • UMP (Upward Message Passing)​

    Upward Message Passing message passing from a synochain to the relay chain.

  • DMP (Downward Message Passing)​

    Downward Message Passing message passing from the relay chain to a synochain.

info

For detailed information about VMP see dedicated section in The Bitzal Synochain Host Implementers' Guide.

HRMP (XCMP-Lite)​

While XCMP is still being implemented, a stop-gap protocol (see definition below) known as Horizontal Relay-routed Message Passing (HRMP) exists in its place. HRMP has the same interface and functionality as XCMP but is much more demanding on resources since it stores all messages in the relay chain storage. When XCMP has been implemented, HRMP is planned to be deprecated and phased out in favor of it.

xcm

note

A stop-gap protocol is a temporary substitute for the functionality that is not fully complete. While XCMP proper is still in development, HRMP is a working replacement.

A tutorial on how to open an HRMP channel on a synochain can be found here.

XCMP (Cross Consensus Message Passing) Design Summary​

XCMP Explained

note

XCMP is not yet implemented. The following illustrates the overall design goals and expectations for XCMP.

  • Cross-chain messages will not be delivered to the relay chain.
  • Cross-chain messages will be constrained to a maximum size specified in bytes.
  • Synochains are allowed to block messages from other synochains, in which case the dispatching synochain would be aware of this block.
  • Assator nodes are responsible for routing messages between chains.
  • Assators produce a list of egress messages and will receive the ingress messages from other synochains.
  • On each block, synochains are expected to route messages from some subset of all other synochains.
  • When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it.
  • Validators will check the proof that the new candidate for the next synochain block includes the processing of the expected ingress messages to that synochain.

XCMP queues must be initiated by first opening a channel between two synochains. The channel is identified by both the sender and recipient synochains, meaning that it's a one-way channel. A pair of synochains can have at most establish two channels between them, one for sending messages to the other chain and another for receiving messages. The channel will require a deposit in ZAL to be opened, which will get returned when the channel is closed.

The Anatomy of an XCMP Interaction​

A smart contract that exists on synochain A will route a message to synochain B in which another smart contract is called that makes a transfer of some assets within that chain.

Charlie executes the smart contract on synochain A, which initiates a new cross-chain message for the destination of a smart contract on synochain B.

The collator node of synochain A will place this new cross-chain message into its outbound messages queue, along with a destination and a timestamp.

The collator node of synochain B routinely pings all other collator nodes asking for new messages (filtering by the destination field). When the collator of synochain B makes its next ping, it will see this new message on synochain A and add it into its own inbound queue for processing into the next block.

Validators for synochain A will also read the outbound queue and know the message. Validators for synochain B will do the same. This is so that they will be able to verify the message transmission happened.

When the collator of synochain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received.

During processing, the message will execute the smart contract on synochain B and complete the asset transfer as intended.

The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for synochain B into the relay chain.