Many folks have contacted me with their ideas for why the default voting settings of the EOSIO Software should be something other than Approval Voting.
To be specific, the EOSIO Software by default gives each account 30 Approval votes for Block Producers (BPs). Given a list of N candidates, the voter may tick those whom they are willing to have as BPs, up to 30. The system (again by default; this is all customizable) selects the top 21 vote-getters to be Active Block Producers (BPs) and the next 49 or so vote-getters as Standby BPs. Candidates in 71st place and below are ignored by the system for purposes of BP status.
Furthermore, each account votes with a power equal to its number of staked tokens. Thus Alice with 100 staked tokens votes with a power of 100 for each of her 30 favorites; Bob with 50 staked tokens votes with a power of 50 for his 30 favorites. If BP candidate ‘EOSfoo’ is ticked by both, then EOSfoo is credited with a score of 150.
Why Approval voting?
My understanding of the literature on voting is that Approval voting is slightly less effective than Score (aka Range) voting, but both Score and Approval voting outperform Rank (aka Preference) voting.
I encourage the curious to enjoy the voting method simulator here.
Problems with Rank voting were understood dating back to the 1950s; see Arrow’s Impossibility Theorem.
Eliminating Rank voting due to Arrow’s findings, we can look at a Bayesian analysis of the remaining options — scroll down until you see the following graphic from page 239 of William Poundstone’s book Gaming the Vote:
The options are:
1. Pick someone at random
2. Plurality voting (current US standard)
3. Borda count
4. Condorcet method
5. Score (aka Range) voting
6. Approval voting
You’ll see that Score is a bit better than Approval, but Approval is much simpler and outscores everybody else.
This simulation is for single winner elections — it gets a LOT harder with a ballot method that seeks to elect 21 BPs. Here, simplicity and effectiveness are on our side when we pick Approval voting.
Which is why we’re using Approval voting as the installed default method in EOSIO.
If you’d like to see EOSIO use a different system, I encourage you to submit a Constitutional Amendment after the chain goes live, or persuade the majority of BPs and voters to install a different default at launch. (If you’re using EOSIO for a private or alternative chain, you of course are free to install any default voting system you like.)
Why 30 votes per account, and not just 1?
A collaborator in the EOSIO community, Todor, created his own simulation of EOSIO BP Approval voting with each account getting everything from 1 vote to 50 votes each. His math indicates that the risks, particularly of a chain being taken over by a minority using collusion, are actually lower with 30 votes per account rather than one vote per account.
For me, the fact that multiple votes per account has been a stable and successful feature of both BitShares and SteemIt for the past few years, is a good sign.
Why stake-weighted voting power?
In the real world, we are all used to elections featuring one person, one vote. (At least in theory.) Many DPOS blockchains, again including both BitShares and SteemIt, use stake-weighted voting. This is sometimes called (a bit confusingly) “one token, one vote” but it’s actually 30 votes per account, and each vote has a power (as described above) equal to the number of staked tokens owned by that account. Each BP’s vote total is equal to the number of staked tokens that were voted for them.
Isn’t that an Oligopoly, or a Plutocracy — rule by the rich?
Well, yes. Blockchains are exclusively property based; they don’t run prisons and they can’t prosecute people for violent crimes, define or defend national borders, or maintain standing armies. The very reasons that make “one person, one vote” so important in a real-world government, are simply not present in a property based blockchain. And having more tokens might give you more power — it also puts you at greater risk.
To own more tokens is to be more exposed to negative outcomes on that blockchain.
Beyond the Plutocracy
Nevertheless, there have been several suggestions that the EOSIO Software should allow for multiple ‘centers of gravity’ around voting — that the current token-centric voting model be balanced by an additional, separate voting method. Candidates for this have included:
- One strong-identity person, one vote (where “strong identity” meets some explicit criteria for proof of humanity)
- One DApp developer, one vote (or a sliding scale of voting power controlled by DApp popularity) as described in detail here.
- One Block Producer, one vote
- One on-chain vendor, one vote
- …and so on.
These have been floated as existing in parallel with the token-based voting system, where the token-weighted voters are a sort of House of Lords (House of Whales?), and the other a House of Commons (or House of DApps or whatever).
The general plan would be for large system decisions (Constitutional amendments, protocol upgrades, etc.) to require a majority or even supermajority vote in both Houses.
None of these ideas for multiple Houses has been experimented with on public blockchains yet, and I am excited to see how they fare once they are tried.
None of these ideas is fully developed enough to be in the default software settings for EOSIO in time for a June launch.
Fortunately, the EOS community is empowered to alter the default Constitution in two ways — by adopting a different Constitution at launch, and by amending the adopted Constitution after launch, using the amendment process.
In sum, we can expect an EOSIO Software based blockchain to use Approval voting. Approval voting has a decent track record in other DPOS blockchains, and this one has been tweaked to respond to issues in those prior implementations.
We can expect Approval voting to result in a reasonably good outcome (and far better than most other voting systems). We can expect it to have a reasonably simple user experience (just pick up to 30 you approve of) — depending on what interfaces the community creates (or just use the command line tool).
Most importantly we can expect the voting, within the limits of a stake-weighted system, to result in a good-enough choice of Block Producers.