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

Files

T

Alexandru Gheorghe 8d0cd4ffc8 Fix kusama validators getting 0 backing rewards the first session they enter the active set (#3722 )

There is a problem in the way we update `authorithy-discovery` next keys
and because of that nodes that enter the active set would be noticed at
the start of the session they become active, instead of the start of the
previous session as it was intended. This is problematic because:

1. The node itself advertises its addresses on the DHT only when it
notices it should become active on around ~10m loop, so in this case it
would notice after it becomes active.
2. The other nodes won't be able to detect the new nodes addresses at
the beginning of the session, so it won't added them to the reserved
set.

With 1 + 2, we end-up in a situation where the the new node won't be
able to properly connect to its peers because it won't be in its peers
reserved set. Now, the nodes accept by default`MIN_GOSSIP_PEERS: usize =
25` connections to nodes that are not in the reserved set, but given
Kusama size(> 1000 nodes) you could easily have more than`25` new nodes
entering the active set or simply the nodes don't have slots anymore
because, they already have connections to peers not in the active set.

In the end what the node would notice is 0 backing rewards because it
wasn't directly connected to the peers in its backing group.

## Root-cause

The flow is like this:
1. At BAD_SESSION - 1, in `rotate_session` new nodes are added to
QueuedKeys
https://github.com/paritytech/polkadot-sdk/blob/02e1a7f476d7d7c67153e975ab9a1bdc02ffea12/substrate/frame/session/src/lib.rs#L609
```
<QueuedKeys<T>>::put(queued_amalgamated.clone());
<QueuedChanged<T>>::put(next_changed);
```
2. AuthorityDiscovery::on_new_session is called with `changed` being the
value of `<QueuedChanged<T>>:` at BAD_SESSION - **2** because it was
saved before being updated
https://github.com/paritytech/polkadot-sdk/blob/02e1a7f476d7d7c67153e975ab9a1bdc02ffea12/substrate/frame/session/src/lib.rs#L613
3. At BAD_SESSION - 1, `AuthorityDiscovery::on_new_session` doesn't
updated its next_keys because `changed` was false.
4. For the entire durations of `BAD_SESSION - 1` everyone calling
runtime api `authorities`(should return past, present and future
authorities) won't discover the nodes that should become active .
5. At the beginning of BAD_SESSION, all nodes discover the new nodes are
authorities, but it is already too late because reserved_nodes are
updated only at the beginning of the session by the `gossip-support`.
See above why this bad.

## Fix
Update next keys with the queued_validators at every session, not matter
the value of `changed` this is the same way babe pallet correctly does
it.
https://github.com/paritytech/polkadot-sdk/blob/02e1a7f476d7d7c67153e975ab9a1bdc02ffea12/substrate/frame/babe/src/lib.rs#L655

## Notes

- The issue doesn't reproduce with proof-authorities changes like
`versi` because `changed` would always be true and `AuthorityDiscovery`
correctly updates its next_keys every time.
- Confirmed at session `37651` on kusama that this is exactly what it
happens by looking at blocks with polkadot.js.

## TODO
- [ ] Move versi on proof of stake and properly test before and after
fix to confirm there is no other issue.

---------

Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>

2024-03-18 11:45:39 +00:00

benchmarking

Removes as [disambiguation_path] from derive_impl usage (#3652 )

2024-03-15 07:46:09 +00:00

src

Fix kusama validators getting 0 backing rewards the first session they enter the active set (#3722 )

2024-03-18 11:45:39 +00:00

Cargo.toml

Lift dependencies to the workspace (Part 1) (#2070 )

2024-02-12 11:19:20 +00: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