Skip to content
  1. Apr 02, 2024
    • Dastan's avatar
      migrations: prevent accidentally using unversioned migrations instead of... · e5427969
      Dastan authored
      migrations: prevent accidentally using unversioned migrations instead of `VersionedMigration` (#3835)
      
      closes #1324 
      
      #### Problem
      Currently, it is possible to accidentally use inner unversioned
      migration instead of `VersionedMigration` since both implement
      `OnRuntimeUpgrade`.
      
      #### Solution
      
      With this change, we make it clear that value of `Inner` is not intended
      to be used directly. It is achieved by bounding `Inner` to new trait
      `UncheckedOnRuntimeUpgrade`, which has the same interface (except
      `unchecked_` prefix) as `OnRuntimeUpgrade`.
      
      #### `try-runtime` functions
      
      Since developers can implement `try-runtime` for `Inner` value in
      `VersionedMigration` and have custom logic for it, I added the same
      `try-runtime` functions to `UncheckedOnRuntimeUpgrade`. I looked for a
      ways to not duplicate functions, but couldn't find anything that doesn't
      significantly change the codebase. So I would appreciate If you have any
      suggestions to improve this
      
      cc @liamaharon
      
       @xlc 
      
      polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      e5427969
    • Serban Iorga's avatar
      Align dependencies with `parity-bridges-common` (#3937) · 8e95a3e1
      Serban Iorga authored
      Working towards migrating the `parity-bridges-common` repo inside
      `polkadot-sdk`. This PR upgrades some dependencies in order to align
      them with the versions used in `parity-bridges-common`
      
      Related to
      https://github.com/paritytech/parity-bridges-common/issues/2538
      8e95a3e1
    • Bastian Köcher's avatar
      Fix parachain upgrade scheduling when done by the owner/root (#3341) · 12eb285d
      Bastian Köcher authored
      When using `schedule_code_upgrade` to change the code of a parachain in
      the relay chain runtime, we had already fixed to not set the `GoAhead`
      signal. This was done to not brick any parachain after the upgrade,
      because they were seeing the signal without having any upgrade prepared.
      The remaining problem is that the parachain code is only upgraded after
      a parachain header was enacted, aka the parachain made some progress.
      However, this is quite complicated if the parachain is bricked (which is
      the most common scenario why to manually schedule a code upgrade). Thus,
      this pull request replaces `SetGoAhead` with `UpgradeStrategy` to signal
      to the logic kind of strategy want to use. The strategies are either
      `SetGoAheadSignal` or `ApplyAtExpectedBlock`. `SetGoAheadSignal` sets
      the go ahead signal as before and awaits a parachain block.
      `ApplyAtExpectedBlock` schedules the upgrade and applies it directly at
      the `expected_block` without waiting for the parachain to make any kind
      of progress.
      12eb285d
    • Adrian Catangiu's avatar
      pallet-xcm: fix weights for all XTs and deprecate unlimited weight ones (#3927) · d0ebb850
      Adrian Catangiu authored
      
      
      Fix "double-weights" for extrinsics, use only the ones benchmarked in
      the runtime.
      
      Deprecate extrinsics that don't specify WeightLimit, remove their usage
      across the repo.
      
      ---------
      
      Signed-off-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: command-bot <>
      d0ebb850
  2. Apr 01, 2024
  3. Mar 29, 2024
  4. Mar 27, 2024
    • Gonçalo Pestana's avatar
      Extrinsic to restore corrupt staking ledgers (#3706) · bbdbeb7e
      Gonçalo Pestana authored
      This PR adds a new extrinsic `Call::restore_ledger ` gated by
      `StakingAdmin` origin that restores a corrupted staking ledger. This
      extrinsic will be used to recover ledgers that were affected by the
      issue discussed in
      https://github.com/paritytech/polkadot-sdk/issues/3245.
      
      The extrinsic will re-write the storage items associated with a stash
      account provided as input parameter. The data used to reset the ledger
      can be either i) fetched on-chain or ii) partially/totally set by the
      input parameters of the call.
      
      In order to use on-chain data to restore the staking locks, we need a
      way to read the current lock in the balances pallet. This PR adds a
      `InspectLockableCurrency` trait and implements it in the pallet
      balances. An alternative would be to tightly couple staking with the
      pallet balances but that's inelegant (an example of how it would look
      like in [this
      branch](https://github.com/paritytech/polkadot-sdk/tree/gpestana/ledger-badstate-clean_tightly)).
      
      More details on the type of corruptions and corresponding fixes
      https://hackmd.io/DLb5jEYWSmmvqXC9ae4yRg?view#/
      
      We verified that the `Call::restore_ledger` does fix all current
      corrupted ledgers in Polkadot and Kusama. You can verify it here
      https://hackmd.io/v-XNrEoGRpe7APR-EZGhOA.
      
      **Changes introduced**
      - Adds `Call::restore_ledger ` extrinsic to recover a corrupted ledger;
      - Adds trait `frame_support::traits::currency::InspectLockableCurrency`
      to allow external pallets to read current locks given an account and
      lock ID;
      - Implements the `InspectLockableCurrency` in the pallet-balances.
      - Adds staking locks try-runtime checks
      (https://github.com/paritytech/polkadot-sdk/issues/3751)
      
      **Todo**
      - [x] benchmark `Call::restore_ledger`
      - [x] throughout testing of all ledger recovering cases
      - [x] consider adding the staking locks try-runtime checks to this PR
      (https://github.com/paritytech/polkadot-sdk/issues/3751)
      - [x] simulate restoring all ledgers
      (https://hackmd.io/Dsa2tvhISNSs7zcqriTaxQ?view) in Polkadot and Kusama
      using chopsticks -- https://hackmd.io/v-XNrEoGRpe7APR-EZGhOA
      
      Related to https://github.com/paritytech/polkadot-sdk/issues/3245
      Closes https://github.com/paritytech/polkadot-sdk/issues/3751
      
      ---------
      
      Co-authored-by: command-bot <>
      bbdbeb7e
    • Ermal Kaleci's avatar
      process enqueued messages on idle (#3844) · 8342947b
      Ermal Kaleci authored
      
      
      This will make it possible to use remaining weight on idle for
      processing enqueued messages.
      More context here https://github.com/paritytech/polkadot-sdk/issues/3709
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      8342947b
    • Andrei Sandu's avatar
      collation-generation + collator-protocol: collate on multiple assigned cores (#3795) · 417c54c6
      Andrei Sandu authored
      
      
      This works only for collators that implement the `collator_fn` allowing
      `collation-generation` subsystem to pull collations triggered on new
      heads.
      
      Also enables
      `request_v2::CollationFetchingResponse::CollationWithParentHeadData` for
      test adder/undying collators.
      
      TODO:
      - [x] fix tests
      - [x] new tests
      - [x] PR doc
      
      ---------
      
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      417c54c6
    • Francisco Aguirre's avatar
      pallet-xcm: Deprecate `execute` and `send` in favor of `execute_blob` and `send_blob` (#3749) · feee773d
      Francisco Aguirre authored
      
      
      `execute` and `send` try to decode the xcm in the parameters before
      reaching the filter line.
      The new extrinsics decode only after the filter line.
      These should be used instead of the old ones.
      
      ## TODO
      - [x] Tests
      - [x] Generate weights
      - [x] Deprecation issue ->
      https://github.com/paritytech/polkadot-sdk/issues/3771
      - [x] PRDoc
      - [x] Handle error in pallet-contracts
      
      This would make writing XCMs in PJS Apps more difficult, but here's the
      fix for that: https://github.com/polkadot-js/apps/pull/10350.
      Already deployed! https://polkadot.js.org/apps/#/utilities/xcm
      
      Supersedes https://github.com/paritytech/polkadot-sdk/pull/1798/
      
      ---------
      
      Co-authored-by: default avatarPG Herveou <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      feee773d
  5. Mar 26, 2024
    • Pavel Orlov's avatar
      XCM Fee Payment Runtime API (#3607) · 3c972fc1
      Pavel Orlov authored
      
      
      The PR provides API for obtaining:
      - the weight required to execute an XCM message,
      - a list of acceptable `AssetId`s for message execution payment,
      - the cost of the weight in the specified acceptable `AssetId`.
      
      It is meant to address an issue where one has to guess how much fee to
      pay for execution. Also, at the moment, a client has to guess which
      assets are acceptable for fee execution payment.
      See the related issue
      https://github.com/paritytech/polkadot-sdk/issues/690.
      With this API, a client is supposed to query the list of the supported
      asset IDs (in the XCM version format the client understands), weigh the
      XCM program the client wants to execute and convert the weight into one
      of the acceptable assets. Note that the client is supposed to know what
      program will be executed on what chains. However, having a small
      companion JS library for the pallet-xcm and xtokens should be enough to
      determine what XCM programs will be executed and where (since these
      pallets compose a known small set of programs).
      ```Rust
      pub trait XcmPaymentApi<Call>
      	where
      		Call: Codec,
      	{
      		/// Returns a list of acceptable payment assets.
      		///
      		/// # Arguments
      		///
      		/// * `xcm_version`: Version.
      		fn query_acceptable_payment_assets(xcm_version: Version) -> Result<Vec<VersionedAssetId>, Error>;
      		/// Returns a weight needed to execute a XCM.
      		///
      		/// # Arguments
      		///
      		/// * `message`: `VersionedXcm`.
      		fn query_xcm_weight(message: VersionedXcm<Call>) -> Result<Weight, Error>;
      		/// Converts a weight into a fee for the specified `AssetId`.
      		///
      		/// # Arguments
      		///
      		/// * `weight`: convertible `Weight`.
      		/// * `asset`: `VersionedAssetId`.
      		fn query_weight_to_asset_fee(weight: Weight, asset: VersionedAssetId) -> Result<u128, Error>;
      		/// Get delivery fees for sending a specific `message` to a `destination`.
      		/// These always come in a specific asset, defined by the chain.
      		///
      		/// # Arguments
      		/// * `message`: The message that'll be sent, necessary because most delivery fees are based on the
      		///   size of the message.
      		/// * `destination`: The destination to send the message to. Different destinations may use
      		///   different senders that charge different fees.
      		fn query_delivery_fees(destination: VersionedLocation, message: VersionedXcm<()>) -> Result<VersionedAssets, Error>;
      	}
      ```
      An
      [example](https://gist.github.com/PraetorP/4bc323ff85401abe253897ba990ec29d)
      of a client side code.
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: default avatarDaniel Shiposha <[email protected]>
      3c972fc1
    • Tsvetomir Dimitrov's avatar
      Migrate parachain swaps to Coretime (#3714) · 90234543
      Tsvetomir Dimitrov authored
      This PR notifies broker pallet for any parachain slot swaps performed on
      the relay chain. This is achieved by registering an `OnSwap` for the the
      `coretime` pallet. The hook sends XCM message to the broker chain and
      invokes a new extrinsic `swap_leases` which updates `Leases` storage
      item (which keeps the legacy parachain leases).
      
      I made two assumptions in this PR:
      1.
      [`Leases`](https://github.com/paritytech/polkadot-sdk/blob/4987d798/substrate/frame/broker/src/lib.rs#L120)
      in `broker` pallet and
      [`Leases`](https://github.com/paritytech/polkadot-sdk/blob/4987d798
      
      /polkadot/runtime/common/src/slots/mod.rs#L118)
      in `slots` pallet are in sync.
      2. `swap_leases` extrinsic from `broker` pallet can be triggered only by
      root or by the XCM message from the relay chain. If not - the extrinsic
      will generate an error and do nothing.
      
      As a side effect from the changes `OnSwap` trait is moved from
      runtime/common/traits.rs to runtime/parachains. Otherwise it is not
      accessible from `broker` pallet.
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/3552
      
      TODOs:
      
      - [x] Weights
      - [x] Tests
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatareskimor <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      90234543
    • 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
  6. Mar 23, 2024
  7. Mar 21, 2024
    • Alejandro Martinez Andres's avatar
      Revert `SendXcmOrigin` in Rococo & Westend (#2571) · 01d65f6b
      Alejandro Martinez Andres authored
      
      
      Based on issue
      [#2512](https://github.com/paritytech/polkadot-sdk/issues/2512), it
      seems that some ecosystem teams are using these networks to set up their
      staging environments and test certain use cases, some of them involving
      sending XCMs from the relay with origins not allowed in the current
      configuration.
      
      This change reverts the configuration of `SendXcmOrigin`.
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      01d65f6b
    • Alin Dima's avatar
      Elastic scaling: runtime dependency tracking and enactment (#3479) · 4842faf6
      Alin Dima authored
      
      
      Changes needed to implement the runtime part of elastic scaling:
      https://github.com/paritytech/polkadot-sdk/issues/3131,
      https://github.com/paritytech/polkadot-sdk/issues/3132,
      https://github.com/paritytech/polkadot-sdk/issues/3202
      
      Also fixes https://github.com/paritytech/polkadot-sdk/issues/3675
      
      TODOs:
      
      - [x] storage migration
      - [x] optimise process_candidates from O(N^2)
      - [x] drop backable candidates which form cycles
      - [x] fix unit tests
      - [x] add more unit tests
      - [x] check the runtime APIs which use the pending availability storage.
      We need to expose all of them, see
      https://github.com/paritytech/polkadot-sdk/issues/3576
      - [x] optimise the candidate selection. we're currently picking randomly
      until we satisfy the weight limit. we need to be smart about not
      breaking candidate chains while being fair to all paras -
      https://github.com/paritytech/polkadot-sdk/pull/3573
      
      Relies on the changes made in
      https://github.com/paritytech/polkadot-sdk/pull/3233 in terms of the
      inclusion policy and the candidate ordering
      
      ---------
      
      Signed-off-by: default avataralindima <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatareskimor <[email protected]>
      4842faf6
    • Egor_P's avatar
      [Backport] version bumps and prdocs reordering 1.9.0 (#3758) · 7b6b061e
      Egor_P authored
      This PR backports:
      - node version bump
      - `spec_vesion` bump
      - reordering of the `prdocs` to the appropriate folder
      from the `1.9.0` release branch
      7b6b061e
    • gupnik's avatar
      Migrates Westend to Runtime V2 (#3754) · 93b1abb2
      gupnik authored
      Step in https://github.com/paritytech/polkadot-sdk/issues/3688
      93b1abb2
  8. Mar 20, 2024
    • eskimor's avatar
      Fix algorithmic complexity of on-demand scheduler with regards to number of cores. (#3190) · b74353d3
      eskimor authored
      
      
      We witnessed really poor performance on Rococo, where we ended up with
      50 on-demand cores. This was due to the fact that for each core the full
      queue was processed. With this change full queue processing will happen
      way less often (most of the time complexity is O(1) or O(log(n))) and if
      it happens then only for one core (in expectation).
      
      Also spot price is now updated before each order to ensure economic back
      pressure.
      
      
      TODO:
      
      - [x] Implement
      - [x] Basic tests
      - [x] Add more tests (see todos)
      - [x] Run benchmark to confirm better performance, first results suggest
      > 100x faster.
      - [x] Write migrations
      - [x] Bump scale-info version and remove patch in Cargo.toml
      - [x] Write PR docs: on-demand performance improved, more on-demand
      cores are now non problematic anymore. If need by also the max queue
      size can be increased again. (Maybe not to 10k)
      
      Optional: Performance can be improved even more, if we called
      `pop_assignment_for_core()`, before calling `report_processed` (Avoid
      needless affinity drops). The effect gets smaller the larger the claim
      queue and I would only go for it, if it does not add complexity to the
      scheduler.
      
      ---------
      
      Co-authored-by: default avatareskimor <[email protected]>
      Co-authored-by: default avatarantonva <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAnton Vilhelm Ásgeirsson <[email protected]>
      Co-authored-by: default avatarordian <[email protected]>
      b74353d3
    • Tsvetomir Dimitrov's avatar
      Expose `ClaimQueue` via a runtime api and use it in `collation-generation` (#3580) · e58e854a
      Tsvetomir Dimitrov authored
      The PR adds two things:
      1. Runtime API exposing the whole claim queue
      2. Consumes the API in `collation-generation` to fetch the next
      scheduled `ParaEntry` for an occupied core.
      
      Related to https://github.com/paritytech/polkadot-sdk/issues/1797
      e58e854a
  9. Mar 19, 2024
    • Davide Galassi's avatar
      Implement crypto byte array newtypes in term of a shared type (#3684) · 1e9fd237
      Davide Galassi authored
      Introduces `CryptoBytes` type defined as:
      
      ```rust
      pub struct CryptoBytes<const N: usize, Tag = ()>(pub [u8; N], PhantomData<fn() -> Tag>);
      ```
      
      The type implements a bunch of methods and traits which are typically
      expected from a byte array newtype
      (NOTE: some of the methods and trait implementations IMO are a bit
      redundant, but I decided to maintain them all to not change too much
      stuff in this PR)
      
      It also introduces two (generic) typical consumers of `CryptoBytes`:
      `PublicBytes` and `SignatureBytes`.
      
      ```rust
      pub struct PublicTag;
      pub PublicBytes<const N: usize, CryptoTag> = CryptoBytes<N, (PublicTag, CryptoTag)>;
      
      pub struct SignatureTag;
      pub SignatureBytes<const N: usize, CryptoTag> = CryptoBytes<N, (SignatureTag, CryptoTag)>;
      ```
      
      Both of them use a tag to differentiate the two types at a higher level.
      Downstream specializations will further specialize using a dedicated
      crypto tag. For example in ECDSA:
      
      
      ```rust
      pub struct EcdsaTag;
      
      pub type Public = PublicBytes<PUBLIC_KEY_SERIALIZED_SIZE, EcdsaTag>;
      pub type Signature = PublicBytes<PUBLIC_KEY_SERIALIZED_SIZE, EcdsaTag>;
      ```
      
      Overall we have a cleaner and most importantly **consistent** code for
      all the types involved
      
      All these details are opaque to the end user which can use `Public` and
      `Signature` for the cryptos as before
      1e9fd237
    • Matteo Muraca's avatar
      Removed `pallet::getter` usage from Beefy and MMR pallets (#3740) · 817870e3
      Matteo Muraca authored
      Part of #3326 
      
      cc @Kianenigma @ggwpez @liamaharon
      
       
      
      polkadot address: 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp
      
      ---------
      
      Signed-off-by: default avatarMatteo Muraca <[email protected]>
      817870e3
    • Juan Ignacio Rios's avatar
      Add HRMP notification handlers to the xcm-executor (#3696) · 8b3bf39a
      Juan Ignacio Rios authored
      
      
      Currently the xcm-executor returns an `Unimplemented` error if it
      receives any HRMP-related instruction.
      What I propose here, which is what we are currently doing in our forked
      executor at polimec, is to introduce a trait implemented by the executor
      which will handle those instructions.
      
      This way, if parachains want to keep the default behavior, they just use
      `()` and it will return unimplemented, but they can also implement their
      own logic to establish HRMP channels with other chains in an automated
      fashion, without requiring to go through governance.
      
      Our implementation is mentioned in the [polkadot HRMP
      docs](https://arc.net/l/quote/hduiivbu), and it was suggested to us to
      submit a PR to add these changes to polkadot-sdk.
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: command-bot <>
      8b3bf39a
  10. Mar 17, 2024
  11. Mar 15, 2024
  12. Mar 14, 2024
  13. Mar 13, 2024
    • georgepisaltu's avatar
      Revert "FRAME: Create `TransactionExtension` as a replacement for... · bbd51ce8
      georgepisaltu authored
      
      Revert "FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280)" (#3665)
      
      This PR reverts #2280 which introduced `TransactionExtension` to replace
      `SignedExtension`.
      
      As a result of the discussion
      [here](https://github.com/paritytech/polkadot-sdk/pull/3623#issuecomment-1986789700),
      the changes will be reverted for now with plans to reintroduce the
      concept in the future.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      bbd51ce8
  14. Mar 11, 2024
  15. Mar 08, 2024
  16. Mar 07, 2024
    • Pablo Andrés Dorado Suárez's avatar
      fix(pallet-benchmarking): split test functions in v2 (#3574) · f4fbddec
      Pablo Andrés Dorado Suárez authored
      Closes #376
      
      ---------
      
      Co-authored-by: command-bot <>
      f4fbddec
    • Muharem Ismailov's avatar
      Deprecate xcm::body::TREASURER_INDEX constant, use standard Treasury varian instead (#3608) · 629506ce
      Muharem Ismailov authored
      Deprecate the `xcm::body::TREASURER_INDEX` constant and use the standard
      Treasury variant from the `xcm::BodyId` type instead.
      
      To align with the production runtimes:
      https://github.com/polkadot-fellows/runtimes/pull/149
      629506ce
    • Andrei Sandu's avatar
      ParaInherent create: update `apply_weight_limit` wrt elastic scaling (#3573) · c16fcc47
      Andrei Sandu authored
      
      
      Changes the way we perform the random selection of backed candidates
      when there isn't enough room for all of them. Instead of picking
      individual backed candidates `apply_weight` now operates on chains of
      candidates. This is fully backwards compatible and relies on the node
      side (provisioner/prospective parachains) doing the heavy lifting and
      providing the candidates in the order they form a chain.
      
      The same approach can be implemented for bitfields random selection once
      https://github.com/paritytech/polkadot-sdk/pull/3479 is merged.
      
      The approach taken in this PR aims for reduced additional complexity at
      the cost of being less fair wrt how many backed candidates from each
      chain are picked. It favors elastic scaling parachains vs parachains not
      using elastic scaling, but from my perspective it should be fine as this
      should happen under exceptional circumstances like dispute storms.
      
      Note: to make things more fair we can consider specializing `random_sel`
      such that it will try to pick candidates one by one in the order
      provided by the provisioner such that non elastic scaling parachains
      have the same chance of getting a candidate backed.
      
      ---------
      
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      c16fcc47
  17. 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` (deprecated) and the `_bare_compat` bits of
      `TransactionExtension` (deprecated).
        - Inherents: Not gossiped, validated with `ProvideInherent`.
      - Extended (Extra data): Gossiped, validated via `TransactionExtension`.
        - Signed transactions (with a hardcoded signature).
        - General transactions (without a hardcoded signature).
      
      `TransactionExtension` differs from `SignedExtension` because:
      - A signature on the underlying transaction may validly not be present.
      - It may alter the origin during validation.
      - `pre_dispatch` is renamed to `prepare` and need not contain the checks
      present in `validate`.
      - `validate` and `prepare` is passed an `Origin` rather than a
      `AccountId`.
      - `validate` may pass arbitrary information into `prepare` via a new
      user-specifiable type `Val`.
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`. It is encoded *for the entire transaction* and
      passed in to each extension as a new argument to `validate`. This
      facilitates the ability of extensions to acts as underlying crypto.
      
      There is a new `DispatchTransaction` trait which contains only default
      function impls and is impl'ed for any `TransactionExtension` impler. It
      provides several utility functions which reduce some of the tedium from
      using `TransactionExtension` (indeed, none of its regular functions
      should now need to be called directly).
      
      Three transaction version discriminator ("versions") are now
      permissible:
      - 0b000000100: Bare (used to be called "Unsigned"): contains Signature
      or Extra (extension data). After bare transactions are no longer
      supported, this will strictly identify an Inherents only.
      - 0b100000100: Old-school "Signed" Transaction: contains Signature and
      Extra (extension data).
      - 0b010000100: New-school "General" Transaction: contains Extra
      (extension data), but no Signature.
      
      For the New-school General Transaction, it becomes trivial for authors
      to publish extensions to the mechanism for authorizing an Origin, e.g.
      through new kinds of key-signing schemes, ZK proofs, pallet state,
      mutations over pre-authenticated origins or any combination of the
      above.
      
      ## Code Migration
      
      ### NOW: Getting it to build
      
      Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
      accompanied by renaming your aggregate type in line with the new
      terminology. E.g. Before:
      
      ```rust
      /// The SignedExtension to the basic transaction logic.
      pub type SignedExtra = (
      	/* snip */
      	MySpecialSignedExtension,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
      ```
      
      After:
      
      ```rust
      /// The extension to the basic transaction logic.
      pub type TxExtension = (
      	/* snip */
      	AsTransactionExtension<MySpecialSignedExtension>,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
      ```
      
      You'll also need to alter any transaction building logic to add a
      `.into()` to make the conversion happen. E.g. Before:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let extra: SignedExtra = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */),
      	);
      	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		extra,
      	)
      }
      ```
      
      After:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let tx_ext: TxExtension = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */).into(),
      	);
      	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		tx_ext,
      	)
      }
      ```
      
      ### SOON: Migrating to `TransactionExtension`
      
      Most `SignedExtension`s can be trivially converted to become a
      `TransactionExtension`. There are a few things to know.
      
      - Instead of a single trait like `SignedExtension`, you should now
      implement two traits individually: `TransactionExtensionBase` and
      `TransactionExtension`.
      - Weights are now a thing and must be provided via the new function `fn
      weight`.
      
      #### `TransactionExtensionBase`
      
      This trait takes care of anything which is not dependent on types
      specific to your runtime, most notably `Call`.
      
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`.
      - Weight must be returned by implementing the `weight` function. If your
      extension is associated with a pallet, you'll probably want to do this
      via the pallet's existing benchmarking infrastructure.
      
      #### `TransactionExtension`
      
      Generally:
      - `pre_dispatch` is now `prepare` and you *should not reexecute the
      `validate` functionality in there*!
      - You don't get an account ID any more; you get an origin instead. If
      you need to presume an account ID, then you can use the trait function
      `AsSystemOriginSigner::as_system_origin_signer`.
      - You get an additional ticket, similar to `Pre`, called `Val`. This
      defines data which is passed from `validate` into `prepare`. This is
      important since you should not be duplicating logic from `validate` to
      `prepare`, you need a way of passing your working from the former into
      the latter. This is it.
      - This trait takes two type parameters: `Call` and `Context`. `Call` is
      the runtime call type which used to be an associated type; you can just
      move it to become a type parameter for your trait impl. `Context` is not
      currently used and you can safely implement over it as an unbounded
      type.
      - There's no `AccountId` associated type any more. Just remove it.
      
      Regarding `validate`:
      - You get three new parameters in `validate`; all can be ignored when
      migrating from `SignedExtension`.
      - `validate` returns a tuple on success; the second item in the tuple is
      the new ticket type `Self::Val` which gets passed in to `prepare`. If
      you use any information extracted during `validate` (off-chain and
      on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
      pass it through with this. For the tuple's last item, just return the
      `origin` argument.
      
      Regarding `prepare`:
      - This is renamed from `pre_dispatch`, but there is one change:
      - FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
      `validate`!!
      - (This is different to `SignedExtension` which was required to run the
      same checks in `pre_dispatch` as in `validate`.)
      
      Regarding `post_dispatch`:
      - Since there are no unsigned transactions handled by
      `TransactionExtension`, `Pre` is always defined, so the first parameter
      is `Self::Pre` rather than `Option<Self::Pre>`.
      
      If you make use of `SignedExtension::validate_unsigned` or
      `SignedExtension::pre_dispatch_unsigned`, then:
      - Just use the regular versions of these functions instead.
      - Have your logic execute in the case that the `origin` is `None`.
      - Ensure your transaction creation logic creates a General Transaction
      rather than a Bare Transaction; this means having to include all
      `TransactionExtension`s' data.
      - `ValidateUnsigned` can still be used (for now) if you need to be able
      to construct transactions which contain none of the extension data,
      however these will be phased out in stage 2 of the Transactions Horizon,
      so you should consider moving to an extension-centric design.
      
      ## TODO
      
      - [x] Introduce `CheckSignature` impl of `TransactionExtension` to
      ensure it's possible to have crypto be done wholly in a
      `TransactionExtension`.
      - [x] Deprecate `SignedExtension` and move all uses in codebase to
      `TransactionExtension`.
        - [x] `ChargeTransactionPayment`
        - [x] `DummyExtension`
        - [x] `ChargeAssetTxPayment` (asset-tx-payment)
        - [x] `ChargeAssetTxPayment` (asset-conversion-tx-payment)
        - [x] `CheckWeight`
        - [x] `CheckTxVersion`
        - [x] `CheckSpecVersion`
        - [x] `CheckNonce`
        - [x] `CheckNonZeroSender`
        - [x] `CheckMortality`
        - [x] `CheckGenesis`
        - [x] `CheckOnlySudoAccount`
        - [x] `WatchDummy`
        - [x] `PrevalidateAttests`
        - [x] `GenericSignedExtension`
        - [x] `SignedExtension` (chain-polkadot-bulletin)
        - [x] `RefundSignedExtensionAdapter`
      - [x] Implement `fn weight` across the board.
      - [ ] Go through all pre-existing extensions which assume an account
      signer and explicitly handle the possibility of another kind of origin.
      - [x] `CheckNonce` should probably succeed in the case of a non-account
      origin.
      - [x] `CheckNonZeroSender` should succeed in the case of a non-account
      origin.
      - [x] `ChargeTransactionPayment` and family should fail in the case of a
      non-account origin.
        - [ ] 
      - [x] Fix any broken tests.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarChevdor <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarMaciej <[email protected]>
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: default avatarTsvetomir Dimitrov <[email protected]>
      Co-authored-by: default avatarJavier Bullrich <[email protected]>
      Co-authored-by: default avatarKoute <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: Vladimir Istyufeev's avatarVladimir Istyufeev <[email protected]>
      Co-authored-by: default avatarRoss Bulat <[email protected]>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarSvyatoslav Nikolsky <[email protected]>
      Co-authored-by: default avatarAndré Silva <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatars0me0ne-unkn0wn <[email protected]>
      Co-authored-by: default avatarordian <[email protected]>
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      Co-authored-by: default avatarAaro Altonen <[email protected]>
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarAlexander Samusev <[email protected]>
      Co-authored-by: default avatarJulian Eager <[email protected]>
      Co-authored-by: default avatarMichal Kucharczyk <[email protected]>
      Co-authored-by: default avatarDavide Galassi <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avataryjh <[email protected]>
      Co-authored-by: default avatarTom Mi <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      Co-authored-by: default avatarWill | Paradox | ParaNodes.io <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarPG Herveou <[email protected]>
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarJuan Girini <[email protected]>
      Co-authored-by: default avatarbader y <[email protected]>
      Co-authored-by: default avatarJames Wilson <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarasynchronous rob <[email protected]>
      Co-authored-by: default avatarParth <[email protected]>
      Co-authored-by: default avatarAndrew Jones <[email protected]>
      Co-authored-by: default avatarJonathan Udd <[email protected]>
      Co-authored-by: default avatarSerban Iorga <[email protected]>
      Co-authored-by: default avatarEgor_P <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: default avatarEvgeny Snitko <[email protected]>
      Co-authored-by: default avatarJust van Stam <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      Co-authored-by: default avatardzmitry-lahoda <[email protected]>
      Co-authored-by: default avatarzhiqiangxu <[email protected]>
      Co-authored-by: default avatarNazar Mokrynskyi <[email protected]>
      Co-authored-by: default avatarAnwesh <[email protected]>
      Co-authored-by: default avatarcheme <[email protected]>
      Co-authored-by: default avatarSam Johnson <[email protected]>
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: default avatarJegor Sidorenko <[email protected]>
      Co-authored-by: default avatarMuharem <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      Co-authored-by: default avatarAlexandru Gheorghe <[email protected]>
      Co-authored-by: default avatarGabriel Facco de Arruda <[email protected]>
      Co-authored-by: default avatarSquirrel <[email protected]>
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: command-bot <>
      fd5f9292
  18. Mar 01, 2024
  19. Feb 29, 2024