- Feb 02, 2024
-
-
Marcin S. authored
Built on top of https://github.com/paritytech/polkadot-sdk/pull/2826/ which was a trial run. Guide: https://github.com/w3f/polkadot-wiki/blob/master/docs/maintain/maintain-guides-async-backing.md --------- Signed-off-by:
georgepisaltu <[email protected]> Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by:
Dónal Murray <[email protected]> Co-authored-by:
Dmitry Sinyavin <[email protected]> Co-authored-by:
s0me0ne-unkn0wn <[email protected]> Co-authored-by:
Svyatoslav Nikolsky <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]> Co-authored-by:
georgepisaltu <[email protected]>
-
Branislav Kontur authored
## TODO - [x] change constants when CI fails (should fail :) ) ## Result On the AssetHubRococo: 1701175800126 -> 1700929825257 = 0.15 % decreased. ``` # Before ( [xcm] Fix `SovereignPaidRemoteExporter` and `DepositAsset` handling (#3157)) Feb 02 12:59:05.520 ERROR bridges::estimate: `bridging::XcmBridgeHubRouterBaseFee` actual value: 1701175800126 for runtime: statemine-1006000 (statemine-0.tx14.au1) # After Feb 02 13:02:40.647 ERROR bridges::estimate: `bridging::XcmBridgeHubRouterBaseFee` actual value: 1700929825257 for runtime: statemine-1006000 (statemine-0.tx14.au1) ``` On the AssetHubWestend: 2116038876326 -> 1641718372993 = 22.4 % decreased. ``` # Before ( [xcm] Fix `SovereignPaidRemoteExporter` and `DepositAsset` handling (#3157)) Feb 02 12:56:00.880 ERROR bridges::estimate: `bridging::XcmBridgeHubRouterBaseFee` actual value: 2116038876326 for runtime: westmint-1006000 (westmint-0.tx14.au1) # After Feb 02 13:04:42.515 ERROR bridges::estimate: `bridging::XcmBridgeHubRouterBaseFee` actual value: 1641718372993 for runtime: westmint-1006000 (westmint-0.tx14.au1) ```
-
- Jan 31, 2024
-
-
Branislav Kontur authored
The `parachains-common` contains a lots of constants and type definitions which are used for `polkadot-sdk`'s testnet runtimes and also for `polkadot-fellows`'s production [SP runtimes](https://github.com/polkadot-fellows/runtimes/tree/main/system-parachains/constants). This PR cleans `parachains-common` module to contain only common and generic functionality. Testnet-specific constants have been moved to the separate module dedicated just for testnets: `polkadot-sdk/cumulus/parachains/runtimes/constants/` Part of: https://github.com/paritytech/polkadot-sdk/issues/3054 --------- Co-authored-by:
georgepisaltu <[email protected]>
-
- Jan 22, 2024
-
-
Marcin S. authored
The goal is to move all system chains on Rococo (+ other testnets?) to use async backing. Starting with `asset-hub-rococo` to get feedback, before I do the rest. ## Related Example: https://github.com/paritytech/polkadot-sdk/pull/1619/ Guide: https://github.com/w3f/polkadot-wiki/blob/master/docs/maintain/maintain-guides-async-backing.md --------- Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by:
Dónal Murray <[email protected]>
-
- Jan 16, 2024
-
-
Francisco Aguirre authored
# Note for reviewer Most changes are just syntax changes necessary for the new version. Most important files should be the ones under the `xcm` folder. # Description Added XCMv4. ## Removed `Multi` prefix The following types have been renamed: - MultiLocation -> Location - MultiAsset -> Asset - MultiAssets -> Assets - InteriorMultiLocation -> InteriorLocation - MultiAssetFilter -> AssetFilter - VersionedMultiAsset -> VersionedAsset - WildMultiAsset -> WildAsset - VersionedMultiLocation -> VersionedLocation In order to fix a name conflict, the `Assets` in `xcm-executor` were renamed to `HoldingAssets`, as they represent assets in holding. ## Removed `Abstract` asset id It was not being used anywhere and this simplifies the code. Now assets are just constructed as follows: ```rust let asset: Asset = (AssetId(Location::new(1, Here)), 100u128).into(); ``` No need for specifying `Concrete` anymore. ## Outcome is now a named fields struct Instead of ```rust pub enum Outcome { Complete(Weight), Incomplete(Weight, Error), Error(Error), } ``` we now have ```rust pub enum Outcome { Complete { used: Weight }, Incomplete { used: Weight, error: Error }, Error { error: Error }, } ``` ## Added Reanchorable trait Now both locations and assets implement this trait, making it easier to reanchor both. ## New syntax for building locations and junctions Now junctions are built using the following methods: ```rust let location = Location { parents: 1, interior: [Parachain(1000), PalletInstance(50), GeneralIndex(1984)].into() }; ``` or ```rust let location = Location::new(1, [Parachain(1000), PalletInstance(50), GeneralIndex(1984)]); ``` And they are matched like so: ```rust match location.unpack() { (1, [Parachain(id)]) => ... (0, Here) => ..., (1, [_]) => ..., } ``` This syntax is mandatory in v4, and has been also implemented for v2 and v3 for easier migration. This was needed to make all sizes smaller. # TODO - [x] Scaffold v4 - [x] Port github.com/paritytech/polkadot/pull/7236 - [x] Remove `Multi` prefix - [x] Remove `Abstract` asset id --------- Co-authored-by: command-bot <> Co-authored-by:
Keith Yeung <[email protected]>
-
- Dec 21, 2023
-
-
Svyatoslav Nikolsky authored
related to https://github.com/paritytech/parity-bridges-common/issues/2739
-
- Dec 15, 2023
-
-
Svyatoslav Nikolsky authored
This PR adds possibility for relay chain governance to halt and resume bridge pallets using XCM calls. Following calls are enabled over XCM for the `root` origin: `pallet_bridge_grandpa::set_operating_mode`, `pallet_bridge_parachains::set_operating_mode` and `pallet_bridge_messages::set_operating_mode`.
-
- Dec 13, 2023
-
-
Svyatoslav Nikolsky authored
So far the `bridge-hub-test-utils` contained a tests set for testing BridgeHub runtime that is bridging with the remote **parachain**. But we have https://github.com/paritytech/polkadot-sdk/pull/2540 coming, which would add Rococo <> Bulletin chain bridge (where Bulletin = standalone chain that is using GRANDPA finality). Then it'll be expanded to Polkadot BH as well. So this PR adds the same set of tests to the `bridge-hub-test-utils`, but for the case when remote chain is the chain with GRANDPA finality. There's a lot of changes in this PR - I'll describe some: - I've added `BasicParachainRuntime` trait to decrease number of lines we need to add to `where` clause. Could revert, but imo it is useful; - `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is a submodule for generating test data for the test sets. `from_parachain.rs` is used in tests for the case when remote chain is a parachain, `from_grandpa_chain.rs` - for the bridges with remote GRANDPA chains. `mod.rs` has some code, shared by both types of tests; - `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is a submodule with all test cases. The `mod.rs` has tests, suitable for all cases. There's also `wth_parachain.rs` and `with_grandpa_chain.rs` with the same meaning as above; - I've merged the "core" code of two previous tests - `relayed_incoming_message_works` and `complex_relay_extrinsic_works` into one single `relayed_incoming_message_works` test. So now we are always constructing extrinsics and are dispatching them using executive module (meaning all signed extensions are also tested). New test set is used here: https://github.com/paritytech/polkadot-sdk/pull/2540. Once this PR is merged, I'll merge that other PR with master to remove duplicate changes. I'm also planning to cleanup generic constraints + remove some unnecessary assumptions about used chains in a follow-up PRs. But for now I think this PR has enough changes, so don't want to complicate it even more. --- Breaking changes for the code that have used those tests before: - the `construct_and_apply_extrinsic` callback now accepts the `RuntimeCall` instead of the `pallet_utility::Call`; - the `construct_and_apply_extrinsic` now may be called multiple times for the single test, so make sure the `frame_system::CheckNonce` is correctly constructed; - all previous tests have been moved from `bridge_hub_test_utils::test_cases` to `bridge_hub_test_utils::test_cases::from_parachain` module; - there are several changes in test arguments - please refer to https://github.com/paritytech/polkadot-sdk/compare/sv-tests-for-bridge-with-remote-grandpa-chain?expand=1#diff-79a28d4d3e1749050341c2424f00c4c139825b1a20937767f83e58b95166735c for details.
-
- Dec 12, 2023
-
-
Branislav Kontur authored
## Summary This pull request proposes a solution for improved control of the versioned XCM flow over the bridge (across different consensus chains) and resolves the situation where the sending chain/consensus has already migrated to a higher XCM version than the receiving chain/consensus. ## Problem/Motivation The current flow over the bridge involves a transfer from AssetHubRococo (AHR) to BridgeHubRococo (BHR) to BridgeHubWestend (BHW) and finally to AssetHubWestend (AHW), beginning with a reserve-backed transfer on AHR. In this process: 1. AHR sends XCM `ExportMessage` through `XcmpQueue`, incorporating XCM version checks using the `WrapVersion` feature, influenced by `pallet_xcm::SupportedVersion` (managed by `pallet_xcm::force_xcm_version` or version discovery). 2. BHR handles the `ExportMessage` instruction, utilizing the latest XCM version. The `HaulBlobExporter` converts the inner XCM to [`VersionedXcm::from`](https://github.com/paritytech/polkadot-sdk/blob/63ac2471aa0210f0ac9903bdd7d8f9351f9a635f/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465-L467), also using the latest XCM version. However, challenges arise: - Incompatibility when BHW uses a different version than BHR. For instance, if BHR migrates to **XCMv4** while BHW remains on **XCMv3**, BHR's `VersionedXcm::from` uses `VersionedXcm::V4` variant, causing encoding issues for BHW. ``` /// Just a simulation of possible error, which could happen on BHW /// (this code is based on actual master without XCMv4) let encoded = hex_literal::hex!("0400"); println!("{:?}", VersionedXcm::<()>::decode(&mut &encoded[..])); Err(Error { cause: None, desc: "Could not decode `VersionedXcm`, variant doesn't exist" }) ``` - Similar compatibility issues exist between AHR and AHW. ## Solution This pull request introduces the following solutions: 1. **New trait `CheckVersion`** - added to the `xcm` module and exposing `pallet_xcm::SupportedVersion`. This enhancement allows checking the actual XCM version for desired destinations outside of the `pallet_xcm` module. 2. **Version Check in `HaulBlobExporter`** uses `CheckVersion` to check known/configured destination versions, ensuring compatibility. For example, in the scenario mentioned, BHR can store the version `3` for BHW. If BHR is on XCMv4, it will attempt to downgrade the message to version `3` instead of using the latest version `4`. 3. **Version Check in `pallet-xcm-bridge-hub-router`** - this check ensures compatibility with the real destination's XCM version, preventing the unnecessary sending of messages to the local bridge hub if versions are incompatible. These additions aim to improve the control and compatibility of XCM flows over the bridge and addressing issues related to version mismatches. ## Possible alternative solution _(More investigation is needed, and at the very least, it should extend to XCMv4/5. If this proves to be a viable option, I can open an RFC for XCM.)._ Add the `XcmVersion` attribute to the `ExportMessage` so that the sending chain can determine, based on what is stored in `pallet_xcm::SupportedVersion`, the version the destination is using. This way, we may not need to handle the version in `HaulBlobExporter`. ``` ExportMessage { network: NetworkId, destination: InteriorMultiLocation, xcm: Xcm<()> destination_xcm_version: Version, // <- new attritbute }, ``` ``` pub trait ExportXcm { fn validate( network: NetworkId, channel: u32, universal_source: &mut Option<InteriorMultiLocation>, destination: &mut Option<InteriorMultiLocation>, message: &mut Option<Xcm<()>>, destination_xcm_version: Version, , // <- new attritbute ) -> SendResult<Self::Ticket>; ``` ## Future Directions This PR does not fix version discovery over bridge, further investigation will be conducted here: https://github.com/paritytech/polkadot-sdk/issues/2417. ## TODO - [x] `pallet_xcm` mock for tests uses hard-coded XCM version `2` - change to 3 or lastest? - [x] fix `pallet-xcm-bridge-hub-router` - [x] fix HaulBlobExporter with version determination [here](https://github.com/paritytech/polkadot-sdk/blob/2183669d05f9b510f979a0cc3c7847707bacba2e/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465) - [x] add unit-tests to the runtimes - [x] run benchmarks for `ExportMessage` - [x] extend local run scripts about `force_xcm_version(dest, version)` - [ ] when merged, prepare governance calls for Rococo/Westend - [ ] add PRDoc Part of: https://github.com/paritytech/parity-bridges-common/issues/2719 --------- Co-authored-by: command-bot <>
-
- Dec 06, 2023
-
-
Branislav Kontur authored
## Summary This PR aligns Rococo/Westend bridge with latest Bridges repo development: - https://github.com/paritytech/parity-bridges-common/pull/2727 - https://github.com/paritytech/parity-bridges-common/pull/2728 - https://github.com/paritytech/parity-bridges-common/pull/2729 Part of: https://github.com/paritytech/parity-bridges-common/issues/2452
-
- Nov 13, 2023
-
-
Adrian Catangiu authored
## Motivation `pallet-xcm` is the main user-facing interface for XCM functionality, including assets manipulation functions like `teleportAssets()` and `reserve_transfer_assets()` calls. While `teleportAsset()` works both ways, `reserve_transfer_assets()` works only for sending reserve-based assets to a remote destination and beneficiary when the reserve is the _local chain_. ## Solution This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to support transfers when reserves are other chains. This will allow complete, **bi-directional** reserve-based asset transfers user stories using `pallet-xcm`. Enables following scenarios: - transferring assets with local reserve (was previously supported iff asset used as fee also had local reserve - now it works in all cases), - transferring assets with reserve on destination, - transferring assets with reserve on remote/third-party chain (iff assets and fees have same remote reserve), - transferring assets with reserve different than the reserve of the asset to be used as fees - meaning can be used to transfer random asset with local/dest reserve while using DOT for fees on all involved chains, even if DOT local/dest reserve doesn't match asset reserve, - transferring assets with any type of local/dest reserve while using fees which can be teleported between involved chains. All of the above is done by pallet inner logic without the user having to specify which scenario/reserves/teleports/etc. The correct scenario and corresponding XCM programs are identified, and respectively, built automatically based on runtime configuration of trusted teleporters and trusted reserves. #### Current limitations: - while `fees` and "non-fee" `assets` CAN have different reserves (or fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among themselves, have different reserve locations (this is also implicitly enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely increased in the future). - `fees` and "non-fee" `assets` CANNOT have **different remote** reserves (this could also be supported in the future, but adds even more complexity while possibly not being worth it - we'll see what the future holds). Fixes https://github.com/paritytech/polkadot-sdk/issues/1584 Fixes https://github.com/paritytech/polkadot-sdk/issues/2055 --------- Co-authored-by:
Francisco Aguirre <[email protected]> Co-authored-by:
Branislav Kontur <[email protected]>
-
- Nov 03, 2023
-
-
Svyatoslav Nikolsky authored
Right now governance could only control byte-fee component of Rococo <> Westend message fees (paid at Asset Hubs). This PR changes it a bit: 1) governance now allowed to control both fee components - byte fee and base fee; 2) base fee now includes cost of "default" delivery and confirmation transactions, in addition to `ExportMessage` instruction cost.
-
- Nov 01, 2023
-
-
Branislav Kontur authored
## Summary Asset bridging support for AssetHub**Rococo** <-> AssetHub**Wococo** was added [here](https://github.com/paritytech/polkadot-sdk/pull/1215), so now we aim to bridge AssetHub**Rococo** and AssetHub**Westend**. (And perhaps retire AssetHubWococo and the Wococo chains). ## Solution **bridge-hub-westend-runtime** - added new runtime as a copy of `bridge-hub-rococo-runtime` - added support for bridging to `BridgeHubRococo` - added tests and benchmarks **bridge-hub-rococo-runtime** - added support for bridging to `BridgeHubWestend` - added tests and benchmarks - internal refactoring by splitting bridge configuration per network, e.g., `bridge_to_whatevernetwork_config.rs`. **asset-hub-rococo-runtime** - added support for asset bridging to `AssetHubWestend` (allows to receive only WNDs) - added new xcm router for `Westend` - added tests and benchmarks **asset-hub-westend-runtime** - added support for asset bridging to `AssetHubRococo` (allows to receive only ROCs) - added new xcm router for `Rococo` - added tests and benchmarks ## Deployment All changes will be deployed as a part of https://github.com/paritytech/polkadot-sdk/issues/1988. ## TODO - [x] benchmarks for all pallet instances - [x] integration tests - [x] local run scripts Relates to: https://github.com/paritytech/parity-bridges-common/issues/2602 Relates to: https://github.com/paritytech/polkadot-sdk/issues/1988 --------- Co-authored-by: command-bot <> Co-authored-by:
Adrian Catangiu <[email protected]> Co-authored-by:
joe petrowski <[email protected]>
-