XCM: Tools for uniquely referencing messages#7234
Conversation
|
@gavofyork https://gitlab.parity.io/parity/mirrors/polkadot/-/jobs/2889552 was started for your command Comment |
|
@gavofyork Command |
|
bot fmt |
|
@gavofyork https://gitlab.parity.io/parity/mirrors/polkadot/-/jobs/2890345 was started for your command Comment |
|
@gavofyork Command |
| pub type Result = result::Result<(), Error>; | ||
|
|
||
| /* | ||
| TODO: XCMv4 |
There was a problem hiding this comment.
I'm guessing the code here should be migrated to v4 when we get to creating it.
Co-authored-by: Keith Yeung <[email protected]>
* 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.
SendXcmimplementationWithUniqueTopicis introduced as a wrapping router and appends all XCMs sent through it with aSetTopic(t)wheretis a universally uniqueXcmHashvalue which will be used to identify the message. This is returned by thefn deliverimplementation for recording in events.TrailingSetTopicAsIdis introduced which is a wrapping barrier (i.e. accepts another barrier as a parameter) and which elides a trailingSetTopicon 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
XcmRoutertype 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
SetTopicinstruction 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.rsappend the derivative (bridged) messages withSetTopiccontaining a derivative topic value. For this to work,WithUniqueTopicdoes not append aSetTopicto the message if it already ends with one.Additionally this adds the message ID to all events which send a message and refactors the
Eventenum in pallet XCM to have named fields. Also, addedWeighttoxcm::latest::preludeand by extensionxcm::prelude.Breaking Changes
This contains a breaking change into the XCM Barrier API,
trait ShouldExecute:weight_credit: &mut Weightbecomesproperties: &mut Properties.This won't affect you unless you implement the
ShouldExecutetrait; if you do, you'll need to alter the prototype accordingly. If you use or mutate theweight_creditargument, then you can find it in the new API asproperties.weight_credit.TODO
routing.rs*SetTopicshould change message hash/ID accordinglysend_xcmusage)WithUniqueTopicavoids setting topic again