pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-06 04:28:01 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
5ba8921787609dddbabb8be3443186b65fdde190
pezkuwi-subxt/substrate/frame/session
T
History
Branislav Kontur bb8ddc46c1 [frame] #[pallet::composite_enum] improved variant count handling + removed pallet_balances's MaxHolds config (#2657) 
I started this investigation/issue based on @liamaharon question
[here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499).

## Problem

The `pallet_balances` integrity test should correctly detect that the
runtime has correct distinct `HoldReasons` variant count. I assume the
same situation exists for RuntimeFreezeReason.

It is not a critical problem, if we set `MaxHolds` with a sufficiently
large value, everything should be ok. However, in this case, the
integrity_test check becomes less useful.

**Situation for "any" runtime:**
- `HoldReason` enums from different pallets:
```rust
        /// from pallet_nis
        #[pallet::composite_enum]
	pub enum HoldReason {
		NftReceipt,
	}

        /// from pallet_preimage
        #[pallet::composite_enum]
	pub enum HoldReason {
		Preimage,
	}

        // from pallet_state-trie-migration
        #[pallet::composite_enum]
	pub enum HoldReason {
		SlashForContinueMigrate,
		SlashForMigrateCustomTop,
		SlashForMigrateCustomChild,
	}
```

- generated `RuntimeHoldReason` enum looks like:
```rust
pub enum RuntimeHoldReason {

    #[codec(index = 32u8)]
    Preimage(pallet_preimage::HoldReason),

    #[codec(index = 38u8)]
    Nis(pallet_nis::HoldReason),

    #[codec(index = 42u8)]
    StateTrieMigration(pallet_state_trie_migration::HoldReason),
}
```

- composite enum `RuntimeHoldReason` variant count is detected as `3`
- we set `type MaxHolds = ConstU32<3>`
- `pallet_balances::integrity_test` is ok with `3`(at least 3)

However, the real problem can occur in a live runtime where some
functionality might stop working. This is due to a total of 5 distinct
hold reasons (for pallets with multi-instance support, it is even more),
and not all of them can be used because of an incorrect `MaxHolds`,
which is deemed acceptable according to the `integrity_test`:
  ```
  // pseudo-code - if we try to call all of these:

T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(),
&nft_owner, deposit)?;
T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(),
&nft_owner, deposit)?;

T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(),
&nft_owner, deposit)?;

  // With `type MaxHolds = ConstU32<3>` these two will fail

T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(),
&nft_owner, deposit)?;

T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(),
&nft_owner, deposit)?;
  ```  


## Solutions

A macro `#[pallet::*]` expansion is extended of `VariantCount`
implementation for the `#[pallet::composite_enum]` enum type. This
expansion generates the `VariantCount` implementation for pallets'
`HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants
must be plain enum values without fields to ensure a deterministic
count.

The composite runtime enum, `RuntimeHoldReason` and
`RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum
of pallets' enum `VariantCount::VARIANT_COUNT`:
```rust
#[frame_support::pallet(dev_mode)]
mod module_single_instance {

	#[pallet::composite_enum]
	pub enum HoldReason {
		ModuleSingleInstanceReason1,
		ModuleSingleInstanceReason2,
	}
...
}

#[frame_support::pallet(dev_mode)]
mod module_multi_instance {

	#[pallet::composite_enum]
	pub enum HoldReason<I: 'static = ()> {
		ModuleMultiInstanceReason1,
		ModuleMultiInstanceReason2,
		ModuleMultiInstanceReason3,
	}
...
}


impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount
    for RuntimeHoldReason
{
    const VARIANT_COUNT: u32 = 0
        + module_single_instance::HoldReason::VARIANT_COUNT
        + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT
        + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT
        + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT;
}
```

In addition, `MaxHolds` is removed (as suggested
[here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573))
from `pallet_balances`, and its `Holds` are now bounded to
`RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let
the runtime specify `MaxHolds`.


## For reviewers

Relevant changes can be found here:
- `substrate/frame/support/procedural/src/lib.rs` 
-  `substrate/frame/support/procedural/src/pallet/parse/composite.rs`
-  `substrate/frame/support/procedural/src/pallet/expand/composite.rs`
-
`substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs`
-
`substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs`
-
`substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs`
- `substrate/frame/support/src/traits/misc.rs`

And the rest of the files is just about removed `MaxHolds` from
`pallet_balances`

## Next steps

Do the same for `MaxFreezes`
https://github.com/paritytech/polkadot-sdk/issues/2997.

---------

Co-authored-by: command-bot <>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Dónal Murray <donal.murray@parity.io>
Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com>
2024-01-31 06:19:16 +00:00
..
benchmarking
[frame] #[pallet::composite_enum] improved variant count handling + removed pallet_balances's MaxHolds config (#2657)
2024-01-31 06:19:16 +00:00
src
Switch All construct_runtimes to New Syntax (#2979)
2024-01-22 07:15:53 +00:00
Cargo.toml
Sync Cargo.toml and crates.io versions (#3034)
2024-01-26 18:14:03 +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()
}

Related Pallets

License: Apache-2.0

Reference in New Issue View Git Blame Copy Permalink