Michal Kucharczyk
7a10154188
* BlockId removal: refactor of runtime API It changes the arguments of: - `ApiExt` methods: `has_api`, `has_api_with`, `api_version` - `CallApiAt` method: `runtime_version_at` from: `BlockId<Block>` to: `Block::Hash` It also changes the first argument of all generated runtime API calls from: `BlockId<Block>` to: `Block::Hash` This PR is part of BlockId::Number refactoring analysis (paritytech/substrate#11292) * BlockId removal: refactor of runtime API - tests - tests adjusted to new runtime API, - some tests migrated from block number to block hash * benchmarking-cli: BlockId(0) migrated to info().genesis_hash `runtime_api.call()` now requires the block hash instead of BlockId::Number. To access the genesis hash widely used in benchmarking engine the Client was constrained to satisfy `sp_blockchain::HeaderBackend<Block>` trait which provides `info().genesis_hash`. * trivial: api.call(BlockId) -> api.call(Hash) - Migrated all `runtime_api.calls` to use Hash - Noteworthy (?): -- `validate_transaction_blocking` in transaction pool, * CallApiAtParams::at changed to Block::Hash * missed doc updated * Apply suggestions from code review Co-authored-by: Bastian Köcher <git@kchr.de> * ".git/.scripts/commands/fmt/fmt.sh" * BlockId removal: Benchmark::consumed_weight Little refactor around `Benchmark::consumed_weight`: `BlockId` removed. * at_hash renamed * wrong merge fixed * beefy worker: merged with master * beefy: tests: missing block problem fixed * Apply review suggestion * fix --------- Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: command-bot <>
Proof of work consensus for Substrate.
To use this engine, you can need to have a struct that implements
PowAlgorithm. After that, pass an instance of the struct, along
with other necessary client references to import_queue to setup
the queue.
This library also comes with an async mining worker, which can be
started via the start_mining_worker function. It returns a worker
handle together with a future. The future must be pulled. Through
the worker handle, you can pull the metadata needed to start the
mining process via MiningWorker::metadata, and then do the actual
mining on a standalone thread. Finally, when a seal is found, call
MiningWorker::submit to build the block.
The auxiliary storage for PoW engine only stores the total difficulty.
For other storage requirements for particular PoW algorithm (such as
the actual difficulty for each particular blocks), you can take a client
reference in your PowAlgorithm implementation, and use a separate prefix
for the auxiliary storage. It is also possible to just use the runtime
as the storage, but it is not recommended as it won't work well with light
clients.
License: GPL-3.0-or-later WITH Classpath-exception-2.0