Voting and democracy in Cryptoland: EIP-999
Introduction.
Voting on proposals for a crypto project is not a panacea. Frequent votes that have been ill-constructed can be as troublesome as having none.
How the Ethereum community deals with this Parity wallet resolution is an interesting mini case study in crypto governance, the value and power of the community’s voice…and whether and when its needed.
Background.
On 6th November 2017, the Parity multi-sig wallets created since 20th July were ‘accidentally’ frozen by a now infamous noob, devops199. The result? 584 frozen wallets, containing some 513,473 ETH, currently worth $330mn. Due to the more professional nature of multi-signature wallet users, the victims are mostly limited to ICO projects operating these wallets (Polkadot, c300k ETH, Iconomi c100k ETH, Musiconomi c15k ETH).
Parity developers have been working on various solutions to restore the frozen funds. Initially they were looking at state changes that would result in hard forks to restore the balances. Recently they are focussing on a proposal, EIP-999, whereby a patch is deployed to restore only the affected wallets, leaving the broader EVM unchanged and so it seems no longer requiring a fork. This is much more amenable than a fork solution but still not without controversy.
EIP-999, a community issue.
Even though the number of users and the sum of ETH involved is far less than the 3.6mn ETH and 11k users of the 2016 DAO hack, the community is paying close attention to how this issue is resolved.
Of the various arguments being debated around this Proposal, the ones that I find the compelling are,
In favour of amending the balances:
a) To prove that Ethereum has a safety net, allowing developers and users to experiment with the nascent technology without fear of critical mistakes. Allowing faster development and innovation.
b) It could possibly be implemented without a hard fork, leaving other Ethereum applications or users uninterrupted.
Against amending the balances:
a) It was a mistake, not a malicious attack. Errors should have accompanying costs to prevent an otherwise never ending stream of moral hazard.
b) Safety nets should be preserved for serious, protocol level errors.
At the heart of the dispute is the classic debate on the degree of immutability that a blockchain should possess. While there is no disagreement that one of the key attractive features of a mature blockchain platform is its immutable record of history, the evolutionary battle-testing process of blockchain development is expectedly not without mistakes. Being able to correct and update the technology in an incremental way is important but one that must be balanced with its costs. Moral hazard and a severe loss of credibility is what await blockchain projects that are too eager to smooth every wrinkle.
Voting on the Parity proposals:
There is currently a coin vote running for the Parity wallet proposal, EIP-999 here. So far almost 4mln ETH has been voted ($2.7bn) with ‘No' in the lead at 56%.
Rather than assigning one vote per user or address, the system gives a vote per 1 ETH. Whist leading to the obvious cries of elitism and centralisation, this is a refreshing simple and effective solution for assigning voting power for decisions amongst shared stakeholders. As long as the large holders/voters own the same asset and benefit from this asset in the same way as the smaller holders/voters, then incentives are aligned. *see comment section below for further discussion on this*
An ETH whale or mining pool will not put their weight of vote behind a proposal that could negatively impact the market cap of ETH in the long run (though with upgrades such as the transition from PoW to PoS, incentives are not aligned between the large and small holders at inception due to the differing value accretion of block rewards vs capital appreciation of a hodler). This is NOT similar to assigning votes based on wealth (or tax amount paid) in a real-world ‘democracy’. In this scenario, the interests and exposures of the wealthy are clearly not aligned to those who are considered too poor to cast a vote.
However, there are several problems with the ongoing EIP-999 vote that may reduce the conclusiveness that this process should otherwise have brought.
1) Signing, not transferring. Vote casting on etherchain.org is done by signing a message from an ETH account rather than transferring an arbitrary amount (the method used by carbonvote). This not only means that a dead/frozen wallet can still vote but a multi-sig wallet can be voted by the creator- an individual who besides not being a multi-signature may not even be a registered signature on the wallet. Because of this oversight, it appears that the very same Polkadot wallet that is frozen and under debate has voted for the ‘Yes’ camp. See here for full Reddit explanation.
2) Cronyism? As pointed out here, why should the Parity locked funds take priority over the numerous other accidentally frozen funds due to user errors eg amounts sent by accident to dead wallets such as this zero wallet. Ethereum co-founder, Gavin Wood, being behind both Parity and Polkadot, the biggest victim of the incident makes certain criticism fairly obvious.
3) Voter representation. Many real-world referendums are invalidated if less than a threshold amount of voters take part. For example, Denmark requires a 30–40% participation and Italy, greater than 50%. By comparison, the highly important DAO vote in 2016 had only 4.5% participation!
Regardless of the outcome, the community is obviously getting frustrated with this topic. The contract WithdrawDAO, holding $140mn of ETH voted today for a resounding ‘don’t care’. Which begs the question, what if the ‘winning’ majority holds less than 51% of the signed ETH? This will surely invalidate and trivialise the outcome of this vote even further.
Solutions?
Votes should be held rarely but when doing so, ensure they are better constructed and better publicised. In the meantime, investors should be able to rely upon representative democracy and accompanying communication in aligning the token’s value with it’s viability.
I believe that a credible project should only tinker with their blockchain’s immutability in the most severe of cases and that retroactive ‘safety nets’ should be saved for serious, protocol level errors. In this case, Parity was operating on top of Ethereum. Why the users of other Dapps on the Ethereum ecosystem should be punished for a Parity developer mistake, explicitly if a hard fork or implicitly via moral hazard, is difficult to argue. Moreover, the desire to have a ‘safe’ environment for developers and users to trial these technologies is in direct opposition to the market valuations of these projects. If the crypto community is to justify the $350bn of expectations that the world is placing on it, the degree of professionalism and rigour needs to rise to meet this. Creating this technology is very difficult but fortunately, the rewards are commensurate.
The question then becomes, what constitutes such a ‘severe error’ with wide enough implications to warrant opening the can of immutability worms? Are the average token holders (holders) sufficiently informed or sufficiently interested to vocalise their views (clue is in their name)? And more so, what’s to stop this sliding scale of ‘severity’ from descending into continuous plebiscites, sapping the already stretched resources from core developer teams?
I believe that deferring to the age-old system of representative democracy and accepting a degree of centralisation here can reduce these issues. In its simplest form, by holding an ETH token you are implicitly agreeing with how Vitalik and the core devs plan to run the project. Or taken a step further (eg DPoS), groups of token holders can regularly select parties to act on their behalf. In doing so, you are handing over decision making on all but the most contentious issues to these experienced and professional individuals who have the most information with which to make the decisions. If you don’t like the decisions they are making or you don’t like their ethos, then sell ETH and buy something else; or fork the network if the decision is really that polarising. How are these actors held accountable? By having the same incentives as the affronted token holder, maximising the market cap of ETH. Opponents of this form of blockchain centralisation have been likened it to a (benign) dictatorship; but this is too far. Whilst it’s very hard for subjects of a real-world dictatorship to escape their leader, in crypto-land, all it takes is a Coinbase account.
In order for this to be an acceptable substitute for full decentralisation, the information and visibility that regular token holders receive has to improve. Given the growing monetary firepower of these crypto projects and the elevated position in the financial landscape that they are targeting, complete with institutional-scale players, the very least that a crypto project should have is an ‘investor-relations’ team.
The core dev team should be aware of the community’s views and voice but should not be explicitly deferring to them for guidance at all turns. If given enough information and an accompanying freedom to choose between projects, free-market forces can help us to a path that maximises protocol value.
Conclusions:
Although the idea of frequent votes may seem at first like a desirable feature of a decentralised system, without an accepted method of prioritising and conducting them their outcomes risk infuriating rather than informing the community.
Decentralisation and immutability are two key components and attractions of blockchain projects. However, unless they are being employed effectively it can be detrimental to a project’s advancement to be inflexibly handcuffed to these concepts. Both concepts are a sliding scale and the most successful projects and investments will recognise this, engaging and explaining this to the community along the way, using well designed votes for rare circumstances.
If the available information and visibility improve, the cost of lessened decentralisation or an occasionally altered history can be reduced.
///
Follow me on twitter @cryptobonsai
