Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[migrations] Migration from static Lanes to dynamic lanes (master) #2794

Closed
5 tasks
bkontur opened this issue Jan 17, 2024 · 1 comment
Closed
5 tasks

[migrations] Migration from static Lanes to dynamic lanes (master) #2794

bkontur opened this issue Jan 17, 2024 · 1 comment
Assignees
@bkontur
Milestone
Kusama <> Polkado...

Comments

@bkontur
Copy link
Contributor

bkontur commented Jan 17, 2024 •
edited
Loading

Actually, we defined hard-coded lane between AssetHubs (Ro/We, K/P), but we need to have migration from this static to dynamic lanes stored on-chain.

I think we don't need this for Rococo/Westend, we can to governance calls (but maybe it would be cool to test migration).
But surely, we need this for Kusama/Polkadot, because when we upgrade runtimes to the dynamic lanes, we cannot wait for follow-up governance calls to establish lane between AssetHubs again.

  • check what everything needs to be migrated
    • storage
    • laneIds
  • prepare migration
  • add migration to the polkadot-fellows repo
@bkontur bkontur self-assigned this Jan 17, 2024
@bkontur bkontur mentioned this issue Apr 12, 2024
Closed
1 task
@bkontur bkontur mentioned this issue May 2, 2024
Open
6 tasks
@bkontur bkontur mentioned this issue Jul 16, 2024
Merged
12 tasks
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 26, 2024
@bkontur
Make LaneId backwards compatible - part 1
5aa0d7c 
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 27, 2024
@bkontur
Make LaneId backwards compatible - part 1
c7a254f 
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 29, 2024
@bkontur
Make LaneId backwards compatible - part 1
7f493a1 
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 29, 2024
@bkontur
Disconnect BridgeId and LaneId to be able fix backwards compatibl…
2431b1a 
…ity and XCM upgrades

Addressing:
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 30, 2024
@bkontur
Make LaneId backwards compatible - part 1
7a3e721 
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 30, 2024
@bkontur
Disconnect BridgeId and LaneId to be able fix backwards compatibl…
ab40f4e 
…ity and XCM upgrades

Addressing:
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 31, 2024
@bkontur
Make LaneId backwards compatible - part 1
fb819e0 
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
bkontur added a commit to paritytech/polkadot-sdk that referenced this issue Jul 31, 2024
@bkontur
Disconnect BridgeId and LaneId to be able fix backwards compatibl…
692b80b 
…ity and XCM upgrades

