-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for versioned notification for HRMP pallet #4281
Conversation
…ks` covering non-lastest XCM version scenario
…nto bko-hrmp-fix-xcm-version-4003
bot help |
bot bench polkadot-pallet --runtime=rococo --pallet=runtime_parachains::hrmp |
bot bench polkadot-pallet --runtime=rococo --pallet=runtime_parachains::hrmp |
bot clean |
bot bench polkadot-pallet --runtime=rococo --pallet=runtime_parachains::hrmp |
@bkontur https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6106217 was started for your command Comment |
@bkontur https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6106218 was started for your command Comment |
The CI pipeline was cancelled due to failure one of the required jobs. |
…=rococo --target_dir=polkadot --pallet=runtime_parachains::hrmp
@bkontur Command |
…=westend --target_dir=polkadot --pallet=runtime_parachains::hrmp
@bkontur Command |
which controls the encoding of XCM notifications related to the opening/closing of HRMP channels. | ||
If your runtime does not concern itself with the XCM version used for notifications, | ||
you can set it as `type VersionWrapper = ()` to always use the latest XCM. | ||
If your runtime does care about the XCM version when sending to child parachains, |
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.
So if your runtime is a parachain you just put ()
, right?
What does it mean to concern oneself about versions? Is it allowing older versions of XCM?
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.
So if your runtime is a parachain you just put
()
, right?
The HRMP pallet is dedicated to relay chain runtimes, I don't think that any parachain runtime uses this HRMP pallet.
What does it mean to concern oneself about versions? Is it allowing older versions of XCM?
The problem could arise from a higher version on the relay chain than on the receiving parachain. For example, imagine that we update Polkadot with xcm::v5
, but Polimec still uses xcm::v4
. Without this fix, they could lose messages because they would not be able to decode xcm::v5
.
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.
Perhaps it could be possible to replace most of the functionality related to the WrapVersion with just the SendXcm
trait. In this scenario, the HRMP pallet would use type XcmSender = ChildParachainRouter
, potentially simplifying things. However, this approach would introduce another layer of complexity, particularly regarding handling transport fees. Nevertheless, I think these HRMP notifications are treated as system notifications, which is why they are sent directly by dmp::Pallet::<T>::queue_downward_message
.
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Closes: paritytech#4003 (please see for the problem description) ## TODO - [x] add more tests covering `WrapVersion` corner cases (e.g. para has lower version, ...) - [x] regenerate benchmarks `runtime_parachains::hrmp` (fix for Rococo is here: paritytech#4332) ## Questions / possible improvements - [ ] A `WrapVersion` implementation for `pallet_xcm` initiates version discovery with [note_unknown_version](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L2527C5-L2527C25), there is possibility to avoid this overhead in this HRMP case to create new `WrapVersion` adapter for `pallet_xcm` which would not use `note_unknown_version`. Is it worth to do it or not? - [ ] There's a possibility to decouple XCM functionality from the HRMP pallet, allowing any relay chain to generate its own notifications. This approach wouldn't restrict notifications solely to the XCM. However, it's uncertain whether it's worthwhile or desirable to do so? It means making HRMP pallet more generic. E.g. hiding HRMP notifications behind some trait: ``` trait HrmpNotifications { fn on_channel_open_request( sender: ParaId, proposed_max_capacity: u32, proposed_max_message_size: u32) -> primitives::DownwardMessage; fn on_channel_accepted(recipient: ParaId) -> primitives::DownwardMessage; fn on_channel_closing(initiator: ParaId, sender: ParaId, recipient: ParaId) -> primitives::DownwardMessage; } ``` and then we could have whatever adapter, `impl HrmpNotifications for VersionedXcmHrmpNotifications {...}`, ``` impl parachains_hrmp::Config for Runtime { .. type HrmpNotifications = VersionedXcmHrmpNotifications; .. } ``` --------- Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <[email protected]>
Closes: paritytech#4003 (please see for the problem description) ## TODO - [x] add more tests covering `WrapVersion` corner cases (e.g. para has lower version, ...) - [x] regenerate benchmarks `runtime_parachains::hrmp` (fix for Rococo is here: paritytech#4332) ## Questions / possible improvements - [ ] A `WrapVersion` implementation for `pallet_xcm` initiates version discovery with [note_unknown_version](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L2527C5-L2527C25), there is possibility to avoid this overhead in this HRMP case to create new `WrapVersion` adapter for `pallet_xcm` which would not use `note_unknown_version`. Is it worth to do it or not? - [ ] There's a possibility to decouple XCM functionality from the HRMP pallet, allowing any relay chain to generate its own notifications. This approach wouldn't restrict notifications solely to the XCM. However, it's uncertain whether it's worthwhile or desirable to do so? It means making HRMP pallet more generic. E.g. hiding HRMP notifications behind some trait: ``` trait HrmpNotifications { fn on_channel_open_request( sender: ParaId, proposed_max_capacity: u32, proposed_max_message_size: u32) -> primitives::DownwardMessage; fn on_channel_accepted(recipient: ParaId) -> primitives::DownwardMessage; fn on_channel_closing(initiator: ParaId, sender: ParaId, recipient: ParaId) -> primitives::DownwardMessage; } ``` and then we could have whatever adapter, `impl HrmpNotifications for VersionedXcmHrmpNotifications {...}`, ``` impl parachains_hrmp::Config for Runtime { .. type HrmpNotifications = VersionedXcmHrmpNotifications; .. } ``` --------- Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <[email protected]>
Closes: #4003 (please see for the problem description)
TODO
WrapVersion
corner cases (e.g. para has lower version, ...)runtime_parachains::hrmp
(fix for Rococo is here: HRMP - setDefaultChannelSizeAndCapacityWithSystem
with dynamic values according to theActiveConfig
#4332)Questions / possible improvements
WrapVersion
implementation forpallet_xcm
initiates version discovery with note_unknown_version, there is possibility to avoid this overhead in this HRMP case to create newWrapVersion
adapter forpallet_xcm
which would not usenote_unknown_version
. Is it worth to do it or not?impl HrmpNotifications for VersionedXcmHrmpNotifications {...}
,