Skip to content
Snippets Groups Projects
  1. Feb 18, 2025
  2. Feb 17, 2025
    • Ankan's avatar
      [Staking] Bounded Slashing: Paginated Offence Processing & Slash Application (#7424) · dda2cb59
      Ankan authored
      
      closes https://github.com/paritytech/polkadot-sdk/issues/3610.
      
      helps https://github.com/paritytech/polkadot-sdk/issues/6344, but need
      to migrate storage `Offences::Reports` before we can remove exposure
      dependency in RC pallets.
      
      replaces https://github.com/paritytech/polkadot-sdk/issues/6788.
      
      ## Context  
      Slashing in staking is unbounded currently, which is a major blocker
      until staking can move to a parachain (AH).
      
      ### Current Slashing Process (Unbounded)  
      
      1. **Offence Reported**  
      - Offences include multiple validators, each with potentially large
      exposure pages.
      - Slashes are **computed immediately** and scheduled for application
      after **28 eras**.
      
      2. **Slash Applied**  
      - All unapplied slashes are executed in **one block** at the start of
      the **28th era**. This is an **unbounded operation**.
      
      
      ### Proposed Slashing Process (Bounded)  
      
      1. **Offence Queueing**  
         - Offences are **queued** after basic sanity checks.  
      
      2. **Paged Offence Processing (Computing Slash)**  
         - Slashes are **computed one validator exposure page at a time**.  
         - **Unapplied slashes** are stored in a **double map**:  
           - **Key 1 (k1):** `EraIndex`  
      - **Key 2 (k2):** `(Validator, SlashFraction, PageIndex)` — a unique
      identifier for each slash page
      
      3. **Paged Slash Application**  
      - Slashes are **applied one page at a time** across multiple blocks.
      - Slash application starts at the **27th era** (one era earlier than
      before) to ensure all slashes are applied **before stakers can unbond**
      (which starts from era 28 onwards).
      
      ---
      
      ## Worst-Case Block Calculation for Slash Application  
      
      ### Polkadot:  
      - **1 era = 24 hours**, **1 block = 6s** → **14,400 blocks/era**  
      - On parachains (**12s blocks**) → **7,200 blocks/era**  
      
      ### Kusama:  
      - **1 era = 6 hours**, **1 block = 6s** → **3,600 blocks/era**  
      - On parachains (**12s blocks**) → **1,800 blocks/era**  
      
      ### Worst-Case Assumptions:  
      - **Total stakers:** 40,000 nominators, 1000 validators. (Polkadot
      currently has ~23k nominators and 500 validators)
      - **Max slashed:** 50% so 20k nominators, 250 validators.  
      - **Page size:** Validators with multiple page: (512 + 1)/2 = 256 ,
      Validators with single page: 1
      
      ### Calculation:  
      There might be a more accurate way to calculate this worst-case number,
      and this estimate could be significantly higher than necessary, but it
      shouldn’t exceed this value.
      
      Blocks needed: 250 + 20k/256 = ~330 blocks.
      
      ##  *Potential Improvement:*  
      - Consider adding an **Offchain Worker (OCW)** task to further optimize
      slash application in future updates.
      - Dynamically batch unapplied slashes based on number of nominators in
      the page, or process until reserved weight limit is exhausted.
      
      ----
      ## Summary of Changes  
      
      ### Storage  
      - **New:**  
        - `OffenceQueue` *(StorageDoubleMap)*  
          - **K1:** Era  
          - **K2:** Offending validator account  
          - **V:** `OffenceRecord`  
        - `OffenceQueueEras` *(StorageValue)*  
          - **V:** `BoundedVec<EraIndex, BoundingDuration>`  
        - `ProcessingOffence` *(StorageValue)*  
          - **V:** `(Era, offending validator account, OffenceRecord)`  
      
      - **Changed:**  
        - `UnappliedSlashes`:  
          - **Old:** `StorageMap<K -> Era, V -> Vec<UnappliedSlash>>`  
      - **New:** `StorageDoubleMap<K1 -> Era, K2 -> (validator_acc, perbill,
      page_index), V -> UnappliedSlash>`
      
      ### Events  
      - **New:**  
        - `SlashComputed { offence_era, slash_era, offender, page }`  
        - `SlashCancelled { slash_era, slash_key, payout }`  
      
      ### Error  
      - **Changed:**  
        - `InvalidSlashIndex` → Renamed to `InvalidSlashRecord`  
      - **Removed:**  
        - `NotSortedAndUnique`  
      - **Added:**  
        - `EraNotStarted`  
      
      ### Call  
      - **Changed:**  
        - `cancel_deferred_slash(era, slash_indices: Vec<u32>)`  
          → Now takes `Vec<(validator_acc, slash_fraction, page_index)>`  
      - **New:**  
      - `apply_slash(slash_era, slash_key: (validator_acc, slash_fraction,
      page_index))`
      
      ### Runtime Config  
      - `FullIdentification` is now set to a unit type (`()`) / null identity,
      replacing the previous exposure type for all runtimes using
      `pallet_session::historical`.
      
      ## TODO
      - [x] Fixed broken `CancelDeferredSlashes`.
      - [x] Ensure on_offence called only with validator account for
      identification everywhere.
      - [ ] Ensure we never need to read full exposure.
      - [x] Tests for multi block processing and application of slash.
      - [x] Migrate UnappliedSlashes 
      - [x] Bench (crude, needs proper bench as followup)
        - [x] on_offence()
        - [x] process_offence()
        - [x] apply_slash()
       
       
      ## Followups (tracker
      [link](https://github.com/paritytech/polkadot-sdk/issues/7596))
      - [ ] OCW task to process offence + apply slashes.
      - [ ] Minimum time for governance to cancel deferred slash.
      - [ ] Allow root or staking admin to add a custom slash.
      - [ ] Test HistoricalSession proof works fine with eras before removing
      exposure as full identity.
      - [ ] Properly bench offence processing and slashing.
      - [ ] Handle Offences::Reports migration when removing validator
      exposure as identity.
      
      ---------
      
      Co-authored-by: default avatarGonçalo Pestana <g6pestana@gmail.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarKian Paimani <5588131+kianenigma@users.noreply.github.com>
      Co-authored-by: default avatarGuillaume Thiolliere <gui.thiolliere@gmail.com>
      Co-authored-by: default avatarkianenigma <kian@parity.io>
      Co-authored-by: default avatarGiuseppe Re <giuseppe.re@parity.io>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
    • cmd[bot]'s avatar
      Update from bkontur running command 'bench --pallet... · 4d746d20
      cmd[bot] authored
      Update from bkontur running command 'bench --pallet polkadot_runtime_parachains::paras --runtime westend rococo'
      4d746d20
    • Oliver Tale-Yazdi's avatar
      [AHM] Make pallet types public (#7579) · ca91d4b5
      Oliver Tale-Yazdi authored
      
      Preparation for AHM and making stuff public.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
    • Branislav Kontur's avatar
      Fix Rococo/Westend · e14f3311
      Branislav Kontur authored
    • Daniel Olano's avatar
      Change pallet referenda TracksInfo::tracks to return an iterator (#2072) · c078d2f4
      Daniel Olano authored
      
      Returning an iterator in `TracksInfo::tracks()` instead of a static
      slice allows for more flexible implementations of `TracksInfo` that can
      use the chain storage without compromising a lot on the
      performance/memory penalty if we were to return an owned `Vec` instead.
      
      ---------
      
      Co-authored-by: default avatarPablo Andrés Dorado Suárez <hola@pablodorado.com>
    • cmd[bot]'s avatar
      Update from bkontur running command 'fmt' · 1a9dba41
      cmd[bot] authored
      1a9dba41
    • Branislav Kontur's avatar
      Add `force_set_current_code` test · 693c2773
      Branislav Kontur authored
    • Branislav Kontur's avatar
    • rainb0w-pr0mise's avatar
      `pallet-utility: if_else` (#6321) · ead8fbdf
      rainb0w-pr0mise authored
      
      # Utility Call Fallback
      
      This introduces a new extrinsic: **`if_else`**
      
      Which first attempts to dispatch the `main` call(s). If the `main`
      call(s) fail, the `fallback` call(s) is dispatched instead. Both calls
      are executed with the same origin.
      
      In the event of a fallback failure the whole call fails with the weights
      returned.
      
      ## Use Case
      Some use cases might involve submitting a `batch` type call in either
      main, fallback or both.
      
      Resolves #6000
      
      Polkadot Address: 1HbdqutFR8M535LpbLFT41w3j7v9ptEYGEJKmc6PKpqthZ8
      
      ---------
      
      Co-authored-by: default avatarrainbow-promise <154476501+rainbow-promise@users.noreply.github.com>
      Co-authored-by: default avatarGuillaume Thiolliere <gui.thiolliere@gmail.com>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
  3. Feb 14, 2025
    • Kian Paimani's avatar
      [AHM] Multi-block staking election pallet (#7282) · a025562b
      Kian Paimani authored
      ## Multi Block Election Pallet
      
      This PR adds the first iteration of the multi-block staking pallet. 
      
      From this point onwards, the staking and its election provider pallets
      are being customized to work in AssetHub. While usage in solo-chains is
      still possible, it is not longer the main focus of this pallet. For a
      safer usage, please fork and user an older version of this pallet.
      
      ---
      
      ## Replaces
      
      - [x] https://github.com/paritytech/polkadot-sdk/pull/6034 
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5272
      
      ## Related PRs: 
      
      - [x] https://github.com/paritytech/polkadot-sdk/pull/7483
      - [ ] https://github.com/paritytech/polkadot-sdk/pull/7357
      - [ ] https://github.com/paritytech/polkadot-sdk/pull/7424
      - [ ] https://github.com/paritytech/polkadot-staking-miner/pull/955
      
      This branch can be periodically merged into
      https://github.com/paritytech/polkadot-sdk/pull/7358 ->
      https://github.com/paritytech/polkadot-sdk/pull/6996
      
      ## TODOs: 
      
      - [x] rebase to master 
      - Benchmarking for staking critical path
        - [x] snapshot
        - [x] election result
      - Benchmarking for EPMB critical path
        - [x] snapshot
        - [x] verification
        - [x] submission
        - [x] unsigned submission
        - [ ] election results fetching
      - [ ] Fix deletion weights. Either of
        - [ ] Garbage collector + lazy removal of all paged storage items
        - [ ] Confirm that deletion is small PoV footprint.
      - [ ] Move election prediction to be push based. @tdimitrov 
      - [ ] integrity checks for bounds 
      - [ ] Properly benchmark this as a part of CI -- for now I will remove
      them as they are too slow
      - [x] add try-state to all pallets
      - [x] Staking to allow genesis dev accounts to be created internally
      - [x] Decouple miner config so @niklasad1 can work on the miner
      72841b73
      - [x] duplicate snapshot page reported by @niklasad1
      
       
      - [ ] https://github.com/paritytech/polkadot-sdk/pull/6520 or equivalent
      -- during snapshot, `VoterList` must be locked
      - [ ] Move target snapshot to a separate block
      
      ---------
      
      Co-authored-by: default avatarGonçalo Pestana <g6pestana@gmail.com>
      Co-authored-by: default avatarAnkan <10196091+Ank4n@users.noreply.github.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarGuillaume Thiolliere <gui.thiolliere@gmail.com>
      Co-authored-by: default avatarGiuseppe Re <giuseppe.re@parity.io>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
    • Bastian Köcher's avatar
    • Oliver Tale-Yazdi's avatar
      [mq pallet] Custom next queue selectors (#6059) · 7aac8861
      Oliver Tale-Yazdi authored
      
      Changes:
      - Expose a `force_set_head` function from the `MessageQueue` pallet via
      a new trait: `ForceSetHead`. This can be used to force the MQ pallet to
      process this queue next.
      - The change only exposes an internal function through a trait, no audit
      is required.
      
      ## Context
      
      For the Asset Hub Migration (AHM) we need a mechanism to prioritize the
      inbound upward messages and the inbound downward messages on the AH. To
      achieve this, a minimal (and no breaking) change is done to the MQ
      pallet in the form of adding the `force_set_head` function.
      
      An example use of how to achieve prioritization is then demonstrated in
      `integration_test.rs::AhmPrioritizer`. Normally, all queues are
      scheduled round-robin like this:
      
      `| Relay | Para(1) | Para(2) | ... | Relay | ... `
      
      The prioritizer listens to changes to its queue and triggers if either:
      - The queue processed in the last block (to keep the general round-robin
      scheduling)
      - The queue did not process since `n` blocks (to prevent starvation if
      there are too many other queues)
      
      In either situation, it schedules the queue for a streak of three
      consecutive blocks, such that it would become:
      
      `| Relay | Relay | Relay | Para(1) | Para(2) | ... | Relay | Relay |
      Relay | ... `
      
      It basically transforms the round-robin into an elongated round robin.
      Although different strategies can be injected into the pallet at
      runtime, this one seems to strike a good balance between general service
      level and prioritization.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarmuharem <ismailov.m.h@gmail.com>
  4. Feb 13, 2025
  5. Feb 12, 2025
  6. Feb 08, 2025
  7. Feb 07, 2025
  8. Feb 04, 2025
    • Alexander Theißen's avatar
      revive: Include immutable storage deposit into the contracts `storage_base_deposit` (#7230) · 4c28354b
      Alexander Theißen authored
      
      This PR is centered around a main fix regarding the base deposit and a
      bunch of drive by or related fixtures that make sense to resolve in one
      go. It could be broken down more but I am constantly rebasing this PR
      and would appreciate getting those fixes in as-one.
      
      **This adds a multi block migration to Westend AssetHub that wipes the
      pallet state clean. This is necessary because of the changes to the
      `ContractInfo` storage item. It will not delete the child storage
      though. This will leave a tiny bit of garbage behind but won't cause any
      problems. They will just be orphaned.**
      
      ## Record the deposit for immutable data into the `storage_base_deposit`
      
      The `storage_base_deposit` are all the deposit a contract has to pay for
      existing. It included the deposit for its own metadata and a deposit
      proportional (< 1.0x) to the size of its code. However, the immutable
      code size was not recorded there. This would lead to the situation where
      on terminate this portion wouldn't be refunded staying locked into the
      contract. It would also make the calculation of the deposit changes on
      `set_code_hash` more complicated when it updates the immutable data (to
      be done in #6985). Reason is because it didn't know how much was payed
      before since the storage prices could have changed in the mean time.
      
      In order for this solution to work I needed to delay the deposit
      calculation for a new contract for after the contract is done executing
      is constructor as only then we know the immutable data size. Before, we
      just charged this eagerly in `charge_instantiate` before we execute the
      constructor. Now, we merely send the ED as free balance before the
      constructor in order to create the account. After the constructor is
      done we calculate the contract base deposit and charge it. This will
      make `set_code_hash` much easier to implement.
      
      As a side effect it is now legal to call `set_immutable_data` multiple
      times per constructor (even though I see no reason to do so). It simply
      overrides the immutable data with the new value. The deposit accounting
      will be done after the constructor returns (as mentioned above) instead
      of when setting the immutable data.
      
      ## Don't pre-charge for reading immutable data
      
      I noticed that we were pre-charging weight for the max allowable
      immutable data when reading those values and then refunding after read.
      This is not necessary as we know its length without reading the storage
      as we store it out of band in contract metadata. This makes reading it
      free. Less pre-charging less problems.
      
      ## Remove delegate locking
      
      Fixes #7092
      
      This is also in the spirit of making #6985 easier to implement. The
      locking complicates `set_code_hash` as we might need to block settings
      the code hash when locks exist. Check #7092 for further rationale.
      
      ## Enforce "no terminate in constructor" eagerly
      
      We used to enforce this rule after the contract execution returned. Now
      we error out early in the host call. This makes it easier to be sure to
      argue that a contract info still exists (wasn't terminated) when a
      constructor successfully returns. All around this his just much simpler
      than dealing this check.
      
      ## Moved refcount functions to `CodeInfo`
      
      They never really made sense to exist on `Stack`. But now with the
      locking gone this makes even less sense. The refcount is stored inside
      `CodeInfo` to lets just move them there.
      
      ## Set `CodeHashLockupDepositPercent` for test runtime
      
      The test runtime was setting `CodeHashLockupDepositPercent` to zero.
      This was trivializing many code paths and excluded them from testing. I
      set it to `30%` which is our default value and fixed up all the tests
      that broke. This should give us confidence that the lockup doeposit
      collections properly works.
      
      ## Reworked the `MockExecutable` to have both a `deploy` and a `call`
      entry point
      
      This type used for testing could only have either entry points but not
      both. In order to fix the `immutable_data_set_overrides` I needed to a
      new function `add_both` to `MockExecutable` that allows to have both
      entry points. Make sure to make use of it in the future :)
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
  9. Feb 03, 2025
    • Alin Dima's avatar
      deprecate AsyncBackingParams (#7254) · 4cd07c56
      Alin Dima authored
      
      Part of https://github.com/paritytech/polkadot-sdk/issues/5079.
      
      Removes all usage of the static async backing params, replacing them
      with dynamically computed equivalent values (based on the claim queue
      and scheduling lookahead).
      
      Adds a new runtime API for querying the scheduling lookahead value. If
      not present, falls back to 3 (the default value that is backwards
      compatible with values we have on production networks for
      allowed_ancestry_len)
      
      Also resolves most of
      https://github.com/paritytech/polkadot-sdk/issues/4447, removing code
      that handles async backing not yet being enabled.
      While doing this, I removed the support for collation protocol version 1
      on collators, as it only worked for leaves not supporting async backing
      (which are none).
      I also unhooked the legacy v1 statement-distribution (for the same
      reason as above). That subsystem is basically dead code now, so I had to
      remove some of its tests as they would no longer pass (since the
      subsystem no longer sends messages to the legacy variant). I did not
      remove the entire legacy subsystem yet, as that would pollute this PR
      too much. We can remove the entire v1 and v2 validation protocols in a
      follow up PR.
      
      In another PR: remove test files with names `prospective_parachains`
      (it'd pollute this PR if we do now)
      
      TODO:
      - [x] add deprecation warnings
      - [x] prdoc
      
      ---------
      
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
  10. Jan 30, 2025
    • ordian's avatar
      fix pre-dispatch PoV underweight for ParasInherent (#7378) · 0d35be7b
      ordian authored
      
      This should fix the error log related to PoV pre-dispatch weight being
      lower than post-dispatch for `ParasInherent`:
      ```
      ERROR tokio-runtime-worker runtime::frame-support: Post dispatch weight is greater than pre dispatch weight. Pre dispatch weight may underestimating the actual weight. Greater post dispatch weight components are ignored.
                                              Pre dispatch weight: Weight { ref_time: 47793353978, proof_size: 1019 },
                                              Post dispatch weight: Weight { ref_time: 5030321719, proof_size: 135395 }
      ```
      
      ---------
      
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
  11. Jan 28, 2025
    • Andrew Jones's avatar
      Implement pallet view function queries (#4722) · 0b8d7441
      Andrew Jones authored
      
      Closes #216.
      
      This PR allows pallets to define a `view_functions` impl like so:
      
      ```rust
      #[pallet::view_functions]
      impl<T: Config> Pallet<T>
      where
      	T::AccountId: From<SomeType1> + SomeAssociation1,
      {
      	/// Query value no args.
      	pub fn get_value() -> Option<u32> {
      		SomeValue::<T>::get()
      	}
      
      	/// Query value with args.
      	pub fn get_value_with_arg(key: u32) -> Option<u32> {
      		SomeMap::<T>::get(key)
      	}
      }
      ```
      ### `QueryId`
      
      Each view function is uniquely identified by a `QueryId`, which for this
      implementation is generated by:
      
      ```twox_128(pallet_name) ++ twox_128("fn_name(fnarg_types) -> return_ty")```
      
      The prefix `twox_128(pallet_name)` is the same as the storage prefix for pallets and take into account multiple instances of the same pallet.
      
      The suffix is generated from the fn type signature so is guaranteed to be unique for that pallet impl. For one of the view fns in the example above it would be `twox_128("get_value_with_arg(u32) -> Option<u32>")`. It is a known limitation that only the type names themselves are taken into account: in the case of type aliases the signature may have the same underlying types but a different id; for generics the concrete types may be different but the signatures will remain the same.
      
      The existing Runtime `Call` dispatchables are addressed by their concatenated indices `pallet_index ++ call_index`, and the dispatching is handled by the SCALE decoding of the `RuntimeCallEnum::PalletVariant(PalletCallEnum::dispatchable_variant(payload))`. For `view_functions` the runtime/pallet generated enum structure is replaced by implementing the `DispatchQuery` trait on the outer (runtime) scope, dispatching to a pallet based on the id prefix, and the inner (pallet) scope dispatching to the specific function based on the id suffix.
      
      Future implementations could also modify/extend this scheme and routing to pallet agnostic queries.
      
      ### Executing externally
      
      These view functions can be executed externally via the system runtime api:
      
      ```rust
      pub trait ViewFunctionsApi<QueryId, Query, QueryResult, Error> where
      	QueryId: codec::Codec,
      	Query: codec::Codec,
      	QueryResult: codec::Codec,
      	Error: codec::Codec,
      {
      	/// Execute a view function query.
      fn execute_query(query_id: QueryId, query: Query) -> Result<QueryResult,
      Error>;
      }
      ```
      ### `XCQ`
      Currently there is work going on by @xlc to implement [`XCQ`](https://github.com/open-web3-stack/XCQ/) which may eventually supersede this work.
      
      It may be that we still need the fixed function local query dispatching in addition to XCQ, in the same way that we have chain specific runtime dispatchables and XCM.
      
      I have kept this in mind and the high level query API is agnostic to the underlying query dispatch and execution. I am just providing the implementation for the `view_function` definition.
      
      ### Metadata
      Currently I am utilizing the `custom` section of the frame metadata, to avoid modifying the official metadata format until this is standardized.
      
      ### vs `runtime_api`
      There are similarities with `runtime_apis`, some differences being:
      - queries can be defined directly on pallets, so no need for boilerplate declarations and implementations
      - no versioning, the `QueryId` will change if the signature changes. 
      - possibility for queries to be executed from smart contracts (see below)
      
      ### Calling from contracts
      Future work would be to add `weight` annotations to the view function queries, and a host function to `pallet_contracts` to allow executing these queries from contracts.
      
      ### TODO
      
      - [x] Consistent naming (view functions pallet impl, queries, high level api?)
      - [ ] End to end tests via `runtime_api`
      - [ ] UI tests
      - [x] Mertadata tests
      - [ ] Docs
      
      ---------
      
      Co-authored-by: default avatarkianenigma <kian@parity.io>
      Co-authored-by: default avatarJames Wilson <james@jsdw.me>
      Co-authored-by: default avatarGiuseppe Re <giuseppe.re@parity.io>
      Co-authored-by: default avatarGuillaume Thiolliere <guillaume.thiolliere@parity.io>
  12. Jan 27, 2025
  13. Jan 26, 2025
  14. Jan 24, 2025
  15. Jan 23, 2025
    • Andrei Sandu's avatar
      Deprecate ParaBackingState API (#6867) · e9393a9a
      Andrei Sandu authored
      
      Currently the `para_backing_state` API is used only by the prospective
      parachains subsystems and returns 2 things: the constraints for
      parachain blocks and the candidates pending availability.
      
      This PR deprecates `para_backing_state` and introduces a new
      `backing_constraints` API that can be used together with
      `candidates_pending_availability` to get the same information provided
      by `para_backing_state`.
      
      TODO:
      - [x] PRDoc
      
      ---------
      
      Signed-off-by: default avatarAndrei Sandu <andrei-mihail@parity.io>
      Co-authored-by: command-bot <>
    • Alin Dima's avatar
      bump lookahead to 3 for testnet genesis (#7252) · cfc5b6f5
      Alin Dima authored
      This is the right value after
      https://github.com/paritytech/polkadot-sdk/pull/4880, which corresponds
      to an allowedAncestryLen of 2 (which is the default)
      
      WIll fix https://github.com/paritytech/polkadot-sdk/issues/7105
    • runcomet's avatar
      Balances: Configurable Number of Genesis Accounts with Specified Balances for Benchmarking (#6267) · 04847d51
      runcomet authored
      
      # Derived Dev Accounts
      
      Resolves https://github.com/paritytech/polkadot-sdk/issues/6040
      
      ## Description
      This update introduces support for creating an arbitrary number of
      developer accounts at the genesis block based on a specified derivation
      path. This functionality is gated by the runtime-benchmarks feature,
      ensuring it is only enabled during benchmarking scenarios.
      
      ### Key Features
      - Arbitrary Dev Accounts at Genesis: Developers can now specify any
      number of accounts to be generated at genesis using a hard derivation
      path.
      
      - Default Derivation Path: If no derivation path is provided (i.e., when
      `Option<dev_accounts: (..., None)>` is set to `Some` at genesis), the
      system will default to the path `//Sender//{}`.
      
      - No Impact on Total Token Issuance: Developer accounts are excluded
      from the total issuance of the token supply at genesis, ensuring they do
      not affect the overall balance or token distribution.
      
      polkadot address: 14SRqZTC1d8rfxL8W1tBTnfUBPU23ACFVPzp61FyGf4ftUFg
      
      ---------
      
      Co-authored-by: default avatarSebastian Kunert <skunert49@gmail.com>
  16. Jan 22, 2025
    • Serban Iorga's avatar
      Enable BEEFY `report_fork_voting()` (#6856) · 1bdb817f
      Serban Iorga authored
      Related to https://github.com/paritytech/polkadot-sdk/issues/4523
      
      Follow-up for: https://github.com/paritytech/polkadot-sdk/pull/5188
      
      Reopening https://github.com/paritytech/polkadot-sdk/pull/6732 as a new
      PR
      
      ---------
      
      Co-authored-by: command-bot <>
  17. Jan 20, 2025
  18. Jan 17, 2025
  19. Jan 16, 2025
    • Ankan's avatar
      [Staking] Currency <> Fungible migration (#5501) · f5673cf2
      Ankan authored
      Migrate staking currency from `traits::LockableCurrency` to
      `traits::fungible::holds`.
      
      Resolves part of https://github.com/paritytech/polkadot-sdk/issues/226.
      
      ## Changes
      ### Nomination Pool
      TransferStake is now incompatible with fungible migration as old pools
      were not meant to have additional ED. Since they are anyways deprecated,
      removed its usage from all test runtimes.
      
      ### Staking
      - Config: `Currency` becomes of type `Fungible` while `OldCurrency` is
      the `LockableCurrency` used before.
      - Lazy migration of accounts. Any ledger update will create a new hold
      with no extra reads/writes. A permissionless extrinsic
      `migrate_currency()` releases the old `lock` along with some
      housekeeping.
      - Staking now requires ED to be left free. It also adds no consumer to
      staking accounts.
      - If hold cannot be applied to all stake, the un-holdable part is force
      withdrawn from the ledger.
      
      ### Delegated Staking
      The pallet does not add provider for agents anymore.
      
      ## Migration stats
      ### Polkadot
      Total accounts that can be migrated: 59564
      Accounts failing to migrate: 0
      Accounts with stake force withdrawn greater than ED: 59
      Total force withdrawal: 29591.26 DOT
      
      ### Kusama
      Total accounts that can be migrated: 26311
      Accounts failing to migrate: 0
      Accounts with stake force withdrawn greater than ED: 48
      Total force withdrawal: 1036.05 KSM
      
      
      [Full logs here](https://hackmd.io/@ak0n/BklDuFra0).
      
      ## Note about locks (freeze) vs holds
      With locks or freezes, staking could use total balance of an account.
      But with holds, the account needs to be left with at least Existential
      Deposit in free balance. This would also affect nomination pools which
      till now has been able to stake all funds contributed to it. An
      alternate version of this PR is
      https://github.com/paritytech/polkadot-sdk/pull/5658 where staking
      pallet does not add any provider, but means pools and delegated-staking
      pallet has to provide for these accounts and makes the end to end logic
      (of provider and consumer ref) lot less intuitive and prone to bug.
      
      This PR now introduces requirement for stakers to maintain ED in their
      free balance. This helps with removing the bug prone incrementing and
      decrementing of consumers and providers.
      
      ## TODO
      - [x] Test: Vesting + governance locked funds can be staked.
      - [ ] can `Call::restore_ledger` be removed? @gpestana 
      - [x] Ensure unclaimed withdrawals is not affected by no provider for
      pool accounts.
      - [x] Investigate kusama accounts with balance between 0 and ED.
      - [x] Permissionless call to release lock.
      - [x] Migration of consumer (dec) and provider (inc) for direct stakers.
      - [x] force unstake if hold cannot be applied to all stake.
      - [x] Fix try state checks (it thinks nothing is staked for unmigrated
      ledgers).
      - [x] Bench `migrate_currency`.
      - [x] Virtual Staker migration test.
      - [x] Ensure total issuance is upto date when minting rewards.
      
      ## Followup
      - https://github.com/paritytech/polkadot-sdk/issues/5742
      
      ---------
      
      Co-authored-by: command-bot <>
    • Liam Aharon's avatar
      Implement `pallet-asset-rewards` (#3926) · be2404cc
      Liam Aharon authored
      
      Closes #3149 
      
      ## Description
      
      This PR introduces `pallet-asset-rewards`, which allows accounts to be
      rewarded for freezing `fungible` tokens. The motivation for creating
      this pallet is to allow incentivising LPs.
      
      See the pallet docs for more info about the pallet.
      
      ## Runtime changes
      
      The pallet has been added to
      - `asset-hub-rococo`
      - `asset-hub-westend`
      
      The `NativeAndAssets` `fungibles` Union did not contain `PoolAssets`, so
      it has been renamed `NativeAndNonPoolAssets`
      
      A new `fungibles` Union `NativeAndAllAssets` was created to encompass
      all assets and the native token.
      
      ## TODO
      - [x] Emulation tests
      - [x] Fill in Freeze logic (blocked
      https://github.com/paritytech/polkadot-sdk/issues/3342) and re-run
      benchmarks
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarmuharem <ismailov.m.h@gmail.com>
      Co-authored-by: default avatarGuillaume Thiolliere <gui.thiolliere@gmail.com>
  20. Jan 15, 2025
  21. Jan 14, 2025