Addressing:
paritytech/parity-bridges-common#2500
paritytech/parity-bridges-common#2794
github-merge-queue bot pushed a commit to paritytech/polkadot-sdk that referenced this issue Sep 2, 2024
@bkontur @svyatonik @franciscoaguirre
[bridges-v2] Permissionless lanes (#4949)
2210099 
Relates to:
paritytech/parity-bridges-common#2451
Closes: paritytech/parity-bridges-common#2500

## Summary

Now, the bridging pallet supports only static lanes, which means lanes
that are hard-coded in the runtime files. This PR fixes that and adds
support for dynamic, also known as permissionless, lanes. This means
that allowed origins (relay chain, sibling parachains) can open and
close bridges (through BridgeHubs) with another bridged (substrate-like)
consensus using just `xcm::Transact` and `OriginKind::Xcm`.

_This PR is based on the migrated code from the Bridges V2
[branch](#4427) from the
old `parity-bridges-common`
[repo](https://github.com/paritytech/parity-bridges-common/tree/bridges-v2)._

## Explanation

Please read
[bridges/modules/xcm-bridge-hub/src/lib.rs](https://github.com/paritytech/polkadot-sdk/blob/149b0ac2ce43fba197988f2642032fa24dd8289a/bridges/modules/xcm-bridge-hub/src/lib.rs#L17-L136)
to understand how managing bridges works. The basic concepts around
`BridgeId` and `LaneId` are also explained there.


## TODO

- [x] search and fix for comment: `// TODO:(bridges-v2) - most of that
stuff was introduced with free header execution:
#4102 - more info in the
comment
[bellow](#4427 (comment))
- [x] TODO: there's only one impl of `EnsureOrigin<Success = Location>`

## TODO - not blocking review

**benchmarking:**
- [x] regenerate all relevant weights for BH/AH runtimes
- [ ] regenerate default weights for bridging pallets e.g.
`modules/messages/src/weights.rs`
- [ ] add benchmarks for `xcm-bridge-hub` pallet
#5550

**testing:**
- [ ] add xcm-emulator tests for Rococo/Penpal to Westend/Penpal with
full opening channel and sending/receiving `xcm::Transact`

**migrations:**
- [x] add migrations for BridgeHubRococo/Westend
paritytech/parity-bridges-common#2794 (to be
reusable for P/K bridge)
  - [x] check also storage migration, if needed for pallets
  - [ ] migration for XCM type (optional)
  - [x] migration for static lanes to the dynamic (reuse for fellows)

**investigation:**
- [ ] revisit
paritytech/parity-bridges-common#2380
- [ ] check congestion around `LocalXcmChannelManager` and
`OutboundLanesCongestedSignals` impls -
#5551
  - to be reusable for polkadot-fellows
- return `report_bridge_status` was remove, so we need to `XcmpQueue`
alternative?

---------

Signed-off-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
x3c41a pushed a commit to paritytech/polkadot-sdk that referenced this issue Sep 4, 2024
@bkontur @svyatonik
@franciscoaguirre @x3c41a
[bridges-v2] Permissionless lanes (#4949)
eb664be 
Relates to:
paritytech/parity-bridges-common#2451
Closes: paritytech/parity-bridges-common#2500

## Summary

Now, the bridging pallet supports only static lanes, which means lanes
that are hard-coded in the runtime files. This PR fixes that and adds
support for dynamic, also known as permissionless, lanes. This means
that allowed origins (relay chain, sibling parachains) can open and
close bridges (through BridgeHubs) with another bridged (substrate-like)
consensus using just `xcm::Transact` and `OriginKind::Xcm`.

_This PR is based on the migrated code from the Bridges V2
[branch](#4427) from the
old `parity-bridges-common`
[repo](https://github.com/paritytech/parity-bridges-common/tree/bridges-v2)._

## Explanation

Please read
[bridges/modules/xcm-bridge-hub/src/lib.rs](https://github.com/paritytech/polkadot-sdk/blob/149b0ac2ce43fba197988f2642032fa24dd8289a/bridges/modules/xcm-bridge-hub/src/lib.rs#L17-L136)
to understand how managing bridges works. The basic concepts around
`BridgeId` and `LaneId` are also explained there.

## TODO

- [x] search and fix for comment: `// TODO:(bridges-v2) - most of that
stuff was introduced with free header execution:
#4102 - more info in the
comment
[bellow](#4427 (comment))
- [x] TODO: there's only one impl of `EnsureOrigin<Success = Location>`

## TODO - not blocking review

**benchmarking:**
- [x] regenerate all relevant weights for BH/AH runtimes
- [ ] regenerate default weights for bridging pallets e.g.
`modules/messages/src/weights.rs`
- [ ] add benchmarks for `xcm-bridge-hub` pallet
#5550

**testing:**
- [ ] add xcm-emulator tests for Rococo/Penpal to Westend/Penpal with
full opening channel and sending/receiving `xcm::Transact`

**migrations:**
- [x] add migrations for BridgeHubRococo/Westend
paritytech/parity-bridges-common#2794 (to be
reusable for P/K bridge)
  - [x] check also storage migration, if needed for pallets
  - [ ] migration for XCM type (optional)
  - [x] migration for static lanes to the dynamic (reuse for fellows)

**investigation:**
- [ ] revisit
paritytech/parity-bridges-common#2380
- [ ] check congestion around `LocalXcmChannelManager` and
`OutboundLanesCongestedSignals` impls -
#5551
  - to be reusable for polkadot-fellows
- return `report_bridge_status` was remove, so we need to `XcmpQueue`
alternative?

---------

Signed-off-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
@bkontur
Copy link
Contributor Author

bkontur commented Sep 13, 2024

this was already merged to the polkadot-sdk master

@bkontur bkontur closed this as completed Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bkontur bkontur

Labels
None yet
Projects
Bridges + XCM
Status: Done
Milestone
Kusama <> Polkadot Parachain Bridge V2
Development

No branches or pull requests
1 participant
@bkontur