Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The following research provides a general overview of blockchain governance. It will evaluate the opinions of leading experts in blockchain governance and describe the current governance models operating in the space. 

Vlad Zamfir’s Theories on Governance:

In his ­article Zamfir focuses on legitimacy, and argues that community consensus on what is ‘legitimate’ will ultimately decide whether a decision is disputable or not. In essence, people must grant legitimacy to the governing institution in order to recognize its decisions. Without this legitimacy, the governing institution of the blockchain will ultimately fail because it will lack authority from the people.

In order to gain authority and legitimacy from the community, Zamfir states that you must be aware of the politics of each participant and their purposes for using the blockchain. This includes node operators, core developers, and coin holders. The diversity of their motivations to join the blockchain must be recognized in the governance model.

Zamfir poses five possible outcomes of blockchain governance in the world as we see it today:

Autonomous Blockchains

In this model, Blockchain governance does nothing except ensure that the blockchain keeps functioning according to pre-determined rules of protocol, which is expected not to change unless absolutely necessary. The legitimate decision of this model is to not do anything at all. While the pros of this may lie in its simplicity, it lacks accountability for harm done to the community.

Blockchain Capture

A blockchain capture implies that the governance of the blockchain has been maliciously overtaken by a single group to rule unequivocally. There are four types of capture:

  • Corporate Capture: Corporate governance of a corporation becomes the source of legitimacy for the blockchain governance.
  • State Capture: ‘regional blockchains’ are governed by the rules of that jurisdiction depending on what state the blockchain is being operated on in.
  • Developer Capture: Core developers of the software hold the sole legitimacy of governance.
  • Cartel Capture: A group of participants in the blockchain collude to control its governance.

The pro of this model is that these are the governance models that most of the community is used to. The downside though, is that capturers will most likely operate in self-interest over the stakeholder.

Internet Censorship

In this model, sovereign states outlaw and censure the use of and access to the blockchain if it is not in compliance with local regulation. This would result in a local government controlling the legal implications of an international blockchain.

Public International Law & Diplomacy

The blockchain would be governed through international institutions under the  traditional legal boundaries of multilateral agreements. This model would grant its legitimacy to institutions such as the United Nations (UN). The negative of this model is that it’s bound to regional politics and has the ability to avoid local unpopularity by how removed it is, therefore disenfranchising the community.

International Private Cooperation

In this model, the blockchain is open for participation by the public and governed by relationships between people, businesses, and NGO’s.

Vitalik Bituren’s Theories on Governance:

Bituren defines governance as a series of input’s with a single output: f(x1, x2…xn) à y. In this system, the inputs are legitimate stakeholders and the output is the decision made. In recognizing the oversimplification of this model, he continues to state that governance operates in ‘layers’.

He recognizes a coordination model of governance, where the bottom layer is the real world. For blockchain users, this bottom layer is the individuals ability to run whatever software they want in their capacity as a user, node operator, stakeholder, etc. The bottom layer is always the ultimate deciding factor. But, Bituren argues that the peoples actions on this layer can be influenced by the layers operating above it.

The second layer exists of coordinated institutions. The purpose of these institutions is to develop standards for behaviors that the rest of the community can fall behind. This requires that there be an established culture in which everyone, typically, listens to organized institutions.

Coin Voting Mechanisms

Loosely coupled voting is coin voting at a layer two coordination institution. In this case, if X update was voted to be implemented, then users will download and update the protocol. Dissidents who do not support the update may choose to ignore it.

Tightly coupled voting is coin voting at a layer one, in-protocol feature. In this case, if X update is voted to be implemented, then the change happens automatically. If a minority dissents to the decision, they can hard fork and cancel the new protocol. Tightly coupled voting favors the majority and forces the minority to exert significant effort to hard fork the protocol.

Issues with Coin Voting

Low voter participation is a predominant criticism of coin voting. Wealth distribution is unequal which can lead to unfair advantages. In addition, it creates issues of legitimacy if only a small percentage of the community is making all of the decisions. An attacker with only a small percentage of the total coins can sway the vote significantly.

