Skip to main content

Validator

info

This page provides a general overview of the role of validators in Kusama. For more detailed information you can read the Parachain Protocol Overview.

Validators secure the relay chain by staking KSM, 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 one of 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 KSM, thereby discouraging bad actors. Good performance, however, will be rewarded, with validators receiving block rewards (including transaction fees) in the form of KSM 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 an era roles can change

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โ€‹

Other Referencesโ€‹

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โ€‹

  • HashQuark Staking Strategy - The HashQuark staking strategy dashboard helps you choose the optimal set-up to maximize rewards, and provides other useful network monitoring tools.
  • Polkastats - Polkastats is a cleanly designed dashboard for validator statistics.
  • YieldScan - Staking yield maximization platform, designed to minimize effort.
  • Subscan Validators Page - Displays information on the current validators - not as tailored for validators as the other sites.