XCM: Message Queues

[gavofyork]

Several improvements needed before we can lift the harsh restrictions placed on message queues at present:

• Introduce fees to allow actors on the Relay-chain to send DMP messages. XCM: Properly set the pricing for the DMP router polkadot#6843
• Ensure incoming DMP messages queue rather than execute immediately on receipt.
• Remove pallet::without_storage_info from all message-queue pallets (use Preimages pallet as needed).
• Relay-chain should limit per-block HRMP bandwidth to something manageable by not requiring all sending channels to move forward by a whole block at once.
• Ensure no queue overloads the PoV at message execution. This can be done fairly easily by only queuing messages whose size is less than some maximum. Messages which exceed the limit should be placed in the oversize message queue with the message data stored as a preimage. Both fields of the weight should be checked prior to execution.
• Allow suspension of any/all XCM queue processing for one block by an inherent if enough BABE slots have been missed.
• Limit reentrancy via a thread_local counter to limit stack depth which an Xcm Transact can create.

Once all items are complete, safeguards designed to avoid PoV-exhaustion can be removed. At this point, sane v2 -> v3 weight conversions must also be removed; instead the Weight should be approximately equivalent to a block's total PoV weight. This will make almost all v2 messages overweight on a v3 system. The practical fix is to upgrade to v3.

Related: paritytech/polkadot#6129

[xlc]

To confirm, we can remove the XCM SafeCallFilter once this PR is addressed?

[kianenigma]

To confirm, we can remove the XCM SafeCallFilter once this PR is addressed?

Yes, as per:

https://github.com/paritytech/polkadot/blob/7129e9bdba2c82e4b173f567b5d6a3c3f7191782/runtime/kusama/src/xcm_config.rs#L150-L157

[kianenigma]

@ggwpez can this be closed?

[ggwpez]

Allow suspension of any/all XCM queue processing for one block by an inherent if enough BABE slots have been missed.

Could probably be split into another issue, if still relevant.

Relay-chain should limit per-block HRMP bandwidth to something manageable by not requiring all sending channels to move forward by a whole block at once.

I guess this could still be an issue, if a parachain receives messages from all its channels at once and has a lot of them open. I will check this as part of the AHM preparations if it needs adjustments.
Although not sure what direction to go in. We dont really want to allow a linear lag between the enqueued and processed messages, since that would kill liveness. But possibly a constant factor could work while also updating the HostConfiguration of the chain dynamically to notify the other chains that the channel has lower throughput limits now.