mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-05-07 17:48:01 +00:00
c78c2892a4
* mark template and utils as non-publish * switch to development version for testing * activate unleash check * maybe if I disable all rules... * Fix isolated compilation of `max-encoded-len-derive` with `syn` error[E0369]: binary operation `==` cannot be applied to type `syn::Path` --> src/lib.rs:88:29 | 88 | .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate)) | --------- ^^ ----------------------------------- _ | | | syn::Path error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. Error: could not compile `max-encoded-len-derive` * WIP: bump changes crates since v3 tag to next breaking cargo unleash version bump-breaking --changed-since v3.0.0 cargo unleash version set-pre dev --changed-since v3.0.0 FIXME: Don't modify crates that are not yet released, e.g. `max-encoded-len-derive` * Update lockfile * WIP: Bump sp-transaction-pool as well * WIP: Bump sp-offchain as well * WIP: Bump frame-system-rpc-runtime-api as well * WIP: Bump sp-authority-discovery as well * Manually deactivate dev-deps before `cargo unleash check` Otherwise we run into `Cycle detected` error. * Bump sp-consensus-slots * Add missing Cargo.lock change * Bump sp-consensus-vrf as well * Bump sp-keyring as well * Bump sp-consensus-pow as well * Try to speed up the `unleash-check` job Previously, the job took 106 minutes - let's see if explicitly specifying a `CARGO_TARGET_DIR` will help * fixup: Ensure the temp target dir exists for unleash check * Bump pallet-transaction-payment-rpc-runtime-api as well Needed for Polkadot * Bump pallet-transaction-payment-rpc as well Needed for Polkadot * Try updating crates after patching in the Polkadot CI job * Use another approach to update patched Substrate crates * Try to update all sp-core versions in Polkadot CI job * Simplify sp-core version checking * Apply another shellcheck lint * Just do the simplest thing I guess * Welp don't do --offline then * Clean up `unleash-check` job triggers Co-authored-by: Denis Pisarev <denis.pisarev@parity.io> * Fix a note in unleash-check cache step * Add a note about temporary optimization in cargo-unleash * Pin a newer version of cargo-unleash Co-authored-by: Igor Matuszewski <xanewok@gmail.com> Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
Session Module
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
ShouldEndSessiontrait. When the session is ending, a new validator set can be chosen byOnSessionEndingimplementations. - 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_keysfor use not in the next session, but the session after next. They are stored inNextKeys, a mapping between the caller'sValidatorIdand the session keys provided.set_keysallows users to set their session key prior to being selected as validator. It is a public call since it usesensure_signed, which checks that the origin is a signed account. As such, the account ID of the origin stored inNextKeysmay 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
ShouldEndSessionto dictate a new session's start. This pallet provides thePeriodicSessionsstruct 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_initializefunction queries the provided implementation ofShouldEndSession. If the session is to end the newly activated validator IDs and session keys are taken from storage and passed to theSessionHandler. The validator set supplied bySessionManager::new_sessionand the corresponding session keys, which may have been registered viaset_keysduring the previous session, are written to storage where they will wait one session before being passed to theSessionHandlerthemselves.
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::Module<T>>::validators()
}
Related Modules
License: Apache-2.0