mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-09 20:11:09 +00:00
frame-benchmarking-cli: Remove native dispatch requirement (#14474)
* 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:
Generated
+3
@@ -2600,11 +2600,13 @@ dependencies = [
|
||||
"sp-database",
|
||||
"sp-externalities",
|
||||
"sp-inherents",
|
||||
"sp-io",
|
||||
"sp-keystore",
|
||||
"sp-runtime",
|
||||
"sp-state-machine",
|
||||
"sp-storage",
|
||||
"sp-trie",
|
||||
"sp-wasm-interface",
|
||||
"thiserror",
|
||||
"thousands",
|
||||
]
|
||||
@@ -5353,6 +5355,7 @@ dependencies = [
|
||||
"sp-keyring",
|
||||
"sp-keystore",
|
||||
"sp-runtime",
|
||||
"sp-statement-store",
|
||||
"sp-timestamp",
|
||||
"sp-tracing",
|
||||
"sp-transaction-storage-proof",
|
||||
|
||||
@@ -124,7 +124,7 @@ pub fn run() -> sc_cli::Result<()> {
|
||||
)
|
||||
}
|
||||
|
||||
cmd.run::<Block, service::ExecutorDispatch>(config)
|
||||
cmd.run::<Block, ()>(config)
|
||||
},
|
||||
BenchmarkCmd::Block(cmd) => {
|
||||
let PartialComponents { client, .. } = service::new_partial(&config)?;
|
||||
|
||||
@@ -58,6 +58,7 @@ sp-keystore = { version = "0.27.0", path = "../../../primitives/keystore" }
|
||||
sp-consensus = { version = "0.10.0-dev", path = "../../../primitives/consensus/common" }
|
||||
sp-transaction-storage-proof = { version = "4.0.0-dev", path = "../../../primitives/transaction-storage-proof" }
|
||||
sp-io = { path = "../../../primitives/io" }
|
||||
sp-statement-store = { path = "../../../primitives/statement-store" }
|
||||
|
||||
# client dependencies
|
||||
sc-client-api = { version = "4.0.0-dev", path = "../../../client/api" }
|
||||
|
||||
@@ -117,7 +117,7 @@ pub fn run() -> Result<()> {
|
||||
)
|
||||
}
|
||||
|
||||
cmd.run::<Block, ExecutorDispatch>(config)
|
||||
cmd.run::<Block, sp_statement_store::runtime_api::HostFunctions>(config)
|
||||
},
|
||||
BenchmarkCmd::Block(cmd) => {
|
||||
// ensure that we keep the task manager alive
|
||||
|
||||
@@ -1152,10 +1152,10 @@ where
|
||||
// Verification for imported blocks is skipped in two cases:
|
||||
// 1. When importing blocks below the last finalized block during network initial
|
||||
// synchronization.
|
||||
// 2. When importing whole state we don't calculate epoch descriptor, but rather
|
||||
// read it from the state after import. We also skip all verifications
|
||||
// because there's no parent state and we trust the sync module to verify
|
||||
// that the state is correct and finalized.
|
||||
// 2. When importing whole state we don't calculate epoch descriptor, but rather read it
|
||||
// from the state after import. We also skip all verifications because there's no
|
||||
// parent state and we trust the sync module to verify that the state is correct and
|
||||
// finalized.
|
||||
return Ok(block)
|
||||
}
|
||||
|
||||
|
||||
@@ -78,11 +78,11 @@ pub(crate) struct VoterOracle<B: Block> {
|
||||
///
|
||||
/// There are three voter states coresponding to three queue states:
|
||||
/// 1. voter uninitialized: queue empty,
|
||||
/// 2. up-to-date - all mandatory blocks leading up to current GRANDPA finalized:
|
||||
/// queue has ONE element, the 'current session' where `mandatory_done == true`,
|
||||
/// 2. up-to-date - all mandatory blocks leading up to current GRANDPA finalized: queue has ONE
|
||||
/// element, the 'current session' where `mandatory_done == true`,
|
||||
/// 3. lagging behind GRANDPA: queue has [1, N] elements, where all `mandatory_done == false`.
|
||||
/// In this state, everytime a session gets its mandatory block BEEFY finalized, it's
|
||||
/// popped off the queue, eventually getting to state `2. up-to-date`.
|
||||
/// In this state, everytime a session gets its mandatory block BEEFY finalized, it's popped
|
||||
/// off the queue, eventually getting to state `2. up-to-date`.
|
||||
sessions: VecDeque<Rounds<B>>,
|
||||
/// Min delta in block numbers between two blocks, BEEFY should vote on.
|
||||
min_block_delta: u32,
|
||||
|
||||
@@ -84,19 +84,17 @@ use std::{
|
||||
/// the API of this behaviour and towards the peerset manager is aggregated in
|
||||
/// the following way:
|
||||
///
|
||||
/// 1. The enabled/disabled status is the same across all connections, as
|
||||
/// decided by the peerset manager.
|
||||
/// 2. `send_packet` and `write_notification` always send all data over
|
||||
/// the same connection to preserve the ordering provided by the transport,
|
||||
/// as long as that connection is open. If it closes, a second open
|
||||
/// connection may take over, if one exists, but that case should be no
|
||||
/// different than a single connection failing and being re-established
|
||||
/// in terms of potential reordering and dropped messages. Messages can
|
||||
/// be received on any connection.
|
||||
/// 3. The behaviour reports `NotificationsOut::CustomProtocolOpen` when the
|
||||
/// first connection reports `NotifsHandlerOut::OpenResultOk`.
|
||||
/// 4. The behaviour reports `NotificationsOut::CustomProtocolClosed` when the
|
||||
/// last connection reports `NotifsHandlerOut::ClosedResult`.
|
||||
/// 1. The enabled/disabled status is the same across all connections, as decided by the peerset
|
||||
/// manager.
|
||||
/// 2. `send_packet` and `write_notification` always send all data over the same connection to
|
||||
/// preserve the ordering provided by the transport, as long as that connection is open. If it
|
||||
/// closes, a second open connection may take over, if one exists, but that case should be no
|
||||
/// different than a single connection failing and being re-established in terms of potential
|
||||
/// reordering and dropped messages. Messages can be received on any connection.
|
||||
/// 3. The behaviour reports `NotificationsOut::CustomProtocolOpen` when the first connection
|
||||
/// reports `NotifsHandlerOut::OpenResultOk`.
|
||||
/// 4. The behaviour reports `NotificationsOut::CustomProtocolClosed` when the last connection
|
||||
/// reports `NotifsHandlerOut::ClosedResult`.
|
||||
///
|
||||
/// In this way, the number of actual established connections to the peer is
|
||||
/// an implementation detail of this behaviour. Note that, in practice and at
|
||||
|
||||
@@ -402,9 +402,9 @@ pub trait NetworkNotification {
|
||||
/// a receiver. With a `NotificationSender` at hand, sending a notification is done in two
|
||||
/// steps:
|
||||
///
|
||||
/// 1. [`NotificationSender::ready`] is used to wait for the sender to become ready
|
||||
/// 1. [`NotificationSender::ready`] is used to wait for the sender to become ready
|
||||
/// for another notification, yielding a [`NotificationSenderReady`] token.
|
||||
/// 2. [`NotificationSenderReady::send`] enqueues the notification for sending. This operation
|
||||
/// 2. [`NotificationSenderReady::send`] enqueues the notification for sending. This operation
|
||||
/// can only fail if the underlying notification substream or connection has suddenly closed.
|
||||
///
|
||||
/// An error is returned by [`NotificationSenderReady::send`] if there exists no open
|
||||
|
||||
@@ -192,12 +192,10 @@ pub struct Finalized<Hash> {
|
||||
/// The event generated by the `follow` method.
|
||||
///
|
||||
/// The events are generated in the following order:
|
||||
/// 1. Initialized - generated only once to signal the
|
||||
/// latest finalized block
|
||||
/// 1. Initialized - generated only once to signal the latest finalized block
|
||||
/// 2. NewBlock - a new block was added.
|
||||
/// 3. BestBlockChanged - indicate that the best block
|
||||
/// is now the one from this event. The block was
|
||||
/// announced priorly with the `NewBlock` event.
|
||||
/// 3. BestBlockChanged - indicate that the best block is now the one from this event. The block was
|
||||
/// announced priorly with the `NewBlock` event.
|
||||
/// 4. Finalized - State the finalized and pruned blocks.
|
||||
#[derive(Debug, Clone, PartialEq, Serialize, Deserialize)]
|
||||
#[serde(rename_all = "camelCase")]
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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))]
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
//!
|
||||
|
||||
@@ -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:
|
||||
///
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
//!
|
||||
//! Given a committee `A` and an edge weight vector `w`, a balanced solution is one that
|
||||
//!
|
||||
//! 1. it maximizes the sum of member supports, i.e `Argmax { sum(support(c)) }`. for all `c` in
|
||||
//! 1. it maximizes the sum of member supports, i.e `Argmax { sum(support(c)) }`. for all `c` in
|
||||
//! `A`.
|
||||
//! 2. it minimizes the sum of supports squared, i.e `Argmin { sum(support(c).pow(2)) }` for all `c`
|
||||
//! in `A`.
|
||||
|
||||
@@ -343,10 +343,10 @@ impl Response {
|
||||
/// A buffered byte iterator over response body.
|
||||
///
|
||||
/// Note that reading the body may return `None` in following cases:
|
||||
/// 1. Either the deadline you've set is reached (check via `#error`;
|
||||
/// In such case you can resume the reader by setting a new deadline)
|
||||
/// 2. Or because of IOError. In such case the reader is not resumable and will keep
|
||||
/// returning `None`.
|
||||
/// 1. Either the deadline you've set is reached (check via `#error`; In such case you can resume
|
||||
/// the reader by setting a new deadline)
|
||||
/// 2. Or because of IOError. In such case the reader is not resumable and will keep returning
|
||||
/// `None`.
|
||||
/// 3. The body has been returned. The reader will keep returning `None`.
|
||||
#[derive(Clone)]
|
||||
pub struct ResponseBody {
|
||||
|
||||
@@ -220,16 +220,16 @@ pub struct OffenceDetails<Reporter, Offender> {
|
||||
/// for a typical usage scenario:
|
||||
///
|
||||
/// 1. An offence is detected and an evidence is submitted on-chain via the
|
||||
/// [`OffenceReportSystem::publish_evidence`] method. This will construct
|
||||
/// and submit an extrinsic transaction containing the offence evidence.
|
||||
/// [`OffenceReportSystem::publish_evidence`] method. This will construct and submit an extrinsic
|
||||
/// transaction containing the offence evidence.
|
||||
///
|
||||
/// 2. If the extrinsic is unsigned then the transaction receiver may want to
|
||||
/// perform some preliminary checks before further processing. This is a good
|
||||
/// place to call the [`OffenceReportSystem::check_evidence`] method.
|
||||
/// 2. If the extrinsic is unsigned then the transaction receiver may want to perform some
|
||||
/// preliminary checks before further processing. This is a good place to call the
|
||||
/// [`OffenceReportSystem::check_evidence`] method.
|
||||
///
|
||||
/// 3. Finally the report extrinsic is executed on-chain. This is where the user
|
||||
/// calls the [`OffenceReportSystem::process_evidence`] to consume the offence
|
||||
/// report and enact any required action.
|
||||
/// 3. Finally the report extrinsic is executed on-chain. This is where the user calls the
|
||||
/// [`OffenceReportSystem::process_evidence`] to consume the offence report and enact any
|
||||
/// required action.
|
||||
pub trait OffenceReportSystem<Reporter, Evidence> {
|
||||
/// Longevity, in blocks, for the evidence report validity.
|
||||
///
|
||||
|
||||
@@ -51,6 +51,8 @@ sp-runtime = { version = "24.0.0", path = "../../../primitives/runtime" }
|
||||
sp-state-machine = { version = "0.28.0", path = "../../../primitives/state-machine" }
|
||||
sp-storage = { version = "13.0.0", path = "../../../primitives/storage" }
|
||||
sp-trie = { version = "22.0.0", path = "../../../primitives/trie" }
|
||||
sp-io = { version = "23.0.0", path = "../../../primitives/io" }
|
||||
sp-wasm-interface = { version = "14.0.0", path = "../../../primitives/wasm-interface" }
|
||||
gethostname = "0.2.3"
|
||||
|
||||
[features]
|
||||
|
||||
@@ -27,8 +27,8 @@ use sc_cli::{
|
||||
execution_method_from_cli, CliConfiguration, ExecutionStrategy, Result, SharedParams,
|
||||
};
|
||||
use sc_client_db::BenchmarkingState;
|
||||
use sc_executor::{NativeElseWasmExecutor, WasmExecutor};
|
||||
use sc_service::{Configuration, NativeExecutionDispatch};
|
||||
use sc_executor::WasmExecutor;
|
||||
use sc_service::Configuration;
|
||||
use serde::Serialize;
|
||||
use sp_core::{
|
||||
offchain::{
|
||||
@@ -143,11 +143,11 @@ not created by a node that was compiled with the flag";
|
||||
|
||||
impl PalletCmd {
|
||||
/// Runs the command and benchmarks the chain.
|
||||
pub fn run<BB, ExecDispatch>(&self, config: Configuration) -> Result<()>
|
||||
pub fn run<BB, ExtraHostFunctions>(&self, config: Configuration) -> Result<()>
|
||||
where
|
||||
BB: BlockT + Debug,
|
||||
<<<BB as BlockT>::Header as HeaderT>::Number as std::str::FromStr>::Err: std::fmt::Debug,
|
||||
ExecDispatch: NativeExecutionDispatch + 'static,
|
||||
ExtraHostFunctions: sp_wasm_interface::HostFunctions,
|
||||
{
|
||||
if let Some(output_path) = &self.output {
|
||||
if !output_path.is_dir() && output_path.file_name().is_none() {
|
||||
@@ -182,7 +182,7 @@ impl PalletCmd {
|
||||
}
|
||||
|
||||
let spec = config.chain_spec;
|
||||
let strategy = self.execution.unwrap_or(ExecutionStrategy::Native);
|
||||
let strategy = self.execution.unwrap_or(ExecutionStrategy::Wasm);
|
||||
let pallet = self.pallet.clone().unwrap_or_default();
|
||||
let pallet = pallet.as_bytes();
|
||||
let extrinsic = self.extrinsic.clone().unwrap_or_default();
|
||||
@@ -212,13 +212,15 @@ impl PalletCmd {
|
||||
let method =
|
||||
execution_method_from_cli(self.wasm_method, self.wasmtime_instantiation_strategy);
|
||||
|
||||
let executor = NativeElseWasmExecutor::<ExecDispatch>::new_with_wasm_executor(
|
||||
WasmExecutor::builder()
|
||||
.with_execution_method(method)
|
||||
.with_max_runtime_instances(2)
|
||||
.with_runtime_cache_size(2)
|
||||
.build(),
|
||||
);
|
||||
let executor = WasmExecutor::<(
|
||||
sp_io::SubstrateHostFunctions,
|
||||
frame_benchmarking::benchmarking::HostFunctions,
|
||||
ExtraHostFunctions,
|
||||
)>::builder()
|
||||
.with_execution_method(method)
|
||||
.with_max_runtime_instances(2)
|
||||
.with_runtime_cache_size(2)
|
||||
.build();
|
||||
|
||||
let extensions = || -> Extensions {
|
||||
let mut extensions = Extensions::default();
|
||||
|
||||
@@ -80,8 +80,8 @@ impl WasmBuilderSelectProject {
|
||||
///
|
||||
/// 1. Call [`WasmBuilder::new`] to create a new builder.
|
||||
/// 2. Select the project to build using the methods of [`WasmBuilderSelectProject`].
|
||||
/// 3. Set additional `RUST_FLAGS` or a different name for the file containing the WASM code
|
||||
/// using methods of [`WasmBuilder`].
|
||||
/// 3. Set additional `RUST_FLAGS` or a different name for the file containing the WASM code using
|
||||
/// methods of [`WasmBuilder`].
|
||||
/// 4. Build the WASM binary using [`Self::build`].
|
||||
pub struct WasmBuilder {
|
||||
/// Flags that should be appended to `RUST_FLAGS` env variable.
|
||||
|
||||
Reference in New Issue
Block a user