Why on-chain governance?

Asynchronous Phil
Polkadot Network
Published in
6 min readSep 27, 2018

On-chain governance addresses many problems we have seen in off-chain governance, such as unclear decision-making processes and a lack of oversight. It has the ability to make decision-making transparent, accountable, and binding, as well as the promise to create innovative governance mechanisms. However, it has been a controversial topic in the blockchain space, with most criticisms being aimed at coin voting¹.

Criticisms by Vlad Zamfir and Vitalik Buterin cite examples of hoarding and cartel-like behavior seen in some early coin-voting projects². But focusing on a few examples of coin voting³ is merely looking at one rather rudimentary model of on-chain governance. Referring to all on-chain governance as coin voting is like calling all blockchains as cryptocurrencies.

As we rely more on blockchains, making decisions about how to upgrade them becomes increasingly important. These are decisions that may affect millions of people and should have high standards of clarity and accountability — which blockchains can provide.

More transparent governance

Everyone who understands Bitcoin knows that bitcoins are minted deterministically to produce a maximum of 21 million bitcoins over time. Anyone can look into the source code to verify this process. This transparency is powerful. It provides the basis for all consensus in the system and mathematically verifies that everyone is playing by the same rules.

On-chain governance guarantees that the process for forming consensus is absolutely transparent. Similar to how Bitcoin exposes the rules for minting new coins, on-chain models must adhere to open-sourcing their governance mechanism so that anyone can see how a blockchain decides to upgrade. For instance, before users decide to join a blockchain community, they can see if it makes decisions using simple majority coin-voting or identity-based quadratic voting, if they include a mix of GPU hashpower voting and a technocratic developer council, or if they use another mechanism. In contrast, current Bitcoin and Ethereum governance systems, aside from their BIP and EIP processes, are not very well formalized, and may change ad-hoc depending on the decision being made and stakeholders involved.

For example, a blockchain with on-chain governance would publish details about their governance model, including the voting style, quorum thresholds, majority thresholds, voting periods, and other possible governance parameters. Even the procedure for amending these governance attributes would also be open-source.

Accountability

Using Bitcoin as an example again, every address’s balance is publicly listed with its amount for everyone to see. All the bitcoins in every address will, without a doubt, sum up to be the entire amount of coins allotted for the system at a given point in time. This accountability makes it possible to audit the chain for truth and consistency amongst peers, and ensure you are a “peer” on the peer-to-peer network in which you are participating.

The transparency of on-chain governance ensures no part of the governance mechanism is hidden or left obscure, and its accountability ensures a full public audit trail will be available so that all transactions concerning governance decisions can be tracked and accounted for. From the initial proposal to its implementation, any update to a proposal can be publicly tracked, including its support or contention.

Publicly available data on decisions allows for experimentation in governance mechanisms and interfaces. A blockchain’s audit trail can be used for things such as assessing future decisions by gauging the sentiment of blockchain participants on certain issues. Additionally, due diligence systems such as unit and integration tests can be added to improve the quality of proposals, and enforcement of these checks could be built in.

Bindingness

Imagine a blockchain community agrees upon an upcoming change. For nearly six months, developers, miners, and users work toward implementing the upgrade, and then, when it’s meant to be implemented, it doesn’t happen. This is what can happen with non-binding agreements, and is a bit like what happened with Bitcoin’s attempt to implement Segwit2x. Agreements that are made off-chain are non-binding.

Making decisions binding is essential, and the glue that holds on-chain governance together. It provides two main benefits: no individual parties can block the consensus as defined by the governance mechanism, and it incentivizes the proposal of sound, tested, and ready-to-ship upgrades. Decisions are bound to a vote’s result, and any roll-back procedures would also be accounted for in order to know when a decision is truly “final.” Depending on the governance mechanism, you could implement easy or hard rollback processes, just as you can implement easy or hard upgrade processes.

Possibilities with governance toolkits

As previously mentioned, coin voting (aka stake-weighted voting) is just one method to help a community resolve contentious disputes in a manner that is transparent and resistant to trivial attacks. Stake-weighted voting is a low-hanging fruit for producing a sybil-resistant, on-chain governance model in these early days of blockchain governance, but there are many more mechanisms, including but not limited to:

Every mechanism, whether on-chain or off-chain, has its trade-offs. It is important for participants to be aware of these trade-offs in order to better understand the system they want to participate in and use. Experimentation is key in discovering the model best fit for any system, and learnings can be more easily acquired and shared when the data and methodology is transparent and accountable.

Upgrading the status quo

Right now, the overwhelming majority of the governance of decentralized systems is performed off-chain. Measuring community sentiment and user intentions is mostly done on Web 2.0 platforms such as Reddit, Twitter, Github and forums, centralized platforms that are susceptible to various forms of opaque attack and bias. Web 3.0 shouldn’t be governed using Web 2.0 platforms.

We got into this space because we believe in the power of the technology we have developed and embraced — decentralized consensus. If you believe in the power of blockchains, you should believe in their potential to revolutionize governance.

Footnotes

  • [1] And also of course, the consideration of node operators by changing the defaults from REJECT to ACCEPT.This is a very complex topic I plan on addressing in a separate piece but basically boils down to the fact that node operators, as node operators alone, have no on-chain economic incentive to run a node, and external (i.e., off-chain) endeavors such as running an exchange, accepting payments, mining/validating, and deploying contracts incentivize those parties to run a node. Whether governing “on-chain” or “off-chain,” node operators aren’t more included or excluded. It’s about the defaults, which Zamfir correctly, but probabilistically, aligns as being ACCEPT in on-chain governance systems. Defaults can be set to ACCEPT, but on-chain governance models can also be extremely conservative to reduce the pace of upgrades, and perhaps make it even more difficult to upgrade than some existing off-chain models.
  • [2] DPoS models with a low number and a static number of validator slots such as EOS and Lisk have been criticized for creating environments where power can be rather easily centralized.
  • [3] Coin voting as a governance method has had its problems, but with improved distribution methods we could discover a social system or collective of individuals where voting with your stake (aka, “skin in the game”) may prove to be beneficial not only for the highest stakeholders, but the minorities as well. More experimentation from different communities and blockchains is required.
  • [4] Around 50 major Bitcoin companies got together at Conesensus 2017 to make a compromise on the long-standing Bitcoin blocksize debate. The agreement appeased both sides by planning first to implement Segwit, and doubling the blocksize a few months later. Once Segwit was implemented, and some problems with the coding of Segwit2x were revealed, and one side reneged on their agreement to increase the blocksize. This story is much more complex. Start with the Wikipedia page and follow the sources to see exactly how this dramatic story unfolded.
  • [5] There’s no documentation yet, but the Slock.it team is working on a voting interface that uses an account’s gas-spent as the value for their votes. The aim of using gas-spent is to weigh long-time users of Ethereum over newer users. Gas voting can also be applied to contracts, so that developers that deployed those contracts are weighted based on the use of their contracts. The aim of using gas-spent on contracts is to weigh important/popular/effective developers over those who haven’t contributed as much to the community.

--

--