Change LaneId underlying type from [u8; 4] to H256 #2221
Merged
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
svyatonik
added
P-Relay
P-Runtime
PR-audit-needed
svyatonik
commented
Jun 21, 2023
svyatonik
commented
Jun 21, 2023
svyatonik
pushed a commit
that referenced
this pull request
Jul 17, 2023
* Collectives integration tests xcm v3 * remove comment * review fixs --------- Co-authored-by: parity-processbot <>
bkontur
pushed a commit
that referenced
this pull request
May 7, 2024
* change LaneId underlying type from [u8; 4] to H256 * fixed typo * added some tests * spelling * started fixing testnets * uncommented call size test * changed RewardsAccountParams encoding + added values separator when computing LaneId * review suggestions
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.
related to #2213, #2451 and #2457
This PR changes the lane identifier from
LaneId([u8; 4])toLaneId(H256). This gives us ability to generate unique lane identifiers on both sides of the bridge given that two bridge endpoints have their own unique identifiers. In bridge testnets it is theChainId(which will also be deprecated soon in #2457) and in XCM world it is the location withinGlobalConsensus. So now e.g. lane for serving bridge between two asset hubs (Kusama.AssetHub<>Polkadot.AssetHub) doesn't need to be hardcoded anywhere - it's just ablake2_256(order(Kusama.AssetHub.XcmLocation, Polkadot.AssetHub.Location).encode())I've started implementing map of
(location1, location2) => LaneIdin #2213, but decided to do this refactor first - it'll make our life significantly easier. For example we won't get any accidental collisions due to lack of "bridge-open" synchronization protocol.IMPORTANT: there are two breaking changes in this PR, which would require storage migrations:
LaneIdeither in values and/or keys. This include:pallet_bridge_messages::InboundLanes,pallet_bridge_messages::OutboundLanes,pallet_bridge_messages::OutboundLanes,pallet_bridge_relayers::RelayerRewards;bp_relayers::RewardsAccountParamshas changed, but it is already included in the migration from (1);This is a breaking change and would require storage migration on all chains with previous version of pallets.
Obviously, breaking changes also makes new relayer incompatible with old runtimes and vice versa.
Please say now if you have something against this approach or know a better approach. Meanwhile I'll work on remaining TODOs here: