1. Nov 29, 2023
    • PG Herveou's avatar
      Contracts: use compiled rust tests (#2347) · 2135fa87
      PG Herveou authored
      see #2189
      
      This PR does the following:
      - Bring the user api functions into a new pallet-contracts-uapi (They
      are currently defined in ink!
      [here])(https://github.com/paritytech/ink/blob/master/crates/env/src/engine/on_chain/ext.rs
      
      )
      - Add older api versions and unstable to the user api trait.
      - Remove pallet-contracts-primitives and bring the types it defined in
      uapi / pallet-contracts
      - Add the infrastructure to build fixtures from Rust files and test it
      works by replacing `dummy.wat` and `call.wat`
      - Move all the doc from wasm/runtime.rs to pallet-contracts-uapi.
      
      This will be done in a follow up:
      - convert the rest of the test from .wat to rust
      - bring risc-v uapi up to date with wasm
      - finalize the uapi host fns, making sure everything is codegen from the
      source host fns in pallet-contracts
      
      ---------
      
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      2135fa87
  2. Nov 28, 2023
    • Sebastian Kunert's avatar
      Remove long deprecated `AllPalletsWithoutSystemReversed` (#2509) · 82017934
      Sebastian Kunert authored
      Remove deprecated `AllPalletsXY` types.
      
      They have been deprecated for nearly 1.5 years now, I think its fine to
      remove them.
      If anyone feels like we should first put a date on the deprecation as
      stated in the deprecation guideline, feel free to speak up. To me it
      looks like this has been forgotten and can be directly removed.
      82017934
    • Aaro Altonen's avatar
      Rework the event system of `sc-network` (#1370) · e71c484d
      Aaro Altonen authored
      This commit introduces a new concept called `NotificationService` which
      allows Polkadot protocols to communicate with the underlying
      notification protocol implementation directly, without routing events
      through `NetworkWorker`. This implies that each protocol has its own
      service which it uses to communicate with remote peers and that each
      `NotificationService` is unique with respect to the underlying
      notification protocol, meaning `NotificationService` for the transaction
      protocol can only be used to send and receive transaction-related
      notifications.
      
      The `NotificationService` concept introduces two additional benefits:
        * allow protocols to start using custom handshakes
        * allow protocols to accept/reject inbound peers
      
      Previously the validation of inbound connections was solely the
      responsibility of `ProtocolController`. This caused issues with light
      peers and `SyncingEngine` as `ProtocolController` would accept more
      peers than `SyncingEngine` could accept which caused peers to have
      differing views of their own states. `SyncingEngine` would reject excess
      peers but these rejections were not properly communicated to those peers
      causing them to assume that they were accepted.
      
      With `NotificationService`, the local handshake is not sent to remote
      peer if peer is rejected which allows it to detect that it was rejected.
      
      This commit also deprecates the use of `NetworkEventStream` for all
      notification-related events and going forward only DHT events are
      provided through `NetworkEventStream`. If protocols wish to follow each
      other's events, they must introduce additional abtractions, as is done
      for GRANDPA and transactions protocols by following the syncing protocol
      through `SyncEventStream`.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/512
      Fixes https://github.com/paritytech/polkadot-sdk/issues/514
      Fixes https://github.com/paritytech/polkadot-sdk/issues/515
      Fixes https://github.com/paritytech/polkadot-sdk/issues/554
      Fixes https://github.com/paritytech/polkadot-sdk/issues/556
      
      ---
      These changes are transferred from
      https://github.com/paritytech/substrate/pull/14197
      
       but there are no
      functional changes compared to that PR
      
      ---------
      
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      e71c484d
    • s0me0ne-unkn0wn's avatar
    • gupnik's avatar
      Moves all test runtimes to use `derive_impl` (#2409) · cd8741c8
      gupnik authored
      Step in https://github.com/paritytech/polkadot-sdk/issues/171
      
      
      
      This PR adds `derive_impl` on all `frame_system` config impls for mock
      runtimes. The overridden configs are maintained as of now to ensure
      minimal changes.
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      cd8741c8
    • Liam Aharon's avatar
      Set `frame_system::LastRuntimeUpgrade` after running `try-runtime` migrations (#2515) · 6dc3e6c9
      Liam Aharon authored
      Sets `frame_system::LastRuntimeUpgrade` after running try-runtime
      migrations to better emulate real behavior.
      
      This fixes an issue where migrations using the spec version to determine
      whether to execute can incorrectly fail idempotency checks.
      
      @s0me0ne-unkn0wn noticed this issue with the session key migration
      introduced in https://github.com/paritytech/polkadot-sdk/pull/2265.
      6dc3e6c9
    • Ross Bulat's avatar
      Pools: Add ability to configure commission claiming permissions (#2474) · 75062717
      Ross Bulat authored
      Addresses #409.
      
      This request has been raised by multiple community members - the ability
      for the nomination pool root role to configure permissionless commission
      claiming:
      
      > Would it be possible to have a claim_commission_other extrinsic for
      claiming commission of nomination pools permissionless?
      
      This PR does not quite introduce this additional call, but amends
      `do_claim_commission` to check a new `claim_permission` field in the
      `Commission` struct, configured by an enum:
      
      ```
      enum CommissionClaimPermission {
         Permissionless,
         Account(AccountId),
      }
      ```
      This can be optionally set in a bonded pool's
      `commission.claim_permission` field:
      
      ```
      struct BondedPool {
         commission: {
            <snip>
            claim_permission: Option<CommissionClaimPermission<T::AccountId>>,
         },
         <snip>
      }
      ```
      
      This is a new field and requires a migration to add it to existing
      pools. This will be `None` on pool creation, falling back to the `root`
      role having sole access to claim commission if it is not set; this is
      the behaviour as it is today. Once set, the field _can_ be set to `None`
      again.
      
      #### Changes
      - [x] Add `commision.claim_permission` field.
      - [x] Add `can_claim_commission` and amend `do_claim_commission`.
      - [x] Add `set_commission_claim_permission` call.
      - [x] Test to cover new configs and call.
      - [x] Add and amend benchmarks.
      - [x] Generate new weights + slot into call
      `set_commission_claim_permission`.
      - [x] Add migration to introduce `commission.claim_permission`, bump
      storage version.
      - [x] Update Westend weights.
      - [x] Migration working.
      
      ---------
      
      Co-authored-by: command-bot <>
      75062717
  3. Nov 27, 2023
  4. Nov 25, 2023
  5. Nov 24, 2023
  6. Nov 23, 2023
  7. Nov 22, 2023
    • James Wilson's avatar
      Make TypeInfo for SkipCheckIfFeeless transparent, too (#2449) · 0d6dcb3f
      James Wilson authored
      
      
      The `SkipCheckifFeeless::IDENTIFIER` became transparent (ie was whatever
      the inner signed ext was). This PR just makes the `TypeInfo` transparent
      too, so that libraries that use said info to decode the data (ie subxt)
      can behave identically whether or not the `SkipCheckifFeeless` wrapper
      is used or not.
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      0d6dcb3f
    • gupnik's avatar
      Fixes import path in benchmark macro (#2437) · 98f9e2ea
      gupnik authored
      Fully-qualified path was not being used in benchmark macro for one of
      the cases. This PR fixes this and removes the unnecessary import in a
      couple of files, which I believe was done to fix this issue.
      98f9e2ea
    • Ross Bulat's avatar
      Deprecate `RewardDestination::Controller` (#2380) · 7a32f4be
      Ross Bulat authored
      
      
      Deprecates `RewardDestination::Controller` variant.
      
      - [x] `RewardDestination::Controller` annotated with `#[deprecated]`.
      - [x] `Controller` variant is now handled the same way as `Stash` in
      `payout_stakers`.
      - [x] `set_payee` errors if `RewardDestination::Controller` is provided.
      - [x] Added `update_payee` call to lazily migrate
      `RewardDestination::Controller` `Payee` storage entries to
      `RewardDestination::Account(controller)` .
      - [x] `payout_stakers_dead_controller` has been removed from benches &
      weights - was not used.
      - [x] Tests no longer use `RewardDestination::Controller`.
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      7a32f4be
  8. Nov 21, 2023
  9. Nov 20, 2023
  10. Nov 17, 2023
  11. Nov 15, 2023
    • Bastian Köcher's avatar
      frame-system: Add `last_runtime_upgrade_spec_version` (#2351) · ea4085ab
      Bastian Köcher authored
      
      
      Adds a function for querying the last runtime upgrade spec version. This
      can be useful for when writing runtime level migrations to ensure that
      they are not executed multiple times. An example would be a session key
      migration.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      ea4085ab
    • joe petrowski's avatar
      Identity Deposits Relay to Parachain Migration (#1814) · c79b234b
      joe petrowski authored
      The goal of this PR is to migrate Identity deposits from the Relay Chain
      to a system parachain.
      
      The problem I want to solve is that `IdentityOf` and `SubsOf` both store
      an amount that's held in reserve as a storage deposit. When migrating to
      a parachain, we can take a snapshot of the actual `IdentityInfo` and
      sub-account mappings, but should migrate (off chain) the `deposit`s to
      zero, since the chain (and by extension, accounts) won't have any funds
      at genesis.
      
      The good news is that we expect parachain deposits to be significantly
      lower (possibly 100x) on the parachain. That is, a deposit of 21 DOT on
      the Relay Chain would need 0.21 DOT on a parachain. This PR proposes to
      migrate the deposits in the following way:
      
      1. Introduces a new pallet with two extrinsics: 
      - `reap_identity`: Has a configurable `ReapOrigin`, which would be set
      to `EnsureSigned` on the Relay Chain (i.e. callable by anyone) and
      `EnsureRoot` on the parachain (we don't want identities reaped from
      there).
      - `poke_deposit`: Checks what deposit the pallet holds (at genesis,
      zero) and attempts to update the amount based on the calculated deposit
      for storage data.
      2. `reap_identity` clears all storage data for a `target` account and
      unreserves their deposit.
      3. A `ReapIdentityHandler` teleports the necessary DOT to the parachain
      and calls `poke_deposit`. Since the parachain deposit is much lower, and
      was just unreserved, we know we have enough.
      
      One awkwardness I ran into was that the XCMv3 instruction set does not
      provide a way for the system to teleport assets without a fee being
      deducted on reception. Users shouldn't have to pay a fee for the system
      to migrate their info to a more efficient location. So I wrote my own
      program and did the `InitiateTeleport` accounting on my own to send a
      program with `UnpaidExecution`. Have discussed an
      `InitiateUnpaidTeleport` instruction with @franciscoaguirre . Obviously
      any chain executing this would have to pass a `Barrier` for free
      execution.
      
      TODO:
      
      - [x] Confirm People Chain ParaId
      - [x] Confirm People Chain deposit rates (determined in
      https://github.com/paritytech/polkadot-sdk/pull/2281
      
      )
      - [x] Add pallet to Westend
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      c79b234b
  12. Nov 14, 2023
  13. Nov 13, 2023
    • gupnik's avatar
      Adds syntax for marking calls feeless (#1926) · 60c77a2e
      gupnik authored
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1725
      
      
      
      This PR adds the following changes:
      1. An attribute `pallet::feeless_if` that can be optionally attached to
      a call like so:
      ```rust
      #[pallet::feeless_if(|_origin: &OriginFor<T>, something: &u32| -> bool {
      	*something == 0
      })]
      pub fn do_something(origin: OriginFor<T>, something: u32) -> DispatchResult {
           ....
      }
      ```
      The closure passed accepts references to arguments as specified in the
      call fn. It returns a boolean that denotes the conditions required for
      this call to be "feeless".
      
      2. A signed extension `SkipCheckIfFeeless<T: SignedExtension>` that
      wraps a transaction payment processor such as
      `pallet_transaction_payment::ChargeTransactionPayment`. It checks for
      all calls annotated with `pallet::feeless_if` to see if the conditions
      are met. If so, the wrapped signed extension is not called, essentially
      making the call feeless.
      
      In order to use this, you can simply replace your existing signed
      extension that manages transaction payment like so:
      ```diff
      - pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
      + pallet_skip_feeless_payment::SkipCheckIfFeeless<
      +	Runtime,
      +	pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
      + >,
      ```
      
      ### Todo
      - [x] Tests
      - [x] Docs
      - [x] Prdoc
      
      ---------
      
      Co-authored-by: Nikhil Gupta <>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      60c77a2e
    • Bastian Köcher's avatar
      pallet-grandpa: Remove `GRANDPA_AUTHORITIES_KEY` (#2181) · ebcf0a0f
      Bastian Köcher authored
      
      
      Remove the `GRANDPA_AUTHORITIES_KEY` key and its usage. Apparently this
      was used in the early days to communicate the grandpa authorities to the
      node. However, we have now a runtime api that does this for us. So, this
      pull request is moving from the custom managed storage item to a FRAME
      managed storage item.
      
      This pr also includes a migration for doing the switch on a running
      chain.
      
      ---------
      
      Co-authored-by: default avatarDavide Galassi <[email protected]>
      ebcf0a0f
  14. Nov 10, 2023
  15. Nov 09, 2023
  16. Nov 08, 2023
  17. Nov 07, 2023
    • Bill Laboon's avatar
      Fix "slashaed" typo (#2205) · 44c7a5eb
      Bill Laboon authored
      # Description
      
      This merely fixes a typo in the documentation, replacing the typo
      "slashaed" with "slashed". Since external entities use the comments for
      explanations of events, this will then be shown externally. I noticed
      this when reviewing [this
      event](https://polkadot.subscan.io/extrinsic/0xb6bc1e3abde0c2ed9c500c74cfc64cdb8179e5d9af97f4bf53242ce4cdd15a1d?event=18064194-6)
      on Subscan.
      
      This is not related to any other issues or PRs.
      44c7a5eb
    • vuittont60's avatar
      docs: fix typos (#2193) · 4caa3d8d
      vuittont60 authored
      4caa3d8d
    • Liam Aharon's avatar
      Initialise on-chain `StorageVersion` for pallets added after genesis (#1297) · c4211b65
      Liam Aharon authored
      Original PR https://github.com/paritytech/substrate/pull/14641
      
      ---
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/109
      
      
      
      ### Problem
      Quoting from the above issue:
      
      > When adding a pallet to chain after genesis we currently don't set the
      StorageVersion. So, when calling on_chain_storage_version it returns 0
      while the pallet is maybe already at storage version 9 when it was added
      to the chain. This could lead to issues when running migrations.
      
      ### Solution
      
      - Create a new trait `BeforeAllRuntimeMigrations` with a single method
      `fn before_all_runtime_migrations() -> Weight` trait with a noop default
      implementation
      - Modify `Executive` to call
      `BeforeAllRuntimeMigrations::before_all_runtime_migrations` for all
      pallets before running any other hooks
      - Implement `BeforeAllRuntimeMigrations` in the pallet proc macro to
      initialize the on-chain version to the current pallet version if the
      pallet has no storage set (indicating it has been recently added to the
      runtime and needs to have its version initialised).
      
      ### Other changes in this PR
      
      - Abstracted repeated boilerplate to access the `pallet_name` in the
      pallet expand proc macro.
      
      ### FAQ
      
      #### Why create a new hook instead of adding this logic to the pallet
      `pre_upgrade`?
      
      `Executive` currently runs `COnRuntimeUpgrade` (custom migrations)
      before `AllPalletsWithSystem` migrations. We need versions to be
      initialized before the `COnRuntimeUpgrade` migrations are run, because
      `COnRuntimeUpgrade` migrations may use the on-chain version for critical
      logic. e.g. `VersionedRuntimeUpgrade` uses it to decide whether or not
      to execute.
      
      We cannot reorder `COnRuntimeUpgrade` and `AllPalletsWithSystem` so
      `AllPalletsWithSystem` runs first, because `AllPalletsWithSystem` have
      some logic in their `post_upgrade` hooks to verify that the on-chain
      version and current pallet version match. A common use case of
      `COnRuntimeUpgrade` migrations is to perform a migration which will
      result in the versions matching, so if they were reordered these
      `post_upgrade` checks would fail.
      
      #### Why init the on-chain version for pallets without a current storage
      version?
      
      We must init the on-chain version for pallets even if they don't have a
      defined storage version so if there is a future version bump, the
      on-chain version is not automatically set to that new version without a
      proper migration.
      
      e.g. bad scenario:
      
      1. A pallet with no 'current version' is added to the runtime
      2. Later, the pallet is upgraded with the 'current version' getting set
      to 1 and a migration is added to Executive Migrations to migrate the
      storage from 0 to 1
          a. Runtime upgrade occurs
          b. `before_all` hook initializes the on-chain version to 1
      c. `on_runtime_upgrade` of the migration executes, and sees the on-chain
      version is already 1 therefore think storage is already migrated and
      does not execute the storage migration
      Now, on-chain version is 1 but storage is still at version 0.
      
      By always initializing the on-chain version when the pallet is added to
      the runtime we avoid that scenario.
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      c4211b65
  18. Nov 06, 2023