The hitchhiker’s series by Cryptium Labs aims to provide the reader with the most essential things one should know about a Proof-of-Stake network in a succinct article. It is written without any previous knowledge requirements about the latter, so readers who are currently or will be interacting with the network do so in an informed manner and with better understanding.
The topics covered range from an introduction to the Polkadot protocol, its consensus mechanism(s), its novel sybil resistance mechanism (Nominated Proof-of-Stake), its governance mechanism, as well as an overview of the network’s ecosystem– explained with the stress on the economic and security implications for Polkadot nominators, as well as validators.
What is Polkadot?
Polkadot is a public blockchain protocol project, the reference node implementation of which is written in Rust, an increasingly popular programming language characterised by its focus on performance and safety. Unlike cryptocurrency protocols such as Bitcoin, or smart contract platforms such as ethereum or Tezos, the Polkadot network does not grant any functionalities at all. The purpose of Polkadot’s relay chain purpose is to not only foster heterogeneous blockchains (parachains), but even abstract state transition functions that do not necessarily share the distinct features of a blockchain. In order to serve as a substratum for the latter, the network is equipped with two main qualities: shared security (aka pooled security) and trust-less interchain transactability among the different programs.
Polkadot’s Hybrid Consensus
One of the major innovations of Polkadot is its shared security. In order to enable shared security, Polkadot’s architecture strongly relies on its peculiar hybrid consensus system.
A crucial aspect of Polkadot’s hybrid consensus system is that it distinguishes between the functions of block production and finality: the mechanism that produces blocks (BABE) is not the same mechanism that is deployed to finalise blocks (GRANDPA).
Blind Assignment for Blockchain Extension (BABE) is Polkadot’s block production mechanism and it specifies the set of rules by which new blocks on Polkadot are authored. BABE is a variant of the family of longest-chain consensus algorithms and is akin to Cardano’s Ouroboros Praos consensus mechanism. GHOST-based Recursive ANcestor Deriving Prefix Agreement (GRANDPA) is a finality gadget, an overlay on top of the relay chain that implements its own variant of BFT consensus: a block is finalised if at least 2/3 of the validator set have provided an attestation for the validity of a specific block.
Polkadot’s hybrid consensus aims to mitigate the tradeoff between liveness and provable finality. Most networks deploy either a variant of longest chain consensus (PoW or PoS system that mimic the dynamics of Nakamoto Consensus) or a pure BFT-consensus mechanism. A downside of the former is that consensus is only able to provide probabilistic finality. A downside of the latter, exemplified by the deployment of a pure Tendermint-based consensus algorithm, is that a certain threshold of nodes being unresponsive can cause the network to halt. Polkadot’s design of hybrid consensus is theoretically able to tolerate up to 1/3 of Byzantine nodes in partial synchrony, and up to 1/5 Byzantine nodes in asynchrony.
Polkadot’s Nominated Proof-of-Stake (NPoS)
In Polkadot, the mechanism that establishes the rules and requirements for a node to participate in consensus is named Nominated Proof-of-Stake. Compared to other variants, such as Tezos’ LPoS or Cosmos Network’s BPoS, NPoS is divergent in the following components:
- Similar to other PoS systems, validator slots are allocated via a lottery-like system.
- Inflation is 10% (for the first year), of which 100% are allocated to all validators should 50% of all DOT be at stake.
- Remaining inflation resulting from any positive or negative variations from 50% of DOTs globally at stake are allocated to the Polkadot treasury (governance-managed spendable community pool).
- The set is fixed, at the time of writing this is 50, albeit can be expanded (up to 1,000).
- Validators can increase their stake by soliciting nominators.
- Rewards are distributed equally among all validators in the set.
- Validators can set a fee (%) that will be automatically deducted from the rewards corresponding to their nominators.
- The slashing conditions (levels) are defined as follows: 1) going offline for a determined amount of time is punished via removal of this validator from the consensus set (chilling); 2) going offline subsequently after a determined number of occurrences is penalised via a slashed lower % of the stake in addition to chilling; 3) isolated safety faults or double-signatures on GRANDPA leads to a moderate % of stake being slashed in addition to chilling; 4) validators involved in correlated safety fault occurrences, which may indicate collusion, are subject to losing the majority or the totality of their stake, in addition to dropping out of consensus.
To calculate the potential losses of one or a group of validators that commit a safety fault on BABE or GRANDPA, consider the following formula:
x = offenders
n = total no. validatorsPenalty = Min( ( 3 * x / n ) ^ 2, 1 )
Let’s make a few examples:
x = 33
n = 100Penalty = Min( ( 3 * 33 / 100 ) ^ 2, 1 ) = 0.9801 (98.01%)
The 33 offenders will lose 98.01 % of their stake.
x = 10
n = 100Penalty = Min( ( 3 * 10 / 100 ) ^ 2, 1 ) = 0.09 (9%)
The 10 offenders lose 9% of their stake.
x = 1
n = 100Penalty = Min( ( 3 * 1 / 100 ) ^ 2, 1 ) = 0.0009 (0.09%)
The single offender loses 0.09% of their stake.
As you might have realised, the slashing percentage grows exponentially with every additional simultaneous offender involved in a specific safety fault. This is designed to discourage collusion among validators as much as possible, as the safety in GRANDPA (and any variant of BFT consensus algorithms) is only guaranteed given that at least 2/3 of the set are non malicious.
In other words, an incident where 1/3 of the validating set commits a fault is substantially more dangerous for the network than an incident where a single validator committed a fault.
- DOT holders who do not want to operate a validating node themselves can nominate 1–16 validators.
- Unlike in LPoS, but similar to BPoS, nominations are at stake. Nominators’ DOTs are proportionally subject to the liveness and safety penalties, should the chosen validator(s) commit a liveness and/or safety fault.
- Nominators’ rewards are automatically calculated pro-rata (service fees are also automatically deducted) and distributed to the nominators’ accounts.
- Nominators are able to claim their rewards by interacting with a client that supports such functionality.
- After staking, a nominator can stop staking by submitting an unbonding transaction. Afterwards, the DOTs will be locked for ~28 days before they are accessible.
Polkadot’s Governance Mechanism
Comparable to other networks that deploy a form of on-chain governance, such as Tezos or Cosmos, Polkadot’s governance mechanism aims to ensure that changes to the existing network can only be adopted when the majority of the DOT stakeholders desire so. Grosso modo, Polkadot’s governance system has two bodies that can make binding decisions on proposals: the council and the public.
The council is an on-chain organism with 23 fixed seats, members of which are elected via the Phragmén’s election method (the same as the one through which validator slots are allocated). The Polkadot council is able to make decisions on a limited type of proposals (e.g. treasury spending or reversing a level 1 or 2 slashing events) without involvement of the public. For a proposal to be adopted, it must be voted favourably by the strict majority and 0 vetoes. Such events are referred to as council motions. Diagram I illustrates the process of a proposal that has been proposed by the council and successfully undergone its council motion:
The public is composed of all the DOT holders on the network. Anyone who holds enough DOTs for the initial deposit is able to submit a proposal. Unlike proposals submitted by the council, the public has no restrictions on the class of proposals.
Once a proposal is submitted, other DOT holders that wish to signal their agreement with the latter can deposit DOTs. As the public is able to suggest more than one proposal at a time, every proposal is added to a queue, out of which one proposal, the top proposal or the one that attracted the highest amount of stake bonded, proceeds to its referendum. During a referendum, the public is able to cast a vote aye or nay on the proposal. The Super-Majority Approve tallying method is applied on public referenda. Simply put, this tallying method requires a higher amount of aye votes the lower the turnout. Diagram II illustrates the process of a proposal submitted by the public, which successfully passed its referendum:
Dual Governance Mechanism
Above we described the process of a council-submitted proposal undergoing a successful council motion, and the process of a public-submitted proposal undergoing a successful referendum. Nonetheless, Polkadot’s governance system accounts for several additional scenarios and cases that involve the participation of both the council and the public.
- The council is able to cancel a referendum if it deems the proposal to be uncontroversially dangerous or malicious for the Polkadot network or a critical flaw in the proposal is discovered. In such case, a 2/3 majority vote of the council can cancel a referendum (Diagram III).
- The council is able to submit proposals that go beyond treasury spending or reversing a level 1 or 2 slashing events. However, such proposals have to undergo both a council motion, as well as a referendum. Furthermore, the applied tallying method for the proposals referendum is dependant on the result of the council motion: Super-Majority Against is applied if the motion reached a complete agreement (Diagram IV); Simple-Majority is applied if the motion resulted in a majority agreement (Diagram V).
The Polkadot Ecosystem
The Web3.0 Foundation
Web3.0 Technologies Stiftung is based in Zug, Switzerland. Web3.0 Foundation has the mandate to research, develop, apply and maintain technologies that form the “Web3.0” tech stack, including the Polkadot network. In alignment with their mandate, the Web3.0 Foundation launched a grants program to fund research and development.
- Wallets and their status
- Available block explorers are Polkadot-JS, Polkascan, and subscan (for Substrate-based chains)
About Cryptium Labs
Cryptium Labs is a security-oriented validator operated by protocol researchers and engineers. The company was funded in summer 2018 and has since successfully secured Tezos since July 2018, IRISnet and the Cosmos Network since March 2019 among others on mainnet. Cryptium Labs has not only relentlessly secured the Kusama Network since its launch in August 2019, but has continuously tested and provided developer feedback throughout the developer releases of Polkadot.
- Check out the networks secured in mainnet and testnets
- Learn about our security architecture
- Our Kusama and Polkadot portal (WIP)
- Join our community on Discord
Interested in Nominating Cryptium Labs on Polkadot?
Drop us an email to email@example.com to subscribe to the Kusama/Polkadot mailing list and / or get help to nominate ✨