Andrew Jones
4c7539cab5
* Use beefy branch with scale-info * Add patches * Sprinkle some TypeInfo derives * Add some TypeInfo deriv * Cargo.lock * Derive TypeInfo and skip type params for Xcm types * Cargo.lock * Fix up scale_info bounds attributes * Fix up dependencies * Use my own beefy-primitives branch * Bump BEEFY * Update patches * Add some scale-info dependencies and TypeInfo derives * More TypeInfo decoration * Update scale-info * Some TypeInfos and remove more Event pallet::metadata * Moar TypeInfos * TypeInfos galore, fix up metadata runtime API * TypeInfo * TypeInfos, update other runtime metadata APIs * Fix up Kusama, comment out some `usize` QueueSize parameter types * Remove local diener patches * Cargo.lock * Cargo.lock * Update to scale-info crates.io release * Update primitive-types branch * Update pallet-beefy to use custom branch * Update other parity-common deps * Update parity-common patches * bump a bunch of deps in parity-common * Remove parity-common patches * Bump finality-grandpa version * Cargo.lock * Update scale-info to 0.9.1 * Add recursion_limit for runtime-parachains * Add some scale_info attributes * Cargo.lock * Revert finality-grandpa bump * Cargo.lock, scale-info update * cargo update * Make sure using patched version of finality-grandpa * Use patched scale-info * Update to scale-info 0.10.0 * Update finality-grandpa * Cargo.lock * Update beefy deps * Update beefy deps again * Add scale-info dependency * Remove deprecated pallet::metadata attributes. * Add some missing scale-info deps and derives * Use some variant struct call syntax * Add missing TypeInfo impl * Add some more TypeInfo impls * Convert some call enum struct variant constructors * More scale-info deps and derives * Call enum struct variants * TypeInfo derives * Call enum variant structs * scale-info deps and derives * Call enum variant struct constructors * Use beefy-primitives scale-info feature * Use grandpa-bridge-gadget master branch * Remove finality-grandpa patch * Add missing scale_info dependency and derive * Fix up some call variant constructors * Add missing scale_info dependency * Fix some test errors * More TypeInfo derives * More call variant structs * Call variant structs in tests * Cargo.lock * Fmt * Fix more call struct variants * Another call struct variant * add scale-info/std features explicitly * More call struct variants * Add missing scale-info dependency * Fmt * review: activate scale-info/std where missing * Remove some duplicate std feature activation * review: add scale_info bounds() attr * More call variant structs * Remove recursion limit * Update beefy-primitives * Update beefy-primitives * Fix simnet call variant struct errors * Fmt * cargo update -p beefy-primitives * Add some missing TypeInfo derives * Fix some call variants * Fix some call variant underscores * Cargo.lock * Cargo.lock * Add missing TypeInfo derive * Add some more missing TypeInfo derives * Even more missing TypeInfo derives * Add TypeInfo derives to new xcm types * Fmt * Cargo.lock * Add missing TypeInfo impls * Cargo.lock * More missing TypeInfos * Fixes * Cargo.lock * Cargo.lock * Add TypeInfo impls to xcm v2 * Update to scale-info 1.0 * Update finality-grandpa 0.14.4, patch for now * Update beefy * Remove patched finality-grandpa * Add TypeInfo impl to Outcome * Fixes * Call variant struct * Call variant struct * Fix test * Add TypeInfo impl * Cargo.lock * Cargo.lock * Cargo.lock * git checkout master Cargo.lock * update Substrate * Add missing scale-info features for beefy-primitives * Fmt * Remove check for now * Update beefy-primitives, removes scale-info feature * Update beefy-primitives again Co-authored-by: adoerr <0xad@gmx.net> Co-authored-by: Andronik Ordian <write@reusable.software> Co-authored-by: thiolliere <gui.thiolliere@gmail.com> Co-authored-by: parity-processbot <> Co-authored-by: Bastian Köcher <info@kchr.de>
Staking Miner
Substrate chains validators compute a basic solution for the NPoS election. The optimization of the solution is computing-intensive and can be delegated to the staking-miner. The staking-miner does not act as validator and focuses solely on the optimization of the solution.
The staking miner connects to a specified chain and keeps listening to new Signed phase of the pallet-election-provider-multi-phase in order to submit solutions to the NPoS election. When the correct time comes, it computes its solution and submit it to the chain. The default miner algorithm is sequential-phragmen] with a configurable number of balancing iterations that improve the score.
Running the staking-miner requires passing the seed of a funded account in order to pay the fees for the transactions that will be sent. The same account's balance is used to reserve deposits as well. The best solution in each round is rewarded. All correct solutions will get their bond back. Any invalid solution will lose their bond.
You can check the help with:
staking-miner --help
Building
You can build from the root of the Polkadot repository using:
cargo build --release --locked --package staking-miner
Docker
There are 2 options to build a staking-miner Docker image:
- injected binary: the binary is first built on a Linux host and then injected into a Docker base image. This method only works if you have a Linux host or access to a pre-built binary from a Linux host.
- multi-stage: the binary is entirely built within the multi-stage Docker image. There is no requirement on the host in terms of OS and the host does not even need to have any Rust toolchain installed.
Building the injected image
First build the binary as documented above. You may then inject the binary into a Docker base image usingfrom the root of the Polkadot repository:
docker build -t staking-miner -f scripts/docker/staking-miner/staking_miner-injected.Dockerfile target/release
Building the multi-stage image
Unlike the injected image that requires a Linux pre-built binary, this option does not requires a Linux host, nor Rust to be installed. The trade-off however is that it takes a little longer to build and this option is less ideal for CI tasks. You may build the multi-stage image the root of the Polkadot repository with:
docker build -t staking-miner -f scripts/docker/staking-miner/staking_miner-builder.Dockerfile .
Running
A Docker container, especially one holding one of your SEED should be kept as secure as possible.
While it won't prevent a malicious actor to read your SEED if they gain access to your container, it is nonetheless recommended running this container in read-only mode:
# The following line starts with an extra space on purpose:
SEED=0x1234...
docker run --rm -it \
--name staking-miner \
--read-only \
-e RUST_LOG=info \
-e SEED=$SEED \
-e URI=wss://your-node:9944 \
staking-miner dry-run