pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-13 14:01:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

frame-benchmarking-cli: Remove native dispatch requirement (#14474)

Browse Source 
* frame-benchmarking-cli: Remove native dispatch requirement

No need for this, we can just use the `WasmExecutor` directly.

* Fixes

* Pass benchmarking host functions

* Ensure we can pass custom host functions
This commit is contained in:
Bastian Köcher
2023-06-29 17:56:25 +02:00
committed by GitHub
parent 0e58bd91b6
commit 83caca85b6
20 changed files with 117 additions and 119 deletions
Download Patch File Download Diff File Expand all files Collapse all files
substrate/frame/benchmarking/src/lib.rs
+11 -12
View File
@@ -246,22 +246,21 @@ pub use v1::*;
/// of impls and structs required by the benchmarking engine. Additionally, a benchmark
/// function is also generated that resembles the function definition you provide, with a few
/// modifications:
/// 1. The function name is transformed from i.e. `original_name` to `_original_name` so as not
/// to collide with the struct `original_name` that is created for some of the benchmarking
/// engine impls.
/// 2. Appropriate `T: Config` and `I` (if this is an instance benchmark) generics are added to
/// the function automatically during expansion, so you should not add these manually on
/// your function definition (but you may make use of `T` and `I` anywhere within your
/// benchmark function, in any of the three sections (setup, call, verification).
/// 1. The function name is transformed from i.e. `original_name` to `_original_name` so as not to
/// collide with the struct `original_name` that is created for some of the benchmarking engine
/// impls.
/// 2. Appropriate `T: Config` and `I` (if this is an instance benchmark) generics are added to the
/// function automatically during expansion, so you should not add these manually on your
/// function definition (but you may make use of `T` and `I` anywhere within your benchmark
/// function, in any of the three sections (setup, call, verification).
/// 3. Arguments such as `u: Linear<10, 100>` are converted to `u: u32` to make the function
/// directly callable.
/// 4. A `verify: bool` param is added as the last argument. Specifying `true` will result in
/// the verification section of your function executing, while a value of `false` will skip
/// 4. A `verify: bool` param is added as the last argument. Specifying `true` will result in the
/// verification section of your function executing, while a value of `false` will skip
/// verification.
/// 5. If you specify a return type on the function definition, it must conform to the [rules
/// below](#support-for-result-benchmarkerror-and-the--operator), and the last statement of
/// the function definition must resolve to something compatible with `Result<(),
/// BenchmarkError>`.
/// below](#support-for-result-benchmarkerror-and-the--operator), and the last statement of the
/// function definition must resolve to something compatible with `Result<(), BenchmarkError>`.
///
/// The reason we generate an actual function as part of the expansion is to allow the compiler
/// to enforce several constraints that would otherwise be difficult to enforce and to reduce
substrate/frame/contracts/src/schedule.rs
+14 -15
View File
@@ -145,21 +145,20 @@ impl Limits {
/// There there is one field for each wasm instruction that describes the weight to
/// execute one instruction of that name. There are a few exceptions:
///
/// 1. If there is a i64 and a i32 variant of an instruction we use the weight
/// of the former for both.
/// 2. The following instructions are free of charge because they merely structure the
/// wasm module and cannot be spammed without making the module invalid (and rejected):
/// End, Unreachable, Return, Else
/// 3. The following instructions cannot be benchmarked because they are removed by any
/// real world execution engine as a preprocessing step and therefore don't yield a
/// meaningful benchmark result. However, in contrast to the instructions mentioned
/// in 2. they can be spammed. We price them with the same weight as the "default"
/// instruction (i64.const): Block, Loop, Nop
/// 4. We price both i64.const and drop as InstructionWeights.i64const / 2. The reason
/// for that is that we cannot benchmark either of them on its own but we need their
/// individual values to derive (by subtraction) the weight of all other instructions
/// that use them as supporting instructions. Supporting means mainly pushing arguments
/// and dropping return values in order to maintain a valid module.
/// 1. If there is a i64 and a i32 variant of an instruction we use the weight of the former for
/// both.
/// 2. The following instructions are free of charge because they merely structure the wasm module
/// and cannot be spammed without making the module invalid (and rejected): End, Unreachable,
/// Return, Else
/// 3. The following instructions cannot be benchmarked because they are removed by any real world
/// execution engine as a preprocessing step and therefore don't yield a meaningful benchmark
/// result. However, in contrast to the instructions mentioned in 2. they can be spammed. We
/// price them with the same weight as the "default" instruction (i64.const): Block, Loop, Nop
/// 4. We price both i64.const and drop as InstructionWeights.i64const / 2. The reason for that is
/// that we cannot benchmark either of them on its own but we need their individual values to
/// derive (by subtraction) the weight of all other instructions that use them as supporting
/// instructions. Supporting means mainly pushing arguments and dropping return values in order
/// to maintain a valid module.
#[cfg_attr(feature = "std", derive(Serialize, Deserialize))]
#[derive(Clone, Encode, Decode, PartialEq, Eq, ScheduleDebug, TypeInfo)]
#[scale_info(skip_type_params(T))]
substrate/frame/im-online/src/lib.rs
+1 -1
View File
@@ -656,7 +656,7 @@ impl<T: Config> Pallet<T> {
//
// At index `idx`:
// 1. A (ImOnline) public key to be used by a validator at index `idx` to send im-online
// heartbeats.
// heartbeats.
let authorities = Keys::<T>::get();
// local keystore
substrate/frame/recovery/src/lib.rs
+22 -26
View File
@@ -48,34 +48,30 @@
//! ### Recovery Life Cycle
//!
//! The intended life cycle of a successful recovery takes the following steps:
//! 1. The account owner calls `create_recovery` to set up a recovery configuration
//! for their account.
//! 2. At some later time, the account owner loses access to their account and wants
//! to recover it. Likely, they will need to create a new account and fund it with
//! enough balance to support the transaction fees and the deposit for the
//! recovery process.
//! 3. Using this new account, they call `initiate_recovery`.
//! 4. Then the account owner would contact their configured friends to vouch for
//! the recovery attempt. The account owner would provide their old account id
//! and the new account id, and friends would call `vouch_recovery` with those
//! parameters.
//! 5. Once a threshold number of friends have vouched for the recovery attempt,
//! the account owner needs to wait until the delay period has passed, starting
//! when they initiated the recovery process.
//! 6. Now the account owner is able to call `claim_recovery`, which subsequently
//! allows them to call `as_recovered` and directly make calls on-behalf-of the lost
//! 1. The account owner calls `create_recovery` to set up a recovery configuration for their
//! account.
//! 7. Using the now recovered account, the account owner can call `close_recovery`
//! on the recovery process they opened, reclaiming the recovery deposit they
//! placed.
//! 2. At some later time, the account owner loses access to their account and wants to recover it.
//! Likely, they will need to create a new account and fund it with enough balance to support the
//! transaction fees and the deposit for the recovery process.
//! 3. Using this new account, they call `initiate_recovery`.
//! 4. Then the account owner would contact their configured friends to vouch for the recovery
//! attempt. The account owner would provide their old account id and the new account id, and
//! friends would call `vouch_recovery` with those parameters.
//! 5. Once a threshold number of friends have vouched for the recovery attempt, the account owner
//! needs to wait until the delay period has passed, starting when they initiated the recovery
//! process.
//! 6. Now the account owner is able to call `claim_recovery`, which subsequently allows them to
//! call `as_recovered` and directly make calls on-behalf-of the lost account.
//! 7. Using the now recovered account, the account owner can call `close_recovery` on the recovery
//! process they opened, reclaiming the recovery deposit they placed.
//! 8. Then the account owner should then call `remove_recovery` to remove the recovery
//! configuration on the recovered account and reclaim the recovery configuration
//! deposit they placed.
//! 9. Using `as_recovered`, the account owner is able to call any other pallets
//! to clean up their state and reclaim any reserved or locked funds. They
//! can then transfer all funds from the recovered account to the new account.
//! 10. When the recovered account becomes reaped (i.e. its free and reserved
//! balance drops to zero), the final recovery link is removed.
//! configuration on the recovered account and reclaim the recovery configuration deposit they
//! placed.
//! 9. Using `as_recovered`, the account owner is able to call any other pallets to clean up their
//! state and reclaim any reserved or locked funds. They can then transfer all funds from the
//! recovered account to the new account.
//! 10. When the recovered account becomes reaped (i.e. its free and reserved balance drops to
//! zero), the final recovery link is removed.
//!
//! ### Malicious Recovery Attempts
//!
substrate/frame/support/src/lib.rs
+8 -8
View File
@@ -2708,13 +2708,13 @@ pub mod pallet_prelude {
/// - query the metadata using the `state_getMetadata` RPC and curl, or use `subsee -p
/// <PALLET_NAME> > meta.json`
/// 2. Generate the template upgrade for the pallet provided by `decl_storage` with the
/// environment variable `PRINT_PALLET_UPGRADE`: `PRINT_PALLET_UPGRADE=1 cargo check -p
/// my_pallet`. This template can be used as it contains all information for storages,
/// genesis config and genesis build.
/// environment variable `PRINT_PALLET_UPGRADE`: `PRINT_PALLET_UPGRADE=1 cargo check -p
/// my_pallet`. This template can be used as it contains all information for storages,
/// genesis config and genesis build.
/// 3. Reorganize the pallet to have the trait `Config`, `decl_*` macros,
/// [`ValidateUnsigned`](`pallet_prelude::ValidateUnsigned`),
/// [`ProvideInherent`](`pallet_prelude::ProvideInherent`), and Origin` all together in one
/// file. Suggested order:
/// [`ValidateUnsigned`](`pallet_prelude::ValidateUnsigned`),
/// [`ProvideInherent`](`pallet_prelude::ProvideInherent`), and Origin` all together in one
/// file. Suggested order:
/// * `Config`,
/// * `decl_module`,
/// * `decl_event`,
@@ -2774,8 +2774,8 @@ pub mod pallet_prelude {
/// 8. **migrate error**: rewrite it with attribute
/// [`#[pallet::error]`](#error-palleterror-optional).
/// 9. **migrate storage**: `decl_storage` provide an upgrade template (see 3.). All storages,
/// genesis config, genesis build and default implementation of genesis config can be
/// taken from it directly.
/// genesis config, genesis build and default implementation of genesis config can be taken
/// from it directly.
///
/// Otherwise here is the manual process:
///