Removal of execution strategies

[bkchr]

This pull request is about removing the execution strategies. The execution strategy was determining how a runtime call would be executed, e.g. only use the wasm runtime, only use the native or a combination of both. Based on the context of the runtime call (block import, block building etc) the execution strategy could be configured. So, a node could for example use the native runtime for building a block and then use the wasm runtime to import blocks. Just because the execution strategy was saying to use the native runtime, it didn't mean that we would use the native runtime all the time. For example when the native runtime doesn't match the wasm runtime a runtime call could not use the native runtime as this could lead to nondeterministic behavior. If not changed by the user via CLI the default execution strategy for all contexts is already set to wasm only.

In the light of removing the native runtime choosing the execution strategy will be irrelevant as the only strategy to choose would be "wasm only". This pull requests should be seen as preparation for making sp-api not compile time dependent on the native runtime.

Behavior changes of the runtime api

When calling into the runtime using the runtime api (sp-api) there was always the possibility to register execution extensions. These execution extensions would then be accessible from any host function. Before this pull request based on the context given to the runtime call there could have been passed custom "capabilities". These capabilities determined which kind of execution extensions the runtime call could access. The default context for every runtime call was OffchainCall with no explicit capabilities. This meant that the runtime call had access to the read from the offchain database, use the keystore and to submit a transaction to the transaction pool. All of this isn't available by default anymore. This means when you have some code that wants to submit a transaction from a runtime call, the transaction pool needs to be registered manually as execution extension for the runtime api instance. The runtime api instance now provides the register_extension function for registering these execution extensions. These execution extensions will then be available for the entire lifetime of the runtime api instance, aka for all calls done via this instance. This is another behavior change which now also keeps the execution extensions "alive" while building a block (because this keeps internally the runtime api instance alive). The "global" execution extensions factory also still exists, but should only be used to initialize execution extensions that need to be available for every runtime call. For simplifying the creation of a transaction pool execution extension this pull requests introduces OffchainTransactionPoolFactory. This factory can be used to instantiate instances of the transaction pool extension at given blocks. The pull requests shows how to use them in the BABE and Grandpa client crates.

Removal of build_offchain_workers

To spawn offchain workers the sc-service crate provided the function build_offchain_workers. This function was any reference to sc-offchain was removed from the sc-service crate. First, this makes the sc-service crate less "god-like" and secondly makes the initialization of the offchain worker more "obvious" to the user. To spawn the offchain worker, the following code needs to be added to the service file:

if enable_offchain_worker {
	task_manager.spawn_handle().spawn(
		"offchain-workers-runner",
		"offchain-work",
		sc_offchain::OffchainWorkers::new(sc_offchain::OffchainWorkerOptions {
			runtime_api_provider: client.clone(),
			keystore: Some(keystore_container.keystore()),
			offchain_db: backend.offchain_storage(),
			transaction_pool: Some(OffchainTransactionPoolFactory::new(
				transaction_pool.clone(),
			)),
			network_provider: network.clone(),
			is_validator: role.is_authority(),
			enable_http_requests: true,
			custom_extensions: move |_| {
				vec![]
			},
		})
		.run(client.clone(), task_manager.spawn_handle())
		.boxed(),
	);
}

This provides a way to provide all the required objects that will then be available as execution extension from the offchain_worker call in the runtime. The custom_extensions is a closure that will be called every time the offchain_worker should be called and can return custom execution extensions that should be made available.

Changes to Grandpa and BABE client crates

The sc-consensus-grandpa crate now requires the parameter offchain_tx_pool_factory in GrandpaParams. This will be used by grandpa when there is an equivocation report to submit the transaction from the runtime.

The sc-consensus-babe crate changes the signature of import_queue to receive the dedicated ImportQueueParams. These parameters have named args to make it more obvious what each of them is doing. It also gets the offchain tx pool factory passed which it will use when sending an equivocation report.

CLI args deprecation

The following CLI args are now deprecated:

• --execution-syncing
• --execution-import-block
• --execution-block-construction
• --execution-offchain-worker
• --execution-other
• --execution

All of these CLI args are still present, but the node will print an error if the user passes them. In the future these will be removed.

polkadot companion: paritytech/polkadot#7443
cumulus companion: paritytech/cumulus#2836

[jasl]

node-template not integrate statement-store, so this seems not necessary.

[bkchr]

Good find! Ty