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

Revisit usage of BridgeTable, NetworkExportTable in the xcm-bridge-router configuration #2380

Open
svyatonik opened this issue Aug 16, 2023 · 1 comment
Open

Revisit usage of BridgeTable, NetworkExportTable in the xcm-bridge-router configuration #2380

svyatonik opened this issue Aug 16, 2023 · 1 comment
Assignees
@svyatonik @bkontur
Milestone
Kusama <> Polkado...

Comments

@svyatonik
Copy link
Contributor

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 the pallet-xcm-bridge-hub-router. Now instead of simply checking that the message is sent to the BridgedNetworkId consensus, we are also reading the "bridge" configuration from the Bridges config parameter.

I'm currently porting changes from polkadot-staging + dynamic-fees-v1 to master 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.
@svyatonik svyatonik self-assigned this Aug 16, 2023
@svyatonik svyatonik mentioned this issue Aug 23, 2023
Merged
@EmmanuellNorbertTulbure EmmanuellNorbertTulbure transferred this issue from paritytech/parity-bridges-common Aug 25, 2023
@the-right-joyce the-right-joyce transferred this issue from paritytech/polkadot-sdk Aug 25, 2023
@svyatonik svyatonik mentioned this issue Aug 25, 2023
Open
4 tasks
@bkontur bkontur self-assigned this May 2, 2024
@bkontur bkontur mentioned this issue May 2, 2024
Open
6 tasks
@bkontur bkontur mentioned this issue Jul 16, 2024
Merged
12 tasks
@acatangiu
Copy link
Collaborator

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
@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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@svyatonik svyatonik

@bkontur bkontur

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

No branches or pull requests
4 participants
@svyatonik @bkontur @acatangiu @EmmanuellNorbertTulbure