Game-theoretic attacks are also a fear in coin voting systems. When voting, he ability of one vote to make an impact is weak. Couple that with a small stake and the vote becomes even more insignificant. Buterin argues that this seeming insignificance may lead to bribery and vote-buying. He argues that while this is a problem for all coin voting systems, it is worse with tightly coupled voting systems. While the minority in a loosely coupled voting system can opt to not download the software, therefore making bribery less significant, in a tightly coupled system bribery has a much more pervasive impact on the community because it is automatically updated.

The overarching goal is to avoid centralization via the amount of coin ownership a single person has. But another downside of coin voting is that it only allows for one class of users. People who have coin as a store-of-value versus medium-of-exchange are naturally going to have interests that conflict. In addition, block producers, core developers, node operators, and coin holders will all have different interests that they are trying to protect. By only allowing coin holders to vote, many of these groups will be underrepresented.

Bituren’s Proposed Model

Bituren proposes a model he coined ‘Multifactorial Consensus’. He defines this governance model as one which pools all opinions from each group and the ultimate decision depends on the collective opinions of these groups together. He defines the following items as part of governance:

  • The roadmap of the project and the direction it is moving in
  • Consensus among the core developers and team
  • Coin holder votes
  • User votes via a sybil-resistant system
  • A set of established norms

He argues for cryptoeconomics: “the use of economic incentives together with cryptography to design and secure different kinds of systems and applications, including consensus protocols.”

Social trust assumptions are not universal, what one faction trusts another may not. Cryptoeconomics is about trying to reduce social trust assumptions by economically incentivizing good behavior and disincentivizing bad behavior.

Two Types of Potential Problems on the Blockchain:

There are two types of problems that are critical on the blockchain: Sybil attacks and the Byzantine General Problem. It is important to understand these two issues in order to create a governance model that recognizes and avoids these two issues.

The Sybil Attack

A Sybil attack involves a remote node forging multiple fake identities to gain undue influence in a peer-to-peer network. The question for developers to focus on is can the local entity (node) reliably verify the uniqueness of identities provided by remote entities?

There are two ways to broach this. One is direct validation, where a local entity can give out a large enough work to all entities simultaneously and make sure all answers come back within a given time. This form of validation uses proof of work and energy distribution to ensure that all nodes are operating honestly. By constraining resources, resource usage validation ensures that only one entity can complete the work in a certain amount of time.

The second form, indirect validation establishes a chain of validity. A local node can establish validity with a remote node and then that same remote node can vouch for the validity of other nodes. Unlike direct validation though, remote nodes have the potential to collude and vouch for faulty nodes.

The Byzantine General Problem

Famously described in 1982 by Lamport, Shostak, and Pease, the Byzantine General Problem describes a group of more than two generals who need to decide whether to attack their common enemy. The caveat is that one or more of the generals may lie about their choice. In order to reach consensus here, the commander and every lieutenant must agree on the same decision (ie. to attack or retreat).

Two important constraints must be met:

  • IC1: All loyal generals must agree upon a common decision
  • IC2: If a loyal general asks another general to ‘attack’, then that loyal general obeys that order. Same for ‘retreat’ command from one loyal general to another.

In the case of three generals, it is impossible to meet consensus according to the above conditions if there is one traitor. This means that if there are m + 1 generals, then at most there can be m/3 traitors in the group. If this condition is not met there cannot be consensus.

The Byzantine Fault Tolerance is the characteristic which defines a system that can tolerate the types of failures caused by the Byzantine Generals Issue. For the blockchain, this formula is helpful for misbehaving nodes. In the case of misbehaving m nodes, at least 3m + 1 level of good nodes are needed to reach consensus.

 

Off-Chain Governance Models

Improvement Proposal (IP) Model

Bitcoin and Ethereum both adhere to the improvement proposal (IP) governance model. These proposals serve as design documents providing information or describing a new feature to the cryptocurrency community. They provide detailed specifications of the proposed feature and the rationale for why it should be implemented.

In these models there are usually three types of proposals. The first, which affects the protocol and codebase, second which proposes a change in guidelines and processes but does not change code or protocol, and third which is informational and does not require rigorous consensus like the previous proposals.

