Skip to main content

Set up a Full Node

If you're building dapps or products on a Substrate-based chain like Polkadot, Kusama or a custom Substrate implementation, you probably want the ability to run a node-as-a-back-end. After all, it's always better to rely on your own infrastructure than on a third-party-hosted one in this brave new decentralized world.

This guide will show you how to connect to Polkadot network, but the same process applies to any other Substrate-based chain. First, let's clarify the term full node.

Types of Nodes

A blockchain's growth comes from a genesis block, extrinsics, and events.

When a validator seals block 1, it takes the blockchain's state at block 0. It then applies all pending changes on top of it, and emits the events that are the result of these changes. Later, the state of the chain at block 1 is used in the same way to build the state of the chain at block 2, and so on. Once two thirds of the validators agree on a specific block being valid, it is finalized.

An archive node keeps all the past blocks. An archive node makes it convenient to query the past state of the chain at any point in time. Finding out what an account's balance at a certain block was, or which extrinsics resulted in a certain state change are fast operations when using an archive node. However, an archive node takes up a lot of disk space - around Kusama's 1.6 millionth block this was around 15 to 20GB.

Archive nodes are used by utilities that need past information - like block explorers, council scanners, discussion platforms like Polkassembly, and others. They need to be able to look at past on-chain data.

A full node is pruned: it discards all finalized blocks older than a configurable number except the genesis block: This is 256 blocks from the last finalized one, by default. A node that is pruned this way requires much less space than an archive node.

A full node may eventually be able to rebuild the entire chain with no additional information, and become an archive node, but at the time of writing, this is not implemented. If you need to query historical blocks past what you pruned, you need to purge your database and resync your node starting in archive mode. Alternatively you can use a backup or snapshot of a trusted source to avoid needing to sync from genesis with the network, and only need the blocks past that snapshot.

Full nodes allow you to read the current state of the chain and to submit and validate extrinsics directly on the network without relying on a centralized infrastructure provider.

Another type of node is a light node. A light node has only the runtime and the current state, but does not store past blocks and so cannot read historical data without requesting it from a node that has it. Light nodes are useful for resource restricted devices. An interesting use-case of light nodes is a Chrome extension, which is a node in its own right, running the runtime in WASM format as well as a full or light node that is completely encapsulated in WASM and can be integrated into webapps: https://github.com/paritytech/smoldot#wasm-light-node

Setup Instructions

This is not recommended if you're a validator. Please see the secure validator setup if you are running validator.

NOTE: The bash commands that are provided to run against your node use Polkadot as the default chain.

Use the --chain flag if you are following the setup instructions to setup a Kusama node. For example:

./target/release/polkadot --name "Your Node's Name" --chain kusama

  • Install Homebrew within the terminal by running:

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

  • Then, run:

    brew install openssl cmake llvm

  • Install Rust in your terminal by running:

    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

  • Once Rust is installed, run the following command to clone and build the polkadot code:

    git clone https://github.com/paritytech/polkadot polkadot
    cd polkadot
    ./scripts/init.sh
    cargo build --release

  • Start your node:

    ./target/release/polkadot --name "Your Node's Name"

  • Find your node on Telemetry

Get Substrate

Follow instructions as outlined here - note that Windows users will have their work cut out for them. It's better to use a virtual machine instead.

Test if the installation was successful by running cargo --version.

λ cargo --version
cargo 1.41.0 (626f0f40e 2019-12-03)

Clone and Build

The paritytech/polkadot repo's master branch contains the latest Polkadot code.

git clone https://github.com/paritytech/polkadot polkadot
cd polkadot
./scripts/init.sh
cargo build --release

Alternatively, if you wish to use a specific release, you can check out a specific tag (v0.8.3 in the example below):

git clone https://github.com/paritytech/polkadot polkadot
cd polkadot
git checkout tags/v0.8.3
./scripts/init.sh
cargo build --release

Run

The built binary will be in the target/release folder, called polkadot.

Polkadot:

./target/release/polkadot --name "Your Node's Name"

Use the --help flag to find out which flags you can use when running the node. For example, if connecting to your node remotely, you'll probably want to use --ws-external and --rpc-cors all.

The syncing process will take a while depending on your bandwidth, processing power, disk speed and RAM. On a \$10 DigitalOcean droplet, the process can complete in some 36 hours.

Congratulations, you're now syncing with Polkadot. Keep in mind that the process is identical when using any other Substrate chain.

Running an Archive Node

When running as a simple sync node (above), only the state of the past 256 blocks will be kept. When validating, it defaults to archive mode. To keep the full state use the --pruning flag:

Polkadot:

./target/release/polkadot --name "My node's name" --pruning archive

It is possible to almost quadruple synchronization speed by using an additional flag: --wasm-execution Compiled. Note that this uses much more CPU and RAM, so it should be turned off after the node is in sync.

Using Docker

Finally, you can use Docker to run your node in a container. Doing this is a bit more advanced so it's best left up to those that either already have familiarity with docker, or have completed the other set-up instructions in this guide. If you would like to connect to your node's WebSockets ensure that you run you node with the --rpc-external and --ws-external commands.

docker run -p 9944:9944 parity/polkadot:v0.8.24 --name "calling_home_from_a_docker_container" --rpc-external --ws-external