Blockchain Governance Considerations

Author: Vitalik Buterin

Original Title: 《Notes on Blockchain Governance》

Published on: December 17, 2017

A recent interesting trend in blockchain governance is the resurgence of on-chain token holder voting as a multi-objective decision-making mechanism. Token holder voting is sometimes used to decide who operates the supernodes that run the network (as seen in systems like EOS, NEO, Lisk, etc., which use Delegated Proof of Stake (DPOS) mechanisms), sometimes to vote on protocol parameters (such as Ethereum's gas limit), and sometimes to vote on or directly implement bulk protocol upgrades (like Tezos). In all of these cases, voting is automated—the protocol itself contains all the logic needed to change the validation set or update its own rules, and it is done automatically based on the voting results.

Clear on-chain governance is often seen as having several major advantages. First, unlike the highly conservative philosophy advocated by Bitcoin, it can rapidly evolve and adopt necessary technical improvements. Second, by establishing a clear decentralized framework, it can avoid known pitfalls of informal governance, which people feel is too unstable and prone to chain splits, or becomes overly centralized in practice—similar to the arguments made in the famous 1972 paper "The Tyranny of Structurelessness."

From Tezos documentation:

While all blockchains maintain account consistency through economic incentives, no blockchain has a robust on-chain mechanism that can seamlessly modify protocol rules and reward protocol development. Therefore, first-generation blockchains effectively granted centralized core development teams or miners the power to make design choices.

And:

That's true, but why would you want to lower the difficulty of [minor chain splits]? Splits undermine network effects.

Another benefit of on-chain governance for selecting validators is that it allows the network to impose high computational performance requirements on validators without introducing economic centralization risks and other flaws in public blockchains (such as the validator dilemma).

In summary, on-chain governance currently seems very affordable… so where does the problem lie?

What is Blockchain Governance?

First, we need to more clearly describe what the process of "blockchain governance" is. Generally, there are two informal governance models, which I refer to as the "decision" view of governance and the "coordination" view of governance. The decision function view sees governance as a function f(x1, x2 … xn) -> y, where the inputs are the wishes of various legitimate stakeholders (senators, presidents, property owners, shareholders, voters, etc.), and the output is the decision.

The decision function view can often serve as an approximation, but it is clearly prone to failure: people can often violate rules and escape punishment, sometimes the rules themselves are ambiguous, and sometimes this leads to…—at least at certain times, these three possibilities are good things. Moreover, in general, even behavior within the system is shaped by incentives generated by actions taken outside the system, which is at least a good thing at certain times.

In contrast, the coordination model of governance sees governance as existing in a multi-layered form. In the real world, the bottom layer is the physical laws themselves (or, as a geopolitical realist might say, guns and bombs), and in the blockchain realm, we can further abstract it as the ability of everyone to run any software they want as users, miners, stakeholders, validators, or any other agents permitted by the blockchain protocol. The bottom layer is often the ultimate decision layer; for example, if all Bitcoin users one day awaken and decide to edit their client source code and replace the entire code with an Ethereum client that tracks the balance of a specific ERC20 token contract, then that ERC20 token becomes Bitcoin. While the ultimate governance power at the bottom layer is unassailable, the actions taken at this layer may be influenced by those at the upper layers.

The second layer (which is also crucial) is the coordination mechanism. Coordination mechanisms aim to create focal points around how and when individuals should act to better coordinate behavior. There are many situations in both blockchain governance and real life where if you act in a certain way, you are likely to achieve nothing (or worse), but if everyone acts together, the expected outcome can be achieved.

The above image is an abstract coordination game. Acting in concert with others also benefits you.

In these situations, your interests are aligned with others. When others are acting, you should act; when others stop, you should stop. You can think of the coordination mechanism as a green or red flag hanging in the sky to signal "go" or "stop," creating a culture where everyone pays attention to these flags and (usually) follows the commands. Why do people have the motivation to follow these flags? Because others have already complied with the flags, you are also motivated to do the same.

The above image shows a Byzantine general commanding troops to advance. This action is not only to rally the soldiers' courage and morale but also to reassure them, allowing them to charge into battle with the same collective spirit, so that individual soldiers do not despair and commit suicide when fighting alone.

Strong statement: The concept of coordination flags encompasses everything we refer to as "governance"; in the absence of coordination games (or more generally, multiple equilibrium games), the concept of governance is meaningless.

In the real world, military orders serve the universal function of flags, while in the blockchain world, the simplest example of such flags is the mechanism that tells people whether a hard fork is "in progress." Coordination mechanisms can be very formal or informal, often providing ambiguous guidance. Ideally, flags are always either red or green. However, sometimes flags may be yellow, or even holographic, meaning that they are green for some participants and yellow or red for others. There may also be situations where multiple flags conflict with each other.

Thus, the key governance questions become:

What should the first layer be? In other words, what kind of functions should the initial protocol itself establish? How will this affect the ability to change formalized (i.e., decision function-like) protocols and the power levels of different types of agents to act in different ways?

What should the second layer be? In other words, what coordination mechanisms should be encouraged for people to care about?

The Role of Token Voting

Ethereum also has a history of token voting, including:

• Voting on DAO proposals: https://daostats.github.io/proposals.html
• DAO Carbonvote: http://v1.carbonvote.com/
• EIP 186/649/669 Carbonvote: http://carbonvote.com/

The three examples above refer to loosely coupled token voting, or token voting as a second-layer coordination mechanism. Ethereum indeed has no examples of tightly coupled token voting (i.e., token voting as a feature within the first-layer protocol), but there is an example of tightly coupled miner voting: the right of miners to vote on the gas limit. Clearly, tightly coupled voting and loosely coupled voting are in competition within the governance mechanism space, so it is worth analyzing what their respective advantages and disadvantages are.

Assuming zero transaction costs and that they are the only governance mechanism, the two are clearly equivalent. If a loosely coupled vote calls for a change, it is equivalent to raising a "green flag," encouraging everyone to download the update; if a minority wants to resist, all they have to do is not download the update; if a tightly coupled vote calls for this change, the change will happen automatically, and if a minority wants to resist, they may install a hard fork update to reverse the change. However, creating a hard fork clearly incurs some transaction costs, leading to some important differences.

One very simple yet important difference is that tightly coupled voting defaults to supporting the majority opinion of the blockchain, which requires a minority to expend considerable effort to adjust a hard fork to maintain the existing properties of the blockchain, while loosely coupled voting merely serves as a coordination tool, still requiring users to actually download and run software that will execute any given fork. However, there are many other differences between the two. Now, let’s examine some arguments against voting and analyze how each argument applies to first-layer voting and second-layer voting.

Low Voter Participation

So far, one of the main criticisms of token voting mechanisms is that regardless of where these mechanisms are attempted, voter participation tends to be very low. The voter participation rate for DAO Carbonvote is only 4.5%:

Additionally, wealth distribution is highly unequal, and the combination of these two factors results in the following chart, created by a critic of the DAO fork:

• Total Ether Supply: Total supply of Ether | One voter: One voter | No Fork: No fork -

EIP 186 Carbonvote had about 2.7 million Ether votes. The voting participation rate for DAO proposals was no better, never reaching 10%. Outside the Ethereum realm, the situation is not optimistic either; even in BitShares, where the core community contract is designed around voting, the highest-supported candidate received only 17% of the votes, while in the Lisk system, it reached as high as 30%, but we will discuss other issues with these systems later.

Low voter participation means two things. First, it is difficult for voting to gain legitimacy because it only reflects the opinions of a small portion of people. Second, attackers holding only a small portion of tokens can sway the vote. Both tightly coupled and loosely coupled voting face these issues.

Game-Theoretic Attacks

In addition to the highly publicized "major attacks," the DAO also has some much smaller game-theoretic vulnerabilities; an article on HackingDistributed summarizes this well. However, this is just the tip of the iceberg. Even if all the details are executed correctly, voting mechanisms typically have a significant flaw: in any vote, the probability that any specific voter will influence the outcome is very small, so the individual motivation for each voter to vote correctly is also negligible. Moreover, if everyone's stakes are small, their motivation to vote correctly becomes even more negligible. Therefore, spreading relatively few bribes among participants may be enough to influence their decisions, likely leading them to make choices they would not agree with in a collective decision-making context.

Now you might say that people are not evil selfish beings seeking to maximize their own interests; they would not accept a $0.50 bribe just because the above calculations indicate their individual influence is small and vote in favor of giving Josh Arza $20 million; rather, they would selflessly refuse to do evil. The following text provides two responses to this criticism.

First, there are many ways to carry out seemingly reasonable "bribery"; for example, exchanges can offer interest rates for deposits (or, to put it more vaguely, exchanges can invest in creating good interfaces and features), and exchange operators can freely use large deposits to vote. Exchanges profit from a chaotic situation, so their motivations are clearly very different from those of users and token holders.

Second, and more frustratingly, in practice, it seems that people (at least from the perspective of crypto token holders) are profit maximizers and do not seem to view accepting one or two bribes as an evil selfish act. As shown in "Figure A," we can examine the situation in Lisk, where the candidate representative pool appears to have been successfully controlled by two major groups, which explicitly bribed token holders to vote for them and required each member in the pool to vote for others.

This is the voting of 55 members (out of 101) within LiskElite:

Translation of the content in the figure

Member Rules:

Each Elite member, except for the Chinese representative, must share 25% of the LISK they produce with their voters every week;

Each Elite member, except for the Chinese representative, must donate 5% of their produced LISK to the Elite Lisk Fund to support the Lisk ecosystem;

Each Elite member must vote for other members;

The Elite membership registration system is now closed and is not accepting new members.

Voter Rules:

1. You must vote for all members of the Elite Group to receive rewards;

2. The Elite will distribute rewards once a week, which will automatically enter the voter's account.

The Elite Group reserves all rights.

This is the voting of 33 members within LiskGDT:

Translation of the content in the figure:

Funding Pool

10% is used for GDT Lisk development, 90% is returned as rewards to voters.

GDT Members

Not on the payment list, and return their rewards for silver-level and above GDT rewards.

As seen in "Figure B," some voters in Ark benefited from bribery:

Here, it is important to note that there is another key difference between tightly coupled and loosely coupled voting. In loosely coupled voting, direct or indirect voting bribery can occur, but if the community collectively believes that a specific proposal or group of votes constitutes a game-theoretic attack, they can agree socially to ignore it. In fact, this has happened—Carbonvote has a blacklist of known exchange addresses, and votes from these addresses are invalidated. In tightly coupled voting, such a blacklist cannot be created at the protocol level because agreeing on who to blacklist is itself a blockchain governance decision. However, because the blacklist is part of a voting tool created by the community, it may only indirectly affect protocol changes, and voting tools containing bad blacklists may be rejected by the community.

It is worth noting that this section does not predict that all tightly coupled voting systems will soon succumb to bribery attacks. Many (tightly coupled) systems could very well survive, and there is a simple reason behind this: all these projects have founders or foundations that conducted large pre-mining, who play important centralized roles and are committed to ensuring that the success of their platforms is not easily influenced by bribery, possessing enough tokens to withstand most bribery attacks. However, while this centralized trust model may be useful in certain environments during the early stages of a project, it is unsustainable in the long run.

Non-Representativeness

An important reason against voting is that token holders are just one type of user, and their interests may conflict with those of other user types. In pure cryptocurrency cases like Bitcoin, the use cases for value storage ("holding") and medium of exchange ("buying coffee") are inherently conflicting, as value storage places more emphasis on security, while the latter emphasizes usability. For Ethereum, this conflict is even worse, as many people use Ethereum for reasons unrelated to Ether (see: CryptoKitties), and even unrelated to digital assets that generally carry value (see: Ethereum Name Service).

Moreover, even if token holders are the only relevant type of user (imagine a well-formed social contract whose sole purpose is to become the next generation of digital gold cryptocurrency), we still face the challenge that wealthy token holders will have a greater voice than ordinary holders, paving the way for the centralization of token holdings and leading to unimpeded decision-making centralization. Or, in other words…

If you want to understand a project that embodies all these shortcomings, please refer to: https://btcgeek.com/bitshares-trying-memorycoin-year-ago-disastrous-ends/.

This flaw applies equally to tightly coupled and loosely coupled voting; however, loosely coupled voting is better suited to reach a compromise, thereby alleviating the above issues, which we will discuss later.

Centralization

Let’s take a look at the current tightly coupled voting live experiment on Ethereum—the gas limit. Here is the evolution of the gas limit over the past two years:

- Ethereum Gas Limit Average Chart -

You may notice that the overall feel of this curve resembles another chart you may be familiar with:

- Marginal Highest Tax Rate on Income Tax: 1913 ~ 2003 -

Fundamentally, they both appear to be magical numbers created and continuously adjusted by a relatively centralized team sitting in a room. What happened in the first figure (gas limit voting)? Miners generally follow the direction favored by the community, which is facilitated by social consensus similar to pushing for a hard fork (core developer support, Reddit upvotes, etc.; and in Ethereum, the gas limit has never sparked such serious controversy as token voting).

Therefore, if voters lack technical knowledge and must submit to the control of a group of experts, it is uncertain whether voting can actually provide genuinely decentralized results. This is another flaw that exists in both tightly coupled and loosely coupled voting.

Update: Since writing this article, Ethereum miners seem to have managed to raise the gas limit from 6.7 million to 8 million without even discussing it with core developers or the Ethereum Foundation. So there is still hope; however, achieving this requires overcoming challenges in community building and other non-technical work.

Digital Charters

Some have suggested adopting "digital charters" to mitigate the risks of uncontrolled bad governance algorithms. Digital charters specify the expected properties that a protocol should have through mathematical methods and require any new code changes to come with verifiable proofs that they meet these properties. At first glance, this seems like a good idea, but I believe we should also approach it with caution.

Overall, establishing specifications for protocol properties and making these specifications serve a function of a coordination flag is a very good idea. For core properties that we consider important and valuable in a protocol, this allows us to memorialize them, making them harder to change. However, this practice should ideally be implemented in a loosely coupled (i.e., second-layer) model rather than a tightly coupled (i.e., first-layer) model.

Fundamentally, any meaningful specification is actually difficult to express completely; this is part of the problem of value complexity. Even seemingly clear things like a limit of 21 million tokens are subject to this. Of course, we can add a line of code stating total_supply <= 21000000 and include a comment saying, "must not delete under any circumstances," but there are many circumventions regarding this matter. For example, we can imagine a soft fork that increases mandatory transaction fees, where the mandatory transaction fees are proportional to the value of the tokens × time value since the last issuance of tokens, which amounts to a delay fee, equivalent to deflation. People could also create another currency called Bjtcoin, with 21 million new units, and add a feature—if someone initiates a Bitcoin transaction, miners can intercept that transaction and seize their Bitcoin, sending an equivalent amount of bjtcoin to the recipient; this would quickly force Bitcoin and bjtcoins to become substitutes for each other, increasing the "total supply" to 42 million without adding code. "Soft" specifications like non-interference with application state are harder to enforce.

We hope that if a protocol change violates a guarantee clause, it should be considered illegal even if passed by vote—there should be a coordination mechanism waving a red flag. We also hope that if a protocol change, while following the letter of the specification, openly violates its spirit, it should still be considered illegal. Specifications that exist at the second layer (i.e., in the minds of community members rather than in the protocol's code) are best suited to achieve this goal.

Towards Balance

However, I do not wish to say that token voting or other explicit on-chain voting schemes have no place in governance. The main alternative seems to be core developer consensus, but I believe that a system controlled by "ivory tower intellectuals" also poses a significant threat in its failure mode. These "intellectuals" are more focused on abstract concepts and solutions, and their interest in technological advancement far outweighs their interest in improving user experience and everyday practical issues like transaction fees.

So how do we solve this dilemma? First, we would note a few passages from slatestarcodex in the traditional ** context:

The low-level error is: you find that a certain system has become somewhat Moloch-like [i.e., yielding to special interests that deviate from the right path], and you say, "Well, we will place it under the control of another system to solve this problem. We will also write a bright red label saying 'Do not MOLOCH-ize' to control this system."

*("I see that capital ** sometimes deviates from the right path. Let’s place it under government control to solve this problem. We will only allow honest people to hold positions of power to control the government.")*

*I do not claim to have a good alternative, but new liberal ** can provide a suitable alternative in some cases—finding a few good systems, optimizing them according to different criteria that roughly align with human welfare, allowing them to compete in a structure of checks and balances, hoping they will fail in different places, like Swiss cheese, giving people some freedom of choice to escape any bad system, and then leaving the rest to cultural evolution.*

In blockchain governance, this seems to be the only way forward. The blockchain governance approach I advocate is "multi-factor consensus," voting on different coordination flags, institutions, and groups, with the final decision depending on the results derived from all these mechanisms. These coordination flags may include:

• Roadmaps (i.e., a series of early ideas about the project's development direction released in the project's history)
• Consensus reached among the dominant core development teams
• Token holder voting
• User voting conducted through some anti-witch-hunt voting system
• Established specifications (e.g., non-interference with applications, 21 million token limit)

I believe it is very useful to make token voting one of the coordination mechanisms for deciding whether to implement a change. While it is a flawed and unrepresentative signal, it can resist witch-hunt attacks—if you see 10 million Ether votes for a proposal, you cannot simply dismiss it by saying, "Oh, that’s just a purchase by a Russian bot with fake social media accounts." It also serves as a signal completely disconnected from the core development team, which can be used if necessary. However, as mentioned above, there are ample reasons to explain why token voting should not be the only coordination mechanism.

What underpins all of this is its key distinction from traditional systems, which is the interesting aspect of blockchain: the "first layer" that supports the entire system requires every user to agree to all protocol changes, as well as their freedom and credible threats, and creates forks when someone tries to impose changes they consider malicious upon them.

In some limited circumstances, tightly coupled voting is also feasible— for example, despite its flaws, miners being able to vote on the gas limit has proven to be very beneficial on multiple occasions. Compared to the serious problems that could arise from any specific gas limit or block size limit hardcoded into the protocol on day one, the risk of miners attempting to abuse their power may be lower. In this case, allowing miners to vote on the gas limit is a good thing. However, "allowing miners or validators to vote on a few specific parameters that need to change at any moment" is vastly different from granting them arbitrary control over protocol rules or allowing voting to control validation rights. Moreover, both theoretically and practically, these broad visions of on-chain governance have much more nebulous potential.