Skip to content
  1. Mar 01, 2024
  2. Feb 28, 2024
    • Oliver Tale-Yazdi's avatar
      Multi-Block-Migrations, `poll` hook and new System callbacks (#1781) · eefd5fe4
      Oliver Tale-Yazdi authored
      This MR is the merge of
      https://github.com/paritytech/substrate/pull/14414 and
      https://github.com/paritytech/substrate/pull/14275. It implements
      [RFC#13](https://github.com/polkadot-fellows/RFCs/pull/13), closes
      https://github.com/paritytech/polkadot-sdk/issues/198.
      
      ----- 
      
      This Merge request introduces three major topicals:
      
      1. Multi-Block-Migrations
      1. New pallet `poll` hook for periodic service work
      1. Replacement hooks for `on_initialize` and `on_finalize` in cases
      where `poll` cannot be used
      
      and some more general changes to FRAME.  
      The changes for each topical span over multiple crates. They are listed
      in topical order below.
      
      # 1.) Multi-Block-Migrations
      
      Multi-Block-Migrations are facilitated by creating `pallet_migrations`
      and configuring `System::Config::MultiBlockMigrator` to point to it.
      Executive picks this up and triggers one step of the migrations pallet
      per block.
      The chain is in lockdown mode for as long as an MBM is ongoing.
      Executive does this by polling `MultiBlockMigrator::ongoing` and not
      allowing any transaction in a block, if true.
      
      A MBM is defined through trait `SteppedMigration`. A condensed version
      looks like this:
      ```rust
      /// A migration that can proceed in multiple steps.
      pub trait SteppedMigration {
      	type Cursor: FullCodec + MaxEncodedLen;
      	type Identifier: FullCodec + MaxEncodedLen;
      
      	fn id() -> Self::Identifier;
      
      	fn max_steps() -> Option<u32>;
      
      	fn step(
      		cursor: Option<Self::Cursor>,
      		meter: &mut WeightMeter,
      	) -> Result<Option<Self::Cursor>, SteppedMigrationError>;
      }
      ```
      
      `pallet_migrations` can be configured with an aggregated tuple of these
      migrations. It then starts to migrate them one-by-one on the next
      runtime upgrade.
      Two things are important here:
      - 1. Doing another runtime upgrade while MBMs are ongoing is not a good
      idea and can lead to messed up state.
      - 2. **Pallet Migrations MUST BE CONFIGURED IN `System::Config`,
      otherwise it is not used.**
      
      The pallet supports an `UpgradeStatusHandler` that can be used to notify
      external logic of upgrade start/finish (for example to pause XCM
      dispatch).
      
      Error recovery is very limited in the case that a migration errors or
      times out (exceeds its `max_steps`). Currently the runtime dev can
      decide in `FailedMigrationHandler::failed` how to handle this. One
      follow-up would be to pair this with the `SafeMode` pallet and enact
      safe mode when an upgrade fails, to allow governance to rescue the
      chain. This is currently not possible, since governance is not
      `Mandatory`.
      
      ## Runtime API
      
      - `Core`: `initialize_block` now returns `ExtrinsicInclusionMode` to
      inform the Block Author whether they can push transactions.
      
      ### Integration
      
      Add it to your runtime implementation of `Core` and `BlockBuilder`:
      ```patch
      diff --git a/runtime/src/lib.rs b/runtime/src/lib.rs
      @@ impl_runtime_apis! {
      	impl sp_block_builder::Core<Block> for Runtime {
      -		fn initialize_block(header: &<Block as BlockT>::Header) {
      +		fn initialize_block(header: &<Block as BlockT>::Header) -> RuntimeExecutiveMode {
      			Executive::initialize_block(header)
      		}
      
      		...
      	}
      ```
      
      # 2.) `poll` hook
      
      A new pallet hook is introduced: `poll`. `Poll` is intended to replace
      mostly all usage of `on_initialize`.
      The reason for this is that any code that can be called from
      `on_initialize` cannot be migrated through an MBM. Currently there is no
      way to statically check this; the implication is to use `on_initialize`
      as rarely as possible.
      Failing to do so can result in broken storage invariants.
      
      The implementation of the poll hook depends on the `Runtime API` changes
      that are explained above.
      
      # 3.) Hard-Deadline callbacks
      
      Three new callbacks are introduced and configured on `System::Config`:
      `PreInherents`, `PostInherents` and `PostTransactions`.
      These hooks are meant as replacement for `on_initialize` and
      `on_finalize` in cases where the code that runs cannot be moved to
      `poll`.
      The reason for this is to make the usage of HD-code (hard deadline) more
      explicit - again to prevent broken invariants by MBMs.
      
      # 4.) FRAME (general changes)
      
      ## `frame_system` pallet
      
      A new memorize storage item `InherentsApplied` is added. It is used by
      executive to track whether inherents have already been applied.
      Executive and can then execute the MBMs directly between inherents and
      transactions.
      
      The `Config` gets five new items:
      - `SingleBlockMigrations` this is the new way of configuring migrations
      that run in a single block. Previously they were defined as last generic
      argument of `Executive`. This shift is brings all central configuration
      about migrations closer into view of the developer (migrations that are
      configured in `Executive` will still work for now but is deprecated).
      - `MultiBlockMigrator` this can be configured to an engine that drives
      MBMs. One example would be the `pallet_migrations`. Note that this is
      only the engine; the exact MBMs are injected into the engine.
      - `PreInherents` a callback that executes after `on_initialize` but
      before inherents.
      - `PostInherents` a callback that executes after all inherents ran
      (including MBMs and `poll`).
      - `PostTransactions` in symmetry to `PreInherents`, this one is called
      before `on_finalize` but after all transactions.
      
      A sane default is to set all of these to `()`. Example diff suitable for
      any chain:
      ```patch
      @@ impl frame_system::Config for Test {
       	type MaxConsumers = ConstU32<16>;
      +	type SingleBlockMigrations = ();
      +	type MultiBlockMigrator = ();
      +	type PreInherents = ();
      +	type PostInherents = ();
      +	type PostTransactions = ();
       }
      ```
      
      An overview of how the block execution now looks like is here. The same
      graph is also in the rust doc.
      
      <details><summary>Block Execution Flow</summary>
      <p>
      
      ![Screenshot 2023-12-04 at 19 11
      29](https://github.com/paritytech/polkadot-sdk/assets/10380170/e88a80c4-ef11-4faa-8df5-8b33a724c054)
      
      </p>
      </details> 
      
      ## Inherent Order
      
      Moved to https://github.com/paritytech/polkadot-sdk/pull/2154
      
      
      
      ---------------
      
      
      ## TODO
      
      - [ ] Check that `try-runtime` still works
      - [ ] Ensure backwards compatibility with old Runtime APIs
      - [x] Consume weight correctly
      - [x] Cleanup
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarJuan Girini <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarGavin Wood <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      eefd5fe4
    • Liam Aharon's avatar
      Runtime Upgrade ref docs and Single Block Migration example pallet (#1554) · 12ce4f7d
      Liam Aharon authored
      Closes https://github.com/paritytech/polkadot-sdk-docs/issues/55
      
      - Changes 'current storage version' terminology to less ambiguous
      'in-code storage version' (suggestion by @ggwpez)
      - Adds a new example pallet `pallet-example-single-block-migrations`
      - Adds a new reference doc to replace
      https://docs.substrate.io/maintain/runtime-upgrades/ (temporarily living
      in the pallet while we wait for developer hub PR to merge)
      - Adds documentation for the `storage_alias` macro
      - Improves `trait Hooks` docs 
      - Improves `trait GetStorageVersion` docs
      - Update the suggested patterns for using `VersionedMigration`, so that
      version unchecked migrations are never exported
      - Prevents accidental usage of version unchecked migrations in runtimes
      
      https://github.com/paritytech/substrate/pull/14421#discussion_r1255467895
      - Unversioned migration code is kept inside `mod version_unchecked`,
      versioned code is kept in `pub mod versioned`
      - It is necessary to use modules to limit visibility because the inner
      migration must be `pub`. See
      https://github.com/rust-lang/rust/issues/30905 and
      
      https://internals.rust-lang.org/t/lang-team-minutes-private-in-public-rules/4504/40
      for more.
      
      ### todo
      
      - [x] move to reference docs to proper place within sdk-docs (now that
      https://github.com/paritytech/polkadot-sdk/pull/2102
      
       is merged)
      - [x] prdoc
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarJuan <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatargupnik <[email protected]>
      12ce4f7d
  3. Feb 26, 2024
  4. Feb 21, 2024
    • Clara van Staden's avatar
      Snowbridge - Test pallet order (#3381) · 5a06771e
      Clara van Staden authored
      - Adds a test to check the correct digest for Snowbridge outbound
      messages. For the correct digest to be in the block, the the
      MessageQueue pallet should be configured after the EthereumOutbound
      queue pallet. The added test fails if the EthereumOutbound is configured
      after the MessageQueue pallet.
      - Adds a helper method `run_to_block_with_finalize` to simulate the
      block finalizing. The existing `run_to_block` method does not finalize
      and so it cannot successfully test this condition.
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/3208
      
      ---------
      
      Co-authored-by: claravanstaden <Cats 4 life!>
      5a06771e
  5. Feb 20, 2024
  6. Feb 13, 2024
  7. Feb 12, 2024
  8. Feb 09, 2024
  9. Feb 06, 2024
  10. Feb 02, 2024
  11. Jan 31, 2024
    • Branislav Kontur's avatar
      [xcm] Fix `SovereignPaidRemoteExporter` and `DepositAsset` handling (#3157) · 6ea472ad
      Branislav Kontur authored
      This PR addresses two issues:
      - It modifies `DepositAsset`'s asset filter from `All` to
      `AllCounted(1)` to prevent potentially charging excessive weight/fees.
      This adjustment avoids situations where fees could be calculated based
      on the count of assets, as illustrated
      [here](https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/parachains/runtimes/bridge-hubs/bridge-hub-rococo/src/weights/xcm/mod.rs#L38-L46).
      - It encapsulates `DepositAsset` with `SetAppendix` to ensure that
      `fees` are not trapped in any case. For instance, this prevents issues
      when `ExportXcm::validate` encounters an error during the processing of
      `ExportMessage`.
      6ea472ad
    • Branislav Kontur's avatar
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed... · bb8ddc46
      Branislav Kontur authored
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed `pallet_balances`'s `MaxHolds` config (#2657)
      
      I started this investigation/issue based on @liamaharon question
      [here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499).
      
      ## Problem
      
      The `pallet_balances` integrity test should correctly detect that the
      runtime has correct distinct `HoldReasons` variant count. I assume the
      same situation exists for RuntimeFreezeReason.
      
      It is not a critical problem, if we set `MaxHolds` with a sufficiently
      large value, everything should be ok. However, in this case, the
      integrity_test check becomes less useful.
      
      **Situation for "any" runtime:**
      - `HoldReason` enums from different pallets:
      ```rust
              /// from pallet_nis
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		NftReceipt,
      	}
      
              /// from pallet_preimage
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		Preimage,
      	}
      
              // from pallet_state-trie-migration
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		SlashForContinueMigrate,
      		SlashForMigrateCustomTop,
      		SlashForMigrateCustomChild,
      	}
      ```
      
      - generated `RuntimeHoldReason` enum looks like:
      ```rust
      pub enum RuntimeHoldReason {
      
          #[codec(index = 32u8)]
          Preimage(pallet_preimage::HoldReason),
      
          #[codec(index = 38u8)]
          Nis(pallet_nis::HoldReason),
      
          #[codec(index = 42u8)]
          StateTrieMigration(pallet_state_trie_migration::HoldReason),
      }
      ```
      
      - composite enum `RuntimeHoldReason` variant count is detected as `3`
      - we set `type MaxHolds = ConstU32<3>`
      - `pallet_balances::integrity_test` is ok with `3`(at least 3)
      
      However, the real problem can occur in a live runtime where some
      functionality might stop working. This is due to a total of 5 distinct
      hold reasons (for pallets with multi-instance support, it is even more),
      and not all of them can be used because of an incorrect `MaxHolds`,
      which is deemed acceptable according to the `integrity_test`:
        ```
        // pseudo-code - if we try to call all of these:
      
      T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(),
      &nft_owner, deposit)?;
      T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(),
      &nft_owner, deposit)?;
      
        // With `type MaxHolds = ConstU32<3>` these two will fail
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(),
      &nft_owner, deposit)?;
        ```  
      
      
      ## Solutions
      
      A macro `#[pallet::*]` expansion is extended of `VariantCount`
      implementation for the `#[pallet::composite_enum]` enum type. This
      expansion generates the `VariantCount` implementation for pallets'
      `HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants
      must be plain enum values without fields to ensure a deterministic
      count.
      
      The composite runtime enum, `RuntimeHoldReason` and
      `RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum
      of pallets' enum `VariantCount::VARIANT_COUNT`:
      ```rust
      #[frame_support::pallet(dev_mode)]
      mod module_single_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason {
      		ModuleSingleInstanceReason1,
      		ModuleSingleInstanceReason2,
      	}
      ...
      }
      
      #[frame_support::pallet(dev_mode)]
      mod module_multi_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason<I: 'static = ()> {
      		ModuleMultiInstanceReason1,
      		ModuleMultiInstanceReason2,
      		ModuleMultiInstanceReason3,
      	}
      ...
      }
      
      
      impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount
          for RuntimeHoldReason
      {
          const VARIANT_COUNT: u32 = 0
              + module_single_instance::HoldReason::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT;
      }
      ```
      
      In addition, `MaxHolds` is removed (as suggested
      [here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573))
      from `pallet_balances`, and its `Holds` are now bounded to
      `RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let
      the runtime specify `MaxHolds`.
      
      
      ## For reviewers
      
      Relevant changes can be found here:
      - `substrate/frame/support/procedural/src/lib.rs` 
      -  `substrate/frame/support/procedural/src/pallet/parse/composite.rs`
      -  `substrate/frame/support/procedural/src/pallet/expand/composite.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs`
      - `substrate/frame/support/src/traits/misc.rs`
      
      And the rest of the files is just about removed `MaxHolds` from
      `pallet_balances`
      
      ## Next steps
      
      Do the same for `MaxFreezes`
      https://github.com/paritytech/polkadot-sdk/issues/2997
      
      .
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      bb8ddc46
    • Branislav Kontur's avatar
      [cumulus] `parachains-common` testnet constants cleaning (#3134) · 4450b615
      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: default avatargeorgepisaltu <[email protected]>
      4450b615
  12. Jan 30, 2024
  13. Jan 29, 2024
  14. Jan 26, 2024
  15. Jan 24, 2024
  16. Jan 23, 2024
    • Branislav Kontur's avatar
      Various nits and alignments for testnet runtimes (#3024) · a817d310
      Branislav Kontur authored
      There were several improvements and PRs that didn't apply to all
      runtimes, so this PR attempts to align those small differences. In
      addition, the PR eliminates unused dependencies across multiple modules.
      
      Relates to PR for `polkadot-fellows`:
      https://github.com/polkadot-fellows/runtimes/pull/154
      a817d310
    • Niklas Adolfsson's avatar
      rpc: backpressured RPC server (bump jsonrpsee 0.20) (#1313) · e16ef086
      Niklas Adolfsson authored
      This is a rather big change in jsonrpsee, the major things in this bump
      are:
      - Server backpressure (the subscription impls are modified to deal with
      that)
      - Allow custom error types / return types (remove jsonrpsee::core::Error
      and jsonrpee::core::CallError)
      - Bug fixes (graceful shutdown in particular not used by substrate
      anyway)
         - Less dependencies for the clients in particular
         - Return type requires Clone in method call responses
         - Moved to tokio channels
         - Async subscription API (not used in this PR)
      
      Major changes in this PR:
      - The subscriptions are now bounded and if subscription can't keep up
      with the server it is dropped
      - CLI: add parameter to configure the jsonrpc server bounded message
      buffer (default is 64)
      - Add our own subscription helper to deal with the unbounded streams in
      substrate
      
      The most important things in this PR to review is the added helpers
      functions in `substrate/client/rpc/src/utils.rs` and the rest is pretty
      much chore.
      
      Regarding the "bounded buffer limit" it may cause the server to handle
      the JSON-RPC calls
      slower than before.
      
      The message size limit is bounded by "--rpc-response-size" thus "by
      default 10MB * 64 = 640MB"
      but the subscription message size is not covered by this limit and could
      be capped as well.
      
      Hopefully the last release prior to 1.0, sorry in advance for a big PR
      
      Previous attempt: https://github.com/paritytech/substrate/pull/13992
      
      Resolves https://github.com/paritytech/polkadot-sdk/issues/748, resolves
      https://github.com/paritytech/polkadot-sdk/issues/627
      e16ef086
  17. Jan 22, 2024
  18. Jan 19, 2024
    • Sergej Sakac's avatar
      Enable cross-chain NFT transfers on asset-hub (#2796) · 50a2e28b
      Sergej Sakac authored
      
      
      This PR introduces the following changes:
      
      - [x] Adds a `UniquesTransactor` to asset-hub-rococo
      - [x] Adds a `UniquesTransactor` to asset-hub-westend
      
      We can't add a transactor for `pallet-nfts` like we do for
      `pallet-uniques` because `pallet-nfts` uses `nonfungibles_v2::Mutate`
      instead of `nonfungibles::Mutate`, and making that work would be out of
      scope of this PR.
      
      With these modifications, reserve-based NFT cross-chain transfers can be
      performed on asset-hub.
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      50a2e28b
  19. Jan 18, 2024
  20. Jan 17, 2024
  21. 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
    • 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
  22. Jan 10, 2024
  23. Jan 09, 2024
  24. Dec 22, 2023
  25. Dec 21, 2023
  26. Dec 20, 2023
    • 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