HRMP: Foundation

HRMP - Horizontal Relay Message Passing is the light weight version of XCMP - Cross-Chain Message Passing that does not allow parachains to directly send messages to each other but instead uses the relay chain to facilitate the passing of messages between parachains via a combination of UMP - Upward Message Passing & DMP - Downward Message Passing protocols.

What are these messages?

Polkadot defines this generic cross-consensus-messages format called XCM which is designed to be platform agnostic, what that means is you can not only send messages from blockchain to blockchain but also to smart contracts of other chains.

XCM is defined as

pub struct Xcm<Call>(pub Vec<Instruction<Call>>);

What you see here is a tuple struct with a public vec field and the generic type Call

Inside the Vec is a set of instructions that a specific consensus system must define to have the recipient consensus system execute in a step wise manner, what that means is these set of instructions a.k.a Instruction<Call> is an enum with variants of standard instructions/dispatchable calls that exists in most substrate based chains(i.e. TransferAsset) and a non-standard instruction Transact which allows calls that are specific to the recipient chain.

Questions

• What happens when the formatting of the recipient chain changes in the event of a runtime upgrade?

XCM acts as a layer before the actual runtime of your chain, if you have an instruction to WithdrawAsset/TransferAsset then you can just program the abstraction allowing XCM stay consistent but under the hood implement what ever changes to the formatting and/or pallet you desire, this only applies to standard instructions, for the Transact instruction you have to make sure the transaction format(i.e. dispatchable function format) of the recipient chain stays the same during the cross-chain-communication.

• What's the process of sending XCM

For this purpose we are going to simulate a simple asset transfer on the relay chain initiated by a parachain, we'll be using the xcm-simulator developed by shawn from Acala

Step 1

Clone the Polkadot repo and build

i usually switch to a new branch at this point just so i don't push anything to master by accident.

Step 2

Head over to the xcm-executor library file and add these logs in the process_instruction function just so we can see what happens when we do a simple transfer.

...    /// Process a single XCM instruction, mutating the state of the XCM virtual machine.    fn process_instruction(&mut self, instr: Instruction<Config::Call>) -> Result<(), XcmError> {        println!("instruction: {:?}", instr);        println!("origin: {:?}", self.origin);        println!("holding before: {:?}", self.holding);        let result = match instr {            WithdrawAsset(assets) => {                // Take `assets` from the origin account (on-chain) and place in holding.                let origin = self.origin.as_ref().ok_or(XcmError::BadOrigin)?;                for asset in assets.drain().into_iter() {                    Config::AssetTransactor::withdraw_asset(&asset, origin)?;                    self.holding.subsume(asset);                }                Ok(())            },        ...        };        println!("holding after: {:?}", self.holding);        result...

Also all that is unfamiliar right now will become clearer in the next part, I believe giving a high level overview before delving into the nitty gritty helps, so for now just follow along and I hope it will be worth you time in the end.

running 1 testinstruction: WithdrawAsset(MultiAssets([MultiAsset { id: Concrete(MultiLocation { parents: 0, interior: Here }), fun: Fungible(10) }]))origin: Some(MultiLocation { parents: 0, interior: X1(Parachain(1)) })holding before: Assets { fungible: {}, non_fungible: {} }holding after: Assets { fungible: {Concrete(MultiLocation { parents: 0, interior: Here }): 10}, non_fungible: {} }instruction: BuyExecution { fees: MultiAsset { id: Concrete(MultiLocation { parents: 0, interior: Here }), fun: Fungible(10) }, weight_limit: Unlimited }origin: Some(MultiLocation { parents: 0, interior: X1(Parachain(1)) })holding before: Assets { fungible: {Concrete(MultiLocation { parents: 0, interior: Here }): 10}, non_fungible: {} }holding after: Assets { fungible: {Concrete(MultiLocation { parents: 0, interior: Here }): 10}, non_fungible: {} }instruction: DepositAsset { assets: Wild(All), max_assets: 1, beneficiary: MultiLocation { parents: 0, interior: X1(Parachain(2)) } }origin: Some(MultiLocation { parents: 0, interior: X1(Parachain(1)) })holding before: Assets { fungible: {Concrete(MultiLocation { parents: 0, interior: Here }): 10}, non_fungible: {} }holding after: Assets { fungible: {}, non_fungible: {} }test tests::withdraw_and_deposit ... ok