mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-04-26 14:37:57 +00:00

Files

T

Gonçalo Pestana 8ee4042c3b Refactor staking ledger (#1484 )

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

2023-10-15 22:50:07 +02:00

benchmarking

Refactor staking ledger (#1484 )

2023-10-15 22:50:07 +02:00

src

Restructure dispatch macro related exports (#1162 )

2023-08-31 14:08:44 +03:00

Cargo.toml

Fix build profiles (#1229 )

2023-08-29 13:39:41 +02:00

README.md

Markdown linter (#1309 )

2023-09-04 12:02:32 +03:00

README.md

Session Pallet

The Session module allows validators to manage their session keys, provides a function for changing the session length, and handles session rotation.

Overview

Terminology

Session: A session is a period of time that has a constant set of validators. Validators can only join or exit the validator set at a session change. It is measured in block numbers. The block where a session is ended is determined by the ShouldEndSession trait. When the session is ending, a new validator set can be chosen by OnSessionEnding implementations.
Session key: A session key is actually several keys kept together that provide the various signing functions required by network authorities/validators in pursuit of their duties.
Validator ID: Every account has an associated validator ID. For some simple staking systems, this may just be the same as the account ID. For staking systems using a stash/controller model, the validator ID would be the stash account ID of the controller.
Session key configuration process: Session keys are set using set_keys for use not in the next session, but the session after next. They are stored in NextKeys, a mapping between the caller's ValidatorId and the session keys provided. set_keys allows users to set their session key prior to being selected as validator. It is a public call since it uses ensure_signed, which checks that the origin is a signed account. As such, the account ID of the origin stored in NextKeys may not necessarily be associated with a block author or a validator. The session keys of accounts are removed once their account balance is zero.
Session length: This pallet does not assume anything about the length of each session. Rather, it relies on an implementation of ShouldEndSession to dictate a new session's start. This pallet provides the PeriodicSessions struct for simple periodic sessions.
Session rotation configuration: Configure as either a 'normal' (rewardable session where rewards are applied) or 'exceptional' (slashable) session rotation.
Session rotation process: At the beginning of each block, the on_initialize function queries the provided implementation of ShouldEndSession. If the session is to end the newly activated validator IDs and session keys are taken from storage and passed to the SessionHandler. The validator set supplied by SessionManager::new_session and the corresponding session keys, which may have been registered via set_keys during the previous session, are written to storage where they will wait one session before being passed to the SessionHandler themselves.

Goals

The Session pallet is designed to make the following possible:

Set session keys of the validator set for upcoming sessions.
Control the length of sessions.
Configure and switch between either normal or exceptional session rotations.

Interface

Dispatchable Functions

set_keys - Set a validator's session keys for upcoming sessions.

Public Functions

rotate_session - Change to the next session. Register the new authority set. Queue changes for next session rotation.
disable_index - Disable a validator by index.
disable - Disable a validator by Validator ID

Usage

Example from the FRAME

The Staking pallet uses the Session pallet to get the validator set.

use pallet_session as session;

fn validators<T: pallet_session::Config>() -> Vec<<T as pallet_session::Config>::ValidatorId> {
	<pallet_session::Pallet<T>>::validators()
}

Staking

License: Apache-2.0

README.md

Session Pallet

Overview

Terminology

Goals

Interface

Dispatchable Functions

Public Functions

Usage

Example from the FRAME

Related Pallets