XCMP and SPREE

# XCMP and SPREE XCMP is Polkadot's cross-chain message-passing protocol. It allows one parachain to send messages to another parachain and provides gurantees about the delivery of these messages. XCMP guarantees: - Messages arrive quickly - Messages from one parachain arrive to another in order - Arriving messages were indeed sent in the ﬁnalised history of the sending chain - Recipients will receive messages fairly across senders, helping guarantee that senders never wait indeﬁnitely for their messages to be seen XCMP covers: - Mechanisms for queuing and ordering of messages - Delivering Messages - Consistent History - Message input and output validation - Data availability ## Queuing and Ordering Messages Every parachain block in Polkadot produces a possibly empty list of messages to route to every other block. Parachains can send each other messages once they have established messaging channels with each other. Whilst channel is open, it contains queue of ordered messages that have been sent but not yet acknowledged by the recipient. The sender may add a message to the back of the queue (i.e. send a message), and the recipient may remove a message from the front of the queue (i.e. ack a message). ## Delivering Messages If there are nodes in common between these two networks, messages will be gossiped from one parachain network to another parachain network. ![](https://i.imgur.com/do5rM9H.png) ## Fallback Delivery If the receiving parachain validators realize that the message has not been gossiped in the recipient parachain, they request the message from parachain validators of the sending parachain. Once they have received them, they gossip those messages in the receiving parachain network. ![](https://i.imgur.com/UumxYi5.png) ## Consistent History The relay chain defines a history for all parachains. Relay chain achieve keeping consistent history efficiently by using nested Merkle trees. The header of a parachain block that corresponds to sent messages will contain a single message root hash, the root of a Merkle tree. In turn, the leaves of this Merkle tree are the head of hash chain of messages from this parachain to another. There is a sequence of hashes that contains each message hash, allowing the verification of all sent messages from one parachain to another from this one hash. This allows collator to construct a proof, consisting of many hashes, that they acted on the messages and only those messages that they should be acting on, by first showing that the message root was in the relay chain and then giving a proof that these were the messages from the message root hash. ## Input and Output Validation Parachain headers contain a message root of outgoing messages. To produce a parachain block on a parachain that builds on a paricular relay chain block, a collator would need to look at which parachain headers were built between that relay chain block and the relay chain that included the header of the last parachain block of this parachain. For those messages, the parachain needs to act on the corresponding message data. The parachain state transition verification function uses a validation function to verify that input messages are acted on. The varidation function checks that the parachain's state transition is valid. It relates a new state of the parachain and a set of output messages to a digest of the previous state of the parachain, the parachain block data, and a set of input messages that have been faithfully routed from other parachains or the relay chain. ## Availability for Messages Once the messages have been included in the egress queues, they are kept by collators and full nodes of the sending parachain. When the sending parachain block's headers have been included in the relay chain, the parachain validators will also keep the messages. To guarantee availability, all validators hold erasure-coded pieces that can recover any of the parachain messages. ## XCM Message Types - WithdrawAsset - ReserveAssetDeposit - TeleportAsset - Balances - Transact - RelayTo - RelayedFrom ## Shared Protected Runtime Execution Enclaves (SPREE) SPREE is a way for parachains to have share code, and furthermore for the execution and state of that code to be sandboxed and this code is placed in relay chain. SPREE provide a gurantee that a certain interpretation of the code will be executed on destination parachains. While XCMP gurantees the delivery of a message, it does not guarantee what code will be executed. ### Example of the security gurantees we get from SPREE If A has a native token, the A token, what we would like is to be sure that parachain B could not mint this token. We could enforce this by A keeping an account for B in A’s state. However if an account on B want’s to send some A token to a third parachain C, then it would need to inform A. A SPREE module for tokens would allow this kind of token transfer without this accounting. The module on A would just send a message to the same module on B, sending the tokens to some account. B could then send them on to C and C to A in a similar way. The module itself would account for tokens in accounts on chain B, and Polkadot’s shared security and the module’s code would enforce that B could never mint A tokens. (referenced from [4] pages 37). ## Reference [1] https://research.web3.foundation/en/latest/polkadot/XCMP/index.html [2] https://medium.com/web3foundation/polkadots-messaging-scheme-b1ec560908b7 [3] https://github.com/paritytech/xcm-format [4] https://eprint.iacr.org/2020/641.pdf [5] https://wiki.polkadot.network/docs/en/learn-spree