本記事は、STAKED technologies FounderのそうたによるPolkadotのガバナンスに関する記事を英訳しました。
Summary of Polkadot Governance
** Why is Governance important? **
Public blockchain makes "distribution" and "decentralization" an important objective. Community makes the decisions instead of traditional decision makers. It is important that the mechanisms by which community makes decisions are pre-defined. (This is also true for democratic nations) Being the front-runners, Ethereum and Bitcoin have not put much focus on governance, but Polkadot, which is a newcomer to the space, has a thought-through on-chain governance, which will be summarized here.
- All proposals for protocol changes go through public voting, regardless of where it was submitted to: the public or the council.
- Below is the process until proposal is implemented
- Voting is proposed and enters the queue (bottom right in the figure) (2 weeks)
- Proposals with the most stakes proceed to vote
- Votes are aggregated
- Voting is enforced
- All shapes are determined by Yes, No
- Voting system is weighted by staking and all changes are made through this system. Every two weeks proposal with the highest amount staked will be voted and DOT holders can vote by locking the token for any period of time. There is an enforcement delay (a grace period before the change actually takes effect) after the vote is completed. Enforcement calls a sudo privilege called "set_code".
- An organization comprised of 6 to 24 on-chain accounts, making changes and canceling malicious proposals that are important to the ecosystem
- Term is 12 months
- 6-12 initial members. Seats are increased by one every two weeks, and eventually consisted of members decided in the election (described later)
- Anyone can propose by staking the minimum DOT (about $50) for a certain period. Proposals are queued in a stake order, and if youagree with a proposal, you can support it by staking an additional DOT for the same amount. The tokens being staked are returned to the owners as soon as any of the proposals have been voted.
- Council (unanimous)
- If all members agree with the proposal, the proposal goes directly to the vote without going through the queue. Also, Negative Turnout Bias is required for voting.
- Council (majority)
- If the majority of members agree with the proposal, the proposal goes directly to the vote without going through the queue. Also, voting is a simple majority.
Also, voting is done by tokens, and the weight of voting is represented by
number of tokens locked for voting × lock period
Aggregation of voting results
There are three ways to collect votes.
- Simple majority
- No explanation required
- Adaptive case: majority of Council members agree/vote 100% (almost impossible)
- Positive bias vote
- The required approval rate is 50% to 100%. By requiring more votes, it biases maintaining the status quo (most stable). In the figure above, if the voting rate is 25%, the required votes are adjusted to 66%.
- Adaptive case: Voting rate is less than 100%
- Negative bias vote
- Need more negative votes to reject a proposal. It is clear that the union of the council is an important proposal for the ecosystem, which makes voting easier.
- In the case of a voting rate of 25%, pass with 34% or more, and even with 75%, pass with 46%.
- Adaptive case: unanimous meeting