Improved ExportXcm::validate implementation for BridgeHubs - step 1
#2727
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ah, yes, you're right, I was focused on that sender validation/export stuff, |
3 tasks
bkontur
added a commit
to paritytech/polkadot-sdk
that referenced
this pull request
Dec 6, 2023
## Summary This PR aligns Rococo/Westend bridge with latest Bridges repo development: - paritytech/parity-bridges-common#2727 - paritytech/parity-bridges-common#2728 - paritytech/parity-bridges-common#2729 Part of: paritytech/parity-bridges-common#2452
svyatonik
added a commit
that referenced
this pull request
Dec 8, 2023
svyatonik
added a commit
that referenced
this pull request
Dec 8, 2023
* separate constants for average and worst case relay headers (#2728) * separate constants for average and worst case relay headers * fix compilation * Select header that will be fully refunded in on-demand batch finality relay (#2729) * select header that will be fully refunded for submission in on-demand **batch** finality relay * added the only possible test * spelling * nl * updated comment * backport some nits from #2727 * NotApplicable instead of Unroutable * Grafana update stuff (#2733) --------- Co-authored-by: Branislav Kontur <[email protected]>
serban300
pushed a commit
to serban300/parity-bridges-common
that referenced
this pull request
Mar 27, 2024
…paritytech#2727) * Improved `ExportXcm::validate` implementation for BridgeHubs * spellcheck * Fix try-runtime * Fix try-runtime
serban300
pushed a commit
to serban300/parity-bridges-common
that referenced
this pull request
Apr 8, 2024
…paritytech#2727) * Improved `ExportXcm::validate` implementation for BridgeHubs * spellcheck * Fix try-runtime * Fix try-runtime
bkontur
added a commit
that referenced
this pull request
May 7, 2024
* separate constants for average and worst case relay headers (#2728) * separate constants for average and worst case relay headers * fix compilation * Select header that will be fully refunded in on-demand batch finality relay (#2729) * select header that will be fully refunded for submission in on-demand **batch** finality relay * added the only possible test * spelling * nl * updated comment * backport some nits from #2727 * NotApplicable instead of Unroutable * Grafana update stuff (#2733) --------- Co-authored-by: Branislav Kontur <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
At first, this PR addresses #2452. Currently, on BridgeHubs V1, we don't check the sender to verify if it is allowed to use a dedicated lane. As a result, anyone opening an HRMP channel to the local BridgeHub will be able to send messages to the dedicated lane for AssetHubs.
Secondly, there is an issue raised by Jakob (
#361) regarding the splitting/improvement ofExportXcm::validatefor the messages pallet. As we discussed here on Matrix - we need a wrapper/adapter for HaulBlobExporter, as Slava proposedEnsureMessagesPalletActive.Solution
I reviewed Slava's master implementation for dynamic bridges, and he has already addressed almost both issues with
pallet-xcm-bridge-hub. Therefore, I believe creating any temporaryEnsureMessagesPalletActiveis not necessary.Instead, I backported
pallet-xcm-bridge-hubwith justExportXcmcapabilities and adapted it withXcmBlobHaulerelements to minimize the impact on Bridges V1. We will still proceed with the hard-coded lane for AssetHubs.You can find the
polkadot-sdkcopy of this PR for the Rococo/Westend bridge here: paritytech/polkadot-sdk#2602This PR also brings
polkadot-stagingcloser to themaster, making backports and migrations to V2 easier.Next step
So, if this is the way to go, we should focus on adding the
validate_messagefeature to bothpallet-xcm-bridge-hubandpallet-bridge-messages, which will resolve Jacob's issue, as a follow up PR.Part of: #2452