Polkadot: Updated Overview, Governance, Tech and Research Update, Polkadot DeFi Day, Kusama and…

Github metrics:

Polkadot Implementations

There are Polkadot implementations developed in Rust, C++, Go, and JavaScript.

Parity Polkadot — The Rust client is developed by Parity Technologies in concert with their work on Substrate.

Kagome — C++ implementation of the Polkadot Host being built by Soramitsu, a Japanese digital identity company that previously developed Hyperledger Iroha. They were awarded a grant from the Web3 Foundation and plan to release Kagome by November 2019. As part of the process they are developing a libp2p networking layer in C++.

Gossamer — A Go implementation being built by ChainSafe Systems, a 23-person development team in Toronto that is also building an Eth2.0 Serenity client. Grant announcement.

Polkadot-JS — A JavaScript client and tool set developed by Polkadot JS.

W3F Initiates Launch: Polkadot is Live

Web3 Foundation has launched the initial version of Polkadot, a sharded protocol that allows decentralized blockchain networks to operate together, seamlessly and at scale.

Polkadot gives peer-to-peer applications, organizations, businesses, economies — entire digital societies — the agency required to form, grow, govern themselves, and interact without the need for the centralized institutions.

According to an in-depth “Blockchain Developer Report Q2 2020” published by Outlier Ventures, “Polkadot (+44%) saw substantial developer activity growth.Polkadot launched its mainnet at the end of May 2020, garnering increased interest from external developers.”


  • The Polkadot overview paper is ready and has been promoted by a medium blog post.

Technical Education

  • The Technical Education team has been expanding, updating, and refining the Polkadot Wiki. Some notable additions over the past month are updated guides for validators and nominators of Polkadot, a page that explains the Polkadot launch procedure, a re-do of Phragmen optimization page, and more!


  • The team have focused on development of Polkadot Lab, a framework for running generalized tests on substrate-based networks.



In Polkadot’s governance system all DOT 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 consists of 23 members, with a fixed term of one month. 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 councillor can propose to send a proposal to the governance system. In this example, a councillor proposed a new validator count. If enough councillors vote to approve it, then it will eventually have a public referendum.

the Council also has access to Polkadot’s Treasury. The Treasury is an account that accumulates funds by inflation as well as by taking a portion of transaction fees and slashes. The Council can make and pass proposals to spend these funds for developers, community engagement, or more complex activities like using bridges and decentralized exchanges to trade its own DOTs for other tokens.

When the Council votes on its own proposals, votes are counted by member, not by stake. This makes it difficult for large holders to exercise undue power in Polkadot’s governance; they may be able to get themselves on the Council, but they can’t swing a low-turnout referendum.

The Technical Committee

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.

NPoS is 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 the Medium post How 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.


Web3 Foundation’s Grants Program has distributed nearly five million U.S. dollars to one hundred open-source projects contributing to the Polkadot ecosystem. The program includes two additional Polkadot Host implementations, dozens of components like wallets and block explorers, bridges, and other critical infrastructure and tooling. These teams are spread across the globe, and Web3 Foundation is proud to have them supporting Polkadot. Read more about the 100 Projects Milestone.

Learn more on the Polkadot Launch Roadmap or find out how to get involved in the Proof of Authority network.

By: Logan Saether and Joe Petrowski


What do you think?


电子邮件地址不会被公开。 必填项已用*标注





How to Create the World’s First Mainstream DApp

Bitcoin bull market is back