-
Notifications
You must be signed in to change notification settings - Fork 1.6k
XCM: Tools for uniquely referencing messages #7234
Conversation
@gavofyork Command |
bot fmt |
@gavofyork https://gitlab.parity.io/parity/mirrors/polkadot/-/jobs/2890345 was started for your command Comment |
@gavofyork Command |
@@ -212,6 +212,52 @@ impl From<SendError> for Error { | |||
|
|||
pub type Result = result::Result<(), Error>; | |||
|
|||
/* | |||
TODO: XCMv4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing the code here should be migrated to v4 when we get to creating it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed.
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
* master: XCM: Tools for uniquely referencing messages (#7234) Companion: Substrate#13869 (#7119) Companion for Substrate#14214 (#7283) Fix flaky test and error reporting (#7282) impl guide: Update Collator Generation (#7250) Add staking-miner bin (#7273) metrics: tests: Fix flaky runtime_can_publish_metrics (#7279)
…slashing-client * ao-past-session-slashing-runtime: XCM: Tools for uniquely referencing messages (#7234) Companion: Substrate#13869 (#7119) Companion for Substrate#14214 (#7283) Fix flaky test and error reporting (#7282) impl guide: Update Collator Generation (#7250) Add staking-miner bin (#7273) metrics: tests: Fix flaky runtime_can_publish_metrics (#7279) [companion] Fix request-response protocols backpressure mechanism (#7276) PVF: instantiate runtime from bytes (#7270)
Cumulus Companion: paritytech/cumulus#2601
This introduces several tools to ensure XCM messages are uniquely referenceable, using the topic identifiers introduced in XCMv3.
SendXcm
implementationWithUniqueTopic
is introduced as a wrapping router and appends all XCMs sent through it with aSetTopic(t)
wheret
is a universally uniqueXcmHash
value which will be used to identify the message. This is returned by thefn deliver
implementation for recording in events.TrailingSetTopicAsId
is introduced which is a wrapping barrier (i.e. accepts another barrier as a parameter) and which elides a trailingSetTopic
on the message if one exists before passing the rest into the inner barrier. It is designed to wrap around all other barriers at the top level.To use this functionality, the top-level
XcmRouter
type should be altered from:To:
Also, the barrier condition should be altered from:
To:
Messages coming from any chains instituting this will always have a
SetTopic
instruction as the last instruction, which allows chain explorers to track messages.This is further improved by integrating the topic into the barriers API, allowing the Topic barriers to pass the topic statically into the dispatch system and thus have the event include it rather than the now-defunct message hash.
Also, topics are linkable when XCM is sent over a bridge. This is done through having the bridge primitives in
universal_exports.rs
append the derivative (bridged) messages withSetTopic
containing a derivative topic value. For this to work,WithUniqueTopic
does not append aSetTopic
to the message if it already ends with one.Additionally this adds the message ID to all events which send a message and refactors the
Event
enum in pallet XCM to have named fields. Also, addedWeight
toxcm::latest::prelude
and by extensionxcm::prelude
.Breaking Changes
This contains a breaking change into the XCM Barrier API,
trait ShouldExecute
:weight_credit: &mut Weight
becomesproperties: &mut Properties
.This won't affect you unless you implement the
ShouldExecute
trait; if you do, you'll need to alter the prototype accordingly. If you use or mutate theweight_credit
argument, then you can find it in the new API asproperties.weight_credit
.TODO
routing.rs
*SetTopic
should change message hash/ID accordinglysend_xcm
usage)WithUniqueTopic
avoids setting topic again