Bitcoin’s governance model has seen overwhelming success. It has been able to successfully handle a majority of its disputes and avoid scandal. Ethereum has not, despite its mirrored governance model. Why is that?

Bitcoin and Ethereum’s currency play different roles in the economy and as such cannot be governed in the same manner. Bitcoin is electronic gold --  it’s intended to be a store-of-value. Ethereum on the other hand, with the introduction of Smart Contracts, became a utility coin with the ability to be used as a medium-of-exchange. The difference in utility will ultimately lead to different interests by stakeholders. Bitcoin holders are much more concerned with security whereas Ethereum stakeholders may be much more focused on transaction speeds.

Beyond this, the introduction of Smart Contracts instantiated on the Ethereum blockchain left constant weaknesses in code to be exploited. Decentralized Application (dApp) developers create code, sometimes secure, sometimes fraught with vulnerabilities that are manipulated before the community has the chance to address them. Ethereum has over 2,000 improvement proposals that are active compared to Bitcoins 322 improvement proposals. These vulnerabilities in Smart Contracts, and the inability of the Ethereum governance model to address them quickly, led to the infamous DAO hack, stealing US$50 million in Ethereum tokens from the token sale.

On-Chain Governance Models

Delegated Proof of Stake (DPoS) Model

The delegated proof of stake (DPoS) model is an on-chain governance protocol that has been implemented by multiple blockchains, most notably EOS. There are two important parts of a functioning blockchain under DPoS: 1) the election of a block producer, and 2) the scheduling of block production.

Block producers are elected continuously and control is granted to stakeholders, as they are perceived to have the most to lose if the blockchain is not operating smoothly. Consensus on DPoS requires 2/3 + 1 to resolve all cases. This allows for 21 or more block producers at any given time. In normal production, block producers are supposed to take turns producing blocks every 3 seconds. The assumption, just as with proof of work, is that the longest chain wins. Assuming no one misses their scheduled time, this production will always produce the longest chain.

Minority Fork

If there is a minority fork created by up to 1/3 of malicious nodes, a block will be produced every 9 seconds. The original chain will be producing at a rate of two blocks every 9 seconds. In this case, the original chain will be producing at a faster rate than the fork, therefore remaining the longest chain.

Double Production by a Disconnected Minority

The minority chains, no matter how many of them there are, will always produce at a rate slower than the majority.

Network Fragmentation

The network may fragments in such a way that no fork has a majority. In this case, the longest chain will be that of the longest minority. When the network reconnects, the smaller minorities will realign themselves in such a way that will restore operations unambiguously.

If they two longest forks are the same length, this will not last for long because there is an odd number of block producers. Inevitably, one chain will prevail as the longest, legitimate chain.

Lack of Producers

In the unlikely event that there are a lack of block producers, stakeholders can include votes in their transactions to quickly elect more. During this process, users are aware that the network is in a state of flux until resorted to at least 67% participation. Those who chose to transact under those conditions take that risk knowing that the specific chain they transacted on may not end up being the longest once the network is operating at full capacity.

Corruption of a Majority of Producers

If a majority of producers become corrupt, they can produce an unlimited number of forks with 2/3 confirmation. In this case the irreversible block algorithm reverts to the longest chain. The longest chain will be the one approved by the largest majority, decided by the minority of the remaining honest nodes. This behavior would not last long because stakeholders will vote to replace the block producers.

Transactions as Proof of Stake (TaPoS)

Users sign transactions under a certain assumption about the state of the blockchain. If consensus shifts to a different chain, then it would invalidate the assumptions the signer has when they consented to the transactions.

Under this model, transactions include a hash of a recent block and are considered invalid if that block does not exist in the chains history. Therefore anyone who signs a transaction on an abandoned fork will find that transaction invalid.

This helps avoid long range attacks on alternative forks. Individual stakeholders directly confirm the blockchain every time they transact. Overtime, all the blocks are confirmed by all the stakeholders.

Stake-weighted voting

Child pages (Children Display)

...