Skip to content

XCM: Message Queues #489

@gavofyork

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    I9-optimisationAn enhancement to provide better overall performance in terms of time-to-completion for a task.T6-XCMThis PR/Issue is related to XCM.

    Type

    No type

    Projects

    Status

    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions