Inside the blockchain developer’s mind: The governance crisis

This is Part 3 of a three-part series in which Andrew Levine outlines the issues facing legacy blockchains and posits solutions to these problems. Read Part 1 on the upgradeability crisis here and Part 2 on the vertical scaling crisis here.

Upgradeability, vertical scaling and governance: What all three of these issues have in common is that people are attempting to iterate on top of a flawed architecture. Bitcoin and Ethereum were so transformative that they have totally framed the way we look at these issues.

We need to remember that these were developed at a specific moment in time, and that time is now in the somewhat-distant past when blockchain technology was still in its infancy. One of the areas in which this age is showing is in governance. Bitcoin launched with proof-of-work to establish Byzantine fault tolerance and deliver the decentralization necessary to create a trustless ledger that can be used to host digital money.

With Ethereum, Vitalik Buterin was seeking to generalize the underlying technology so that it could be used not just to host digital money but also to enable developers to program that money. With that goal in mind, it made perfect sense to adopt the consensus algorithm behind the most trusted blockchain: proof-of-work.

Proof-of-work is a mechanism for minimizing Byzantine fault intolerance — proving BFT is not as easy as people like to pretend. It is not a governance system. Bitcoin doesn’t need a governance system because it is not a general-purpose computer. The reason general-purpose computers need a governance system is that computers need to be upgraded.

One needs no clearer proof than the magnitude of changes planned for Ethereum 2.0 and the aggressive advocacy for the adoption of the necessary hard forks. We are not the first to point out this problem. The founders of Tezos accurately forecast this problem, but they ultimately failed to deliver a protocol that meets the needs of most developers for the following reasons:

The smartness of smart contracts

Developers must be able to code up the behaviors they would like to see in the blockchain as smart contracts, and there must be an on-chain process for adding this behavior to the system through an explicit upgrade path. In short, we should be able to see the history of an upgrade just as we can see the history of a given token.

The appropriate place for governance is in determining which smart contracts are made into “system” contracts based on whether they will increase the value of the protocol. The challenge is, of course, coming to a consensus on that value.

The most controversial point I will make is the critical need for algorithmically distinct classes that act as checks and balances on one another. While intuition might suggest that more classes make consensus more difficult, this is not the case.

First, if the upgrade candidates are already running as smart contracts on the mainnet, objective metrics can be used to determine whether the ecosystem would benefit from turning the “user” contract into a “system” contract. Second, if we were not trying to bundle upgrades into hard forks, they could be piecemeal and targeted. We would simply be trying to assess, in a decentralized manner, whether the system would be improved by a single change.

Checks and balances

It is commonly understood that in any economy, there are essentially three factors of production: land (infrastructure), labor and capital. Every major blockchain only recognizes one class: capital. In PoW chains, those who have the most capital buy the most ASICs and determine which upgrades can go through. In proof-of-stake and delegated proof-of-stake chains, control by capital is more direct.

In addition to being problematic on its face, the absence of any other classes to act as a check on capital has a paradoxical effect that leads to political paralysis. No group is homogenous. Classes, properly measured, create efficiency — not inefficiency — by forcing the members of a class to come to a consensus around their common interest. Without such pressure, subclasses (groups within a class) will fight among one another, leading to gridlock. Properly designed classes motivate their members to come to an internal consensus so that they can maximize their influence on the system relative to the other classes.

If we can codify individual classes representing infrastructure, development and capital, then upgrades that receive approval from all three classes must, by definition, add value to the protocol, as these three classes encompass the totality of stakeholders within any economy.

Such a governance system, when combined with a highly upgradeable platform, would be able to rapidly adapt to the needs of developers and end-users, and evolve into a platform that can meet the needs of everyone.

The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.