Detailed Explanation of Polkadot's New Governance Gov2: What Needs to Be Done to Achieve Decentralized Governance?

Original Title: 《Governance V2》

Author: Polkadot

Compiler: PolkaWorld

The text is from the "Governance V2" section of the official Polkadot documentation on the Polkadot Wiki, describing the new governance system of Polkadot and its comparison with the original governance system (Governance V1).

Polkadot employs a complex and sophisticated governance mechanism that allows it to elegantly evolve according to the ultimate demands of its stakeholders. Its goal is to ensure that the majority of stakeholders can always control the network.

The content of this document is subject to change. The governance protocol has undergone several iterations (v1 and v2), with more changes planned (v2.5).

Polkadot's first decentralized governance system (v1) consists of three main components.

• Technical Committee: A technical committee that manages the upgrade schedule.
• Council: An elected "government" approved by voting, responsible for managing parameters, administration, and expenditure proposals.
• Referenda: A universal voting system for all other matters, which gives greater influence to long-term stakeholders. This system worked well in the early years of operation, helping to ensure the proper use of treasury funds and enabling timely upgrades and fixes. Like most early technologies, the system and protocols must continuously evolve with their maturity to improve their shortcomings and keep pace with existing advancements. For example, in "Governance v1," all referenda had the same weight because only one referendum could be voted on at a time, and the voting period could last for weeks. This led the system to favor careful consideration of a very small number of proposals rather than broadly considering many proposals. Thus, "Governance v2" was born!
  "Governance v2," or "Gov2," changed the actual method of daily decision-making, broadening and making the impact of referenda more agile, significantly increasing the number of collective decisions the system can make.

After a final professional review of its code, Gov2 will launch on Kusama. Following testing on Kusama, a proposal will be made to deploy it on Polkadot. (PolkaWorld: Gov2 is currently live on the Kusama network, see: Another Milestone! The Next Generation Decentralized Governance System OpenGov Launches on the Kusama Network!)

The following content will first introduce many core governance principles on the Polkadot network. Understanding the roots of Governance v1 is important for better understanding the direction of the second iteration. These differences and distinctions will be highlighted in various subtopics.

That said, it is important to remember that at this stage in its lifecycle, governance is an evolving protocol. As updates to Governance v2 enter the network, plans for Governance v2.5 are also being developed.

Prerequisites

In summary, the network brings together various novel mechanisms, including amorphous state transition functions stored on-chain and defined in a platform-neutral intermediate language (i.e., WebAssembly), as well as various on-chain voting mechanisms, such as referenda with adaptive absolute majority thresholds and batch approval voting mechanisms.

All changes to the protocol must be agreed upon through stake-weighted referenda.

Mechanism

In Governance v1, active token holders and the council jointly manage network upgrade decisions. Whether the proposal is initiated by the public (token holders) or by the council, it must ultimately go through a universal referendum of all holders, weighted by stake and conviction.

To better understand how the council is composed, please read this chapter.[1]

Governance v2 has several changes. The new governance model reflects its decentralized characteristics in the following ways:

• All responsibilities of the council are transferred to token holders through democratic voting.
• The current council is dissolved collectively.
• Users are allowed to delegate their voting rights to community members in more ways. The council in Gov1 fulfilled its roles as a representative of passive token holders, treasury guardians, and legislative initiators, but was generally seen as a centralized entity. To further decentralize the Polkadot and Kusama networks, Gov2 proposes to return the council's responsibilities to the community.

Referenda

Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific proposal associated with it, which takes the form of a runtime privileged function call (including the most powerful call: set_code, which can switch the entire code of the runtime, achieving functionality that would otherwise require a "hard fork").

Referenda are discrete events with fixed voting periods. When the voting period ends and the votes are counted, if the vote is approved, the function (set_code) will be called. Referenda are always binary; your choices in the vote can only be "in favor," "against," or completely abstain.

In Governance v1, referenda could be initiated in one of the following ways:

• Publicly submitted proposals;
• Proposals passed by a majority or unanimous vote of the council;
• Proposals submitted as part of the execution of a previous referendum;
• Emergency proposals submitted by the technical committee and approved by the council. All referenda have a corresponding execution delay period. This is the time from the end of the referendum to the actual execution of the proposal (assuming the proposal is approved).

If a referendum closes and the votes are counted, it is considered completed. Similarly, if the proposal is approved, it will be scheduled for execution. If the referendum is awaiting results, i.e., is being voted on, it is considered incomplete.

If the proposal is submitted by the public or the council, there is a fixed execution delay period of 28 days. Proposals submitted as part of the execution of a previous referendum can have their execution delay period set as needed. Emergency proposals address significant network issues requiring "fast follow-up," thus shortening execution time.

