Polkadot reveals the truth, Gavin Wood explains Kusama experimental network

The well-conceived cross-chain project Polkadot is now entering the sprint before the main online line, and its development team recently launched a Kusama experimental network that allows developers to build and deploy parallel chains in real-world environments or try Polkadot's governance, staking , nomination and verification capabilities.

So, what is this Kusama network like?

1. What is Kusama?

Kusama is an early, unaudited experimental version of the Polkadot network. Kusama will serve as a testing ground, allowing developers to build and deploy parallel chains in real-world environments or to try Polkadot's governance, staking, nominating and verification capabilities.

• Hero Post: Wuzhen Babbitt Accelerator Potential Project DemoDay, waiting for nothing
• ChainNode evaluation: imKey hardware wallet
• Vitalik: The dawn of the hybrid Layer 2 protocol

2. What is a canary network?

Kusama aims to be the Canary Network of Polkadot, which warns us to protect the safety of downstream developers. Without a network like Kusama, there is no reasonable way to fully understand the potential danger ahead. Developers are building cutting-edge experimental techniques, which means there is no promise as to what Kusama will do or how to work, and there is expected to be a lot of confusion.

Kusama is an early, highly experimental Polkadot network that delivers real economic conditions. The community will own the network without a central disconnect switch, and Kusama will exist as long as the community maintains it. 3. What are the rewards for using the Kusama network?

Polkadot's founding block will retain 1% of DOT tokens to reward Kusama stakeholders and communities . The precise mechanism in this regard has not yet been finalized. There is also a rewards program for key issues that you can find here .

4. What can we do with KSM tokens?

With KSM, you can verify, assign certifiers, contact parallel chains, pay for interoperable messaging, and vote for governance. For more information, see the KSM User Guide .

5. How to get KSM?

KSM's founding distribution will be exactly the same as Dot: if you participate in DOT fundraising, you will have the same share of Kusama tokens. The Web3 Foundation will use its funds to set up a faucet. Currently, people without DOT can apply for a claim. The following is the method of claiming: https://guide.kusama.network/en/latest/start/claims/.

In addition, after the launch of the founding block, the Web3 Foundation will also provide a public tap and a KSM authorization program. 6. Will Kusama eventually become the Polkadot main network?

No, Kusama is a completely different network from polkadot, but it has many of the same features (such as parallel chains) and it uses earlier versions of Polkadot code.

In the long run, Kusama will evolve into an experimental platform for advanced technology that will work with and complement the Polkadot main network. 7. Can KSM be used for trading?

No, it can only be used for the test of the Canary network.

The following is a translation of the Kusama governance mechanism written by polkadot founder Gavin Wood:

At about 9:30 this morning (Switzerland), we started a blockchain, which will soon become the “Kusama Chain Candidate No. 1”, which is the first “wild” deployment, which was originally conceived. It was about three years ago, and we have been actively developing for this for nearly two years. Combining cutting-edge innovations in governance, consensus and scalability, you will experience the world of blockchains that are coming. In short, the polkadot v0.5.0 code has been released and you can now sync to the temporary kusama network. For soft-start purposes, Kusama will initially serve as a PoA (authoritative proof) network, and the verifier node will be run entirely by the Web3 Foundation (of course without compensation!). During this time, many features of the network will be disabled. In particular, balance transfers are not possible, and governance is limited to the “Sudo” module, where the Web3 Foundation holds a single key. The enabled features are limited to the use of the staking , session and claim modules; specifically, support for binding, nomination, and publishing as verifier intent, setting session keys, and claiming KSM.

This period of time will be long enough to allow at least 50 (and ideally 100) good verifiers to be ready. We expect this to take 1-4 weeks. During this time, one or more additional runtime upgrades will occur to incorporate additional features into the chain. This time, part of it is for further testing and logic development, in part to test the runtime upgrade logic itself.

After this phase, the Web3 Foundation will release a final version of the centralized runtime upgrade, which will remove the authority of the Sudo module and the Web3 Foundation for the chain. It will introduce Kusama's founding governance mechanism and enable the NPoS staking system to effectively transform Kusama from a centralized PoA network into a decentralized PoS network. At this point in time, governance and balance transfers will become active and Kusama will enable the functionality.

Founding governance

Kusama's original governance system was called “initial governance”, which is a ternary model. The Referendum Chamber (which can be roughly referred to as the “Legislation” House) is the House with the largest number of members in the three Houses and is the most powerful House to date. All legislation (ie changing the logic of Kusama) must be approved by the House, which consists of all stakeholders (ie KSM token holders), depending on the number of KSMs held and their willingness to continue to hold them. Time for weighted voting.

The other two Houses are the Council (which has some similarities with the implementing agencies) and the Technical Committee . The membership of the board of directors is voted by the token holders. It will initially have seven seats, but only if the community's interest in governance grows, the number of seats should be expanded.

The Technical Committee consists of all Panels that successfully implement or formally designate one of the Polkadot/Kusama Agreements (ie, the Polkadot Runtime Environment or the current Kusama Runtime). The team that achieves these two goals will receive two votes. The team may be added or cancelled by a simple majority vote of the board of directors.

The proposal to vote in the referendum house will last for 28 days. If the proposal is approved, it will take another 30 days to take effect. This allows those who join the NPoS consensus system to have time to quit the network, in which case they consider the legislation to be catastrophic.

