Validating on Polkadot network

A consensus mechanism is a mechanism that ensures to achieve the necessary agreement on the state of the network over distributed processes or multi-agent network. Nodes that form the network have to come to an agreement in order to move forward and build the state of the blockchain. In other words, consensus is about how to create blocks and how to agree on what is the correct set of blocks.

Hybrid consensus

In short BABE is responsible for producing blocks and assigning their authoring while GRANDPA is responsible for finalizing chains.

We talk about both of these acronyms because Polkadot uses what is known as hybrid consensus. Hybrid consensus splits up the finality gadget from the block production mechanism.

More about Polkadot consensus can be found here

GRANDPA

GRANDPA reaches an agreement (commits) exclusively on chains rather than blocks. Thanks to GRANDPA a whole chain of blocks can be produced and finalized at once.

When a block on a given chain receives a super majority vote (more than ⅔ ), all blocks leading up to it are finalized at once, as votes are transitively applied to all of its ancestors. Also, GRANDPA has the ability to finalize a block regardless of how many blocks have been produced since the last finalized one.

The key insight behind GRANDPA is the idea of incorporating the blockchain’s structure into the consensus algorithm. One piece of intuition is that considering a block valid implies considering that block’s parent valid, and so on. Here is a simplified explanation of the algorithm: rather than voting on a single block, we allow participants to vote on the highest block they think is valid, and the algorithm transitively applies the vote to all ancestors of that block. The algorithm then determines the best block which has a >⅔ supermajority amount of votes, and produces a proof-of-finality. The proof-of-finality is constructed by taking the supermajority votes, and bundling them up together into a single message. Signature aggregation can be used to make this smaller.

BABE

Block Author selection: In Polkadot, time is broken up into 6 seconds slots and each slot has a slot leader. A primary slot leader is chosen via VRF -Verifiably Random Function- to author a block. Because of the randomness of VRF, multiple validator can be selected for a given slot, or in some cases a slot can remain empty (no validator selected). To avoid an empty slot, a secondary slot leader is chosen to produce a block through round robin algorithm. If there are multiple leaders chosen by VRF for a given slot, the first leader to produce, broadcast and whose block reaches most of the network wins the block authoring.

Fork choice: As mentioned earlier BABE is responsible for block producing. When new blocks are produced and there are forks, BABE chooses to build on the longest chain with most primary blocks.

There are two main rules:

  • Deterministic: BABE always adds newly produced block on top of GRANDPA’s finalized chain
  • Probabilistic: BABE builds on with the most primary blocks
https://wiki.polkadot.network/docs/en/learn-consensus#fork-choice

In this example Although Chain A, B and C are on last GRANDPA’s finalized block (in black) , the chain that BABE chooses to add a block to is chain B, as it is the longest chain with most primary blocks. Chain D has been excluded as it is not on top of the GRANDPA finalized chain.

Note: Primary blocks are the blocks produced by a slot leader via VRF while secondary blocks are the one produced via round robin. Primary blocks always ‘outweigh’ secondary blocks when they are produced for the same slot.

ERAs and Epochs

https://www.youtube.com/watch?v=-PSPfbAcpiQ&t=1271s

GRANDPA has ERAs and sessions. An ERA is about 1 day and gets broken up into six four hours session, While BABE has epochs and slots. An epoch consists of a whole bunch of different slots and they are exactly six seconds long. There are 2400 slots in each epoch.

Sometimes an epoch can end up with less than 2400 blocks. This is due to slots that end up empty, because sometimes a validator can just miss his turn or produce a block on a fork.

Rewards

So for example, If a validator wins the election at the beginning of ERA 1, he will be a validator from session 2 of ERA1 through session 1 of ERA 2 and then the new validator set will take over on session 2 of ERA 2

Nominated proof of stake

First step is to maximize the amount at stake, and the second is to optimize the distribution of the stake among selected validators.

Let’s say for example you have nominated some people and some of them are in the validator set, but some are not. Phragmen is going to shift all the nomination to the set of validator to maximize the amount at stake. Then, it optimizes distribution among the set of chosen validators in order to achieve the most even possible distribution.

During each ERA, validators in the active set accumulates points. They are primarily awarded for authoring new block and sending commit message to finalize chains. There are also some point awarded for producing uncle blocks but most points are awarded for producing block that end up in the main chain and for finalizing chains.

Rewards are paid based on points not on amount at stake unlike most other DPOS networks. So even if a validator has twice as much at stake than another validator he will get the same reward.

Rewards are distributed to nominator on a pro rata basis. (how much you have at stake behind a specific validator compared to others). Validators can also set a commision which is deducted from the rewards before being distributed to their nominators.

Slashing

  • Being offline: Any validator has to be online and produce blocks in an era or session and the easiest way to prove it is to simply produce a block. However, there is actually a chance that a validator could never be selected to produce a block during a session. In this case the ‘iamonline’ session key is used on the background to sign a message called heartbeat that proves that he is online.
  • GRANDPA equivocation: equivocating in GRANDPA refers to the action of voting on two blocks that are in different chains.
  • BABE equivocation: equivocating in BABE refers to producing two primary blocks instead of one when a validator wins a slot and he is it’s primary author.
  • Unjustified votes: It is when a validator votes for a block that conflicts with the chain that has already been finalized.

Superlinear slashing

Slashing is adjusted depending on how many validators commit an offense. The penalty is more severe depending on how many validators commit an offense. If 2 validators commit an offence the slashing will be less than if 5 people commit an offence.

Note: Nominators get slashed too, so anyone who wishes to nominate a validator will need to be careful when choosing him.

Account abstraction

Controller Account: You can set preferences like how much commision you’d like to take, your payment destination so you pay you reward to either your stash account to increase your amount at stake or your controller. Set session keys or change them, start and stop validating, and set your nomination. You can do all these things without using your stash key to sign messages which , as said earlier, put your funds at risk.

Proxy Account: For governance purposes it is recommended to set up a proxy account which will vote on behalf of your stash account. It is similar to the controller account but is only used for governance not validation.

More info about Polkadot accounts can be found here.

Session Keys

Note: remote signing is in the roadmap, and once available Session keys won’t have to be kept in the client’s key store

  • BABE session key (Sr25519): Used to run VRF(Verifiably Random Function)to select primary slot leaders
  • GRANDPA session key(Ed25519): Used to sign votes
  • Iamonline session key (Sr25519): Used for signing the heartbeat message.
  • ParachainID session key (Sr25519): Used to match validator with parachain

Session keys can be generated whether on the polkadot apps RPC or via CLI. To start validating on polkadot, the chain has to know about a particular validator’s session keys. This is done through submitting an extrinsic on polkadot apps which will associate a particular validator with his Controller account.

Support InchainWorks on Kusama Network by nominating us. Our validator address is: DbAdiLJQDFzLyaLsoFCzrpBLuaBXXqQKdpewUSxqiWJadmp