Gov2 Polkadot’s Next Generation Decentralized Governance

Gov2 Polkadot - Next Gen Decentralized Governance

Introduction

At the time, Polkadot’s first decentralized governance system was very interesting: a tripartite structure with a technical committee managing the upgrade schedule, an elected “government” to manage parameters, proposals, and expenditures, and a general voting system for all other matters, rewarding long-term holders with increased influence. It was loosely based on parliamentary democracy and performed quite well in its initial 2-3 years of operation, helping to ensure the responsible use of treasury funds, fast upgrades, and timely management of critical fixes. However, it also had its drawbacks.

The elected executors (referred to as parliament) were centralized and usually not anonymous. This exposed both the protocol and individual members to a certain level of risk, as they could be pressured to act in a certain way. The technical committee, while having less power, also faced similar risks and greater centralization. In today’s society, decentralization is increasingly necessary for the security and safety of all participants, whether well-intentioned or malicious.

In addition, there was only one “all or nothing” referendum mode – all referendums had equal weight. Partly because of this, only one referendum could take place at a time, lasting several weeks by default. The resulting issues, combined with the limited bandwidth of the parliament, meant that the entire system was more conducive to in-depth consideration of a few proposals rather than broad consideration of many proposals. Instead of harnessing the power of the masses, it inadvertently constrained itself in its efforts to manage potential decision throughput.

The nature of coarse-grained delegation means that the system inherently has a certain exclusivity. Higher barriers to entry within an effective political framework reduce inclusivity and diversity, leading to lower voter turnout and legitimacy.

• BitMEX Founder Arthur Hayes’ Token2049 Speech Fiat Debt and AI-Driven Next Bull Market (with PPT)
• Full Text of Arthur Hayes’ Token2049 Speech in Singapore The Next Bull Market Will Start in Early 2024
• Opportunities and Limitations of Stablecoins Supported by LSD

Clearly, the first governance version of Polkadot was just something that evolved over time. Now, I am pleased to be able to provide a detailed description of the next generation of governance proposals introduced within the Polkadot ecosystem.

Introducing Gov2

The next generation governance system of Polkadot, known as Gov2 during development, aims to address the issues of the current system. Firstly, it does not violate the original governance principles of Polkadot, which state that if they have sufficient credibility in their own opinions, a total of 50% of the stake in the system should be able to ultimately control the future of the system. Similarly, it does not deviate from the pioneering Conviction Voting in Polkadot, which provides greater weight to those willing to lock their tokens in the system for a longer period of time. Additionally, a technical collective is still required, although it differs from the current technical committee in terms of importance, size, member composition, and membership mechanism.

The biggest difference lies in how it manages the practical means of daily decision-making, making the outcomes of referendums more scoped and agile, thereby significantly increasing the number of collective decisions the system can make. Let’s delve deeper into how it works.

Lowering the Barrier

In many ways, Gov2 is actually simpler than the current governance system. There are no other institutions acting as “first-class citizens” in governance, such as parliaments and technical committees. There is no rotating proposal schedule. There is no public proposal queue. Instead, we have only one first-class decision-making mechanism: referenda. The main difference with Gov2 is that there can be many such mechanisms—perhaps even thousands—happening simultaneously.

In Gov2, anyone can initiate a referendum at any time, and they can do so continuously. Anyone can also vote on these referenda. There are no explicit restrictions, meaning that referenda can be voted on at any time.

However, this could lead to an excessive number of voting matters, to the point where an ordinary person may not be able to assess all of them within a reasonable time frame. This could reduce inclusivity and security. Therefore, to make these potential voting matters feasible for ordinary people, we have introduced some interesting new features in the referendum process.

Origin and Track

All referenda are based on proposals, which are essentially another term for “operation” in Polkadot. This is the same as what is described and executed when you make a transaction and include it in a block. Polkadot can execute various operations, but some of those you may already be familiar with are the “transfer” operation that allows assets to be moved between accounts, and the “stake” operation that allows accounts to be locked. There are many other operations as well. What makes this governance feature special is not the proposals/operations themselves, but the Origin used when they are executed.

You can think of Origin as a rich descriptor of privilege levels. When an operation is executed, Origin is passed in, and the logic of the operation typically checks whether it is appropriate. When regular transactions are executed, the Origin parameter is set to a variant called Signed. This means that a specific account in the system (usually authorized through signing the transaction) allows the operation to occur, and it runs with this privilege, further implying, for example, that funds controlled only by this account can be spent.

