The key ingredients to a better blockchain, Part V: Governance
Our understanding of what makes a blockchain successful is becoming clear. What will it take to succeed?
For something no one seemed to care about a year or two ago, blockchain governance has become a hot topic lately, and for good reason. John Light speaks at the Governance Games, Berlin, August 2019. Photo by the author.
[This is part of a multi-part series on the key ingredients to a better blockchain. I recommend starting with part one, Tech and Protocol. See the full list of articles in the series.]
Defining governance is challenging: it involves rules and the way decisions are made, dispute resolution, the exercise of power and authority, how scarce resources are allocated, collective action, and the ways in which a community, network, and protocol change and evolve over time. Because of the pivotal role it plays and due to its complexity, governance is a very big topic and touches upon many aspects of the way a blockchain (or any technology, for that matter) is developed, launched, maintained, upgraded, and operated on a day to day basis. It is also the clearest, most tangible manifestation of the cultural artefacts discussed in earlier articles in this series, in particular Decentralization and Constitution.
Because governance circumscribes change, to some extent every other topic discussed in this series depends upon it. As with many of these other topics, good governance is subjective, not “one size fits all,” and different projects with different stakeholders, values, and goals will necessarily require different systems of governance. Nevertheless, there are some properties that we may generally regard as indicative of good governance. This article attempts to elucidate these generally positive properties, as well as some of the tradeoffs inherent in designing a system of governance.
We must also recognize that, even more than the other topics discussed in this series, governance is an enormous undertaking due to its complexity and multi-faceted nature, and has understandably been the subject of millennia of inquiry and debate. As a result, I can only hope to scratch the surface here. If nothing else, I hope to convince you that governance is worthy of far more thought and attention than most projects have given it to date.
Please note also that blockchain governance happens in several distinct layers. Governance over which data (e.g., blocks and transactions) make it into the canonical blockchain data structure during the normal course of operations is known as consensus. It’s a different kind of governance than what’s discussed below, and as such is beyond the scope of this article (the first article in this series discusses consensus in greater depth).
The rest of this article focuses on governance over the consensus mechanism, which may more accurately be called meta-consensus: achieving consensus (at the social layer) on the process, rules, etc. by which the network achieves consensus on data (at the technical layer, typically).
- What are you governing? Before deciding anything else about governance, it is absolutely essential to define what you’re trying to govern. This could be a protocol (such as “the Bitcoin protocol”), one or more codebases (“Bitcoin Core”), a particular data structure (“Bitcoin mainnet”), a legal organization (such as a foundation), a set of resources (such as cash or developer hours), the network (i.e., logical infrastructure including the nodes themselves), a community (a group of humans), a trademark (“Ethereum”), or something else entirely. Your answers to all of the following questions will depend heavily upon what you’re trying to govern—and different aspects of the ecosystem will likely require different governance structures, so this is a good starting point.
- How is it structured? Once you’ve defined what you’re trying to govern, the next question is, how is it structured or organized? Is there a company, a foundation, an association, a cooperative, or some other type of legal entity that owns or controls it? Is there a DAO, or perhaps an even more informal structure? Are there multiple such entities? Is the governance of your protocol, project, or network unipolar, with a single governing entity, or is it multipolar, with many sources of influence and authority?
- How centralized is governance? Is power in the hands of the many or the few? Are decisions made by a small number of well-connected individuals or organizations at the center of the network, so to speak, or is decision making authority devolved instead to the edges of the network, i.e., to everyday users? Many communities superficially claim to be “decentralized,” but in practice there is nearly always a small number of actors that exert most of the power and influence in the community. While highly efficient, unipolar governance, which can make sense early in the life of a project, is dangerous and may fail to scale socially because it tends to concentrate too much power in the hands of a small group of people, without the checks and balances characteristic of more mature, robust systems of governance.
While many of us in the blockchain community are of course fans of decentralization, we must also recognize an inherent tradeoff: centralized decision making tends to be far more efficient (favoring “liveness”), whereas decentralized decision making takes much longer to arrive at decisions, but those decisions are much more likely to take into account the needs of a more diverse array of stakeholders (favoring “safety”). There’s a reason that companies, which on average have relatively few stakeholders and generally optimize for efficiency of decision making (in order to respond to, e.g., rapidly changing market conditions), tend to vest power in the hands of a small number of people, whereas by contrast nation states, which have to factor in the needs of orders of magnitude more stakeholders, make decisions much more slowly and involve many more people in the process. - What is the form of government? Another way of phrasing this question is to ask: what is the ultimate source of legitimacy and authority in your system? While many projects contort themselves into complex, hybrid models, in practice all systems of governance reduce to one or more of a small menu of options, such as democracy, oligarchy, plutocracy, etc. (Wikipedia has a more complete list). In practice, democracy is impossible in decentralized networks today since, without a centralized, trusted authority to admit “citizens,” there is no robust notion of identity and no way to prevent Sybil attacks. For this reason, nearly all blockchain projects have chosen oligarchy (rule by an anointed elite) or plutocracy (rule by tokenholders, i.e., wealth). Beware that not choosing is not an option: projects that refuse to choose an explicit form of government are nearly always captured by the tyranny of structurelessness, which is a de facto form of oligarchy (more on this below).
-
To what extent is there separation of powers? Regardless of the number of people or organizations participating in governance, it’s essential that absolute power not be vested in a single person, nor in a single body, but rather into multiple such bodies that can hold each other accountable—a system we refer to today as “checks and balances.” The reason should be self-evident: a single person or a single governing body unaccountable to anyone else is effectively an autocracy. The lesson of history is that such a system cannot be expected to adequately consider the needs of many or diverse stakeholders (over, say, enriching itself or striving to remain in power indefinitely). Montesquieu, credited with inventing the tripartite system of governance, put this better than I possibly could:
“There would be an end of every thing, were the same man, or the same body, whether of the nobles or of the people, to exercise those three powers.” - The Spirit of the Laws, Book XI
- How do you define a stakeholder? Defining who is and is not a stakeholder is one of the hardest and also most important decisions that you must make as you design and deploy a network. Stakeholders are not a monolithic group: says Kevin Werbach of the Wharton School of Business, “In the context of corporations, for instance, there is both a more narrow group of stakeholders who have formal property rights in the firm, and a broader stakeholder group that may include employees, customers, local communities where the firm operates, etc. Firms have different views about whether and how to consider these stakeholders in their decision making processes.” In fact, there is an extremely active field of academic inquiry devoted to this subject, called stakeholder theory.
In the context of blockchain, the term stakeholder typically refers to those with an active role in governance, as well as those directly or indirectly impacted by governance. For example, do stakeholders include those who are not yet participants in your network, but who might one day be? Think carefully about where you draw the line: overoptimize too far in one direction and you risk neglecting the needs of and/or disenfranchising large current or potential groups of stakeholders; go too far in the other direction and you’ll find yourself unable to act at all, since there are too many divergent interests to consider. Public blockchains bear a strong resemblance to a commons (in that it’s hard or impossible to exclude people from utilizing them, while their transactional throughput is scarce), and as Elinor Ostrom so wisely pointed out, the first step to designing a sustainable commons is to define clear boundaries. Without a clear definition of a stakeholder, any governance process can and, if enough is at stake, will be Sybil attacked. - How does the protocol evolve? In many ways, governance is about managing change. If nothing ever changed, there’d be very little to govern, but all projects, platforms, and protocols need to evolve to remain relevant. Even the most conservative protocols, such as Bitcoin, actually change quite often: if nothing else, there are always bugs to fix and enhancements to be made. Who has the right to propose a protocol change? How are such changes discussed and implemented, and how do they ultimately make it into the canonical protocol? Do other constituencies, such as miners, node operators, exchanges, and app developers have the power to veto a change by, e.g., refusing to install an upgrade? What happens in case such a veto is exercised? The answers to these critical questions depend directly on your form of government and definition of stakeholder.
- How easy is it to exit? This can mean exiting the community, the network, or some more formal organization such as an association, and it can occur by quitting, forking, or other formal or informal means. How does one exit the community? What costs are associated with exit, whether tangible, such as forfeit stake or profits, or intangible, such as reputation? As discussed in the article in this series on Decentralization, the ability to exit, such as via a contentious fork, is what keeps communities and their leadership honest. It’s one of the purest manifestations of the principles of decentralization and permissionless innovation. The strongest, healthiest communities facilitate easy exit by, for example, making data and identities portable, with the confidence that few would choose to exit from a thriving, well-run community.
- How do stakeholders make their voices heard? The most common ways this happens are by voting and signalling, which differ in whether or not the result is binding (more on this below). Some platforms and communities eschew voting altogether. Bitcoin, for instance, makes no pretense of democracy, but it does allow miners to signal support for or against proposed changes. Instead of voting, Ethereum opts for IETF-style rough consensus, believing that voting is impractical in a community that’s not a membership organization, that it can be gamed, that it tends to ignore minority views, and that it tends to lead to “worse technical outcomes” (to quote the IETF on the matter). Other platforms take the opposite stance, believing that Bitcoin and Ethereum governance are horribly slow, inefficient, and not geared towards resolving contentious issues, and opt instead for highly formalized voting schemes.
In governance systems based on voting, the most important question is whether that voting is loosely or tightly coupled (sometimes known as “binding” or “non-binding”): in other words, do votes serve as signals that get filtered through another layer of social governance (loose coupling), or are they enacted automatically with no further human intervention required (tight coupling)? It’s worth mentioning that tightly-coupled voting is more or less synonymous with “on-chain governance,” which typically involves tokenholders voting on proposals, a form of plutocracy where one token counts as one vote (since on-chain democracy is essentially impossible as described above). - To what extent does governance exhibit transparency and accountability? Is there an eternal, public, free repository of meeting minutes, decisions that were made, public funds that were spent, etc.? If there is one idea in this list that should be both universal and non-contentious, it’s the value of transparency and accountability. There is simply no better way to disenfranchise existing stakeholders (and discourage potential new ones) than to make decisions behind closed doors, especially when those decisions directly impact those stakeholders. By the same token, if those in power aren’t ultimately accountable to whomever or whatever serves as the source of authority and legitimacy (see form of government, above), incentives are badly misaligned, you’re encouraging corruption, and those in power will struggle to be perceived as legitimate. (See Constitution for more on this topic.)
- Is governance implicit or explicit? There is a school of thought in a number of blockchain communities that asserts that blockchains must not be thought of as political entities; that instead, they must be somehow apolitical, an idea that has been dubbed Szabo’s Law. By this line of reasoning, blockchains are “neutral technologies” and, for this reason, they don’t require formalized, explicit governance structures or procedures, nor do they need to factor in the needs of diverse groups of stakeholders. While this may be fine for a pet project involving a handful of friends that know and trust each other, the lesson of history is that this line of thinking doesn’t scale, and that, for lack of explicit governance, implicit power structures always emerge. There simply is no such thing as “neutral technology” and the very act of declaring yourself beyond politics is, ironically, a highly political act. When governance isn’t explicit—i.e., when it’s not clear how someone gains a voice, how changes are made, who controls power, etc.—the tyranny of structurelessness, a de facto form of oligarchy, inevitably arises. To avoid this outcome, it’s essential that governance be made explicit as early as possible, and certainly before conflicts begin to occur, at which point it’s likely already too late to dismantle the existing system. An explicit written statement of foundational principles such as a constitution can help enormously.
- Where and how are the community’s norms encoded? All communities have norms that encode expected behavior, and corresponding positive or negative incentives to enforce those norms. In some cases these norms may be made explicit, such as via a constitution or code of conduct and enforced legally. In other cases they may be implicit or unspoken, enforced instead in a purely social manner. To the extent that norms and incentives are encoded, they may be encoded using either “wet” or “dry” code: “wet” code is interpreted by the human brain (think legal code), whereas “dry” code is interpreted by machines (think computer code). Blockchain communities tend to employ a mix of implicit and explicit, wet and dry encoding of norms: block rewards, for instance, are an explicit dry code incentive to follow the rules of the protocol; restrictions on the use of a brand are an explicit wet code-enforced norm; and being invited to speak at a community event is an implicit social incentive to behave a certain way in the community.
- How is infrastructure work funded? One of the most crucial problems that governance must solve is resource allocation and funding the common good—and work on the infrastructure of the blockchain itself is a common good in economic terms for the same reason, described above, that blockchains bear a strong resemblance to a commons. This is, naturally, one of the most contentious topics in blockchain governance since it involves ages-old questions such as taxation and the role of the state. Blockchains are extraordinarily complex systems, technologically as well as socially, and building, maintaining, and developing them requires a large ongoing commitment of funding. That funding can come from several places: private investors, private companies, or inflation (in practice, very similar to taxation; see for instance the Zcash Founders’ Reward). Where funding comes from and how its use is governed will have a large impact on the sustainability and scalability of your platform and on the types of stakeholders it attracts.
Many of the ideas in this article, including the definition of governance, were heavily influenced by the Wharton Cryptogovernance Workshop. My gratitude to all of its participants and contributors. You may wish to view the governance assessment questionnaire, a product of that initiative, which presents a far more thorough examination than this article can of the questions and tradeoffs of blockchain governance.
The next article in this series is about privacy: why is privacy important for blockchain, and how can and should blockchain platforms and communities promote privacy, both technically and socially?
This article is part of a multi-part series on the key ingredients to a better blockchain. Check out the other articles in the series:
- Part I: Tech and protocol
- Part II: Decentralization
- Part III: Community
- Part IV: Constitution
- Part V: Governance
- Part VI: Privacy
- Part VII: Economics
- Part VIII: Usability
- Part IX: Production Readiness
- Part X: Sustainability
Special thanks to Liat Hoffman, Yael Hoffman, John Light, Kevin Werbach, and Vlad Zamfir for invaluable pre-publication feedback and corrections.