Validator
This page provides a general overview of the role of validators in the Polkadot network. For more detailed information you can read the Parachain Protocol Overview.
Validators secure the relay chain by staking native tokens, validating proofs from collators and participating in consensus with other validators.
Validators play a crucial role in adding new blocks to the relay chain and, by extension, to all parachains. This allows parties to complete cross-chain transactions via the relay chain. They guarantee that each parachain follows its unique rules and can pass messages between shards in a trust-free environment.
Para-validators
Parachain validators (i.e. para-validators) participate to the Parachain Phase of the AnV Protocol, and submit candidate receipts to the relay chain transaction queue so that a block author can include information on the parablock in a fork of of the relay chain.
Para-validators work in groups and are selected by the runtime in every epoch to validate parachain blocks for all parachains connected to the relay chain. The selected para-validators are part of the active validators randomly selected (per epoch) to participate in the validation, creating a validator pool of 200 para-validators.
Para-validators verify that the information contained in an assigned set of parachain blocks is valid. They receive parachain block candidates from the collators together with a Proof-of-Validity (PoV). The para-validators perform the first round of validity checks on the block candidates. Candidates that gather enough signed validity statements are considered backable.
Block Authors
There are validators on the relay chain who participate in the consensus mechanism to produce the relay chain blocks based on validity statements from other validators. These validators are called block authors, they are selected by BABE and can note up to one backable candidate for each parachain to include in the relay chain. A backable candidate included in the relay chain is considered backed in that fork of the chain.
In a relay chain block, block authors will only include candidate receipts that have a parent candidate receipt in an earlier relay chain block. This ensures the parachain follows a valid chain. Also, the block authors will only include a receipt for which they have an erasure coding chunk, ensuring that the system can perform the next round of availability and validity checks.
Other Validators
Validators also contribute to the so-called availability distribution. In fact, once the candidate is backed in a fork of the relay chain, it is still pending availability, i.e. it is not fully included (only tentative included) as part of the parachain until it is proven available (together with the PoV). Information regarding the availability of the candidate will be noted in the following relay chain blocks. Only when there is enough information, the candidate is considered a full parachain block or parablock.
Validators also participate in the so-called approval process. Once the parablock is considered available and part of the parachain, it is still pending approval. Because para-validators are a small subset of all validators, there is a risk that by chance the majority of para-validators assigned to a parachain might be dishonest. It is thus necessary to run a secondary verification of the parablock before it can be considered approved. Having a secondary verification step avoids the allocation of more para-validators that will ultimately reduce the throughput of the system.
Any instances of non-compliance with the consensus algorithms result in disputes with the punishment of the validators on the wrong side by removing some or all their staked tokens, thereby discouraging bad actors. Good performance, however, will be rewarded, with validators receiving block rewards (including transaction fees) in the form of native tokens (DOT or KSM on Kusama) in exchange for their activities.
Finally, validators participate in the chain selection process within GRANDPA, ensuring that only available and valid blocks end within the finalized relay chain.
Within the same era, a Validator can be a para-validator, block author, and participate in the availability distribution or the approval process. Those roles can change between sessions.
Further Readings
Guides
- How to Validate on Polkadot - Guide on how to set up a validator on the Polkadot live network.
- Validator Payout Overview - A short overview on how the validator payout mechanism works.
- How to run your validator as a systemd process -
Guide on running your validator as a
systemd
process so that it will run in the background and start automatically on reboots. - How to Upgrade your Validator - Guide for securely upgrading your validator when you want to switch to a different machine or begin running the latest version of client code.
- How to Use Validator Setup - Guide on how to use Polkadot / Kusama validator setup.
Other References
- How to run a Polkadot node (Docker)
- A Serverless Failover Solution for Web3.0 Validator Nodes - Blog that details how to create a robust failover solution for running validators.
- VPS list
- Polkadot Validator Lounge - A place to chat about being a validator.
- Slashing Consequences - Learn more about slashing consequences for running a validator node.
- Why You Should be A Validator on Polkadot and Kusama
- Roles and Responsibilities of a Validator
- Validating on Polkadot - An explanation of how to validate on Polkadot, with Joe Petrowski and David Dorgan of Parity Technologies, along with Tim Ogilvie from Staked.
Security / Key Management
Monitoring Tools
- PANIC for Polkadot - A monitoring and alerting solution for Polkadot / Kusama node
- Polkadot Telemetry Service - Network information, including what nodes are running on a given chain, what software versions they are running, and sync status.
Validator Stats
- Polkastats - Polkastats is a cleanly designed dashboard for validator statistics.
- Subscan Validators Page - Displays information on the current validators - not as tailored for validators as the other sites.