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++.
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.
- Alfonso Cevallos and Alistair Stewart prepared the first draft of the NPoS paper.
- Alistair, Handan Kılınç Alper, Florian Franzen, and Syed Hosseini have cross-checked the code with the designs of GRANDPA and BABE, where only small discrepancies were found that are being addressed now. Alfonso is cross-checking the implementation of NPoS currently.
- The specification document for the sub-protocols Availability & Validity and XCMP is nearly finished.
- The research team started a research collaboration partnership with the University of Zurich to tackle cryptoeconomic research questions together.
- Aleixo, Master student from ETH University, will start his Master thesis at W3F designing a private interoperability protocol between Polkadot and zCash
- Fatemeh Shiraziwas invited to the program committee of Usenix Security 2021 (Summer 2020 and Winter 2020/2021 submissions).
- 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 Thousand Validator Programme for onboarding validators to the Kusama Network now has over 60 active validators participating. Applications are still open for the programme and if accepted you will get nominations from Web3 Foundation’s stash at regular intervals.
- Bill Laboon’s MOOC is now on week 9 and it’s never too late to sign up and get started.
- Polkadot’s subreddit, r/dot, is being monitored and an effort to revive it as an active place for the community to gather and ask questions is underway.
- The chainspec generator for generating the Polkadot genesis state from the Ethereum smart contract was finalized for Polkadot’s launch and augmented with a more comprehensive state-checking script.
- The team have focused on development of Polkadot Lab, a framework for running generalized tests on substrate-based networks.
- The dev team have started using the Prometheus metrics exposed by substrate-based nodes for an improved monitoring and alerting of Polkadot and Kusama nodes.
- Cloudflare client: during this month we developed a typescript client that wraps the official cloudflare client and makes it easier to interact with it for common tasks, like keeping DNS zones clean or updating DNS records. This will be helpful for publishing data to IPFS and managing access to it using DNSLink.
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.
By: Logan Saether and Joe Petrowski