1. Jan 18, 2024
  2. Jan 17, 2024
  3. 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
    • Dónal Murray's avatar
      Bump rococo relay and coretime-rococo to 1.6 (#2913) · a42a47f8
      Dónal Murray authored
      Co-authored-by: command-bot <>
      a42a47f8
    • Muharem Ismailov's avatar
      XCM WeightTrader: Swap Fee Asset for Native Asset (#1845) · 2cb39f8d
      Muharem Ismailov authored
      Implements an XCM executor `WeightTrader`, facilitating fee payments in
      any asset that can be exchanged for a native asset.
      
      A few constraints need to be observed:
      - `buy_weight` and `refund` operations must be atomic, as another weight
      trader implementation might be attempted in case of failure.
      - swap credit must be utilized since there isn’t an account to which an
      asset of some class can be deposited with a guarantee to meet the
      existential deposit requirement. Also, operating with credits enhances
      the efficiency of the weight trader -
      https://github.com/paritytech/polkadot-sdk/pull/1677
      
      related PRs:
      - (depends) https://github.com/paritytech/polkadot-sdk/pull/2031
      - (depends) https://github.com/paritytech/polkadot-sdk/pull/1677
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/1847
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/1876
      
      // DONE: impl `OnUnbalanced` for a `fungible/s` credit
      // DONE: make the trader free from a concept of a native currency and
      drop few fallible conversions. related issue -
      https://github.com/paritytech/polkadot-sdk/issues/1842
      
      
      // DONE: tests
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      2cb39f8d
    • Bastian Köcher's avatar
      Some random fixes (#2936) · 1c2db174
      Bastian Köcher authored
      - Do not disable `std` feature in the integration tests
      - `contracts-fixtures` test should only check for `riscv` build when the
      feature is enabled
      1c2db174
  4. Jan 10, 2024
  5. Jan 09, 2024
  6. Jan 08, 2024
  7. Jan 07, 2024
  8. Jan 05, 2024
  9. Jan 04, 2024
  10. Dec 28, 2023
  11. Dec 27, 2023
  12. Dec 26, 2023
  13. Dec 22, 2023
  14. Dec 21, 2023
  15. Dec 20, 2023
    • joe petrowski's avatar
      Fix Coretime Master (#2765) · d84e135b
      joe petrowski authored
      Should have merged master into #2682 before merging.
      d84e135b
    • Dónal Murray's avatar
      Fix clippy lints behind feature gates and add new CI step all features (#2569) · d68868f6
      Dónal Murray authored
      
      
      Many clippy lints usually enforced by `-Dcomplexity` and `-Dcorrectness`
      are not caught by CI as they are gated by `features`, like
      `runtime-benchmarks`, while the clippy CI job runs with only the default
      features for all targets.
      
      This PR also adds a CI step to run clippy with `--all-features` to
      ensure the code quality is maintained behind feature gates from now on.
      
      To improve local development, clippy lints are downgraded to warnings,
      but they still will result in an error at CI due to the `-Dwarnings`
      rustflag.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      d68868f6
    • joe petrowski's avatar
      Add Authorize Upgrade Pattern to Frame System (#2682) · 280aa0b5
      joe petrowski authored
      Adds the `authorize_upgrade` -> `enact_authorized_upgrade` pattern to
      `frame-system`. This will be useful for upgrading bridged chains that
      are under the governance of Polkadot without passing entire runtime Wasm
      blobs over a bridge.
      
      Notes:
      
      - Changed `enact_authorized_upgrade` to `apply_authorized_upgrade`.
      Personal opinion, "apply" more accurately expresses what it's doing. Can
      change back if outvoted.
      - Remove `check_version` in favor of two extrinsics, so as to make
      _checked_ the default.
      - Left calls in `parachain-system` and marked as deprecated to prevent
      breaking the API. They just call into the `frame-system` functions.
      - Updated `frame-system` benchmarks to v2 syntax.
      
      ---------
      
      Co-authored-by: command-bot <>
      280aa0b5
    • Muharem Ismailov's avatar
      pallet-asset-conversion: Decoupling Native Currency Dependancy (#2031) · 4f832ea8
      Muharem Ismailov authored
      closes https://github.com/paritytech/polkadot-sdk/issues/1842
      
      Decoupling Pallet from the Concept of Native Currency
      
      Currently, the pallet is intrinsically linked with the concept of native
      currency, requiring users to provide implementations of the
      `fungible::*` and `fungibles::*` traits to interact with native and non
      native assets. This incapsulates some non-related to the pallet
      complexity and makes it less adaptable in contexts where the native
      currency concept is absent.
      
      With this PR, the dependence on `fungible::*` for liquidity-supplying
      assets has been removed. Instead, the native and non-native currencies'
      handling is now overseen by a single type that implements the
      `fungibles::*` traits. To simplify this integration, types have been
      introduced to facilitate the creation of a union between `fungible::*`
      and `fungibles::*` implementations, producing a unified `fungibles::*`
      type.
      
      One of the reasons driving these changes is the ambition to create a
      more user-friendly API for the `SwapCredit` implementation. Given that
      it interacts with two distinct credit types from `fungible` and
      `fungibles`, a unified type was introduced. Clients now manage potential
      conversion failures for those credit types. In certain contexts, it's
      vital to guarantee that operations are fail-safe, like in this impl -
      [PR](https://github.com/paritytech/polkadot-sdk/pull/1845), place in
      [code](https://github.com/paritytech/polkadot-sdk/blob/20b85a5fada8f55c98ba831964f5866ffeadf4da/cumulus/primitives/utility/src/lib.rs#L429).
      
      Additional Updates:
      - abstracted the pool ID and its account derivation logic via trait
      bounds, along with common implementation offerings;
      - removed `inc_providers` on a pool creation for the pool account;
      - benchmarks:
      -- swap complexity is N, not const;
      -- removed `From<u128> + Into<u128>` bound from `T::Balance`;
      -- removed swap/liquidity/.. amount constants, resolve them dynamically
      based on pallet configuration;
      -- migrated to v2 API;
      - `OnUnbalanced` handler for the pool creation fee, replacing direct
      transfers to a specified account ID;
      - renamed `MultiAssetId` to `AssetKind` aligning with naming across
      frame crates;
      
      related PRs:
      - (depends) https://github.com/paritytech/polkadot-sdk/pull/1677
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/2033
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/1876
      
      
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      4f832ea8
  16. Dec 19, 2023
  17. Dec 18, 2023
  18. Dec 15, 2023
  19. Dec 14, 2023
    • Svyatoslav Nikolsky's avatar
      Add Rococo People <> Rococo Bulletin bridge support to Rococo Bridge Hub (#2540) · 097308e3
      Svyatoslav Nikolsky authored
      This PR adds [Rococo
      People](https://github.com/paritytech/polkadot-sdk/pull/2281) <> [Rococo
      Bulletin](https://github.com/zdave-parity/polkadot-bulletin-chain) to
      the Rococo Bridge Hub code. There's a couple of things left to do here:
      - [x] add remaining tests - it'd need some refactoring in the
      `bridge-hub-test-utils` - will do in a separate PR;
      - [x] actually run benchmarks for new messaging pallet (do we have bot
      nowadays?).
      
      The reason why I'm opening it before this ^^^ is ready, is that I'd like
      to hear others opinion on how to deal with hacks with that bridge.
      Initially I was assuming that Rococo Bulletin will be the 1:1 copy of
      the Polkadot Bulletin (to avoid maintaining multiple
      runtimes/releases/...), so you can see many `PolkadotBulletin` mentions
      in this PR, even though we are going to bridge with the parallel chain
      (`RococoBulletin`). That's because e.g. pallet names from
      `construct_runtime` are affecting runtime storage keys and bridges are
      using runtime storage proofs => it is important to use names that the
      Bulletin chain expects.
      
      But in the end, this hack won't work - we can't use Polkadot Bulletin
      runtime to bridge with Rococo Bridge Hub, because Polkadot Bulletin
      expects Polkadot Bridge hub to use `1002` parachain id and Rococo Bridge
      Hub seats on the `1013`. This also affects storage keys using in
      bridging, so I had to add the [`rococo`
      feature](https://github.com/svyatonik/polkadot-bulletin-chain/blob/add-bridge-pallets/runtime/Cargo.toml#L198)
      to the Bulletin chain. So now we can actually alter its runtime and
      adapt it for Rococo.
      
      So the question here is - what's better for us here
      - to leave everything as is (seems hacky and non-trivial);
      - change Bulletin chain runtime when `rococo` feature is used - e.g. use
      proper names there (`WithPolkadotGrandpa` -> `WithRococoGrandpa`, ...)
      - add another set of pallets to the Bulletin chain runtime to bridge
      with Rococo and never use them in production. Similar to hack that we
      had in Rococo/Wococo
      
      cc @acatangiu @bkontur @serban300 
      
      also cc @joepetrowski
      
       as the main "client" of this bridge
      
      ---
      
      A couple words on how this bridge is different from the Rococo <>
      Westend bridge:
      - it is a bridge with a chain that uses GRANDPA finality, not the
      parachain finality (hence the tests needs to be changed);
      - it is a fee-free bridge. So
      `AllowExplicitUnpaidExecutionFrom<Equals<SiblingPeople>>` + we are not
      paying any rewards to relayers (apart from compensating transaction
      costs).
      
      ---------
      
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarEgor_P <[email protected]>
      Co-authored-by: command-bot <>
      097308e3
    • Francisco Aguirre's avatar
      Add FungibleAdapter (#2684) · 10a91f82
      Francisco Aguirre authored
      In the move from the old `Currency` traits to the new `fungible/s`
      family of traits, we already had the `FungiblesAdapter` and
      `NonFungiblesAdapter` for multiple fungible and non fungible assets
      respectively. However, for handling only one fungible asset, we were
      missing a `FungibleAdapter`, and so used the old `CurrencyAdapter`
      instead. This PR aims to fill in that gap, and provide the new adapter
      for more updated examples.
      
      I marked the old `CurrencyAdapter` as deprecated as part of this PR, and
      I'll change it to the new `FungibleAdapter` in a following PR.
      The two stages are separated so as to not bloat this PR with some name
      fixes in tests.
      
      ---------
      
      Co-authored-by: command-bot <>
      10a91f82
    • Egor_P's avatar
      [Backport] txn version bump from 1.5.0 (#2709) · 3e4e8c0b
      Egor_P authored
      This PR backports `transaction_version` bump from `1.5.0` release back
      to `master`
      3e4e8c0b