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 12 millionth block this was around 660 GB.
TIP
The Paranodes website lists the database sizes of Polkadot and Kusama nodes in real-time.
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.
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:
macOS
Windows
Linux
Install Homebrew within the terminal by running:
Then, run:
Install Rust in your terminal by running:
Once Rust is installed, run the following command to clone and build the polkadot code:
Start your node:
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.
Clone and Build
The paritytech/polkadot repo's master branch contains the latest Polkadot code.
Alternatively, if you wish to use a specific release, you can check out a specific tag (v0.8.3 in the example below):
Run
The built binary will be in the target/release folder, called polkadot.
Polkadot:
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:
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. Be aware that when you run polkadot in docker the process only listen on localhost by default. If you would like to connect to your node's services (rpc, websockets, and prometheus) you need to ensure that you run you node with the --rpc-external, --ws-external, and --prometheus-external commands.