* network bridge skeleton
* move some primitives around and add debug impls
* protocol registration glue & abstract network interface
* add send_msgs to subsystemctx
* select logic
* transform different events into actions and handle
* implement remaining network bridge state machine
* start test skeleton
* make network methods asynchronous
* extract subsystem out to subsystem crate
* port over overseer to subsystem context trait
* fix minimal example
* fix overseer doc test
* update network-bridge crate
* write a subsystem test-helpers crate
* write a network test helper for network-bridge
* set up (broken) view test
* Revamp network to be more async-friendly and not require Sync
* fix spacing
* fix test compilation
* insert side-channel for actions
* Add some more message types to AllMessages
* introduce a test harness
* impl ProvideInherent for InclusionInherent
* reduce import churn; correct expect message
* move inclusion inherent identifier into primitives
It's not clear precisely why this is desired, but it's a pattern
I've seen in several places, so I'm going this to be on the
safe side. Worst case, we can revert this commit pretty easily.
* bump kusama spec_version to placate CI
* copy sc_basic_authorship::{ProposerFactory, Proposer}
We have from the problem description:
> This Proposer will require an OverseerHandle to make requests via.
That's next on the plate.
* use polkadot custom proposer instead of basic-authorship one
* add some tests
* ensure service compiles and passes tests
* fix typo
* fix service-new compilation
* Subsystem test helpers send messages synchronously
* remove smelly action inspector
* remove superfluous let binding
* fix warnings
* add license header
* empty commit; maybe github will notice the one with changes
* Update node/network/bridge/src/lib.rs
Co-authored-by: Peter Goodspeed-Niklaus <coriolinus@users.noreply.github.com>
* add sanity check to only include valid inherents
* stub: encapsulate block production mechanics instead of copying them
The goal is to end up with something like what's in
validation::block_production::*, which encapsulates
basic block production mechanics. This is a better idea than
just straight-up copying those mechanics.
* partial implementation of propose fn
Doesn't actually compile yet; need to bring in some other
commits to ensure ProvisionerMessage is a thing, and also
figure out how to get the block hash given the current
context.
* fix compilation
* clear a few more compile errors
* finish fn propose
* broken: add timeout to proposal
* add timeout to proposal
* guide: provisioner is responsible for selecting parachain candidates
* implement ProvisionerMessage::RequestInherentData & update fn propose
* impl CreateProposer::init; clean up
* impl std::error::Error for Error
* document error-handling rationale
* cause polkadot-service-new to compile correctly
* Move potentially-blocking call from fn init -> fn propose
This means that we can wrap the delayed call into the same
timeout check used elsewhere.
* document struct Proposer
* extract provisioner data fetch
This satisfies two requirements:
- only applies the timeout to actually fetching the provisioner data,
not to constructing the block after
- simplifies the problem of injecting default data if we could not
get the real provisioner data in time.
Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
Co-authored-by: Gavin Wood <gavin@parity.io>
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.