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

Markdown linter (#1309)

Browse Source 
* Add markdown linting

- add linter default rules
- adapt rules to current code
- fix the code for linting to pass
- add CI check

fix #1243

* Fix markdown for Substrate
* Fix tooling install
* Fix workflow
* Add documentation
* Remove trailing spaces
* Update .github/.markdownlint.yaml

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix mangled markdown/lists
* Fix captalization issues on known words
This commit is contained in:
Chevdor
2023-09-04 11:02:32 +02:00
committed by GitHub
parent 830fde2a60
commit a30092ab42
271 changed files with 6289 additions and 4450 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/utils/staking-miner/README.md
+24 -13
View File
@@ -1,11 +1,19 @@
# 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.
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](https://crates.parity.io/pallet_election_provider_multi_phase/index.html) 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](https://crates.parity.io/sp_npos_elections/phragmen/fn.seq_phragmen_core.html)] with a configurable number of balancing iterations that improve the score.
The staking miner connects to a specified chain and keeps listening to new Signed phase of the
[pallet-election-provider-multi-phase](https://crates.parity.io/pallet_election_provider_multi_phase/index.html) 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](https://crates.parity.io/sp_npos_elections/phragmen/fn.seq_phragmen_core.html)] 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.
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:
```
@@ -22,13 +30,15 @@ cargo build --profile production --locked --package staking-miner --bin staking-
## 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.
- 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](#building).
You may then inject the binary into a Docker base image: `parity/base-bin` (running the command from the root of the Polkadot repository):
First build the binary as documented [above](#building). You may then inject the binary into a Docker base image:
`parity/base-bin` (running the command from the root of the Polkadot repository):
```
TODO: UPDATE THAT
docker build -t staking-miner -f scripts/ci/dockerfiles/staking-miner/staking-miner_injected.Dockerfile target/release
@@ -36,9 +46,9 @@ docker build -t staking-miner -f scripts/ci/dockerfiles/staking-miner/staking-mi
### 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:
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:
```
TODO: UPDATE THAT
docker build -t staking-miner -f scripts/ci/dockerfiles/staking-miner/staking-miner_builder.Dockerfile .
@@ -46,8 +56,9 @@ docker build -t staking-miner -f scripts/ci/dockerfiles/staking-miner/staking-mi
### 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:
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: