Skip to content
Snippets Groups Projects
  1. Mar 17, 2024
  2. Mar 15, 2024
  3. Mar 13, 2024
  4. Mar 04, 2024
    • Gavin Wood's avatar
      FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280) · fd5f9292
      Gavin Wood authored
      Closes #2160
      
      First part of [Extrinsic
      Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415)
      
      Introduces a new trait `TransactionExtension` to replace
      `SignedExtension`. Introduce the idea of transactions which obey the
      runtime's extensions and have according Extension data (né Extra data)
      yet do not have hard-coded signatures.
      
      Deprecate the terminology of "Unsigned" when used for
      transactions/extrinsics owing to there now being "proper" unsigned
      transactions which obey the extension framework and "old-style" unsigned
      which do not. Instead we have __*General*__ for the former and
      __*Bare*__ for the latter. (Ultimately, the latter will be phased out as
      a type of transaction, and Bare will only be used for Inherents.)
      
      Types of extrinsic are now therefore:
      - Bare (no hardcoded signature, no Extra data; used to be known as
      "Unsigned")
      - Bare transactions (deprecated): Gossiped, validated with
      `ValidateUnsigned` (...
  5. Mar 01, 2024
  6. 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 <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarLiam Aharon <liam.aharon@hotmail.com>
      Co-authored-by: default avatarJuan Girini <juangirini@gmail.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: default avatarGavin Wood <gavin@parity.io>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
  7. Feb 09, 2024
  8. Feb 02, 2024
  9. Jan 31, 2024
    • 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 <george.pisaltu@parity.io>
  10. Jan 26, 2024
  11. Jan 24, 2024
    • Just van Stam's avatar
      Transactional processing for XCM (#1222) · 50eb12cf
      Just van Stam authored
      
      Moved from: https://github.com/paritytech/polkadot/pull/6951
      
      closes https://github.com/paritytech/polkadot-sdk/issues/490
      
      - [x] update cumulus
      
      --- 
      This PR introduces transactional processing of certain xcm instructions.
      For the list of instructions checkout
      https://github.com/paritytech/polkadot-sdk/issues/490. The transactional
      processing is implemented as an xcm-executor config item. The two
      implementations in this PR are `FrameTransactionalProcessor` and `()`.
      The `()` implementation does no transactional processing. Each
      implementation of the `ProcessTransaction` trait has an
      `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing
      is actually implemented. If Transactional processing is implemented,
      changes to touched registers should also be rolled back to prevent
      inconsistencies.
      
      
      Note for reviewers:
      Check out the following safety assumption:
      https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30
      
      ---------
      
      Co-authored-by: default avatarKeith Yeung <kungfukeith11@gmail.com>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: command-bot <>
    • Branislav Kontur's avatar
      [cumulus] Feature gates for rococo/westend related stuff in the `parachains-common` (#3041) · a78ff7d7
      Branislav Kontur authored
      
      This PR avoids automatically pulling rococo/westend runtime constants
      into the runtime by default. Usually, we have testnet runtimes dedicated
      to rococo or westend, and therefore, we don't need both dependencies.
      Additionally, it prevents pulling rococo/westend-related items into the
      `polkadot-fellows` repo, as seen in the Cargo.lock
      [here](https://github.com/polkadot-fellows/runtimes/blob/main/Cargo.lock#L14137-L14151)
      and
      [here](https://github.com/polkadot-fellows/runtimes/blob/main/Cargo.lock#L9756-L9770).
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
  12. Jan 23, 2024
  13. Jan 22, 2024
  14. Jan 17, 2024
  15. 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 <kungfukeith11@gmail.com>
  16. 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 <>
  17. Dec 13, 2023
  18. Dec 12, 2023
    • Chevdor's avatar
      Changelogs local generation (#1411) · 42a3afba
      Chevdor authored
      
      This PR introduces a script and some templates to use the prdoc involved
      in a release and build:
      - the changelog
      - a simple draft of audience documentation
      
      Since the prdoc presence was enforced in the middle of the version
      1.5.0, not all PRs did come with a `prdoc` file.
      This PR creates all the missing `prdoc` files with some minimum content
      allowing to properly generate the changelog.
      The generated content is **not** suitable for the audience
      documentation.
      
      The audience documentation will be possible with the next version, when
      all PR come with a proper `prdoc`.
      
      ## Assumptions
      
      - the prdoc files for release `vX.Y.Z` have been moved under
      `prdoc/X.Y.Z`
      - the changelog requires for now for the prdoc files to contain author +
      topic. Thos fields are optional.
      
      The build script can  be called as:
      ```
      VERSION=X.Y.Z ./scripts/release/build-changelogs.sh
      ```
      
      Related:
      -  #1408
      
      ---------
      
      Co-authored-by: default avatarEgorPopelyaev <egor@parity.io>
  19. Dec 05, 2023
  20. Dec 01, 2023
  21. Nov 29, 2023
    • Dónal Murray's avatar
      Remove system parachains Polkadot and Kusama runtimes (#1737) · 63ac2471
      Dónal Murray authored
      Since the Polkadot and Kusama runtimes are no longer in the repo, the
      relevant systems parachains runtimes also need to be removed. More
      context [here](https://github.com/paritytech/polkadot-sdk/issues/603)
      and [here](https://github.com/paritytech/polkadot-sdk/pull/1731).
      
      Removes the following:
      - `asset-hub-kusama` and `asset-hub-polkadot`
      - `bridge-hub-kusama` and `bridge-hub-polkadot`
      - `collectives-polkadot`
      - `glutton-kusama`
      
      Partially solves #603 and adds to #1731.
  22. Nov 27, 2023
    • Chevdor's avatar
      New runtime `spec_version` format + backport of the bump to 1.4.0 (#2468) · 4f8048b9
      Chevdor authored
      
      ## Overview
      
      This PR aligns the `spec_version` formatting to the [recent
      changes](https://github.com/polkadot-fellows/runtimes/pull/26/files#diff-efa4caeb17487ecb13d8f5eb7863c3241d84afa2e73fbf25909a2ca89df0f362R142)
      made for the Polkadot/Kusama runtimes.
      
      It also backports the latest version `v1.4.0` bumps as `1_004_000`.
      
      ## Details
      
      During the switch from `v0.9` to `v1.x`, the format of the
      `spec_version` was modified from: `(M)m_ppp` for a runtime considered on
      version `M.m.pp`. For instance `0.9.42` had a `spec_version` of `9420`.
      
      With the transition to `v1.x`, the format was changed to a bigger number
      (still `u32`) formatted as `MM_mm_ppp` where `1.2.3` would be stored as
      `01_02_003`.
      
      This PR aligns the format with that has been introduced in the
      fellowship repo: `MMM_mmm_ppp`.
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
  23. Nov 15, 2023
  24. Nov 05, 2023
  25. 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 <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarLiam Aharon <liam.aharon@hotmail.com>
      Co-authored-by: default avatarjoe petrowski <25483142+joepetrowski@users.noreply.github.com>
      Co-authored-by: default avatarKian Paimani <5588131+kianenigma@users.noreply.github.com>
      Co-authored-by: command-bot <>
  26. Oct 31, 2023
  27. Oct 27, 2023
    • Liam Aharon's avatar
      Automatically build and attach production and dev runtimes to GH releases (#2054) · a7061712
      Liam Aharon authored
      
      Closes https://github.com/paritytech/release-engineering/issues/6
      
      Adds a new Github Workflow which on a new release being created, builds
      and attaches all runtimes managed in this repository in two flavours:
      - `dev-debug-build`: Built with the `try-runtime` feature and has
      logging enabled
      - `on-chain-release`: Built with the regular old `on-chain-release`
      feature
      
      The new Github Workflow could be extended in the future by the
      @paritytech/release-engineering team to fully automate the release
      process if they choose to, similar to how it is fully automated in the
      Fellowship repo
      (https://github.com/polkadot-fellows/runtimes/blob/main/.github/workflows/release.yml).
      
      The `on-chain-release` did not exist for parachains, so I added it. 
      
      ---
      
      Tested on my fork: 
      - https://github.com/liamaharon/polkadot-sdk/actions/runs/6663773523
      - https://github.com/liamaharon/polkadot-sdk/releases/tag/test-6
      
      ---------
      
      Co-authored-by: default avatarChevdor <chevdor@users.noreply.github.com>
      Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
  28. Oct 26, 2023
  29. Oct 20, 2023
    • Bastian Köcher's avatar
      `xcm`: Change `TypeInfo::path` to not include `staging` (#1948) · f3bf5c1a
      Bastian Köcher authored
      
      The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
      crates.io as someone as squatted `xcm`. The problem with this rename is
      that the `TypeInfo` includes the crate name which ultimately lands in
      the metadata. The metadata is consumed by downstream users like
      `polkadot-js` or people building on top of `polkadot-js`. These people
      are using the entire `path` to find the type in the type registry. Thus,
      their code would break as the type path would now be [`staging_xcm`,
      `VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
      fixes this by renaming the path segment `staging_xcm` to `xcm`.
      
      This requires: https://github.com/paritytech/scale-info/pull/197
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
  30. Oct 18, 2023
  31. Oct 04, 2023
    • Bradley Olson's avatar
      Updating glutton for async backing (#1619) · 0a6dfdf9
      Bradley Olson authored
      Applied changes from the [User Update
      Guide](https://docs.google.com/document/d/1WQijD3bZTCsudOyPcDvugv659nCa2hEp2b_8eRU0h-Q),
      diverging in the node side where service.rs is different for
      `polkadot-parachain` than in the parachain template.
  32. Sep 27, 2023
  33. Sep 18, 2023
  34. Sep 14, 2023
    • Muharem Ismailov's avatar
      Enable `runtime-benchmarks` feature for crates (#1544) · 49c4b201
      Muharem Ismailov authored
      Enable `runtime-benchmarks` feature for `parachain-common` and
      `cumulus-primitives-utility` crates' dependencies.
      
      After adding `runtime-benchmarks = []` under `features` category in
      `Cargo.toml` files for the creates, I did run,
      > zepter lint propagate-feature --feature runtime-benchmarks --workspace
      --fix --feature-enables-dep="runtime-benchmarks:frame-benchmarking"
      
      This changes required for
      https://github.com/paritytech/polkadot-sdk/pull/1333
  35. Aug 30, 2023
  36. Aug 29, 2023
  37. Aug 28, 2023
  38. Aug 25, 2023