An Updated Overview of Polkadot
The new paper Overview of Polkadot and its Design Considerations expands on the white paper, presenting a comprehensive and updated description of Polkadot’s design components and subprotocols. Some of these are outlined here.
By Polkadot•June 3, 2020
Researchers and developers have been working on improving, updating and refining the Polkadot decentralized blockchain platform since it was first conceived in 2016 by Gavin Wood. The new publication “Overview of Polkadot and its Design Considerations” expands on the original white paper, giving a comprehensive and updated review of the protocol.
Polkadot first appeared in 2016 when Gavin Wood published the white paper outlining the technical vision and rationale behind it.
He noted that although blockchain technology holds promise, problems exist that contribute to the lack of its significant real-world deployment. Polkadot aims to address these issues and create a blockchain architecture that is scalable (can grow with demand), where different blockchains with varying functions can co-exist and communicate with each other in a strong shared security system, laying the foundations for the next generation of the internet.
The new paper Overview of Polkadot and its Design Considerations expands on the white paper, presenting a comprehensive and updated description of Polkadot’s design components and subprotocols. Some of these are outlined here.
In a Nutshell
Polkadot is a scalable heterogeneous multi-chain blockchain. This means that it consists of a collaborative decentralized blockchain network called the relay chain that interacts with sharded chains running in parallel, known as parachains. These parachains can be considered as clients of the relay chain, whose purpose is to secure and coordinate them.
Governance
Polkadot has a sophisticated system of governance in which all DOT (Polkadot native token) holders have a say. Proposals can be suggested either by a DOT holder or by the Council. Both need to be agreed by a stake-weighted referendum.
All DOT holders can register to be considered for the Council. The Council currently consists of 13 members, with a fixed term of seven days. Its role is simply to represent passive stakeholders, submit important proposals and, in exceptional circumstances, cancel uncontroversially dangerous or malicious proposals.
Council proposals have the benefit of requiring a lower number of ayes to pass in a referendum compared to a public proposal. Council proposals need to be supported by a strict majority of Council members, with no veto. Dangerous or malicious proposals may only be cancelled with a unanimous vote.
A Technical Committee (consisting of teams that implemented or formally specified the protocol in Polkadot) exists with the sole purpose of detecting issues such as bugs in the code and to fast-track emergency upgrades or changes to the chain. Teams may be added or removed by a majority vote from the Council.
The use of Treasury funds is ultimately controlled by all DOT holders via referendum. The Treasury raises funds by channeling some of the validator rewards (from minting) and by channeling a fraction of the transaction fees and slashings (the fine paid by a validator who acts maliciously or incompetently). These funds are used to pay for the smooth running of the system and the wider ecosystem (marketing, community events and outreach).
Nominated Proof of Stake
Nominated proof of stake (NPoS) is an adaptation of proof of stake (PoS) in which an unlimited number of token holders can back a large but limited number of validators (expected to be in the order of hundreds at genesis). The elected validators are responsible for running the relay chain.
This allows for a massive amount of stake to back validators, much higher than any single user’s holding. As the nominators share possible slashings as well as economic rewards with the validators they back, they are economically incentivized to choose validators with a strong record of performance and security practices.
Using a system of proportional representation, every minority in the nominator set gets to elect a number of validators in proportion to their stake, with no minority underrepresented.
As such, NPoS is not only much more efficient than proof of work (PoW), but also considerably more secure and decentralized than PoS schemes without stake delegation, where only a few whales (owners of a large amount of tokens) can ever become validators.
For a more detailed description of NPoS in Polkadot see also the academic paper Validator election in nominated proof-of-stake and the Medium postHow Nominated Proof-of-Stake will work in Polkadot.
Block Production and Consensus
The validators elected using NPoS are responsible for receiving, validating and republishing blocks on the relay chain using a hybrid consensus protocol that splits the finality gadget (GRANDPA) from the block production mechanism (BABE).
This combination allows 1) probabilistic finality by BABE due to its chain selection rule, where after a certain time the block will be finalized with a probability close to one and 2) provable and deterministic finality by GRANDPA, where finalized blocks stay final forever.
Combining the mechanisms avoids the chance of unknowingly following the wrong fork (a hazard of probabilistic finality) and allows the rapid finalization of blocks, as the slower finality mechanism finalizes blocks separately without risking slower transaction processing or stalling.
Validity and Availability
In brief, parachain collators produce a proof of validity (PoV) block and send it to the parachain validators, who sign its header as valid. A header with enough signatures is added to the relay chain block.
Once a parachain block is created the parachain blob (PoV block and set of outgoing messages) needs to be available for a while to make sure that its validity can be checked by non-adversarial validators. To enable the validators to collectively guarantee the availability, an erasure coding system is used. This distributes the PoV block to all the validators.
Polkadot has a three-level validity check.
First, when the PoV block is verified by the parachain validators they sign and distribute the erasure codes of the parachain blob to each validator.
Second, it is expected that nodes acting as fishermen (which could primarily be functioning as collators) would report invalidity.
Third, a few randomly assigned validators check validity. If a major problem occurs and the block is not made available to them they can reconstruct the PoV block with a sufficient number of the erasure code pieces that were distributed in the first level.
If validators see invalidity reports given by other validators, the blob can be reconstructed from the distributed erasure code pieces. If there are a certain number of invalidity reports and reports that validators do not have the erasure code piece of the parachain block header in the relay chain block, the relay chain block will not be finalized.
If any invalid parachain block is found on the relay chain its validators are slashed. The expected cost of getting an invalid block into Polkadot is higher than the amount of stake backing a single parachain, acting as a deterrent.
If all the parachain blocks referred to by a relay chain block have enough validity reports and there are no challenges, then the relay chain block can be finalised by GRANDPA.
Cross-Chain Message Passing
Cross-Chain Message Passing (XCMP) allows messages to be passed between different parachains in a secure and trust-free way, quickly and in order. One of the main goals of XCMP is to provide a consistent history for messages that have passed between parachains.
This contains two parts:
• Consistent History: Metadata on the output queue of a parachain block are included on the relay chain and later used to authenticate messages by the receiving parachain.
• Reliable Delivery: The message bodies corresponding to this metadata need to be distributed from sender to recipient.
The order of messages is resolved using a simple queuing mechanism based around a Merkle tree to ensure fidelity.
For further information on XCMP, see also the post Polkadot’s Messaging Scheme.
Read the Paper
For a more indepth presentation of these and other design components and subprotocols, download the full paper here.
Stay up to date
To keep up with the continuing changes in the Polkadot universe, keep an eye on our Web3 Foundation’s research blogs and research pages.
We have provided lots of ways for members of the wider Polkadot community to keep up to date with what’s going on. Join us on your favorite Medium.
Join the discussion on Telegram and Riot, or subscribe to Polkadot's newsletter. Learn more about Polkadot in the Polkadot Lightpaper and the Polkadot Wiki. Looking to validate on Polkadot? Join Polkadot’s validator lounge on Riot.
