Check that the bridge satisfies XCM design assumptions

[serban300]

Related to #2443 . Specifically: XCM is designed to not fail at low level (e.g queues are essentially unlimited, overweight messages stick around). And the bridge should be designed in the same way

I would like to:

1. Take a look on the XCMP/UMP/DMP queues and get a better idea on how they are designed and the resilience mechanisms built-in
2. Check the bridge message queues and see if there's anything that we can improve
3. Check the messages pallet and make sure that it can't fail unpredictably

[serban300]

For point 1:

• the MessgeQueue implementation: https://github.com/paritytech/substrate/tree/master/frame/message-queue
• the MessgeQueue PR: General Message Queue Pallet substrate#12485
• The PR for replacing UMP with the MessageQueue: Use Message Queue pallet for UMP dispatch polkadot#6271
• the PR for replacing XCMP and DMP with the MessageQueue: Use Message Queue as DMP and XCMP dispatch queue cumulus#2157

More useful info:

• info about the design of the MessageQueue and PoV calculations: XCM: General XCM Queue Pallet polkadot#6129 (comment)

Taking a look on them

[serban300]

Looked into multiple aspects related to point 1:

1. The backpressure mechanism in case of an overweight message. This is important because it will be used by the XCMP queues that our logic interacts with

In the case of an overweight message, the substrate MessageQueue keeps it in a stale page that's removed from the book => it doesn't impact the PoV size since that page won't be touched anymore and it has no impact on performance. The message will need to be manually executed by calling the execute_overweight extrinsic or manually removed by executing the reap_page extrinsic. This looks good.

2. Is the substrate MessageQueue more resilient than our queue ?

Personally I didn't notice anything related to this yet.

3. Could we use the substrate MessageQueue instead of our queue ?

The MessageQueue has a couple of advantages:

• it is paginated => better PoV size when there are a lot of stored messages from previous blocks. More details: XCM: General XCM Queue Pallet polkadot#6129 (comment)
• it is customizable
• we would reduce our code and rely on a generic component

But I don't think we can use it, because we would need to be able to prove each message individually, and I don't know if that can be done.

• In the bridges queue we store messages in a double-map and prove that the messages are in storage by their key in the map.
• The substrate MessageQueue uses pages, and each page stores some messages in an encoded heap and I'm not sure how we could prove that a message is in storage.

[serban300]

Looked on this in detail and pushed just some small improvements. From what I understand the bridge messages queue satisfies the XCM design assumptions. There is just 1 thing that I would mention:

As far as I understand we don't handle overweight messages. We assume that any message will be just pushed to a queue (XCMP/DMP/UMP) on the bridged chain, so the weight of this operation is constant and fits the block. This is true for all the current bridge configurations. But I'm wondering if it would make sense to have a failsafe mechanism anyway, just in case a message ends up being overweight. Just want to spend a bit more time thinking about this.

[svyatonik]

#2219 has changed the message size limit down to 64Kb. We need to have some document before delivering #2451 - on what lane users can do and what they can't (including this 64Kb limit).

[svyatonik]

A couple of things that I've also found/noticed:

1. XcmpQueue assumes that there's never more than 65_535 pages in the queue (see https://github.com/paritytech/cumulus/blob/7bcbff3605e38fb59d6882e30f7a8a10060234d0/pallets/xcmp-queue/src/lib.rs#L332-L346 - docs and usage of u16 nearby);
2. overweight messages are processed our of order (see this loop - https://github.com/paritytech/cumulus/blob/7bcbff3605e38fb59d6882e30f7a8a10060234d0/pallets/xcmp-queue/src/lib.rs#L678-L698). Shall we allow overweight messages at all - maybe cut off them earlier (at the sending side?);
3. maximal message sizes are set to different values in different directions (iiuc). E,g. max_downward_message_size is set to 1Mb, max_upward_message_size is set to 50Kb and we set it to 64Kb.
4. if there are more than drop_threshold (5) unprocessed message pages, pages are "kinda" silently dropped.

[EmmanuellNorbertTulbure]

@serban300 to leave conclusion for derived new issue

[serban300]

Created #2522 for using the ``pallet-message-queue`. Resolving.