One of the fundamental aspects of blockchain design is the development of blockchain governance mechanisms. Blockchain governance, in simple terms, is the mechanism by which design changes are enacted on a blockchain. A governance system which encourages the ability to adapt and evolve to change is key in a blockchain that aims to be successful long-term.
In essence, the process of change on a blockchain is enacted via changes to the underlying code that the blockchain protocol runs on. In most cases, there is a centralised repository of code that forms the basis for the “clients” that stakeholders use to run nodes. An example of this could be the Ethereum foundation codebase — found here — and its respective clients Geth and Parity — found here and here respectively. These codebases typically contain specifications for the major parts of the protocol, such as block size, mining difficulty, transaction fees and other similarly critical system parameters. Governance is simply the decision making process which leads to changes to these parts of the protocol, whether it be additions/subtractions or alterations of the codebase.
Probably the best way to evaluate blockchain governance is to conceptualise how a governance system handles its participants and their economic incentives. Each group of stakeholders within a blockchain have a different set of incentives. Groups will typically pursue changes to blockchain systems that align with their own interests, such that groups with opposing incentives will compete to enact change on the system. From a logical perspective, the best governance systems will adopt the best economic outcome for the majority of their users. That is, the system will maximise economic welfare for all of its stakeholders, rather than be distorted by the incentives of a few.
Right now, there are really only two extensively used models for blockchain governance. The first is that employed by both Bitcoin and Ethereum, whereby a centralised development team curates community feedback on major protocol issues. The community offers suggestions on specific improvements to make, with the owners of the codebase having final say on which updates are implemented. The second model relies on a community voting system, typically done via an on-chain voting system where stakeholders are assigned votes based on their holdings of the asset of the blockchain. This system is more prevalent in newer blockchains, with the most prominent examples being Smart Contract blockchain’s EOS and NEO. Changes are proposed and voted on by stakeholders, with consensus amongst currency holders being required for any updates to be applied.
We will examine a few specific examples of governance systems, and their respective ability to handle participant incentives, and welfare for users in general.
Bitcoin — The First Blockchain Governance System
Being the first standalone blockchain, Bitcoin’s resilience and growth overtime has been remarkable, with its governance providing a solid basis for its success. The major function of the bitcoin governance system is negotiation for any changes to the rules of the protocol. These rules essentially cover what is required to participate in the bitcoin blockchain consensus, such as the data structures needed for valid transactions and blocks, along with block difficulty changes and block creation fees. The rules are then implemented in the baseline C+ Github code used in Bitcoin clients, with nodes and miners both using their choice of Bitcoin implementation (e.g. Bitcoin Core, Bitcoind etc).
Changes to the protocol rules are enacted via the extensive peer review of proposals called BIPs (Bitcoin Improvement Proposals). As an example, probably the most important BIP that has been enacted is BIP141 (and its following BIP148)— the introduction of the SegWit (segregated witness) changes. These allowed for increases in block size (or relative block size, thanks to the reduction in signature sizes), along with the transaction malleability changes that were required for the lightning network to operate. After a proposal is approved via some degree of consensus amongst active developers, its equivalent code is pushed in the bitcoin core repository, such that clients can integrate the reference code into their respective node implementations.
Whilst all of this sounds quite centralised, it is important to note that the singular implementation of bitcoin does not immediately change the whole network, as both miners and users retain autonomy on which version of the bitcoin client to use. If the core development team were to push changes that were controversial or misaligned to the interests of miners and users, stakeholders could simply choose not adopt the code updates to their bitcoin clients. Consensus within the network can only take over if the rule is adopted by >50% of mining nodes, meaning that miners are validators are the most critical party to confirming any updates to decentralised blockchain protocols.
Ethereum — Stakeholder interests take control
Ethereum’s governance model is very similar to Bitcoin, in that all proposed changes go through the core development team at the Ethereum foundation (much like bitcoin’s core team). Changes are proposed, evaluated and implemented as per the following flow chart:
Because of their similar models of governance, Ethereum’s evolution and change relative to that of Bitcoin demonstrates the influence of stakeholder incentives on governance outcomes. The stakeholders of Ethereum have differing incentives to those of Bitcoin, as Ethereum has its applications focused in serving as a smart contract platform, rather than being used as a store of value. Instead of implementing changes that favour the value of the Ethereum token itself, its governance has focused on changes that tackle its issues as a smart contract platform.
Whilst Bitcoin’s governance has been focused on changes to enhance its role as a store of value, Ethereum’s governance has focused on easing transaction bottlenecks in order to make it a more economically viable smart contract platform. There is no better example of this than Bitcoin’s continued use of increasing difficulty Proof of Work based mining, while Ethereum has begun their transition to a Proof Of Stake system in order to reduce transaction costs (see our POS vs POW article here). The major difference between the two protocol’s governance outcomes has simply been driven by their different goals, with Bitcoin remaining stable and relatively conservative, whilst Ethereum pursues changes to improve its performance.
EOS — A recipe for corruption and collusion?
Instead of relying on a relatively vague consensus amongst core developers, EOS has attempted to implement a decentralised On-chain voting system known as the EOS Referendum process. In brief terms, the EOS referendum process theoretically allows stakeholders to have their personal vote on any change proposed on the EOS protocol. Proposals are developed in a relatively similar way to that of Bitcoin or Ethereum, where a Github code pull request (example request here) is created on the basis of the code proposed. The change is then sent to the voting system, where it is then voted on by a certain portion of stakeholders (this is not completely decided).
Even in its infancy, EOS’s governance system has drawn serious criticism from those in the blockchain space. Ethereum Founder Vitalik Buterin has suggested the current distribution of voting delegation to only the top EOS Block Producers (EOS’s equivalent of miners) creates significant issues by granting centralised power to those who earn all of EOS’s new currency (see here). Given that the current EOS governance system relies upon block producers to vote for changes, the current situation of EOS’s largest block producers colluding to vote for each other (see here) raises significant concerns about the centralisation of voting power. Even without collusion issues, the limited number of votes (only 21 at the moment) mean that it is very unlikely that block producers represent stakeholders proportional to their interests.
More generally, on-chain voting is not something that is particularly viable right now. Basing votes on proportions of currency held will quickly create massive inequalities if individuals vote only to further their own interests (which rationally, they will). Basing votes only on the desires of block producers will inherently create a bias towards the desires of only those block producers (as with EOS). Attempting to equally distribute voting power amongst stakeholders is not a viable option either, as there isn’t currently an effective way to limit users to a single account. Even with a method to limit accounts per user, the decentralised nature of the system allows stakeholders to sell their own votes. It is certainly possible that on-chain voting will be a less problematic solution in the future, but until a mature blockchain system emerges, it seems flawed in practicality.
Governance is contentious almost by design in blockchain. The original purpose being that systems would run without centralised control and decision making, this has many advantages but also can hold back meaningful development. Time will tell whether this is in fact a feature or a flaw. Users now have a meaningful choice though depending on the governance system they prefer and we can sit back and let the market decide.