Governance-level operations can cause operations to run with a higher privilege Origin. The highest privilege among them is the Root Origin, which has unlimited power. This is the Origin from which all approved referendum proposals will be sent. In Gov2, we have many different Origins, each with certain privileges, but many of them are much weaker than Root and more specialized.

In Gov2, we allow proposers to specify which Origin they want their proposal to be executed with. Each supported Origin is associated with a referendum category, and most of these categories will correspond to exactly one Origin, but there may be some categories composed of multiple Origins. Each category has its own Track, which is essentially a pipeline where proposals reside and pass through, and it is completely independent of other categories’ Tracks.

Having independent Tracks allows us to customize the dynamics of referenda based on their implied privilege levels. Referenda with proposals executed by more powerful (read: dangerous!) Origins will have stricter safeguards, higher barriers, and longer consideration periods. The Root Origin has the highest barrier and safeguards. Consideration periods for Origins with relatively less passing power (such as the Tip Origin, which can pay up to 10 DOT from the Treasury) are shorter, and approval thresholds are lower.

Launch

When a referendum is initially created, any community member can vote immediately. However, it has not yet entered a state where its votes can be counted, approved, and subsequently executed. Instead, referendums must meet certain conditions before they enter a state called “decision”, and until they enter this state, they still have not made a decision.

There are three conditions that need to be met: First, all referendums have a lead time. This is the time that must pass after the proposal. This provides time for the initial notification period so that votes can be submitted, preventing the possibility of “decision shooting”, where an attacker who controls a large amount of voting power may attempt to pass a proposal shortly after it is proposed, without allowing the overall voters time to consider and vote.

Secondly, there must be space for decision-making. Each track has its own limit on the number of referendums that can be decided simultaneously. The more powerful (and more dangerous!) an Origin allowed on a track is, the lower this limit is. The Origin at the Root level has a limit of 1, which means that only one super dangerous proposal can be decided at a time. On the other hand, the limit for the relatively weak Tipping track is much stricter, as any damage caused by excessive decision-making is small, and there are many Root-level calls that are more useful. When space is available, the referendum that receives the most approval in the eligible category (otherwise) will be promoted to the decision state.

Finally, a decision deposit must be paid. Creating a referendum is cheap and only requires a deposit related to the on-chain storage required to track it. However, enabling a referendum to be decided carries greater risk and uses up limited space, as we limit the number of referendums that can be decided on each track simultaneously. Therefore, a larger (although refundable) deposit must be paid to mitigate the risk of spam or system inflation.

Decision and Confirmation of Proposals

Once a referendum enters the decision state, it is eligible for approval. This eligibility is only valid for a limited time (28 days on Polkadot), and after this time, it is automatically rejected if not approved. To be approved, it must meet two criteria (referred to as “passing” in this case), and it must continue to meet these criteria for the shortest possible time in the confirmation period. Different tracks have different lengths of confirmation periods, with more powerful tracks requiring more time for confirmation. This is an additional defense against whale voters “shooting” referendums by casting a sufficiently large number of votes.

The two passing criteria are related to approval and support. The past adaptive quorum bias in referendums no longer exists. Now we have a more flexible system that allows these requirements to be customized at a finer granularity. Approval is defined as the share of the approved voting weight (adjusted based on conviction) in the total voting weight (used for approving and rejecting votes). Support is the total number of votes in favor in the approval (ignoring adjustments for conviction) compared to the total number of votes that could be generated in the system.

Each category of referendum has different requirements for these values. However, the most interesting thing is that these requirements can gradually decrease according to a clearly defined timetable. This means that as the voting within 28 days progresses, we can configure things in such a way that proposals require less support and overall approval. In general, they will always start and end in roughly the same way, starting from the highest threshold and ending with the lowest threshold that still meets the overall principles: at least 50% approval is required.

What happens between the two determines whether it is easy to obtain approval before the 28-day deadline. For proposals that use less privileged Origins (such as the Tip category, which only requires a maximum payment of 10 DOT from the Treasury Department), it is more reasonable to lower the required votes earlier. Proposals using highly privileged categories (such as Root) will be easier to accept with less controversy at an earlier stage (thus requiring higher approval).

After Approval