In Gov2, anyone can initiate a referendum at any time, and there is no limit to how many referenda can be initiated. Gov2 introduces several new features called Origins and Tracks to help streamline and process the referendum protocol.

Origin can be thought of as a rich descriptor of a given privilege level. Proposers of referenda now need to choose an appropriate Origin for their requests based on the proposal's requirements.

Each Origin is associated with a category of referendum, and each category is associated with a Track. The Track outlines the lifecycle of the proposal and is independent of other categories' Tracks. Having different independent Tracks allows the network to adjust the dynamics of referenda based on their implied privilege levels.

For example, a Runtime upgrade (set_code call) has a different impact on the ecosystem compared to the approval of treasury tips (reportAwesome call), thus requiring different Origins, where different voting rates, approval rates, deposits, and minimum execution periods will be predetermined on the pallet.

Proposal Referenda

Public Referenda

Anyone can propose a referendum by depositing a minimum amount of tokens within a certain period (number of blocks). If someone agrees with the proposal, they can deposit the same amount of tokens to show support.

• This action is called "endorsement." The proposal with the highest bound token support will be selected as the referendum for the next voting period. Note that this may differ from the absolute number of endorsements; for example, three accounts each binding 20 DOT will "outweigh" ten accounts each binding 1 DOT.

Once the proposal is submitted (i.e., voting occurs), the bound tokens will be released.

For Governance v1, there can be a maximum of 100 public proposals in the proposal queue.

In Gov2, when a referendum is created, the community can immediately vote on it. However, the referendum is not in a state where it can be concluded or otherwise counted for votes, approved, and ultimately executed. Instead, the referendum must meet certain criteria before entering a state called "Deciding." Until they are in this state, they remain pending.

The criteria for entering the Decided state are as follows:

• It must have undergone a lead-in period, which is the amount of time that must pass before a decision can begin. This helps reduce the likelihood of "decision sniping," where an attacker controlling a large amount of voting power might pass a proposal immediately after it is proposed, rather than allowing all voters enough time to consider and participate.
• There must also be remaining space for decisions. All Tracks limit the number of referenda that can be decided simultaneously. Tracks with more powerful capabilities will have lower limits. For example, the limit for a Root level Origin is 1, meaning only one super-critical proposal can be decided at a time.
• A decision deposit must be paid. The cost of creating a referendum is low because the deposit value only includes the value of the on-chain storage needed to track it. However, reviewing and deciding on referenda carries the risk of exhausting the limited positions in the referendum queue. Requiring a larger but refundable deposit helps reduce spam.

Council Referenda (v1)

Council unanimous approval - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will produce a negative voting rate bias (i.e., the fewer the number of stake votes, the fewer the number required for approval ------ see Adaptive Quorum Biasing[2]).

Council majority approval - When only a simple majority of council members agree, a referendum can also be voted on, but it will be a majority vote (the side that receives 51% of the votes wins).

At any given time, there can only be one valid referendum, unless there is an ongoing emergency referendum.

Voting Schedule

In Governance v1, assuming there is at least one proposal in one of the queues, a new referendum will occur every 28 days. There is a queue for proposals approved by the council and a queue for proposals submitted by the public. Voting will alternate between the top proposals in the two queues.

The top-ranked proposal is determined by the amount of stake bound behind it. If the current queue chooses to attempt to create a referendum without proposals (queue is empty), the top proposal from the other queue will enter the referendum.

Multiple referenda cannot be voted on in the same period, except for emergency referenda. Emergency referenda occurring simultaneously with regular referenda (public or council proposed) are the only situation where multiple referenda can be voted on at the same time.

When a proposal is approved, Governance v2 shares the same 28-day qualification period. If it is not approved by the end of this phase, the proposal will be automatically rejected.

Referendum Voting (Governance v2)

In Governance v2, if a proposal meets the requirements for approval rate and support rate, it will be approved, thus removing the adaptive quorum bias system.

Approval rate is defined as the weight of approval votes (after conviction adjustment) as a share of the total voting weight (including approvals and rejections).

Support rate is the total number of approval votes (ignoring conviction adjustment) compared to the total number of votes that could potentially occur in the system.

It must meet this standard within the shortest time of the confirmation period. Different Tracks have different confirmation periods and approval and support requirements. It is now possible to configure the required amount of support and overall approval. For proposals using lower privilege origins, it is more reasonable to lower the required voting rate to a more realistic number earlier compared to proposals using high privilege categories (e.g., Root). Courses with significant political implications may require higher approval earlier to avoid controversy.

In Gov2, proposals that are not approved after 28 days will be considered default rejected, and the Decision Deposit will be refunded. If the proposal manages to remain approved before the end of the confirmation period, it is considered approved and scheduled for execution starting from the proposed origin after the drafting period. The drafting period is specified when the referendum proposal is made but is also subject to minimums based on the Track. More powerful Tracks will enforce longer execution periods to ensure the network has enough time to prepare for any changes the proposal may bring.

