* Add subsystem-util crate.
Start by moving the JobCanceler here.
* copy utility functions for requesting runtime data; generalize
* convert subsystem-util from crate to module in subsystem
The point of making a sub-crate is to ensure that only the necessary
parts of a program get compiled; if a dependent package needed only
subsystem-util, and not subsystem, then subsystem wouldn't need to
be compiled.
However, that will never happen: subsystem-util depends on
subsystem::messages, so subsystem will always be compiled.
Therefore, it makes more sense to add it as a module in the existing
crate than as a new and distinct crate.
* make runtime request sender type generic
* candidate backing subsystem uses util for api requests
* add struct Validator representing the local validator
This struct can be constructed when the local node is a validator;
the constructor fails otherwise. It stores a bit of local data, and
provides some utility methods.
* add alternate constructor for better efficiency
* refactor candidate backing to use utility methods
* fix test breakage caused by reordering tests
* restore test which accidentally got deleted during merge
* start extracting jobs management into helper traits + structs
* use util::{JobHandle, Jobs} in CandidateBackingSubsystem
* implement generic job-manager subsystem impl
This means that the work of implementing a subsystem boils down
to implementing the job, and then writing an appropriate
type definition, i.e.
pub type CandidateBackingSubsystem<Spawner, Context> =
util::JobManager<Spawner, Context, CandidateBackingJob>;
* add hash-extraction helper to messages
* fix errors caused by improper rebase
* doc improvement
* simplify conversion from overseer communication to job message
* document fn hash for all messages
* rename fn hash() -> fn relay_parent
* gracefully shut down running futures on Conclude
* ensure we're validating with the proper validator index
* rename: handle_unhashed_msg -> handle_orphan_msg
* impl Stream for Jobs<Spawner, Job>
This turns out to be relatively complicated and requires some
unsafe code, so we'll want either detailed review, or to choose
to revert this commit.
* add missing documentation for public items
* use pin-project to eliminate unsafe code from this codebase
* rename SenderMessage -> FromJob
* reenvision the subsystem requests as an extension trait
This works within `util.rs`, but fails in `core/backing/src/lib.rs`,
because we don't actually create the struct soon enough. Continuing
down this path would imply substantial rewriting.
* Revert "reenvision the subsystem requests as an extension trait"
This reverts commit a5639e36017a72656b478caddcaa30e2d4e6112a.
The fact is, the new API is more complicated to no real benefit.
* apply suggested futuresunordered join_all impl
* CandidateValidationMessage variants have no top-level relay parents
* rename handle_orphan_msg -> handle_unanchored_msg
* make most node-core-backing types private
Now the only public types exposed in that module are
CandidateBackingSubsystem and ToJob. While ideally we could reduce
the public interface to only the former type, that doesn't work
because ToJob appears in the public interface of CandidateBackingSubsystem.
This also involves changing the definition of CandidateBackingSubsystem;
it is no longer a typedef, but a struct wrapping the job manager.
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 --force --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 make clang 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 Chain Candidate 1 (CC1)
Connect to the global Polkadot CC1 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
Shell Completion
Contributing
Contributing Guidelines
Contributor Code of Conduct
License
Polkadot is GPL 3.0 licensed.