Files
pezkuwi-subxt/polkadot
Peter Goodspeed-Niklaus 21cec309a4 implement provisioner (#1473)
* sketch out provisioner basics

* handle provisionable data

* stub out select_inherent_data

* split runtime APIs into sub-chapters to improve linkability

* explain SignedAvailabilityBitfield semantics

* add internal link to further documentation

* some more work figuring out how the provisioner can do its thing

* fix broken link

* don't import enum variants where it's one layer deep

* make request_availability_cores a free fn in util

* document more precisely what should happen on block production

* finish first-draft implementation of provisioner

* start working on the full and proper backed candidate selection rule

* Pass number of block under construction via RequestInherentData

* Revert "Pass number of block under construction via RequestInherentData"

This reverts commit 850fe62cc0dfb04252580c21a985962000e693c8.

That initially looked like the better approach--it spent the time
budget for fetching the block number in the proposer, instead of
the provisioner, and that felt more appropriate--but it turns out
not to be obvious how to get the block number of the block under
construction from within the proposer. The Chain API may be less
ideal, but it should be easier to implement.

* wip: get the block under production from the Chain API

* add ChainApiMessage to AllMessages

* don't break the run loop if a provisionable data channel closes

* clone only those backed candidates which are coherent

* propagate chain_api subsystem through various locations

* add delegated_subsystem! macro to ease delegating subsystems

Unfortunately, it doesn't work right:

```
error[E0446]: private type `CandidateBackingJob` in public interface
   --> node/core/backing/src/lib.rs:775:1
    |
86  | struct CandidateBackingJob {
    | - `CandidateBackingJob` declared as private
...
775 | delegated_subsystem!(CandidateBackingJob as CandidateBackingSubsystem);
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak private type
```

I'm not sure precisely what's going wrong, here; I suspect the problem is
the use of `$job as JobTrait>::RunArgs` and `::ToJob`; the failure would be
that it's not reifying the types to verify that the actual types are public,
but instead referring to them via `CandidateBackingJob`, which is in fact private;
that privacy is the point.

Going to see if I can generic my way out of this, but we may be headed for a
quick revert here.

* fix delegated_subsystem

The invocation is a bit more verbose than I'd prefer, but it's also
more explicit about what types need to be public. I'll take it as a win.

* add provisioning subsystem; reduce public interface of provisioner

* deny missing docs in provisioner

* refactor core selection per code review suggestion

This is twice as much code when measured by line, but IMO it is
in fact somewhat clearer to read, so overall a win.

Also adds an improved rule for selecting availability bitfields,
which (unlike the previous implementation) guarantees that the
appropriate postconditions hold there.

* fix bad merge double-declaration

* update guide with (hopefully) complete provisioner candidate selection procedure

* clarify candidate selection algorithm

* Revert "clarify candidate selection algorithm"

This reverts commit c68a02ac9cf42b3a4a28eb197d38633a40d0e3e6.

* clarify candidate selection algorithm

* update provisioner to implement candidate selection per the guide

* add test that no more than one bitfield is selected per validator

* add test that each selected bitfield corresponds to an occupied core

* add test that more set bits win conflicts

* add macro for specializing runtime requests; specailize all runtime requests

* add tests harness for select_candidates tests

* add first real select_candidates test, fix test_harness

* add mock overseer and test that success is possible

* add test that the candidate selection algorithm picks the right ones

* make candidate selection test somewhat more stringent
2020-08-06 18:12:15 +02:00
..
2020-05-25 18:34:04 -04:00
2020-08-06 18:12:15 +02:00
2020-08-04 14:53:47 +02:00
2020-08-06 18:12:15 +02:00
2020-08-06 18:12:15 +02:00
2020-04-07 12:08:53 +02:00
2020-04-13 18:48:51 +02:00
2018-08-15 13:57:46 +02:00
2020-08-06 18:12:15 +02:00
2020-08-06 18:12:15 +02:00
2019-09-30 14:39:24 +02:00

Polkadot

Implementation of a https://polkadot.network node in Rust based on the Substrate framework.

NOTE: In 2018, we split our implementation of "Polkadot" from its development framework "Substrate". See the Substrate repo for git history prior to 2018.

This repo contains runtimes for the Polkadot, Kusama, and Westend networks. The README provides information about installing the polkadot binary and developing on the codebase. For more specific guides, like how to be a validator, see the Polkadot Wiki.

Building

Use a Provided Binary

If you want to connect to one of the networks supported by this repo, you can go to the latest release and download the binary that is provided.

Install via Cargo

If you want to install Polkadot in your PATH, you can do so with with:

cargo install --git https://github.com/paritytech/polkadot --tag <version> polkadot

Build from Source

If you'd like to build from source, first install Rust. You may need to add Cargo's bin directory to your PATH environment variable. Restarting your computer will do this for you automatically.

curl https://sh.rustup.rs -sSf | sh

If you already have Rust installed, make sure you're using the latest version by running:

rustup update

Once done, finish installing the support software:

sudo apt install build-essential git clang libclang-dev pkg-config libssl-dev

Build the client by cloning this repository and running the following commands from the root directory of the repo:

git checkout <latest tagged release>
./scripts/init.sh
cargo build --release

Networks

This repo supports runtimes for Polkadot, Kusama, and Westend.

Connect to Polkadot Mainnet

Connect to the global Polkadot Mainnet network by running:

./target/release/polkadot --chain=polkadot

You can see your node on telemetry (set a custom name with --name "my custom name").

Connect to the "Kusama" Canary Network

Connect to the global Kusama canary network by running:

./target/release/polkadot --chain=kusama

You can see your node on telemetry (set a custom name with --name "my custom name").

Connect to the Westend Testnet

Connect to the global Westend testnet by running:

./target/release/polkadot --chain=westend

You can see your node on telemetry (set a custom name with --name "my custom name").

Obtaining DOTs

If you want to do anything on Polkadot, Kusama, or Westend, then you'll need to get an account and some DOT, KSM, or WND tokens, respectively. See the claims instructions for Polkadot if you have DOTs to claim. For Westend's WND tokens, see the faucet instructions on the Wiki.

Hacking on Polkadot

If you'd actually like hack on Polkadot, you can grab the source code and build it. Ensure you have Rust and the support software installed. This script will install or update Rust and install the required dependencies (this may take up to 30 minutes on Mac machines):

curl https://getsubstrate.io -sSf | bash -s -- --fast

Then, grab the Polkadot source code:

git clone https://github.com/paritytech/polkadot.git
cd polkadot

Then build the code. You will need to build in release mode (--release) to start a network. Only use debug mode for development (faster compile times for development and testing).

./scripts/init.sh   # Install WebAssembly. Update Rust
cargo build # Builds all native code

You can run the tests if you like:

cargo test --all

You can start a development chain with:

cargo run -- --dev

Detailed logs may be shown by running the node with the following environment variables set:

RUST_LOG=debug RUST_BACKTRACE=1 cargo run----dev

Development

You can run a simple single-node development "network" on your machine by running:

polkadot --dev

You can muck around by heading to https://polkadot.js.org/apps and choose "Local Node" from the Settings menu.

Local Two-node Testnet

If you want to see the multi-node consensus algorithm in action locally, then you can create a local testnet. You'll need two terminals open. In one, run:

polkadot --chain=polkadot-local --alice -d /tmp/alice

And in the other, run:

polkadot --chain=polkadot-local --bob -d /tmp/bob --port 30334 --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE'

Ensure you replace ALICE_BOOTNODE_ID_HERE with the node ID from the output of the first terminal.

Using Docker

Using Docker

Shell Completion

Shell Completion

Contributing

Contributing Guidelines

Contribution Guidelines

Contributor Code of Conduct

Code of Conduct

License

Polkadot is GPL 3.0 licensed.

Important Notice

https://polkadot.network/testnetdisclaimer