If "one wants to win" (if not, then they are free to sell tokens and then quit the network), all voters must hold tokens for 30 days until the date of the establishment. Those who are willing to hold the token twice will receive additional votes, in which case up to 5 times more votes will be awarded (ie, those who are willing to hold approximately two and a half years of votes will receive 6 times the votes). Those who are not willing to hold can still vote, but their voting power will be reduced by 90% compared to those who vote at least four weeks .

In the case of a 100% turnout (ie, all tokens participate in a vote regardless of the lock-up period), legislation may not be passed unless it receives at least a half of the total number of votes in the First House. As the voter turnout rate decreases, the approval mechanism differs depending on the legislation. In general, a technique called Positive Turnout Bias (or simply absolute majority vote) is applied, in which the number of different voters increases, and legislation is required. The majority has been reduced from 100% to 50%. Alternatively, an absolute majority vote is required to pass any less than a full vote. As the turnout rate increases, the size of the absolute majority required will shrink (and therefore the chances of getting approved will increase).

There are two special cases. One is to require a simple majority, regardless of the voter turnout. This count method is often called majority-carries, and the other is the negative voter bias (Negative Turnout). Bias), but is often referred to as a simple default vote, which requires the overwhelming majority of opponents to prevent the success of the legislation.

Proposing legislative proposals in Kusama

Kusama voted on the legislative proposal once a month, and the participants were the First House. Proposals are proposed by the board of directors or the public (into the public queue). Every month, there will be a proposal that will be voted on, and the last proposal that has not been voted on will be given priority. Therefore, the Council has the power to control 50% of the legislative agenda, while the remaining 50% is controlled by the public.

Public queues are a means of allowing legislation to be more widely implemented. Any user of Kusama can place a proposal in the queue by placing a minimum number of KSM tokens after the proposal, or "attaching" an existing proposal and Add to this deposit. When it is the turn of a new proposal from this public queue, the proposal with the most deposits in the token will begin the voting process.

As mentioned earlier, the mechanism for counting votes in the public voting house is usually an absolute majority vote. There is of course an exception: when more than three-quarters of the board members vote for a proposal, the vote becomes a simple majority vote, not the voter turnout. In addition, the default vote will be used as the voting count method if and only if the Board passes unanimously in its approval.

Fast-tracking

Kusama includes the logic to allow its governance system to quickly handle legislative changes. This kind of legislation's "short-circuiting" allows the proposal to proceed immediately and with the normal monthly proposal.

A piece of legislation can enter the fast track if it is approved by more than half of the members of the board (more than three-quarters) and approved by two-thirds of the members of the technical committee. Here, it will immediately vote in the full referendum, voting time will be much shorter (3 days) than normal voting, and almost immediately. In this case, the approval mechanism remains the same as they were (a simple majority, or, if it is a committee of the whole, the default vote). The mechanism is expected to be sufficient for uncontested bug fixes and technology upgrades, but given the technical committee's approval requirements, the mechanism may be ineffective in an emergency.

Treasury

In addition to legislation, Kusama's governing body also includes the Treasury. The Treasury is made up of KSM tokens, supplemented by transaction fees, slashing, Kusama's staking set of inefficiencies and deposit losses. The purpose of these funds is largely for the benefit of the Kusama network.

How to deploy them is key to the community. Anyone can make a cost proposal, and 5% of the amount spent is non-refundable and then approved or rejected by the board. Those approved projects enter the queue, and every 24 days (budget period), there are financial budgets that are affordable to be excluded from the queue. If there are not enough approved expenditure proposals to use the Treasury funds, then a small portion of the remaining Treasury funds will be burned, which creates a slight deflationary pressure.

Our imaginable spending proposals include:

1. Infrastructure deployment and ongoing operations;
2. Network security operations (monitoring services, ongoing audits, etc.);
3. Ecosystem supply (cooperating with the friendly chain…);
4. Marketing activities (advertising, cooperation, etc.);
5. Community activities and outreach activities (party, Kusama pizza party, hackathon activities);
6. Software development (wallet and wallet integration, client development and upgrades, etc.);

This is ultimately controlled by Kusama stakeholders, and it is this group and its collective imagination and judgment that really determines the progress of the Treasury.

Post-Genesis governance

In addition, two additional governance mechanism plans will be added to the network after the release of Kusama (and the Polkadot main network, if the trial is successful). One is the Oracle committee and the other is the Spontaneous Subject Committee.

Oracle Committee

The Oracle committee is different from the technical committee, whose members are controlled by the members themselves according to a set of natural language rules (somewhat like the Constitution). Unlike the technical committee, members of the Oracle committee are required to vote and pay the voting fee. They will evaluate objectively true or false statements and provide corresponding answers. As a principle, they will never have any type of judgment or opinion.

Their membership is determined by broadly designed objective criteria designed to maximize their chances of honest voting and their identity remains secret until the individual leaves the committee.

Spontaneous Subject Committee

The Spontaneous Theme Committee is designed to be a more flexible way to capture stakeholder perspectives that can be used with existing ternary structures to optimize the legislative process. Essentially, it uses a progressively increasing, statistically random sample to weight the voting population to determine the likelihood of refusal or overwhelming approval for a referendum. Randomly sampled voters will receive ballot compensation and the turnout rate will be taken into account. If you have enough confidence to identify a refusal or approval, you can quickly waive or pass the proposal, thereby freeing the pipeline for other, more controversial legislation.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!