Voluntary Locking

Polkadot uses a concept called "voluntary locking," which allows token holders to increase their voting power by declaring how long they are willing to lock their tokens. Thus, each token holder's voting power will be calculated using the following formula:

Voting Power = token * conviction multiplier

The locking period doubles the voting multiplier, and the conviction multiplier increases the voting multiplier by one.

Locking period voting multiplier 00.111224384165326

The maximum number of times the locking period can "double" is set to 6 (thus a total of 32 locking periods), with one locking period equal to 28 days. Doubling is only allowed; for example, you cannot lock for 24 periods and increase your conviction by 5.5. For more information on the governance event timeline, please refer to the governance section on the Polkadot parameters page[3].

Once tokens are locked, you can still use them for voting and staking; you are only prohibited from transferring these tokens to another account.

Votes are always "counted" at the same time, i.e., at the end of the voting period. This is not affected by the token locking period.

Adaptive Quorum Bias

Adaptive quorum bias was used for a longer time in Governance v2 and has been replaced by the Approval/Support system.

Council

In Governance v1, passive stakeholders on Polkadot are represented by a governing body called the "Council." The council is an on-chain entity composed of multiple participants, each representing an on-chain account. The council currently consists of members on Polkadot.

In addition to controlling the treasury, the council is primarily responsible for three governance tasks:

• Proposing wise referenda
• Canceling dangerous or malicious referenda
• Electing the technical committee

In Governance v2, an alternative strategy is needed to replace the council's previous role as a delegate institution for voters, compensating for the fact that many choose not to participate in daily governance. Gov2 builds on the voting delegation functionality of v1, allowing voters to choose to delegate their voting rights to another voter in the system. It does this by improving a feature called multi-role delegation, where voters can designate different representatives for each category of referendum in the system. Thus, for example, a voter can delegate a certain entity to manage a category of referenda with less impact while choosing a different representative to manage another category with more significant consequences, while still retaining full voting rights over any remaining categories.

Canceling Referenda

In Governance v1, a proposal can be canceled if the technical committee unanimously agrees to cancel it, or if a Root origin (e.g., sudo) triggers this function. The deposit of canceled proposals will be destroyed.

Additionally, a two-thirds majority of the council can cancel a referendum. This may serve as a last resort if issues with the referendum proposal are discovered late (e.g., an error in the runtime code that the proposal will execute).

If the controversy over the cancellation is significant enough that the council cannot achieve a two-thirds majority, the fate of the proposal will be decided collectively by the stakeholders.

In Governance v2, there is a special operation called Cancellation, which is used to intervene in proposals that have already been voted on. This operation will immediately reject the ongoing referendum, regardless of its status. There is also a provision that ensures the proposer’s deposit is forfeited if the proposal is malicious or spam.

Cancellation itself is a governance operation that must be executed by network voting. Cancellation comes with its own Origin and Track, which has a very short lead-in period and approval/support rate curves, where the passing thresholds drop slightly faster because it is invoked in urgent situations.

Technical Committee

In Governance v1, the Technical Committee (hereinafter referred to as TC) was introduced as one of the three houses of Kusama governance (the other two being the council and referenda) in "Kusama Rollout and Governance" https://polkadot.network/blog/kusama-rollout-and-governance/. The TC is composed of teams that have successfully implemented or defined the Polkadot runtime or Polkadot Host. Teams can be added or removed from the TC by a simple majority vote of the council.

The purpose of the TC is to prevent malicious referenda, implement bug fixes, reverse erroneous runtime updates, or add new but battle-tested features. The TC has the authority to expedite proposals using the Democracy pallet and is the only source that can trigger the proposal acceleration feature. We can think of the TC as the "only source" that cannot generate proposals but can accelerate existing proposals.

Fast referenda are the only type of referendum that can occur simultaneously with another referendum. Thus, through fast referenda, two active referenda can occur at the same time. Voting on one will not prevent users from voting on the other.

In Governance v2, a new successor committee called the "Polkadot Fellowship" has been introduced to replace the Technical Committee. It will serve the Polkadot and Kusama networks. Please see below for further details.

Polkadot Fellowship

The Fellowship is a fundamentally autonomous expert body whose primary goal is to represent individuals with technical knowledge of the Polkadot network and protocol. The Fellowship classifies members through "levels" to represent the wisdom of their viewpoints, the quality of their technical foundation, and their alignment with the interests of Polkadot.

Unlike the current Technical Collective, it aims to expand the membership base (i.e., accommodating tens of thousands of members) and has a much lower entry barrier (in terms of governance processes and expertise expectations). Becoming a candidate member of the Fellowship is simple, requiring only a small deposit.

