-
Notifications
You must be signed in to change notification settings - Fork 130
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
Revisit usage of BridgeTable, NetworkExportTable in the xcm-bridge-router configuration #2380
Milestone
Comments
4 tasks
EmmanuellNorbertTulbure
added this to the Kusama <> Polkadot Parachain Bridge V2 milestone
Sep 1, 2023
6 tasks
12 tasks
cc @bkontur I think you can clean this up as part of paritytech/polkadot-sdk#4949 |
github-merge-queue bot
pushed a commit
to paritytech/polkadot-sdk
that referenced
this issue
Sep 2, 2024
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: https://github.com/paritytech/polkadot-sdk/pull/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 <[email protected]> Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Francisco Aguirre <[email protected]>
x3c41a
pushed a commit
to paritytech/polkadot-sdk
that referenced
this issue
Sep 4, 2024
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: https://github.com/paritytech/polkadot-sdk/pull/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 <[email protected]> Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Francisco Aguirre <[email protected]>
This was cleaned-up and reworked by the PR for congestion e.g. https://github.com/paritytech/polkadot-sdk/pull/6231/files#diff-9c9793c594a3cd93997c4b8fb651bd250d49b1b85068cd555aaf8c0809b500e1L86-L97 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Initially I was assuming that (in v2) the sending chains will simply call "open_bridge" method of
pallet-xcm-bridge-hub
(over HRMP) and we won't need to do any helpers at the sending chains - they will do it themselves. However after @bkontur comment (#2294 (comment)), we have added a new config parameter to thepallet-xcm-bridge-hub-router
. Now instead of simply checking that the message is sent to theBridgedNetworkId
consensus, we are also reading the "bridge" configuration from theBridges
config parameter.I'm currently porting changes from
polkadot-staging
+dynamic-fees-v1
tomaster
and I'm going to port this as is. But I have a feeling that maybe we won't need it for v2, or we need to change the current implementation. So we need to revisit this before v2.The text was updated successfully, but these errors were encountered: