If you're coming to Polkadot from Ethereum – whether out of curiosity or necessity – you're probably wondering how they differ. This series will help you learn exactly that. Note that we assume basic knowledge of Ethereum 2.0.
In a previous part, we explained how the two systems approach sharding: the splitting of transaction throughput workload across many smaller connected chains. We recommend starting there.
In this part, we're covering governance.
Governance
The term governance or, more specifically, on-chain governance implies being able to formally and verifiably vote on decisions regarding the blockchain's evolution.
Ethereum
Ethereum has no on-chain governance and will probably never have such a system as it's incredibly difficult – from a political perspective – to add governance into a system post-launch. The decision-making is ultimately social which can be dangerous for the health of the network due to effective lobbying and some groups being better funded or being better at persuasion. Given that it's a smart contract platform, Ethereum has the means to let people signal their opinion both as miners through signing blocks when submitting them to the network, and through smart contracts and coinvotes:
However, neither of these options is formal nor do they any carry real weight. They might be good indicators of stakeholder preference, but as they are not built into the chain's core as decisions that have immediate consequences, they are often disregarded entirely.
Up until recently, Ethereum's governance has progressed smoothly, but as in any system with embedded value, special interests will form in time. This is especially true if there are ways to secretly take advantage of certain properties of the environment for personal gain. The ProgPoW discussion is outside the scope of this article, but is nonetheless an interesting case of where a formal on-chain voting process may have come in handy to resolve the conflict sooner.
Polkadot
Polkadot comes with governance built-in from the start.
In what's called a tricameral (three chambers) governance system, Polkadot is governed by three groups of stakeholders the members of which can and often do overlap: the technical committee, the council, and stakeholders (any DOT holder, including the previous two groups).
The stakeholders are owners of DOT tokens. All stakeholders can propose referenda – changes to the system. This can be anything from number of parachain / validator slots available, to payout fees, treasury expenses, and even runtime (logic) updates like, for example, activating or deactivating a certain module.
The Council consists of 6 to 24 seats (the number grows as the network evolves) occupied by stakeholders who have indicated interest in participating in the direction of the network's evolution. These will be enthusiasts, developers, VCs, large stakeholders, tool builders, dapp users, and more. To become a Council member, one must signal their intent to do so on-chain by sending a special transaction, at which point general stakeholders can vote for them. The top X picks (with X being anything from 6 to 24 at the time) make it into the elected cycle and stay there until it's time to pick a new Council.
The Technical Committee (TC) are the different teams implementing the Polkadot Runtime and Polkadot Runtime Environment. They are voted in by the council by a simple majority carries decision. The same applies when members have to be removed. The TC has only one special ability – fast tracking proposals made by the Council or the stakeholders. If a proposal is an urgent fix or something that's worth speeding along, the TC can vote to speed it up and dramatically decrease the regular voting period and almost completely remove the implementation (enactment) delay. It's important to note that in order for a proposal to be fast-tracked, 75%+ of the Council needs to vote to fast track it, and 66.6%+ of the TC needs to do so as well.
Side note: in Ethereum, members of the Technical Committee would be teams like Nimbus, Chainsafe, the Ethereum Foundation, Pegasys, Prysmatic, Parity, Sigma Prime, and others that are developing Ethereum 2.0 clients.
The Council can influence the urgency of a referendum (as we've noted in the TC case above) and the voting type on a referendum: When a referendum is proposed by anyone, the Council can indicate its support for it. If it's a minority, there's positive turnout bias (bias towards status quo – the proposal is biased towards failing unless a majority turnout of "aye" votes appears); if there is a majority of council members approving it, then there's no bias (majority carries); and finally, if and only if there is unanimous support from the council, there is negative turnout bias (bias towards approval – more "nay" votes would be required for it to fail). Both biases tend towards majority carries (simple 51% win) as the turnout approaches 100%.
IMAGE
Votes are plutocratic in a one-coin-one-vote way, but can get a buff by the voter indicating the desire to lock the tokens in the vote for a period of time. Quoting from the Kusama Rollout and Governance post by Gavin Wood:
All voters are required to hold for the 30 day period up until the enactment date in the case that “their side wins” (if not then they are otherwise free to sell and leave the network). Those willing to hold for twice as long gain an additional vote. This is the case for up to five additional votes (i.e. those willing to hold for approximately two and a half years gain six votes). Those unwilling to hold at all may still vote but with a 90% reduction in power compared to those who hold for the four week minimum.
It should be noted that making proposals for spending the Treasury's funds requires a deposit of 5% of the target amount which is burned if the proposal does not pass, and that the Treasury has to burn some of its remaining funds if not all funds are spent every period of 24 days. Both of these mechanics make for some deflationary pressure.
Another type of proposal is the Treasury spending proposal.
The Treasury is an on-chain vault of tokens intended to be spent by the voters on community and development efforts. Proposals to spend Treasury money are voted on by the Council, not the public, but can be created by either the public or the Council.
In the next part, we'll talk about token economics and explain the Polkadot Treasury.
Missed the previous part on sharding? Read it here!
