Better Blockchain Governance: A Conversation With David Schwartz
Recently, I’ve become obsessed with the concept of blockchain governance after watching Preeti Kassireddy interview Lane Retig from The Ethereum Foundation. Seeing how unstructured Ethereum’s governance is made me wonder: what is the best way to make these global decisions for a blockchain?
So, I sat down with David Schwartz, the CTO of Ripple, in order to answer this question and talk about the design of his invention, the XRP Ledger. While it’s unclear what a perfect blockchain looks like, his deep insights into blockchain consensus, governance, and history provided me with ammunition to form my own opinion.
Why Governance Matters
Blockchain technology could fundamentally change the way we think about value by enabling the creation of a globally accessible platform of exchange. In little over a decade since the invention of Bitcoin, the community has grown to over 7.1 million active users, with major expansion in emerging markets. Many have compared blockchain’s growth pattern to the early days of the internet, and have predicted that many more users are coming. Given how impactful blockchains could be for people around the globe, now is the time to make critical decisions on how to govern these systems, especially to ensure inclusion and stability.
The mechanisms that decide how a blockchain’s protocol changes over time are different for every project. There are many competing approaches to blockchain governance, ranging from on-chain democratic voting to relatively private decision making. Each of these strategies hold trade-offs in development speed and participation that affect users in the ecosystem, even those who do not directly participate in governance.
Importantly, blockchains have network effects, creating a power law distribution in which the majority of blockchain users are concentrated on a small number of blockchain ecosystems. This means a small number of blockchain governance regimes will set precedent for the rest of the industry.
As one of the top three cryptocurrencies by volume, Schwartz’s XRP is definitely part of the powerful.
Formal Governance
It’s important that nodes in any distributed system maintain the same state. In a blockchain, nodes in the network run very compatible software to come to an agreement through consensus about the state of the ledger. A blockchain can “fork” when there is disagreement on this, which can occur for a variety of reasons — intentional or accidental.
Part of governance is preventing an accidental fork. As Schwartz puts it, “Nobody wants an accidental fork. An example of an accidental fork is if Bitstamp and Coinbase disagree on what the current valid state of the ledger is. Then all of a sudden, I could buy XRP at Bitstamp and Coinbase would say they don’t see my XRP on the ledger. This could happen because of a bug in the code or something like an extended internet outage”. Even if the same consensus protocol is used, an external or accidental factor can alter agreement about the state of the ledger, which would result in a fork.
An accidental fork can be prevented by ensuring that miners are running the same software. The best way to guarantee this is through formal processes written in code. Schwartz refers to these as “norms”. Although these norms are specified in code, it’s important to consider that participants in the network run the code because they are in agreement with the norms. Otherwise, they would participate in another network.
I asked Schwartz about XRP Ledger’s norms:
“We have a norm that says you don’t activate a change until 80% of the network signals support for the change. Let’s say only 55% of the network supports the change and you activate it. If the other 45% of the nodes aren’t able to support the new code, you will fork”
This is a great example of XRPL’s robustness principle. 80% consensus makes the system partition-tolerant by halting forward progress when there are disagreements over the ledger state. As Nazrul defines, “a system that is partition-tolerant can sustain any amount of network failure that doesn’t result in a failure of the entire network”. The XRP Ledger would freeze in an emergency and avoid concurrent false progress on two different branches, which would necessarily result in a fork.
To avoid an accidental fork, another norm that XRPL has is a “flag ledger”. Every 256 blocks (or “ledgers” for XRP), miners broadcast their code version to reach agreement on software updates. Schwartz mentioned that, “what typically happens is that there is all kinds of informal governance that goes on, and at one point there is an appeal to the norms to signal that they are in favor of the change. This would happen after informal social consensus is reached”. One thing to note here is that this norm is dependent on informal processes to determine an outcome, and that the software is a last check for the network itself to agree to the update.
Informal Governance
Similar to a nation state, blockchains at scale require direction and adaptation to the real world. A country’s policy is elastic, where depending on economic and political conditions, policies can be implemented over a certain timeframe with the intention of removing them eventually. A blockchain protocol requires consensus from every single validator, making it much harder to make forward progress. Differences like this create difficulties in governing a blockchain, as builders are responsible for the social implications of their technology.
There are numerous competing forms of informal governance in the blockchain space, but Ethereum and Bitcoin serve as great examples to compare with XRP. Again, the governance regimes of these platforms will set significant precedent for the future, so it’s important to get it right now.
According to Schwartz, a good framework to evaluate informal governance is to consider what would happen in the case of a serious disagreement, one that would necessarily result in a fork.
To clarify, governance has many purposes. The goal is not to prevent forks, but best handle situations that could result in a fork. While it can be said that revolution is a sign of a failed government, Schwartz argues that, “Forks are not inherently bad. Let’s say some people on the network absolutely want private transactions, and some say no we have regulatory clients we can’t have private transactions. If they fork, it could be that the resulting two networks have more value separately”. There are two examples of large blockchain forks that were handled with different approaches.
After the DAO hack where a re-entrancy bug allowed a hacker to steal millions of Ether from a crowdfunded smart contract, there was ongoing debate on whether or not to bailout The Dao with a hard fork. The main pillar of governance for Ethereum was the core developers, who had the most stake in the system, and at this point mined most of the coins in the network. After some debate, a quick vote of ether holders was issued, and a majority (89%) of people voted for a hard fork. Ethereum Classic was created as a preservation of the original blockchain.
The anti-bailout group argued that the voter turnout was really low due to the short duration of the vote, and that the Ethereum foundation developers had lots of stake in the DAO, influencing their decision to bailout. This group offers many more examples of what they perceived as the Ethereum Foundation manipulating the blockchain for personal benefit. They saw the Ethereum Foundation’s power over a decentralized blockchain as contradictory. However, despite the creation of Ethereum Classic, most developers decided to go with the original blockchain because of its support from the foundation with developers, a roadmap, and funding.
The second example is Bitcoin’s fork over the block size. As the network gained more adoption a school of thought emerged that the 1mb block size limited utility of the network and increased fees. After debate, a group rallied support and created Bitcoin Classic, which boasted a higher block size. I mentioned to Schwartz that this was different than the DAO fork, because a group of “renegades” left the bitcoin network. He quickly added that, “No matter how renegade they were, they don’t want to break the network. They didn’t do it in secret, and respected the norms of Bitcoin because they wanted constructive change”.
Both of these networks are largely governed by the core development teams and large mining operations. Although the network itself is decentralized, it requires steering by a governing body. Users of a blockchain at minimum trust the code, and by extension, trust the people writing and running that code.
In the case of XRP, when the technology was in infancy, Schwartz along with the other inventors gifted 80% of the networks economic value to Ripple. I asked Schwartz about how this affects governance, and he was honest that “XRP is in a weird place. What we had is a sort of benevolent dictator who had no real authority but who everyone listened to because they had a history of good decisions. Bitcoin was this way at one point too — everyone did what Gavin said — and so was Ethereum”. It’s clear then that the three most popular cryptocurrencies by trading volume all hold this pattern.
The XRP Ledger itself, however, is not technically beholden to the company. Schwartz stated, “Ripple has no formal authority despite having a significant portion of the systems economic value. Validators can technically run whatever software they want. If someone wanted to propose a change taking away 20 Billion XRP from Ripple because they are worried it’s in danger of becoming a security, there’s no legal lever preventing them from doing so”. He hopes that if Ripple makes a decision like this, the validators would refuse to run the new software, at which point it’s unclear what entity would govern the “winning” fork.
This style of governance seems to be effective in creating large communities. The criticism of centralization is legitimate, however, and many have tried to avoid this by using pure on-chain governance. Tezos, for example, possible solution that utilizes a voting mechanism to propose updates. If an amendment is proposed it is moved onto a test-net, and another vote confirms the change to be moved to the main-net. This solution works, but won’t necessarily scale as easily as one with stronger leadership.
Blockchains are governed by physical norms written in code, as well as institutions that make decisions to guide, but not enforce, changes to the network.
All blockchains have some sort of informal governance and degree of centralization. For specific use cases, it’s not very important to have a completely decentralized governance. In fact, it’s more effective to keep these circles small and operate them like companies. The goal of these projects is not necessarily to scale globally. However, when building something more expansive like a cryptocurrency that’s meant to be used by people all across the globe, decentralization provides a pathway to inclusion, even if it doesn’t guarantee it. In the short run, legacy financial institutions like banks will not interface with large crypto-anarchist movements, but will work with companies like Ripple. Having trust in an organization is inevitable, as most users don’t have as much buy in as the thought leaders and core members will. It’s up to the individuals to vote with their participation on what governance schemes they like the best.
I’ve come to the opinion that the winning strategy is to have robust support for the network with dedicated miners who have lots of stake in the system, and experienced core developers who openly share with the community. Having people behind these big decisions, rather than just code is important, especially considering the growing number of blockchain users. While institutional players lay down the groundwork, more projects will grow and change the way that the world interacts, much like the internet did years ago.
Special thanks to the following people for reading the draft of this post, and suggesting edits: Warren Paul Anderson, Mithun Vijayasekar, Gloria Zhao