After 28 days, unapproved proposals are considered to be rejected by default. At this point, the decision deposit can be refunded. On the other hand, if a proposal manages to pass and remains passed within these 28 days, it is considered approved and is planned to be executed by its legitimate Origin at some point after the proposal is made.

The implementation period is also specified when the proposal is made, but it depends on the track. Some more powerful tracks require longer implementation periods to ensure that the network has enough time to prepare for any changes that the proposal may bring.

Intervention

Sometimes, a situation arises where a proposal that is already being voted on (perhaps already passed) contains issues and it is desired to cancel it. One example is the discovery of a chain upgrade later that includes some problem. Although this is not very common, it is not unheard of either.

In Gov2, there is a special operation called Cancelation for such interventions. This operation immediately rejects the ongoing referendum regardless of its status. It actually has two forms, one of which only performs basic operations, and the other also reduces the amount the proposer pays to the referendum deposit.

Cancelation itself is a governance operation that must be executed by a network vote. This can bring potential issues with the timeline, and in order to be useful, proposals that allow the cancellation of proposals to pass quickly must usually be much faster than the possible target proposals. Therefore, Cancelation has its own Origin and Track, with a shorter lead time and a slightly steeper approval/support curve for the threshold.

Flexible Delegation

In a perfect world, everyone would have unlimited time and skills, and every proposal would be researched, discussed, considered, and voted on carefully. However, in the perfect world, we don’t live. Not everyone has the time or desire to have the ability to thoroughly research every issue. With this understanding, the Council was born as the initial governance of Polkadot: an institution appointed by voters to compensate for the fact that many of them are not willing to participate in day-to-day governance. However, the Council has been abolished in Gov2, and we need an alternative means to ensure that the voice of “passive” voters is heard.

The original governance system has a feature called voting delegation, which we have retained and improved in Gov2. For those unfamiliar, this is similar to the premise of liquid democracy: you can delegate your voting power to another voter in the system. When your delegate votes, they not only have their own voting power, but also yours. This works in conjunction with conviction voting, allowing you to lock your tokens to increase the level of voting power your delegate has when voting on behalf of you. Of course, the tokens involved never leave your control, and you can switch delegates or regain direct control at any time.

However, in Gov2, this has been improved through a special feature called Multirole Delegation. This allows you to specify different delegates for each category of referendum in the system. If you don’t want to delegate for a specific category, you can also retain direct control for that category.

This means you can assign one individual for work proposals, which are used for ecosystem contributors to receive tips, another entity for proposals involving larger-scale financial expenditures, another entity for purely technical network upgrades and parameterization proposals, and retain direct control for any other decisions!

Academy and Whitelist

In any well-functioning governance system, the opinions of knowledgeable “experts” play an important role. Expert governance brings its own serious flaws, so we do not want “experts” to be in a commanding position: this introduces centralization, irresponsible authority, and potentially forms the basis for a ruling kernel. This is why the initial governance of Polkadot’s technical committee does not have the logic of “decision-making power”.

It is called the Polkadot Fellowship, referred to as the “Academy” in Gov2. The Academy is a network role that is not responsible for making final decisions on whether to execute proposals. Instead, they support the governance process by providing advice on the technical, compliance, and risk aspects of candidate proposals. This advice is optional, not mandatory, and referenda can choose to adopt or ignore it.

The Academy is not anonymous and is required to disclose their identities to increase transparency and accountability. This is one of the roles of the Academy in Gov2.

Gov2 also introduces a mechanism called the “whitelist”, which allows a group of entities in the system to gain special governance powers. This can be used for various purposes, including introducing new members to the ecosystem, rewarding contributors in the ecosystem, or similar purposes. The whitelist mechanism is highly configurable, and the community can decide how to use it.

Conclusion

Overall, Gov2 is a significant improvement in Polkadot governance, aiming to address issues in the existing system and improve inclusiveness, efficiency, and transparency of governance. It introduces a range of new features, such as multi-track, origins, whitelists, and the Academy, as well as a more flexible delegation election system to better meet different governance needs.

The goal of this system is to strengthen decentralized governance, ensure the security and safety of all participants, and improve the quality and quantity of public decision-making. It provides a more powerful tool for the future development of the Polkadot ecosystem to ensure its long-term success and sustainability.

Author: Gavin Wood

https://medium.com/polkadot-network/gov2-polkadots-next-generation-of-decentralised-governance-4d9ef657d11b

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