1. Jan 10, 2024
  2. Jan 08, 2024
  3. Jan 07, 2024
  4. Jan 04, 2024
  5. Dec 28, 2023
  6. Dec 20, 2023
    • Dónal Murray's avatar
      Fix clippy lints behind feature gates and add new CI step all features (#2569) · d68868f6
      Dónal Murray authored
      
      
      Many clippy lints usually enforced by `-Dcomplexity` and `-Dcorrectness`
      are not caught by CI as they are gated by `features`, like
      `runtime-benchmarks`, while the clippy CI job runs with only the default
      features for all targets.
      
      This PR also adds a CI step to run clippy with `--all-features` to
      ensure the code quality is maintained behind feature gates from now on.
      
      To improve local development, clippy lints are downgraded to warnings,
      but they still will result in an error at CI due to the `-Dwarnings`
      rustflag.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      d68868f6
  7. Dec 18, 2023
  8. Dec 14, 2023
  9. Dec 13, 2023
  10. Dec 12, 2023
    • Ross Bulat's avatar
      Staking: Add `deprecate_controller_batch` AdminOrigin call (#2589) · 048a9c27
      Ross Bulat authored
      
      
      Partially Addresses #2500
      
      Adds a `deprecate_controller_batch` call to the staking pallet that is
      callable by `Root` and `StakingAdmin`. To be used for controller account
      deprecation and removed thereafter. Adds
      `MaxControllersDeprecationBatch` pallet constant that defines max
      possible deprecations per call.
      
      - [x] Add `deprecate_controller_batch` call, and
      `MaxControllersInDeprecationBatch` constant.
      - [x] Add tests, benchmark, weights. Tests that weight is only consumed
      if unique pair.
      - [x] Adds `StakingAdmin` origin to staking's `AdminOrigin` type in
      westend runtime.
      - [x] Determined that worst case 5,900 deprecations does fit into
      `maxBlock` `proofSize` and `refTime` in both normal and operational
      thresholds, meaning we can deprecate all controllers for each network in
      one call.
      
      ## Block Weights
      
      By querying `consts.system.blockWeights` we can see that the
      `deprecate_controller_batch` weights fit within the `normal` threshold
      on Polkadot.
      
      #### `controller_deprecation_batch` where i = 5900:
      #### Ref time: 69,933,325,300
      #### Proof size: 21,040,390
      
      ### Polkadot 
      
      ```
      // consts.query.blockWeights
      
      maxBlock: {
              refTime: 2,000,000,000,000
              proofSize: 18,446,744,073,709,551,615
      }
      normal: {
       maxExtrinsic: {
      	refTime: 1,479,873,955,000
      	proofSize: 13,650,590,614,545,068,195
       }
       maxTotal: {
      	refTime: 1,500,000,000,000
      	proofSize: 13,835,058,055,282,163,711
       }
      }
      ```
      
      ### Kusama
      
      ```
      // consts.query.blockWeights
      
        maxBlock: {
          refTime: 2,000,000,000,000
          proofSize: 18,446,744,073,709,551,615
        }
          normal: {
            maxExtrinsic: {
              refTime: 1,479,875,294,000
              proofSize: 13,650,590,614,545,068,195
            }
            maxTotal: {
              refTime: 1,500,000,000,000
              proofSize: 13,835,058,055,282,163,711
            }
      }
      ```
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      048a9c27
  11. Dec 11, 2023
  12. Dec 08, 2023
  13. Dec 01, 2023
  14. Nov 30, 2023
  15. Nov 28, 2023
  16. Nov 27, 2023
  17. Nov 24, 2023
  18. Nov 23, 2023
  19. 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
  20. Nov 17, 2023
  21. Nov 04, 2023
  22. Nov 01, 2023
    • 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
  23. Oct 24, 2023
  24. Oct 20, 2023
    • Bastian Köcher's avatar
      `xcm`: Change `TypeInfo::path` to not include `staging` (#1948) · f3bf5c1a
      Bastian Köcher authored
      The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
      crates.io as someone as squatted `xcm`. The problem with this rename is
      that the `TypeInfo` includes the crate name which ultimately lands in
      the metadata. The metadata is consumed by downstream users like
      `polkadot-js` or people building on top of `polkadot-js`. These people
      are using the entire `path` to find the type in the type registry. Thus,
      their code would break as the type path would now be [`staging_xcm`,
      `VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
      fixes this by renaming the path segment `staging_xcm` to `xcm`.
      
      This requires: https://github.com/paritytech/scale-info/pull/197
      
      
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      f3bf5c1a
  25. Oct 17, 2023
  26. Oct 15, 2023
    • Gonçalo Pestana's avatar
      Refactor staking ledger (#1484) · 8ee4042c
      Gonçalo Pestana authored
      This PR refactors the staking ledger logic to encapsulate all reads and
      mutations of `Ledger`, `Bonded`, `Payee` and stake locks within the
      `StakingLedger` struct implementation.
      
      With these changes, all the reads and mutations to the `Ledger`, `Payee`
      and `Bonded` storage map should be done through the methods exposed by
      StakingLedger to ensure the data and lock consistency of the operations.
      The new introduced methods that mutate and read Ledger are:
      
      - `ledger.update()`: inserts/updates a staking ledger in storage;
      updates staking locks accordingly (and ledger.bond(), which is synthatic
      sugar for ledger.update())
      - `ledger.kill()`: removes all Bonded and StakingLedger related data for
      a given ledger; updates staking locks accordingly;
      `StakingLedger::get(account)`: queries both the `Bonded` and `Ledger`
      storages and returns a `Option<StakingLedger>`. The pallet impl exposes
      fn ledger(account) as synthatic sugar for `StakingLedger::get(account)`.
      
      Retrieving a ledger with `StakingLedger::get()` can be done by providing
      either a stash or controller account. The input must be wrapped in a
      `StakingAccount` variant (Stash or Controller) which is treated
      accordingly. This simplifies the caller API but will eventually be
      deprecated once we completely get rid of the controller account in
      staking. However, this refactor will help with the work necessary when
      completely removing the controller.
      
      Other goals:
      
      - No logical changes have been introduced in this PR;
      - No breaking changes or updates in wallets required;
      - No new storage items or need to perform storage migrations;
      - Centralise the changes to bonds and ledger updates to simplify the
      OnStakingUpdate updates to the target list (related to
      https://github.com/paritytech/polkadot-sdk/issues/443)
      
      Note: it would be great to prevent or at least raise a warning if
      `Ledger<T>`, `Payee<T>` and `Bonded<T>` storage types are accessed
      outside the `StakingLedger` implementation. This PR should not get
      blocked by that feature, but there's a tracking issue here
      https://github.com/paritytech/polkadot-sdk/issues/149
      
      Related and step towards
      https://github.com/paritytech/polkadot-sdk/issues/443
      8ee4042c
  27. Oct 06, 2023
  28. Oct 01, 2023
  29. Sep 20, 2023
  30. Sep 18, 2023
  31. Sep 15, 2023
  32. Sep 11, 2023
  33. Sep 04, 2023
  34. Aug 31, 2023