Table of contents
Polkadot governance
This section documents various proposed governance improvements for Polkadot, Kusama, and network-alikes.
Council Keep-Alive
Historically, many councils in Polkadot-alike networks suffer from inactivity issues. The councils are also suffering some additional problems.
-
A motion can span across multiple council terms. In this case, when council memberships change, old votes become invalid. Council can also be with seats empty, and this can cause a council motion to become totally invalid due to required approval count when a new council term begins.
-
The difference between no-vote and abstain is blur. In the past, some council members have indicated that they do not have strong preferences over some council motions, or they need more time to think about it. Currently, it is hard to differentiate that from simple inactivity.
-
The current council design does not promote thoughtful council discussions. Rather, it simply encourages people to either immediately vote or to remain in abstained status.
Council period and term
Define council period as \(P\). A council term is \(2P\) and council elections happen every council term. A council term begins with a \(P\)-length proposing period, and ends with a \(P\)-length voting period.
Proposing period
During the proposing period, all council members can propose council motions (for as many as they want). The motions are recorded on-chain, but unvoted. It is expected that council members use this period to thoroughly discuss motions, before reaching any conclusions.
Council motion semantics remain unchanged. It will still require at least
threshold votes (as defined in the motion) to pass.
Voting period
Once the proposing period ends, all proposals during that period enters voting status in the voting period. No new motions can be proposed during this period.
Instead of voting on individual motions, council members submit a full council
report via a new extrinsic council.submitReport. The report is a list of tuple
of (motion_id, pref) where pref can be Aye, Nay or Abstain.
A council report cannot miss any votes. Missing-votes council reports are
invalid, and council.submitReport will reject any such extrinsics. The goal
here is to make sure all motions under the current voting period are considered.
Motion approval
At the end of the voting period, motions enter one of the following status.
-
Approved if more than or equal to threshold council members voted Aye. The motion passes and gets executed.
-
Rejected if more than
(total - threshold)council members voted Nay. The motion is rejected. -
Delayed if none of the above happens. Indicate that council members haven’t made up their minds. If not enough people voted Aye and not enough people voted Nay, then the council motion will be delayed, and voted again in the next council term’s voting period (by entering the next proposing period).
Aliveness check
By the end of the voting period, if a council member fails to submit a council report, then it is removed from the next election’s candidacy list. This simply gives other runners-up a chance to join and does not imply any ill-will. Candidate votes are kept, and the previous council member can later submit candidacy again to become active.
With aliveness check and an explict abstain vote option, we can expect council members to be more active, and as a result, the notion of "prime member" does not hold any special rights any more.
Emergency motion
In some occasions, emergency motions have to be proposed. For them, we design a special motion category. Emergency motions are voted as soon as it is tabled. Emergency motion only lasts time \(E\) (recommended to be only several hours) and there is only one voting choice — Second. If more than threshold council members seconded an emergency motion, then it passes and gets executed. If less than threshold council members seconded an emergency motion, then it is rejected.
Blind voting for Polkadot
Currently, voting results of a democracy referendum are published in real time. If a user holds an opposite opinion of what the current "majority" thinks, one may be hesistant to express oneself. If a large group of users do this, we may lead to a situation of a "silent majority". This system also gives some unfair advantages for those who vote very first (because they can influence the initial sentiment of the public), or those who vote very last (because they will have a good idea how much they should use to vote and lock in order to sway the voting results around).
This proposal changes the voting rule so that we divide the voting period into two phrases. In the first phrase, everyone votes blindly, by publishing a pre-image hash onto the blockchain, and then in the second phrase, the pre-image is revealed.
Specification
Divide the voting period into two phrases, blind voting phrase and revealing phrase.
Change democracy.vote. It still takes vote value and conviction in cleartext.
However, the voting choice "Aye" or "Nay" is changed as follows:
-
In blind voting phrase, every voter generates a 32-byte secret, and compute the hash of SCALE encoding
(secret, AYE)if one wants to vote Aye, or(secret, Nay)if one wants to vote Nay. -
The voter then publishes the hash to the blockchain. As the vote value and conviction at this stage is cleartext, the coin is then locked for the specified enactment.
-
In revealing phrase, every voter reveals the preimage. The 32-byte secret is then discarded, and the voting choice Aye or Nay is recorded.
-
Once the releaving phrase is finished, the referendum is accepted or rejected based on the current voting rules.
Allow explicit abstain in adaptive quorum biasing
Allow explict abstain votes, for voters who really don’t have an opinion on a referendum, but still wants to participate in governance. In case of adaptive quorum biasing, abstain votes are counted in the total turnout.
Specification
Add a third type of choice for voting — abstain.
In case of adaptive quorum biasing, the voting result is calculated as follows, where \(T\) is the total issuance, \(Aye\), \(Nay\) and \(Abs\) are the total number of coins voted Aye, Nay and Abstain respectively.
-
For a super-majority approve referendum, we calculate if \(\frac{Nay}{Aye + Nay + Abs} < \frac{Aye}{T}\)
-
For a super-majority against referendum, we calculate if \(\frac{Nay}{T} < \frac{Aye}{Aye + Nay + Abs}\)
Candle voting for governance referendum
The participation rates on Polkadot referendum are still quite low — less than 1%. Many don’t vote because the referendum is already of their desired outcomes. However, it is currently extremely vulnerable to an adversary swaying the outcome last minute (it only takes couple thousands of worth of DOTs). Rather than trying on the direction of improving participation rates (which we have arguably failed to do), this proposal tries to trackle it from another direction by allowing people to continue their current behaviors, while trying to protect everyone from last minute swaying, by using candle voting.
Specification
Split the voting period into two parts. The first part takes \(\frac{5}{7}\) of the current voting period time, and the second part takes \(\frac{2}{7}\) of the current period time.
-
During the first part, voting happens as normal, unchanged.
-
During the second part (also called the ending period), voting happens as normal. However, at the end of the total period, voting is decided to have ended in an earlier block number during the ending period, by an on-chain random number generator.
This way, an adversary trying to sway a referendum outcome last minute has a high chance of failing. If the adversary tries to vote during the last minute of the first part, then other participants can quickly react during the beginning of the ending period. If the adversary tries to vote during the last minute of the second part, then there is a high chance that the voting will have been decided to have already ended.