Gavin Wood: What changes will Polkadot governance v2 bring? (superior)

Since Polkadot started democratic governance in July 2020, the first version of Polkadot’s on-chain governance system has been running smoothly for nearly two years. At some recent meetings, Gavin has repeatedly mentioned that the second version of Polkadot’s governance system is under preparation, and revealed that the new governance system will be more decentralized, and there may be no council (the first version of governance). the most powerful organization in the system).

At the recent Polkadot Decoded conference in Buenos Aires, Polkadot founder Gavin Wood delivered a speech on Polkadot governance v2, briefly describing the content of the new version of the governance system and its differences from the original system.

This article is the first half of a summary of the talk, translated and organized by PolkaWorld.

Gavin Wood: What changes will Polkadot governance v2 bring? (superior)

Today I want to talk about something I’ve been working on for the past year or so and hope to finish soon. I’ll talk about what it is and why we’re doing it.

Today’s topic is – governance. Governance is a fairly core element of Polkadot, and it’s fair to say that we’ve been a front-line leader in this area and trying to push interesting new models and concepts to try.

The importance of governance

Why should we care about governance?

Because Polkadot and all Dotsama ecosystem parachains are upgradable, this is achieved through WebAssembly, making these chains adaptable and able to change and progress over time. But in order to make a decision on the direction of its change, we need a decision-making process.

In an ordinary centralized organization, it is usually the CEO or his representative who decides the direction of the product. And in a decentralized ecosystem we can’t do that, or shouldn’t do it, so we need a mechanism and process to make collective decisions about how and when the protocol should evolve, and that’s governance.

The first version of the governance system

Polkadot’s current governance system (v1 version) is tricameral – the technical committee does not much and has some power; the council does a lot and has considerable power; Token holders have the final Power, can vote on some things.

There are also some interesting designs, and they are all implemented.

For example, adaptive voter bias, that is, the conditions for the proposal to pass under different voting rates should also be different. This is also a feasible solution when there are not so many people voting.

Conviction voting, it takes us from the original “the more coins, the more power and influence” model, to the “if you care about the long-term interests of the network, you will have more influence” model, the essence The above is that you can lock yourself in Polkadot or a parachain to gain an influence bonus.

Proxy, that is, as a passive holder, you can delegate votes to others and make decisions on your behalf.

Disadvantages of the first version of governance

So what are the disadvantages of this system?

First, it’s slow. It was designed to be slow on purpose for safety, but we cannot deny the fact that it is slow. Under the normal process, it takes about two months from proposal, vote, and implementation.

And it’s not flexible enough either. There can only be one referendum at a time, that is, in a 28-day period, only one thing can happen.

And it’s more difficult to get close to. If you put a ballot proposal in Polkadot, it may never get a vote, just like many referendums fail to make it to the final voting stage.

Finally, the uglier point is that the degree of decentralization is not enough. This system has centralized elements, such as the council. Yes, council members are voted, so in a sense they are reliable. But in any case, it is actually those who are selected who are making decisions that affect everyone. This is a centralization risk.


What is the solution? There are two aspects.

The first is to lower the threshold and make governance simple and cheap. Makes it easy and cheap to propose proposals, how protocols should change, how networks work, and how people vote.

We removed as much centralization as possible, removed councils and technical committees, and allowed infinite referendums to vote directly on everything at the same time.

Sounds simple, right? But it’s a bit like a modern version of a “missile commander” game, where missiles fall from the sky and you fire bullets from the gun at the bottom of the screen to shoot down those missiles before they destroy the city. As the game becomes more difficult, there will be more and more missiles falling on the screen.

The same is true of our new governance system. If you can have an unlimited number of referendums from everyone, then there will be a lot of malicious proposals falling, but you only have a limited number of responsible participants who can execute malicious proposals. and shoot them down before they cause harm.


So how do we ensure the security of the governance system?

One is to limit the number of active decisions in the same period, so that there are not too many decisions for each person to consider. Because the more things that need to be considered, the less time is allocated to each decision, the higher the probability of things going off the rails. Limiting the number of decisions can then reduce this risk.