Fellowship members can vote on any given Fellowship proposal, and the aggregated opinions of members (weighted by level) constitute the Fellowship's considerations.

The voting mechanism for the Fellowship is the same as that for Polkadot stakeholders voting on proposed referenda.

Level System

So how does this level system work?

To prevent a small number of participants from gaining effective control over the network, the system adheres to three main principles:

1. The Fellowship must never have hard power over the network: it cannot change parameters, implement fixes, or move assets. Their only power in governance is the ability to shorten the timeline for referenda to occur.
2. The Fellowship gives more weight to those at higher levels in the overall opinion, but this weight should not be so high compared to the consensus from lower-level members that the opinions of a minority of higher-level members cannot be surpassed.
3. The Fellowship should aim to grow and develop the overall level of its members and their expertise, ensuring that its overall decision-making capability becomes stronger over time. To support these conditions, the Fellowship will establish a charter outlining the requirements and expectations for individuals to gain and maintain a certain level. Higher-level individuals can vote and promote lower-level individuals according to this charter.

Demotion will occur automatically if a member cannot prove their status to other members after a given period.

Suspension can only occur through a referendum, ensuring that the biases of the Fellowship itself do not necessarily lead to expulsion.

To prevent the Fellowship from becoming a cabal (the mere reputation of the Fellowship is insufficient to attain the highest level), attaining the highest level will require a referendum.

If you wish to apply to join the Fellowship or learn more about how it operates, please read the "Detailed Documentation on Polkadot Fellowship."

Whitelist

The Whitelist pallet does one thing: it allows one Origin to elevate another Origin's privilege level for a certain operation.

In Gov2, it allows the Fellowship to authorize a new origin (called Whitelisted-Root) to execute with Root-level permissions and will only be used with certain specific commands authorized by the Fellowship. The Whitelist pallet verifies two things:

1. The origin is indeed Whitelisted-Root (i.e., this referendum has passed on this Track)
2. The proposal has indeed been whitelisted by the Fellowship. If both conditions are met, the operation is executed with Root-level permissions.

This system allows for a new parallel Track (Whitelisted-Root Origin), whose parameters allow for shorter voting periods. Through a transparent process, the global expert community of the Polkadot protocol has determined that this operation is both safe and time-sensitive.

Blacklist

A proposal can be blacklisted by a Root origin (e.g., sudo). Blacklisted proposals and their associated referenda (if any) will be immediately canceled. Additionally, the hash of the blacklisted proposal cannot reappear in the proposal queue. Blacklisting is useful for removing erroneous proposals that may use the same hash, such as when a submitter suggests a proposal in plain text in the second proposal.

After seeing their proposal deleted, submitters who are not well-versed in the Polkadot democratic system may attempt to resubmit the same proposal. That said, this is far from a foolproof method to prevent the submission of invalid proposals—the change of a single character in the proposal text will also change the hash of the proposal, thus invalidating the blacklist generated by the hash.

More Information

• Introduction to the Original Governance System[4]
• Democracy Pallet[5]
• Governance Demo[6] - Dr. Gavin Wood explains the initial governance structure of Polkadot (video)
• Governance on Polkadot[7] - An online seminar explaining how governance works on Polkadot and Kusama
• Governance v2[8]
• Polkadot Direction[9] discussion group
• Kusama Direction[10] discussion group
• PolkAssembly[11] governance website

References

[1] This chapter. : https://wiki.polkadot.network/docs/learn-gov2#council

[2] Adaptive Quorum Biasing: https://wiki.polkadot.network/docs/learn-gov2#adaptive-quorum-biasing

[3] Polkadot Parameters Page: https://wiki.polkadot.network/docs/maintain-polkadot-parameters#governance

[4] Introduction to the Original Governance System: https://github.com/paritytech/polkadot/wiki/Governance

[5] Democracy Pallet: https://github.com/paritytech/substrate/tree/master/frame/democracy/src

[6] Governance Demo: https://www.youtube.com/watch?v=VsZuDJMmVPY\&feature=youtu.be\&t=24734

[7] Governance on Polkadot: https://www.crowdcast.io/e/governance-on-polkadot--

[8] Governance v2: https://medium.com/polkadot-network/gov2-polkadots-next-generation-of-decentralised-governance-4d9ef657d11b

[9] Polkadot Direction: https://matrix.to/#/#polkadot-direction:matrix.parity.io

[10] Kusama Direction: https://matrix.to/#/#kusama:matrix.parity.io

[11] PolkAssembly: https://polkadot.polkassembly.io/

[12] https://wiki.polkadot.network/docs/learn-gov2: https://wiki.polkadot.network/docs/learn-gov2