How will XCMP be designed and implemented to further enhance Polkadot’s cross-chain capabilities?

Author: CoaX1d; Source: PolkaWorld

After a long wait, we finally have an exciting topic: The future form of XCMP.

The research team of the Web3 Foundation has designed and prototyped the XCMP technology in the past few months. XCMP aims to optimize the cross-shard messaging system of Polkadot, replacing the current HRMP (Horizontal Relay Routing Messaging) system, and transferring all computing and on-chain resource consumption to the off-chain.

This article discusses how the design of XCMP serves the overall goal of Polkadot's cross-chain messaging.

Overall design considerations

• Ordered or unordered delivery of messages

• Is message delivery guaranteed

• What are the consequences for the sender or receiver if the message is not received and discarded

• The speed of message delivery and the size of the proof

• Maintainability and flexibility of the protocol

• Security assumptions

Goals of XCMP

Optimize cross-shard message delivery and achieve a fast and scalable heterogeneous sharded blockchain system.

There is currently a cross-chain messaging implementation called HRMP (Horizontal Relay Routing Messaging), but its shortcoming is that it forces the Polkadot relay chain to do a lot of work. XCMP aims to replace the HRMP system and completely move all computation and previous on-chain resource consumption off-chain.

XCMP Design: Merkle Doll Model

The specific design of XCMP adopts "Merkle Matryoshka Dolls" (Merkle Doll Model), which optimizes the proof process by nesting a streamlined binary Merkle structure and avoiding the use of state proofs.

The Doll Process

• Put the XCMP message into the smallest doll - XCMPMessageMMR.

• All the XCMPMessageMMR roots go into the second nesting doll - XCMPChannelTree.

• The root of the XCMPChannelTree goes into the ParachainHeader.

• The ParachainHeader goes into the third nesting doll - ParaHeaderTree.

• The root of the ParaHeaderTree goes into the largest nesting doll - BEEFYMMR.

  
  

When all this is done, we have a single nesting doll or root hash (the BEEFY root) that contains all the messages sent by all parachains from all other parachains.

Verification process

• The source chain sends a message to the target chain and proves the authenticity of the message through the Merkle root of BEEFY (Bridge Efficiency Enabling Finality Yielder).

• The target chain unwraps the nesting dolls layer by layer through the received BEEFY root to verify the message.

Implementation/Integration Direction

XCMP is designed as a direct replacement for HRMP and will be integrated into the existing Polkadot system through a simple module, maintaining compatibility with existing XCM and parachain modules.

Adaptation to On-Demand Core Time

Is XCMP designed to accommodate future on-demand core time and corejam?

In the Polkadot network, core time refers to the allocation of processing power and resources on the chain. "On-demand" means dynamically adjusting resource allocation based on demand to optimize network performance and efficiency.

This brings up the issue of time sensitivity of message verification. Specifically, if the target chain has not produced a block for a period of time, then messages sent to the chain during this period (through proofs nested in the nesting doll model) will be verified based on the outdated BEEFY root hash. If the target chain does not update its BEEFY root hash in time, it may not be able to verify the authenticity of these messages.

To solve this problem, it is proposed to add an additional layer (new nesting doll) to the proof structure. The addition of this new layer allows the collector of the target chain to first recognize that the proof will fail, and then make a small correction to the original proof to adapt to the updated BEEFY root. In this way, even if the target chain has not generated new blocks for a long time, old messages can be efficiently processed and verified. Adding this new layer is a smaller step for relayers and does not require additional storage space on the destination chain.

Therefore, although the Polkadot network has not yet implemented the on-demand core time function, XCMP is designed to be future-proof, providing a way to address the additional complexity brought by on-demand core time, ensuring the flexibility of the system and the verifiability of messages.

Conclusion

The design and prototype of XCMP have been completed on the local test network and will be further implemented.

XCMP marks a further improvement in Polkadot's cross-shard messaging capabilities and enhances its interoperability. The future design of XCMP will continue to focus on community feedback to meet broader needs.