1. Nov 30, 2023
  2. Nov 29, 2023
  3. Nov 28, 2023
    • 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
    • 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
  4. Nov 27, 2023
  5. Nov 22, 2023
    • 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
  6. Nov 20, 2023
  7. Nov 17, 2023
  8. Nov 16, 2023
  9. Nov 15, 2023
    • 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
  10. Nov 14, 2023
  11. Nov 13, 2023
    • Adrian Catangiu's avatar
      pallet-xcm: enhance `reserve_transfer_assets` to support remote reserves (#1672) · 18257373
      Adrian Catangiu authored
      ## Motivation
      
      `pallet-xcm` is the main user-facing interface for XCM functionality,
      including assets manipulation functions like `teleportAssets()` and
      `reserve_transfer_assets()` calls.
      
      While `teleportAsset()` works both ways, `reserve_transfer_assets()`
      works only for sending reserve-based assets to a remote destination and
      beneficiary when the reserve is the _local chain_.
      
      ## Solution
      
      This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to
      support transfers when reserves are other chains.
      This will allow complete, **bi-directional** reserve-based asset
      transfers user stories using `pallet-xcm`.
      
      Enables following scenarios:
      - transferring assets with local reserve (was previously supported iff
      asset used as fee also had local reserve - now it works in all cases),
      - transferring assets with reserve on destination,
      - transferring assets with reserve on remote/third-party chain (iff
      assets and fees have same remote reserve),
      - transferring assets with reserve different than the reserve of the
      asset to be used as fees - meaning can be used to transfer random asset
      with local/dest reserve while using DOT for fees on all involved chains,
      even if DOT local/dest reserve doesn't match asset reserve,
      - transferring assets with any type of local/dest reserve while using
      fees which can be teleported between involved chains.
      
      All of the above is done by pallet inner logic without the user having
      to specify which scenario/reserves/teleports/etc. The correct scenario
      and corresponding XCM programs are identified, and respectively, built
      automatically based on runtime configuration of trusted teleporters and
      trusted reserves.
      
      #### Current limitations:
      - while `fees` and "non-fee" `assets` CAN have different reserves (or
      fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among
      themselves, have different reserve locations (this is also implicitly
      enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely
      increased in the future).
      - `fees` and "non-fee" `assets` CANNOT have **different remote**
      reserves (this could also be supported in the future, but adds even more
      complexity while possibly not being worth it - we'll see what the future
      holds).
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1584
      Fixes https://github.com/paritytech/polkadot-sdk/issues/2055
      
      
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      18257373
    • 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
  12. Nov 10, 2023
    • PG Herveou's avatar
      Contracts: Add XCM traits to interface with contracts (#2086) · 6b7be115
      PG Herveou authored
      We are introducing a new set of `XcmController` traits (final name yet
      to be determined).
      These traits are implemented by `pallet-xcm` and allows other pallets,
      such as `pallet_contracts`, to rely on these traits instead of tight
      coupling them to `pallet-xcm`.
      
      Using only the existing Xcm traits would mean duplicating the logic from
      `pallet-xcm` in these other pallets, which we aim to avoid. Our
      objective is to ensure that when these APIs are called from
      `pallet-contracts`, they produce the exact same outcomes as if called
      directly from `pallet-xcm`.
      
      The other benefits is that we can also expose return values to
      `pallet-contracts` instead of just calling `pallet-xcm` dispatchable and
      getting a `DispatchResult` back.
      
      See traits integration in this PR
      https://github.com/paritytech/polkadot-sdk/pull/1248
      
      , where the traits
      are used as follow to define and implement `pallet-contracts` Config.
      ```rs
      // Contracts config:
      pub trait Config: frame_system::Config {
        // ...
      
        /// A type that exposes XCM APIs, allowing contracts to interact with other parachains, and
        /// execute XCM programs.
        type Xcm: xcm_executor::traits::Controller<
      	  OriginFor<Self>,
      	  <Self as frame_system::Config>::RuntimeCall,
      	  BlockNumberFor<Self>,
        >;
      }
      
      // implementation
      impl pallet_contracts::Config for Runtime {
              // ...
      
      	type Xcm = pallet_xcm::Pallet<Self>;
      }
      ```
      
      ---------
      
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      Co-authored-by: command-bot <>
      6b7be115
    • Liam Aharon's avatar
      Improve `VersionedMigration` naming conventions (#2264) · 84ddbaf6
      Liam Aharon authored
      As suggested by @ggwpez
      (https://github.com/paritytech/polkadot-sdk/pull/2142#discussion_r1388145872),
      remove the `VersionChecked` prefix from version checked migrations (but
      leave `VersionUnchecked` prefixes)
      
      ---------
      
      Co-authored-by: command-bot <>
      84ddbaf6
  13. Nov 09, 2023
    • Oliver Tale-Yazdi's avatar
      Add descriptions to all published crates (#2029) · 48ea86f0
      Oliver Tale-Yazdi authored
      
      
      Missing descriptions (47):  
      
      - [x] `cumulus/client/collator/Cargo.toml`
      - [x] `cumulus/client/relay-chain-inprocess-interface/Cargo.toml`
      - [x] `cumulus/client/cli/Cargo.toml`
      - [x] `cumulus/client/service/Cargo.toml`
      - [x] `cumulus/client/relay-chain-rpc-interface/Cargo.toml`
      - [x] `cumulus/client/relay-chain-interface/Cargo.toml`
      - [x] `cumulus/client/relay-chain-minimal-node/Cargo.toml`
      - [x] `cumulus/parachains/pallets/parachain-info/Cargo.toml`
      - [x] `cumulus/parachains/pallets/ping/Cargo.toml`
      - [x] `cumulus/primitives/utility/Cargo.toml`
      - [x] `cumulus/primitives/aura/Cargo.toml`
      - [x] `cumulus/primitives/core/Cargo.toml`
      - [x] `cumulus/primitives/parachain-inherent/Cargo.toml`
      - [x] `cumulus/test/relay-sproof-builder/Cargo.toml`
      - [x] `cumulus/pallets/xcmp-queue/Cargo.toml`
      - [x] `cumulus/pallets/dmp-queue/Cargo.toml`
      - [x] `cumulus/pallets/xcm/Cargo.toml`
      - [x] `polkadot/erasure-coding/Cargo.toml`
      - [x] `polkadot/statement-table/Cargo.toml`
      - [x] `polkadot/primitives/Cargo.toml`
      - [x] `polkadot/rpc/Cargo.toml`
      - [x] `polkadot/node/service/Cargo.toml`
      - [x] `polkadot/node/core/parachains-inherent/Cargo.toml`
      - [x] `polkadot/node/core/approval-voting/Cargo.toml`
      - [x] `polkadot/node/core/dispute-coordinator/Cargo.toml`
      - [x] `polkadot/node/core/av-store/Cargo.toml`
      - [x] `polkadot/node/core/chain-api/Cargo.toml`
      - [x] `polkadot/node/core/prospective-parachains/Cargo.toml`
      - [x] `polkadot/node/core/backing/Cargo.toml`
      - [x] `polkadot/node/core/provisioner/Cargo.toml`
      - [x] `polkadot/node/core/runtime-api/Cargo.toml`
      - [x] `polkadot/node/core/bitfield-signing/Cargo.toml`
      - [x] `polkadot/node/network/dispute-distribution/Cargo.toml`
      - [x] `polkadot/node/network/bridge/Cargo.toml`
      - [x] `polkadot/node/network/collator-protocol/Cargo.toml`
      - [x] `polkadot/node/network/approval-distribution/Cargo.toml`
      - [x] `polkadot/node/network/availability-distribution/Cargo.toml`
      - [x] `polkadot/node/network/bitfield-distribution/Cargo.toml`
      - [x] `polkadot/node/network/gossip-support/Cargo.toml`
      - [x] `polkadot/node/network/availability-recovery/Cargo.toml`
      - [x] `polkadot/node/collation-generation/Cargo.toml`
      - [x] `polkadot/node/overseer/Cargo.toml`
      - [x] `polkadot/runtime/parachains/Cargo.toml`
      - [x] `polkadot/runtime/common/slot_range_helper/Cargo.toml`
      - [x] `polkadot/runtime/metrics/Cargo.toml`
      - [x] `polkadot/xcm/pallet-xcm-benchmarks/Cargo.toml`
      - [x] `polkadot/utils/generate-bags/Cargo.toml`
      - [x]  `substrate/bin/minimal/runtime/Cargo.toml`
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Signed-off-by: default avataralindima <[email protected]>
      Co-authored-by: default avatarordian <[email protected]>
      Co-authored-by: default avatarTsvetomir Dimitrov <[email protected]>
      Co-authored-by: default avatarMarcin S <[email protected]>
      Co-authored-by: default avataralindima <[email protected]>
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      48ea86f0
  14. Nov 08, 2023
  15. Nov 07, 2023
  16. Nov 06, 2023
  17. Nov 05, 2023
  18. Nov 03, 2023
    • georgepisaltu's avatar
      Identity pallet improvements (#2048) · 21fbc00d
      georgepisaltu authored
      This PR is a follow up to #1661 
      
      - [x] rename the `simple` module to `legacy`
      - [x] fix benchmarks to disregard the number of additional fields
      - [x] change the storage deposits to charge per encoded byte of the
      identity information instance, removing the need for `fn
      additional(&self) -> usize` in `IdentityInformationProvider`
      - [x] ~add an extrinsic to rejig deposits to account for the change
      above~
      - [ ] ~ensure through proper configuration that the new byte-based
      deposit is always lower than whatever is reserved now~
      - [x] remove `IdentityFields` from the `set_fields` extrinsic signature,
      as per [this
      discussion](https://github.com/paritytech/polkadot-sdk/pull/1661#discussion_r1371703403)
      
      > ensure through proper configuration that the new byte-based deposit is
      always lower than whatever is reserved now
      
      Not sure this is needed anymore. If the new deposits are higher than
      what is currently on chain and users don't have enough funds to reserve
      what is needed, the extrinisc fails and they're basically grandfathered
      and frozen until they add more funds and/or make a change to their
      identity. This behavior seems fine to me. Original idea
      [here](https://github.com/paritytech/polkadot-sdk/pull/1661#issuecomment-1779606319).
      
      > add an extrinsic to rejig deposits to account for the change above
      
      This was initially implemented but now removed from this PR in favor of
      the implementation detailed
      [here](https://github.com/paritytech/polkadot-sdk/pull/2088
      
      ).
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      21fbc00d
  19. 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 <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: command-bot <>
      e1c033eb
  20. Nov 01, 2023
    • jserrat's avatar
      9987bbb1
    • Serban Iorga's avatar
    • Ankan's avatar
      [NPoS] Paging reward payouts in order to scale rewardable nominators (#1189) · 00b85c51
      Ankan authored
      helps https://github.com/paritytech/polkadot-sdk/issues/439.
      closes https://github.com/paritytech/polkadot-sdk/issues/473.
      
      PR link in the older substrate repository:
      https://github.com/paritytech/substrate/pull/13498.
      
      # Context
      Rewards payout is processed today in a single block and limited to
      `MaxNominatorRewardedPerValidator`. This number is currently 512 on both
      Kusama and Polkadot.
      
      This PR tries to scale the nominators payout to an unlimited count in a
      multi-block fashion. Exposures are stored in pages, with each page
      capped to a certain number (`MaxExposurePageSize`). Starting out, this
      number would be the same as `MaxNominatorRewardedPerValidator`, but
      eventually, this number can be lowered through new runtime upgrades to
      limit the rewardeable nominators per dispatched call instruction.
      
      The changes in the PR are backward compatible.
      
      ## How payouts would work like after this change
      Staking exposes two calls, 1) the existing `payout_stakers` and 2)
      `payout_stakers_by_page`.
      
      ### payout_stakers
      This remains backward compatible with no signature change. If for a
      given era a validator has multiple pages, they can call `payout_stakers`
      multiple times. The pages are executed in an ascending sequence and the
      runtime takes care of preventing double claims.
      
      ### payout_stakers_by_page
      Very similar to `payout_stakers` but also accepts an extra param
      `page_index`. An account can choose to payout rewards only for an
      explicitly passed `page_index`.
      
      **Lets look at an example scenario**
      Given an active validator on Kusama had 1100 nominators,
      `MaxExposurePageSize` set to 512 for Era e. In order to pay out rewards
      to all nominators, the caller would need to call `payout_stakers` 3
      times.
      
      - `payout_stakers(origin, stash, e)` => will pay the first 512
      nominators.
      - `payout_stakers(origin, stash, e)` => will pay the second set of 512
      nominators.
      - `payout_stakers(origin, stash, e)` => will pay the last set of 76
      nominators.
      ...
      - `payout_stakers(origin, stash, e)` => calling it the 4th time would
      return an error `InvalidPage`.
      
      The above calls can also be replaced by `payout_stakers_by_page` and
      passing a `page_index` explicitly.
      
      ## Commission note
      Validator commission is paid out in chunks across all the pages where
      each commission chunk is proportional to the total stake of the current
      page. This implies higher the total stake of a page, higher will be the
      commission. If all the pages of a validator's single era are paid out,
      the sum of commission paid to the validator across all pages should be
      equal to what the commission would have been if we had a non-paged
      exposure.
      
      ### Migration Note
      Strictly speaking, we did not need to bump our storage version since
      there is no migration of storage in this PR. But it is still useful to
      mark a storage upgrade for the following reasons:
      
      - New storage items are introduced in this PR while some older storage
      items are deprecated.
      - For the next `HistoryDepth` eras, the exposure would be incrementally
      migrated to its corresponding paged storage item.
      - Runtimes using staking pallet would strictly need to wait at least
      `HistoryDepth` eras with current upgraded version (14) for the migration
      to complete. At some era `E` such that `E >
      era_at_which_V14_gets_into_effect + HistoryDepth`, we will upgrade to
      version X which will remove the deprecated storage items.
      In other words, it is a strict requirement that E<sub>x</sub> -
      E<sub>14</sub> > `HistoryDepth`, where
      E<sub>x</sub> = Era at which deprecated storages are removed from
      runtime,
      E<sub>14</sub> = Era at which runtime is upgraded to version 14.
      - For Polkadot and Kusama, there is a [tracker
      ticket](https://github.com/paritytech/polkadot-sdk/issues/433) to clean
      up the deprecated storage items.
      
      ### Storage Changes
      
      #### Added
      - ErasStakersOverview
      - ClaimedRewards
      - ErasStakersPaged
      
      #### Deprecated
      The following can be cleaned up after 84 eras which is tracked
      [here](https://github.com/paritytech/polkadot-sdk/issues/433).
      
      - ErasStakers.
      - ErasStakersClipped.
      - StakingLedger.claimed_rewards, renamed to
      StakingLedger.legacy_claimed_rewards.
      
      ### Config Changes
      - Renamed MaxNominatorRewardedPerValidator to MaxExposurePageSize.
      
      ### TODO
      - [x] Tracker ticket for cleaning up the old code after 84 eras.
      - [x] Add companion.
      - [x] Redo benchmarks before merge.
      - [x] Add Changelog for pallet_staking.
      - [x] Pallet should be configurable to enable/disable paged rewards.
      - [x] Commission payouts are distributed across pages.
      - [x] Review documentation thoroughly.
      - [x] Rename `MaxNominatorRewardedPerValidator` ->
      `MaxExposurePageSize`.
      - [x] NMap for `ErasStakersPaged`.
      - [x] Deprecate ErasStakers.
      - [x] Integrity tests.
      
      ### Followup issues
      [Runtime api for deprecated ErasStakers storage
      item](https://github.com/paritytech/polkadot-sdk/issues/426
      
      )
      
      ---------
      
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarRoss Bulat <[email protected]>
      Co-authored-by: command-bot <>
      00b85c51
  21. Oct 31, 2023
    • Adel Arja's avatar
      1953 defensive testing extrinsic (#1998) · 6e2f94f8
      Adel Arja authored
      
      
      # Description
      
      The `trigger_defensive` call has been added to the `root-testing`
      pallet. The idea is to have this pallet running on `Rococo/Westend` and
      use it to verify if the runtime monitoring works end-to-end.
      
      To accomplish this, `trigger_defensive` dispatches an event when it is
      called.
      
      Closes #1953
      
      # Checklist
      
      - [x] My PR includes a detailed description as outlined in the
      "Description" section above
      - [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
      of this project (at minimum one label for `T`
        required)
      - [ ] I have made corresponding changes to the documentation (if
      applicable)
      - [ ] I have added tests that prove my fix is effective or that my
      feature works (if applicable)
      
      You can remove the "Checklist" section once all have been checked. Thank
      you for your contribution!
      
      ✄
      -----------------------------------------------------------------------------
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      6e2f94f8
    • Alexandru Gheorghe's avatar
      polkadot: parachains: Fix v9 host configuration migration (#2103) · 64f4b156
      Alexandru Gheorghe authored
      
      
      We shouldn't override with their default fields that have been added in
      the previous version(v8), because we are going to lose whatever values have
      been set.
      
      Note, v8 & v9 seems to have landed at the same time on Rococo, probably
      they will land at the same time on westend and other chains, so functionally
      doesn't make much difference, but let's have this fixed for people that copy-paste
      :D, like me.
      
      ---------
      
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      64f4b156
  22. Oct 27, 2023
  23. Oct 24, 2023
    • Oliver Tale-Yazdi's avatar
      Improve features dev-ex (#1831) · 4a443567
      Oliver Tale-Yazdi authored
      Adds a config file that allows to run `zepter` without any arguments in
      the workspace to address all issues.
      A secondary workflow for the CI is provided as `zepter run check`. Both
      the formatting and linting are now in one check for efficiancy.
      
      The latest version also detects some more things that `featalign` was
      already showing.
      
      Error message [in the
      CI](https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3916205)
      now looks like this:
      ```pre
      ...
      crate 'test-parachains' (/Users/vados/Documents/work/polkadot-sdk/polkadot/parachain/test-parachains/Cargo.toml)
        feature 'std'
          must propagate to:
            parity-scale-codec
      Found 55 issues (run with --fix to fix).
      Error: Command 'lint propagate-feature' failed with exit code 1
      
      Polkadot-SDK uses the Zepter CLI to detect abnormalities in the feature configuration.
      It looks like one more more checks failed; please check the console output. You can try to automatically address them by running `zepter`.
      Otherwise please ask directly in the Merge Request, GitHub Discussions or on Matrix Chat, thank you.
      
      For more information, see:
        - https://github.com/paritytech/polkadot-sdk/issues/1831
        - https://github.com/ggwpez/zepter
      
      
      ```
      
      TODO:
      - [x] Check that CI fails correctly
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      4a443567
    • eskimor's avatar
      Remove obsolete comment. (#2008) · 12130a76
      eskimor authored
      
      
      it is indeed correct.
      
      Co-authored-by: default avatareskimor <[email protected]>
      12130a76
    • Tsvetomir Dimitrov's avatar
      Refactor candidates test in paras_inherent (#2004) · 0284e21f
      Tsvetomir Dimitrov authored
      Splits the test in multiple cases.
      0284e21f
    • georgepisaltu's avatar
      Make `IdentityInfo` generic in `pallet-identity` (#1661) · 91851951
      georgepisaltu authored
      Fixes #179 
      
      # Description
      
      This PR makes the structure containing identity information used in
      `pallet-identity` generic through the pallet `Config`. Additionally, the
      old structure is now available in a separate module called `simple`
      (pending rename) and is compatible with the new interface.
      
      Another change in this PR is that while the `additional` field in
      `IdentityInfo` stays for backwards compatibility reasons, the associated
      costs are stil present in the pallet through the `additional` function
      in the `IdentityInformationProvider` interface. This function is marked
      as deprecated as it is only a temporary solution to the backwards
      compatibility problem we had. In short, we could have removed the
      additional fields in the struct and done a migration, but we chose to
      wait and do it off-chain through the genesis of the system parachain.
      After we move the identity pallet to the parachain, additional fields
      will be migrated into the existing fields and the `additional` key-value
      store will be removed. Until that happens, this interface will provide
      the necessary information to properly account for the associated costs.
      
      Additionally, this PR fixes an unrelated issue; the `IdentityField` enum
      used to represent the fields as bitflags couldn't store more than 8
      fields, even though it was marked as `#[repr(u64)]`. This was because of
      the `derive` implementation of `TypeInfo`, which assumed `u8` semantics.
      The custom implementation of this trait in
      https://github.com/paritytech/polkadot-sdk/commit/0105cc0396b7a53d0b290f48b1225847f6d17321
      
      
      fixes the issue.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarSam Johnson <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      91851951
    • Kian Paimani's avatar
      Ensure correct variant count in `Runtime[Hold/Freeze]Reason` (#1900) · 35eb133b
      Kian Paimani authored
      closes https://github.com/paritytech/polkadot-sdk/issues/1882
      
      
      
      ## Breaking Changes
      
      This PR introduces a new item to `pallet_balances::Config`:
      
      ```diff
      trait Config {
      ++    type RuntimeFreezeReasons;
      }
      ```
      
      This value is only used to check it against `type MaxFreeze`. A similar
      check has been added for `MaxHolds` against `RuntimeHoldReasons`, which
      is already given to `pallet_balances`.
      
      In all contexts, you should pass the real `RuntimeFreezeReasons`
      generated by `construct_runtime` to `type RuntimeFreezeReasons`. Passing
      `()` would also work, but it would imply that the runtime uses no
      freezes at all.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      35eb133b
  24. Oct 23, 2023