We can also limit the possible impact of these referendums, which is to limit the amount of damage these missiles would cause if they did hit the ground.

In addition, we can also require a high voter turnout or pass standard before a vote is passed and has impact.

Finally we can increase the time it takes for these decisions to be adopted. More time means more people have enough time to think about the consequences and implications, whether they think it’s a good idea, more time for them to vote, for or against.

We can increase the time before voting begins; we can increase the time during which voting is in progress, such as adding a “are you sure you want it to pass” when the vote appears to be passing; we can even increase the time after voting is over, we can There is an opportunity to reverse the decision, and if anyone strongly disagrees with the impact the proposal has on the network and the protocol, they can back out at this point or take some neutralizing action on their own.

Security vs Agility

Below I talk about the trade-off between security and agility.

The trade-off between security and convenience is a cliché. You have a slider to choose between very safe but not agile, or very agile but not very safe.

The first version of governance limited activity, held a referendum almost once a month, and introduced trust, a centralized institution, so it was safer.

But we want a more agile version, faster, more flexible, and less centralized. So version 2 governance allows us to use more elements to make governance secure in order to get the best and most impactful balance. That said, there may be different types of security measures for different types of referendums.

So what we actually do is limit throughput and lengthen the voting cycle based on the damage that a referendum could theoretically cause. If we can classify a referendum as low-impact, then very conservative safeguards are not necessary. That is, not all referendums and proposals are created equal.

Ranked by influence

In the first version of governance, all referendums and proposals were treated equally. For those who know some technologies, both Polkadot and Substrate-based parachains are within such a framework, the permission level of code execution is called “origin”, and different origins represent different permission levels, a bit like Users on Unix operating systems.

There are actually two things in a proposal: one is the operation, i.e. what you want to do, such as “spend 100 DOT from the treasury”, “deploy a parachain”, “create a new system parachain in this slot and Deploy some code” etc. what you want to do with governance. The second is the source, which is the permission level that the operation will run at, i.e. who/what authorized the operation to happen.

Most operations require a specific source, but not all operations do, and some operations can use many different sources. An example is the transfer operation, this operation is very commonly used, if you want to transfer some DOT/KSM or other coins from your account to other accounts, this is called a transfer operation, you wrap it in a transaction and send it to network. What the network does is check, it looks at who authorized the transfer, the source it checks is a signed source, which means that you signed the transaction, it proves that you really want to authorize the transfer, make sure that The source has been signed.

source and track

What we did in the second edition of governance is that there are a lot of different types of sources that authorize different things, some things are high impact, some are low impact, and we have a different track for each source type. . Each track can have different parameters, different (pass) thresholds. We can guarantee that these parameters and thresholds can be less stringent for orbits with less impactful things; more conservative parameters and higher thresholds are required for orbits of inherently more dangerous things.

Let’s imagine some sources.

For example, Root, it is the almighty origin in Polkadot, Kusama, and Substrate chains. This is everything executed in the old governance system. There is only one level, the super-user level Root, which can do anything.

We have other sources, like ParachainAdmin, that can be used to create new parachains, if you want to create a new system parachain, you don’t need to be able to do anything, you just need to be able to do it, and ParachainAdmin can do it to this matter.

BigSpender source, can spend a lot of money from the treasury; Tipper is a super small spend, can only spend a little money from the treasury.

We can easily see that the impact of these things is different, the impact of being able to do anything is higher than the impact of being able to spend 10 DOT from the treasury.

In these referendum tracks, we can customize a few things.

Like the lead-in period, which is how long it takes before voting really matters. Confirmation period, that is, when a referendum is about to pass, how long it needs to remain in this state before it can actually be approved and entered into a referendum. Turnout and approval requirements, the most important part of a voting system, how many people are willing to vote and how many of them want the bill to pass. How many referendums can be held at the same time. For some matters with little impact, many items can be voted on at one time, it doesn’t matter; if it is a matter of great influence, it may be limited to a few items or even one item at a time.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-07-08 10:46
Next 2022-07-08 10:47

Related articles