mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-04-29 20:47:56 +00:00

Files

T

Peter Goodspeed-Niklaus 44d5aba80d Create a macro which automates creation of benchmark test suites. (#8104 )

* Create a macro which automates creation of benchmark test suites.

* bump impl_version

* allow unused on test_bench_by_name

* use proper doctest ignore attribute

* Explicitly hand the Module to the test suite

Much better practice than depending on it showing up implicitly in
the namespace.

* explicitly import what we need into `mod tests`

* bench_module is `ident` not `tt`

Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

* allow end users to specify arguments for new_test_ext

This turned out to be surprisingly easy. On reflection, it turns out
that of course the compiler can't eagerly evaluate the function call,
but needs to paste it in everywhere desired.

* enable explicitly specifying the path to the benchmarks invocation

also enable optional trailing commas

* Revert "bump impl_version"

This reverts commit 0209e4de33fd43873f8cfc6875815d0fd6151e63.

* list failing benchmark tests and the errors which caused the failure

* harden benchmark tests against internal panics

* suppress warning about ignored profiles

unfortunately, setting the profile here doesn't do anything; we'd
need to set it in every leaf package anyway. However, as this was
just making the default explicit anyway, I think it's safe enough
to remove entirely.

* impl_benchmark_test_suite for assets

* impl_benchmark_test_suite for balances

* impl_benchmark_test_suite for bounties

* impl_benchmark_test_suite for Collective

* impl_benchmark_test_suite for Contracts

* impl_benchmark_test_suite for Democracy

* don't impl_benchmark_test_suite for Elections-Phragmen

* impl_benchmark_test_suite for Identity

Note that Identity tests currently fail. They failed in an identical
way before this change, so as far as I'm concerned, the status quo is
good enough for now.

* impl_benchmark_test_suite for ImOnline

* impl_benchmark_test_suite for indices

For this crate also, the test suite fails identically with and without
this change, so we can say that this change is not the cause of the
tests' failure to compile.

* impl_benchmark_test_suite for lottery

* impl_benchmark_test_suite for merkle-mountain-range

* impl_benchmark_test_suite for Multisig

These tests fail identically with and without the change, so the change
seems unlikely to be the origin of the failures.

* impl_benchmark_test_suite for offences

* impl_benchmark_test_suite for Proxy

Fails identically with and without this change.

* impl_benchmark_test_suite for scheduler

* impl_benchmark_test_suite for session

It turns out to be important to be able to exclude items marked
`#[extra]` sometimes. Who knew?

* impl_benchmark_test_suite for staking

* impl_benchmark_test_suite for system

* impl_benchmark_test_suite for timestamp

* impl_benchmark_test_suite for tips

* impl_benchmark_test_suite for treasury

* impl_benchmark_test_suite for utility

Note that benchmark tests fail identically before and after this change.

* impl_benchmark_test_suite for vesting

* fix wrong module name in impl_benchmark_test_suite in Offences

* address line length nits

* enable optional keyword argument: exec_name

Took a _lot_ of macro-wrangling to get the functionality that I want,
but now you have the option to pass in

```rust
impl_benchmark_test_suite!(
	Elections,
	crate::tests::ExtBuilder::default().desired_members(13).desired_runners_up(7),
	crate::tests::Test,
	exec_name = build_and_execute,
);
```

and have it expand out properly. A selected fragment of the expansion:

```rust
        fn test_benchmarks() {
            crate::tests::ExtBuilder::default()
                .desired_members(13)
                .desired_runners_up(7)
                .build_and_execute(|| {
```

* get rid of dead code

Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

2021-02-16 10:01:20 +01:00

benchmarking

Create a macro which automates creation of benchmark test suites. (#8104 )

2021-02-16 10:01:20 +01:00

src

Switch to latest impl-trait-for-tuples (#8082 )

2021-02-09 13:31:44 +01:00

Cargo.toml

Releasing 3.0 (#8098 )

2021-02-10 19:23:18 +01:00

README.md

Fix CI Link Check (#7639 )

2020-11-30 22:01:18 +00:00

README.md

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 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::Module<T>>::validators()
}

Staking

License: Apache-2.0

README.md

Session Module

Overview

Terminology

Goals

Interface

Dispatchable Functions

Public Functions

Usage

Example from the FRAME

Related Modules