In order to achieve blockchain mass adoption, three fundamental
problems should be solved. Let’s dive into the third one: governance.
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 blockchain is written in a different language than the smart contracts.
- They introduced a political process where decision-making occurs off-chain.
- They failed to deliver on an on-chain explicit upgrade path.
- They failed to establish distinct classes that can act as checks and balances.
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.
source link : https://cointelegraph.com/news/inside-the-blockchain-developer-s-mind-the-governance-crisis
