1. Apr 24, 2024
  2. Apr 12, 2024
    • Branislav Kontur's avatar
      Remove `xcm::v3` from `assets-common` nits (#4037) · 5601f286
      Branislav Kontur authored
      This PR mainly removes `xcm::v3` stuff from `assets-common` to make it
      more generic and facilitate the transition to newer XCM versions. Some
      of the implementations here used hard-coded `xcm::v3::Location`, but now
      it's up to the runtime to configure according to its needs.
      
      Additional/consequent changes:
      - `penpal` runtime uses now `xcm::latest::Location` for `pallet_assets`
      as `AssetId`, because we don't care about migrations here
      - it pretty much simplify xcm-emulator integration tests, where we don't
      need now a lots of boilerplate conversions:
            ```
            v3::Location::try_from(...).expect("conversion works")`
            ```
      - xcm-emulator tests
      - split macro `impl_assets_helpers_for_parachain` to the
      `impl_assets_helpers_for_parachain` and
      `impl_foreign_assets_helpers_for_parachain` (avoids using hard-coded
      `xcm::v3::Location`)
      5601f286
  3. Mar 27, 2024
  4. Mar 26, 2024
    • Dcompoze's avatar
      Fix spelling mistakes across the whole repository (#3808) · 002d9260
      Dcompoze authored
      **Update:** Pushed additional changes based on the review comments.
      
      **This pull request fixes various spelling mistakes in this
      repository.**
      
      Most of the changes are contained in the first **3** commits:
      
      - `Fix spelling mistakes in comments and docs`
      
      - `Fix spelling mistakes in test names`
      
      - `Fix spelling mistakes in error messages, panic messages, logs and
      tracing`
      
      Other source code spelling mistakes are separated into individual
      commits for easier reviewing:
      
      - `Fix the spelling of 'authority'`
      
      - `Fix the spelling of 'REASONABLE_HEADERS_IN_JUSTIFICATION_ANCESTRY'`
      
      - `Fix the spelling of 'prev_enqueud_messages'`
      
      - `Fix the spelling of 'endpoint'`
      
      - `Fix the spelling of 'children'`
      
      - `Fix the spelling of 'PenpalSiblingSovereignAccount'`
      
      - `Fix the spelling of 'PenpalSudoAccount'`
      
      - `Fix the spelling of 'insufficient'`
      
      - `Fix the spelling of 'PalletXcmExtrinsicsBenchmark'`
      
      - `Fix the spelling of 'subtracted'`
      
      - `Fix the spelling of 'CandidatePendingAvailability'`
      
      - `Fix the spelling of 'exclusive'`
      
      - `Fix the spelling of 'until'`
      
      - `Fix the spelling of 'discriminator'`
      
      - `Fix the spelling of 'nonexistent'`
      
      - `Fix the spelling of 'subsystem'`
      
      - `Fix the spelling of 'indices'`
      
      - `Fix the spelling of 'committed'`
      
      - `Fix the spelling of 'topology'`
      
      - `Fix the spelling of 'response'`
      
      - `Fix the spelling of 'beneficiary'`
      
      - `Fix the spelling of 'formatted'`
      
      - `Fix the spelling of 'UNKNOWN_PROOF_REQUEST'`
      
      - `Fix the spelling of 'succeeded'`
      
      - `Fix the spelling of 'reopened'`
      
      - `Fix the spelling of 'proposer'`
      
      - `Fix the spelling of 'InstantiationNonce'`
      
      - `Fix the spelling of 'depositor'`
      
      - `Fix the spelling of 'expiration'`
      
      - `Fix the spelling of 'phantom'`
      
      - `Fix the spelling of 'AggregatedKeyValue'`
      
      - `Fix the spelling of 'randomness'`
      
      - `Fix the spelling of 'defendant'`
      
      - `Fix the spelling of 'AquaticMammal'`
      
      - `Fix the spelling of 'transactions'`
      
      - `Fix the spelling of 'PassingTracingSubscriber'`
      
      - `Fix the spelling of 'TxSignaturePayload'`
      
      - `Fix the spelling of 'versioning'`
      
      - `Fix the spelling of 'descendant'`
      
      - `Fix the spelling of 'overridden'`
      
      - `Fix the spelling of 'network'`
      
      Let me know if this structure is adequate.
      
      **Note:** The usage of the words `Merkle`, `Merkelize`, `Merklization`,
      `Merkelization`, `Merkleization`, is somewhat inconsistent but I left it
      as it is.
      
      ~~**Note:** In some places the term `Receival` is used to refer to
      message reception, IMO `Reception` is the correct word here, but I left
      it as it is.~~
      
      ~~**Note:** In some places the term `Overlayed` is used instead of the
      more acceptable version `Overlaid` but I also left it as it is.~~
      
      ~~**Note:** In some places the term `Applyable` is used instead of the
      correct version `Applicable` but I also left it as it is.~~
      
      **Note:** Some usage of British vs American english e.g. `judgement` vs
      `judgment`, `initialise` vs `initialize`, `optimise` vs `optimize` etc.
      are both present in different places, but I suppose that's
      understandable given the number of contributors.
      
      ~~**Note:** There is a spelling mistake in `.github/CODEOWNERS` but it
      triggers errors in CI when I make changes to it, so I left it as it
      is.~~
      002d9260
  5. Mar 14, 2024
    • Ignacio Palacios's avatar
      Improve Penpal runtime + emulated tests (#3543) · cfc4050d
      Ignacio Palacios authored
      Issues addressed in this PR:
      - Improve *Penpal* runtime:
      - Properly handled received assets. Previously, it treated `(1, Here)`
      as the local native currency, whereas it should be treated as a
      `ForeignAsset`. This wasn't a great example of standard Parachain
      behaviour, as no Parachain treats the system asset as the local
      currency.
      - Remove `AllowExplicitUnpaidExecutionFrom` the system. Again, this
      wasn't a great example of standard Parachain behaviour.
      - Move duplicated
      `ForeignAssetFeeAsExistentialDepositMultiplierFeeCharger` to
      `assets_common` crate.
      - Improve emulated tests:
        - Update *Penpal* tests to new runtime.
      - To simplify tests, register the reserve transferred, teleported, and
      system assets in *Penpal* and *AssetHub* genesis. This saves us from
      having to create the assets repeatedly for each test
      - Add missing test case:
      `reserve_transfer_assets_from_para_to_system_para`.
        - Cleanup.
      - Prevent integration tests crates imports from being re-exported, as
      they were polluting the `polkadot-sdk` docs.
      
      There is still a test case missing for reserve transfers:
      - Reserve transfer of system asset from *Parachain* to *Parachain*
      trough *AssetHub*.
      - This is not yet possible with `pallet-xcm` due to the reasons
      explained in https://github.com/paritytech/polkadot-sdk/pull/3339
      
      ---------
      
      Co-authored-by: command-bot <>
      cfc4050d
  6. Mar 08, 2024
  7. Jan 16, 2024
    • Francisco Aguirre's avatar
      XCMv4 (#1230) · 8428f678
      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: default avatarKeith Yeung <[email protected]>
      8428f678
  8. Dec 22, 2023
  9. Dec 12, 2023
    • Branislav Kontur's avatar
      Ensure xcm versions over bridge (on sending chains) (#2481) · 575b8f8d
      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 <>
      575b8f8d
  10. Nov 27, 2023
  11. Nov 14, 2023
  12. Nov 13, 2023
    • Adrian Catangiu's avatar
      pallet-xcm: enhance `reserve_transfer_assets` to support remote reserves (#1672) · 18257373
      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: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      18257373
  13. Nov 08, 2023
    • Ignacio Palacios's avatar
      [xcm-emulator] Chains generic over Network & Integration tests restructure (#2092) · ffa0e30e
      Ignacio Palacios authored
      Closes:
      - #1383 
      - Declared chains can be now be imported and reused in a different
      crate.
      - Chain declaration are now generic over a generic type `N` (the
      Network)
      - #1389
      - Solved #1383, chains and networks declarations can be restructure to
      avoid having to compile all chains when running integrations tests where
      are not needed.
      - Chains are now declared on its own crate (removed from
      `integration-tests-common`)
      - Networks are now declared on its own crate (removed from
      `integration-tests-common`)
          - Integration tests will import only the relevant Network crate
      - `integration-tests-common` is renamed to
      `emulated-integration-tests-common`
      
      All this is necessary to be able to implement what is described here:
      https://github.com/paritytech/roadmap/issues/56#issuecomment-1777010553
      
      ---------
      
      Co-authored-by: command-bot <>
      ffa0e30e
  14. Nov 02, 2023
    • Oliver Tale-Yazdi's avatar
      Use `Message Queue` as DMP and XCMP dispatch queue (#1246) · e1c033eb
      Oliver Tale-Yazdi authored
      (imported from https://github.com/paritytech/cumulus/pull/2157)
      
      ## Changes
      
      This MR refactores the XCMP, Parachains System and DMP pallets to use
      the [MessageQueue](https://github.com/paritytech/substrate/pull/12485)
      for delayed execution of incoming messages. The DMP pallet is entirely
      replaced by the MQ and thereby removed. This allows for PoV-bounded
      execution and resolves a number of issues that stem from the current
      work-around.
      
      All System Parachains adopt this change.  
      The most important changes are in `primitives/core/src/lib.rs`,
      `parachains/common/src/process_xcm_message.rs`,
      `pallets/parachain-system/src/lib.rs`, `pallets/xcmp-queue/src/lib.rs`
      and the runtime configs.
      
      ### DMP Queue Pallet
      
      The pallet got removed and its logic refactored into parachain-system.
      Overweight message management can be done directly through the MQ
      pallet.
      
      Final undeployment migrations are provided by
      `cumulus_pallet_dmp_queue::UndeployDmpQueue` and `DeleteDmpQueue` that
      can be configured with an aux config trait like:
      
      ```rust
      parameter_types! {
      	pub const DmpQueuePalletName: &'static str = \"DmpQueue\" < CHANGE ME;
      	pub const RelayOrigin: AggregateMessageOrigin = AggregateMessageOrigin::Parent;
      }
      
      impl cumulus_pallet_dmp_queue::MigrationConfig for Runtime {
      	type PalletName = DmpQueuePalletName;
      	type DmpHandler = frame_support::traits::EnqueueWithOrigin<MessageQueue, RelayOrigin>;
      	type DbWeight = <Runtime as frame_system::Config>::DbWeight;
      }
      
      // And adding them to your Migrations tuple:
      pub type Migrations = (
      	...
      	cumulus_pallet_dmp_queue::UndeployDmpQueue<Runtime>,
      	cumulus_pallet_dmp_queue::DeleteDmpQueue<Runtime>,
      );
      ```
      
      ### XCMP Queue pallet
      
      Removed all dispatch queue functionality. Incoming XCMP messages are now
      either: Immediately handled if they are Signals, enqueued into the MQ
      pallet otherwise.
      
      New config items for the XCMP queue pallet:
      ```rust
      /// The actual queue implementation that retains the messages for later processing.
      type XcmpQueue: EnqueueMessage<ParaId>;
      
      /// How a XCM over HRMP from a sibling parachain should be processed.
      type XcmpProcessor: ProcessMessage<Origin = ParaId>;
      
      /// The maximal number of suspended XCMP channels at the same time.
      #[pallet::constant]
      type MaxInboundSuspended: Get<u32>;
      ```
      
      How to configure those:
      
      ```rust
      // Use the MessageQueue pallet to store messages for later processing. The `TransformOrigin` is needed since
      // the MQ pallet itself operators on `AggregateMessageOrigin` but we want to enqueue `ParaId`s.
      type XcmpQueue = TransformOrigin<MessageQueue, AggregateMessageOrigin, ParaId, ParaIdToSibling>;
      
      // Process XCMP messages from siblings. This is type-safe to only accept `ParaId`s. They will be dispatched
      // with origin `Junction::Sibling(…)`.
      type XcmpProcessor = ProcessFromSibling<
      	ProcessXcmMessage<
      		AggregateMessageOrigin,
      		xcm_executor::XcmExecutor<xcm_config::XcmConfig>,
      		RuntimeCall,
      	>,
      >;
      
      // Not really important what to choose here. Just something larger than the maximal number of channels.
      type MaxInboundSuspended = sp_core::ConstU32<1_000>;
      ```
      
      The `InboundXcmpStatus` storage item was replaced by
      `InboundXcmpSuspended` since it now only tracks inbound queue suspension
      and no message indices anymore.
      
      Now only sends the most recent channel `Signals`, as all prio ones are
      out-dated anyway.
      
      ### Parachain System pallet
      
      For `DMP` messages instead of forwarding them to the `DMP` pallet, it
      now pushes them to the configured `DmpQueue`. The message processing
      which was triggered in `set_validation_data` is now being done by the MQ
      pallet `on_initialize`.
      
      XCMP messages are still handed off to the `XcmpMessageHandler`
      (XCMP-Queue pallet) - no change here.
      
      New config items for the parachain system pallet:
      ```rust
      /// Queues inbound downward messages for delayed processing. 
      ///
      /// Analogous to the `XcmpQueue` of the XCMP queue pallet.
      type DmpQueue: EnqueueMessage<AggregateMessageOrigin>;
      ``` 
      
      How to configure:
      ```rust
      /// Use the MQ pallet to store DMP messages for delayed processing.
      type DmpQueue = MessageQueue;
      ``` 
      
      ## Message Flow
      
      The flow of messages on the parachain side. Messages come in from the
      left via the `Validation Data` and finally end up at the `Xcm Executor`
      on the right.
      
      ![Untitled
      (1)](https://github.com/paritytech/cumulus/assets/10380170/6cf8b377-88c9-4aed-96df-baace266e04d)
      
      ## Further changes
      
      - Bumped the default suspension, drop and resume thresholds in
      `QueueConfigData::default()`.
      - `XcmpQueue::{suspend_xcm_execution, resume_xcm_execution}` errors when
      they would be a noop.
      - Properly validate the `QueueConfigData` before setting it.
      - Marked weight files as auto-generated so they wont auto-expand in the
      MR files view.
      - Move the `hypothetical` asserts to `frame_support` under the name
      `experimental_hypothetically`
      
      Questions:
      - [ ] What about the ugly `#[cfg(feature = \"runtime-benchmarks\")]` in
      the runtimes? Not sure how to best fix. Just having them like this makes
      tests fail that rely on the real message processor when the feature is
      enabled.
      - [ ] Need a good weight for `MessageQueueServiceWeight`. The scheduler
      already takes 80% so I put it to 10% but that is quite low.
      
      TODO:
      - [x] Remove c&p code after
      https://github.com/paritytech/polkadot/pull/6271
      - [x] Use `HandleMessage` once it is public in Substrate
      - [x] fix `runtime-benchmarks` feature
      https://github.com/paritytech/polkadot/pull/6966
      
      
      - [x] Benchmarks
      - [x] Tests
      - [ ] Migrate `InboundXcmpStatus` to `InboundXcmpSuspended`
      - [x] Possibly cleanup Migrations (DMP+XCMP)
      - [x] optional: create `TransformProcessMessageOrigin` in Substrate and
      replace `ProcessFromSibling`
      - [ ] Rerun weights on ref HW
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: command-bot <>
      e1c033eb
  15. Oct 11, 2023
    • Branislav Kontur's avatar
      Xcm emulator nits (#1649) · cfb29254
      Branislav Kontur authored
      # Desription
      
      ## Summary 
      
      This PR introduces several nits and tweaks to xcm emulator tests for
      system parachains.
      
      ## Explanation
      
      **Deduplicate `XcmPallet::send(` with root origin code**
      - Introduced `send_transact_to_parachain` which could be easily reuse
      for scenarios like _governance call from relay chain to parachain_.
      
      **Refactor `send_transact_sudo_from_relay_to_system_para_works`**
      - Test covered just one use-case which was moved to the
      `do_force_create_asset_from_relay_to_system_para`, so now we can extend
      this test with more _governance-like_ senarios.
      - Renamed to
      `send_transact_as_superuser_from_relay_to_system_para_works`.
      
      **Remove `send_transact_native_from_relay_to_system_para_fails` test**
      - This test and/or description is kind of misleading, because system
      paras support Native from relay chain by `RelayChainAsNative` with
      correct xcm origin.
      - It tested only sending on relay chain which should go directly to the
      relay chain unit-tests (does not even need to be in xcm emulator level).
      
      ## Future directions
      
      Check restructure parachains integration tests
      [issue](https://github.com/paritytech/polkadot-sdk/issues/1389) and [PR
      with more TODOs](https://github.com/paritytech/polkadot-sdk/pull/1693
      
      ).
      
      ---------
      
      Co-authored-by: default avatarIgnacio Palacios <[email protected]>
      cfb29254
  16. Oct 10, 2023
  17. Sep 29, 2023
  18. Sep 05, 2023
    • joe petrowski's avatar
      Move Relay-Specific Shared Code to One Place (#1193) · a1469180
      joe petrowski authored
      * add common libs
      
      * asset hubs
      
      * add westend
      
      * bridge hubs
      
      * collectives
      
      * contracts
      
      * emulated tests
      
      * parachain bin
      
      * delete collectives constants and update docs
      
      * integration tests should have apache license (some missing, some needed changing)
      
      * propagate features
      
      * fmt
      a1469180
  19. Sep 01, 2023
    • Ignacio Palacios's avatar
      [xcm-emulator] Improve hygiene and clean up (#1301) · 241601b1
      Ignacio Palacios authored
      * improve hygiene & clean up
      
      * improve hygiene & clean up - xcm-emulator
      
      * improve hygiene & clean up - common
      
      * improve hygiene & clean up - tests
      
      * improve hygiene & clean up - tests 2
      
      * last hygiene bits
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      ---------
      
      Co-authored-by: command-bot <>
      241601b1
  20. Aug 30, 2023
  21. Aug 10, 2023
    • Ignacio Palacios's avatar
      Replicate `e2e` integration test as `emulated` (#2958) · eadfbca3
      Ignacio Palacios authored
      
      
      * Allow functions to work over both parachains and relay chains
      
      * additional references
      
      * import
      
      * backup
      
      * refactoring para and relay traits
      
      * use runtime crates to build types
      
      * decouple ProcessMessage
      
      * decouple ProcessMessage 2
      
      * dmp and xcmp handlers decouple
      
      * backup
      
      * refactor done
      
      * common int values working
      
      * added global ext with mutex
      
      * works for two mutex
      
      * single mutex and remove condvar
      
      * global test ext done
      
      * failing moving test_ext because relay block num
      
      * relay_block_number issue fixed
      
      * backup
      
      * Test working with assertions
      
      * assertions get Test as arg
      
      * DispatchArgs as generic
      
      * clean up
      
      * backup
      
      * teleports for asset-hub-kusama done
      
      * improve assert_expected_events macro
      
      * rename Test generics
      
      * check assertions for tuples
      
      * test assertions redone
      
      * reserve_transfer_assets done
      
      * send transact done
      
      * hrmp test for paras
      
      * hrmp channels test done
      
      * hrmp channels test done 2
      
      * before modifying test dispatch
      
      * reserve tests done & Test dispatch fixed
      
      * reserve transfer local asset
      
      * force_create_and_mint_asset
      
      * force create and mint done
      
      * tests done
      
      * fix imports in common
      
      * common events refactored
      
      * add option to events attributes
      
      * asset-hub-polkadot tests done
      
      * asset-hub-westend half done
      
      * relay chain events move to common
      
      * remove failing send tests for asset-hub-westend
      
      * added events to bridge-hub-rococo
      
      * added events to collectives-polkadot
      
      * cargo clean up
      
      * fix asset-hub-westend tests
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * fix clippy
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * Removed unnecessary deps
      
      * Extracted some commonality for Kusama/Polkadot (which will be reused also for BridgeHubs) (#2971)
      
      * Extracted some commonality for Kusama/Polkadot (which will be reused also for BridgeHubs)
      
      * AssetHubRococo should better use AssetHubKusama runtime
      
      * add fund_account
      
      ---------
      
      Co-authored-by: default avatarNachoPal <[email protected]>
      
      * address comments
      
      * rename event assertion helpers
      
      * clean comments
      
      * address comments 2
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      ---------
      
      Co-authored-by: default avatarGiles Cope <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      eadfbca3
  22. Jul 05, 2023
    • Ignacio Palacios's avatar
      Add Bridges to `xcm-emulator` (#2812) · f6b33fe9
      Ignacio Palacios authored
      
      
      * rename bridge hub + BridgeMessages type
      
      * bridge base
      
      * bridge string approach
      
      * add decl_test_bridges macro
      
      * outbound lanes on the way
      
      * get & dispatch mock bridge done
      
      * fix bridge errors + log::debug for messages
      
      * clean up
      
      * update source OutboundLaneData
      
      * rococo & wococo added
      
      * sender_receiver_accounts_parameter_types macro
      
      * sender_receiver_accounts_parameter_types macro 2
      
      * fixed multi parachain + example on the way
      
      * working but router error
      
      * bridge working
      
      * refactor NetworkComponent
      
      * make it generic
      
      * working as generic
      
      * clean up
      
      * last bit
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * fix bridge hub handler name
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * add AssetConversion back for AssetHubWestend
      
      * Update xcm/xcm-emulator/src/lib.rs
      
      Co-authored-by: default avatarSquirrel <[email protected]>
      
      * add LaneId wrapper
      
      * update substrate
      
      * fix wrapper conversion
      
      * remove duplicate in workspace
      
      * Revert "update substrate"
      
      This reverts commit 92e8f201ae433aed3f70b998ebd4c23d9168d0ee.
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarSquirrel <[email protected]>
      f6b33fe9