XCM Horizon

[gavofyork]

Features for v3 lifetime which don't change message format

• XCM: Introduce pallet_assets::Config::CreateOrigin polkadot#6126
• XCM: Should not contain BoundedVec half-impls polkadot#6572
• XCM: Graceful Deletion of Overweight Messages #488
• XCM: Transactional Processing #490
• Real weight for DropAssets. #954
• XCM: Message Queues #489
• XCM: Proper Asset Checking #487
• XCM: Make locking work with multiple assets #864
• XCM: Blocking Barrier  polkadot#4813
• XCM: Create general asset weight weighing framework #736

Version discovery

• Automatic version discovery once channel is open.
• Queue outgoing messages which trigger discovery and send them once the version is known.

Trustless replies

Re-evaluate whether the Query system really is enough to get information on the execution of a remote operation back to the sender trustlessly and resistant to forgery attacks.

Origin aliasing

• XCM: Origin Aliasing polkadot#6668
• XCM: Arbitrary Origin Aliases #722

Improved error reporting

• Simulator should extract XCM execution events and pretty-print
• Ensure XCM is easily identifiable from source to dest.
• Introduce ConversionError enum for when conversion between versions fails with TryFrom, and place that as an inner parameter of XcmError::UnsupportedDestination Figure out a good error reporting mechanism for XCM #920

Wish list

Fees

Fees are attributes of remote locations which are essentially opaque, yet it is important to know them if messages are being sent to/through them in order to ensure messages succeed. This is quite similar to XCM versioning. We should utilise the same kind of mechanisms we have for managing XCM versions of remote locations more generally.

• Instruction and Response to get a fee table from remote locations.
• Fee-Registrar Pallet to store known remote locations' fee table.
• Trait hooks to allow Fee-Registrar pallet to be used to determine remote-payable fees.
• Subscription service to keep data in Fee-Registrar up to date.

Bounds

• XCM: Allow decode length upper bound to be parameterisable #1258

Assets

• XCM: Make locking work with multiple assets #864

Bridging

• QueryExportPrice instruction.
• Dynamic route pricing, based on price queries.
• QueryExportTable instruction and query datatype.
• Dynamic routing based on QueryExportTable replies from known/trusted bridges.

Checkpoints (v4/v5?)

• Allow for the possibility of Commit and Rollback instructions which allow for error-resistant atomic operations. Payment for weight can NEVER be reverted, so the BuyExecution barrier would check for a Commit following after it.

Client

• Get block-builder to provide feedback to the XCM system so that the PoV block doesn't become too big when squeezing in messages in on_idle.
• paritytech/polkadot#4119

Questionable things/vague ideas/low priority

• Efficient encodings for MultiAsset. (TODO: #XCMENCODE)
• Consider removing all BTree stuff and just have a fixed array of MultiAsset registers. This puts the onus on the XCM message author to consider exactly what they're doing, but avoids indeterminate weights coming from sophisticated structures.
• When executing XCM::Transact, use a call filter to be specified in the Config trait. (TODO: #TRANSACTFILTER)
• New type of XcmpMessageFormat which gives every Xcm message an ordering flag so that lighter messages are not needlessly blocked by heavier ones preceding them. This will result in a slower overall dispatch function since it will need the page to be rebuilt with any skipped messages and placed back in storage.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/the-ledger-app-debate-united-we-stand-divided-we-fall/3177/13