One of the concepts that is perhaps hardest to grasp for newcomers to the crypto space is the fact that networks like Bitcoin or Ethereum can be decentralized while still being able to evolve and develop.

How do we know that the supply cap, according to which only 21m bitcoins can ever come into existence, cannot be changed in a few years? Why are changes being made to the economic policy of Ethereum and most importantly who decides these changes? In simple terms how does decentralized governance work?

Listen to our 1hr podcast with Tim Beiko (Ethereum Core Developer) on Ethereum's governance for a deep dive

The truth is decentralized networks have governance processes and every aspect of a network can theoretically change. Perhaps the most important difference to the social contract we abide by in the real world, is that in a decentralized network every participant has the option to “rage quit”, to leave the network if they’re not happy with the latest changes and continue with their own alternate version of the network.

This option doesn’t exist in the real world where we can’t single-handedly exit the system or change its rules. We can’t decide not to pay taxes or to take drugs in public. These rules are determined by the system and close to impossible to change.

How are the rules of the network enforced?

To participate in the Ethereum network you need to run a specific type of software called node software or client. This node software implements the rules of the Ethereum protocol.

To be clear there is not just one software client but actually 4-5 different ones. The most popular one is Geth but other ones like OpenEthereum, Besu or Nethermind are also quite popular. This is in stark contrast to Bitcoin where only one software client exists, namely Bitcoin Core. Client diversity has the benefit of making the network more resilient. If one client software were to fail due to a flaw in the software, the network could still continue to run normally as there are a sufficient number of nodes running on other clients.

Each client is maintained by a different team but all follow the same Ethereum protocol specifications. They differ mostly on small technical subtleties that matter to developers such as the programming language they are written in, the amount of developer support they have, or the open-source licenses they employ.

The Ethereum protocol specifications are high-level rules which coordinate things like the way transactions are broadcasted from end-users into the mempool (where they are picked up by miners) and how miners broadcast their block to the rest of the network once the cryptographic puzzle (a.k.a proof-of-work) has been solved. How they are encoded into the clients is left to the teams.

It also specifies a lot of other things such as the inflation rate (block reward) that goes to miners. In short, it ensures that the transactions contained in blocks follow the rules defined in the Ethereum protocol and state transitions (changes in the distributed database) are executed rightfully. The rules are enforced by code.

If you’re thinking ‘wait a minute, I have used Ethereum before without running a node’, you’re right. However, you connected to the Ethereum network via a remote node provided by your Ethereum wallet application, so technically you’ve still followed the rules.

As you might have noticed, what is written in the node software has a lot of implications and is thus in some cases hotly debated among the Ethereum community as we’ll see in a bit.

Who decides what goes into the software?

The process by which software changes are implemented resembles a lot to the process of how new laws are passed in the real world. Like in the real world various stakeholders exist. For ethereum the main stakeholders are:

• Users: end-users holding $ETH and using Ethereum applications, crypto exchanges, developers building applications on top of Ethereum

• Miners: individuals or business entities who run server farms to validate transactions and secure the network (thereby earning ether)

• Ethereum Core Developers: developers and researchers who contribute to the node software and participate in one of the various technical forums ( Ethereum magicians, AllCoreDevs call, etc.) more on Ethereum Core Developers

Any one of these actors can submit a proposal called an Ethereum Improvement Proposal (EIP) on Github. The difficulty then becomes finding support for that proposal. This can either happen organically because people see the proposal and think it’s sound or by trying to foster support for it and educating people about its benefits.

Ethereum Core Developers are like politicians in the sense that they listen to what end-users want by gauging the sentiment on social media, conferences, articles, etc. When a lot of users demand a certain feature or change to the protocol they will take the proposal into consideration.

After an EIP is submitted it goes through a life cycle of technical reviews, research, and discussions:

1. Draft – An EIP is merged by an EIP Editor into the EIP repository when properly formatted

2. Review - An EIP Author marks an EIP as ready for and requesting Peer Review.

3. Last Call – an EIP that is done with its initial iteration and ready for review by a wide audience.

4. Accepted – a core EIP that has been in the Last Call for at least two weeks and any technical changes that were requested have been addressed by the author.

5. Final – an EIP that the core devs have decided to implement into the various clients (Geth, Nethermind etc.) and release in a future hard fork or has already been released in a hard fork.

If a new EIP is included in a release, miners and other nodes will automatically adopt the changes the next time they upgrade their software. This is called a soft fork. Miners and nodes can run different (old & new) versions of the software without causing any compatibility issues. The changes that are introduced are backwards compatible.

On the other hand, if the software changes that were made are incompatible with the current protocol the governance must schedule a hard fork, or else things can get very messy. As of recently, Ethereum Core developers have started referring to hard forks as “network upgrades”.

During a hard fork, nodes who don’t update their software split from the remaining network since they don’t speak the same “language” as the rest of the network anymore. In other words one set of miners follows a new set of rules whereas the other remain stuck to the old rules.

That’s why hard forks are always scheduled ahead of time to give every node and miner ample time to be prepared.

This is important because if for example a crypto exchange holding a lot of user funds points its nodes towards the wrong chain it could cause a lot of confusion and damage as users would temporarily not be able to retrieve their funds. Most hard forks are a mere formality and followed by all actors but in rare cases, they can be quite contentious and cause an ideological split.

An example of a Hard Fork: The DAO Hack

The DAO was set up in April 2016 as a decentralized autonomous organization. Its purpose was to invest in DeFi and other open source projects, making it a form of a community owned venture capital fund, powered by smart contracts. The project swiftly collected a record-breaking $120 million in Ethereum (ETH) during the crowdfunding phase.

However, in June, some hackers exploited a vulnerability in the smart contract code that allowed them to drain about one-third of the DAO's funds (roughly $50 million) and withdraw it to their own address.

This fueled a huge debate in the community, where members had two opposing views:

1. One side argued that the vulnerability was unfair and their funds should be given back, especially given the early stage the Ethereum project was at

2. Others opined that the whole purpose of a smart-contacts-based system is its immutability and hence, no intervention should take place

Ultimately, the Ethereum community voted in favour of the refund and the Ethereum community executed a hard fork. Since back then Ethereum consisted of a small tight knit community, it was relatively easy to get all the miners on-board and rollback the Blockchain to return the stolen funds to the DAO.

However, the part of the community that rejected the intervention and favored immutability decided to keep using the unforked version of Ethereum: Ethereum Classic (ETC).

Therefore, all people who held ETH at that point received the right to claim the equivalent amount of ETC — to do that, they had to access MyEtherWallet (the most popular Ethereum wallet at the time) and prove ownership over the private keys belonging to their account.

For users who held their ETH in a crypto exchange things were more tricky since they didn’t have access to the private keys. Kraken and Coinbase announced its support and declared that it was crediting client accounts with the equivalent amount of ETC tokens as long as they had an ETH balance on Kraken at the time of the fork, but a few other exchanges didn’t.

All in all you can see that hard forks can be quite confusing for end users and are not a desirable outcome, although, of course not every hard fork results in a chain split. In fact there hasn’t been a chain split that led to the emergence of an entirely new Blockchain ever since.

Do miners control Ethereum?

After reading this you might think that miners are the ones who truly control the network since they can simply reject new software releases endorsed by the community or worse, start running a modified software to attack the network ( more on how miners can attack a network TLDR; very difficult).

In reality things are far more nuanced since miners are profit driven actors who are often large stakeholders of ETH themselves and only want what’s best for the network and their wealth.

But let’s assume for a second a large number of miners would stop mining the Ethereum chain after a new release introduced a rule they’re not pleased with because it’s at their disadvantage (such as reducing the block reward).

Immediately after the fork block that introduces the new rules that miners refuse to upgrade to, the total hashing power (sum of computing power of all miners) of the network would considerably drop.

This would mean that mining the next block would take much longer as normal but very quickly the network would adjust the algorithm difficulty and make it easier for the remaining miners to validate subsequent blocks.

This would continue until the difficulty adjusted such that the remaining hashing power could mine a block every 15 seconds (the target rate set by the network). During this entire time remaining miners would rake in much more profit since with less competition, they’re more likely to find a block and get the block reward.

In an efficient market, new miners would very quickly jump in to profit from the increased profitability and hashing power would gradually shift back to old levels.

Long story short, since miners are a decentralized, heterogeneous group it’s unlikely that they will ever all do the same thing or act as a coordinated group. As long as that’s the case, Ethereum is secure and miners serve the interest of users and developers by carrying out their task of validating transactions.

Conclusion

As you can see Ethereum governance like any governance system has its flaws and merits. Governing a decentralized network is no easy task and other Blockchains like Polkadot are experimenting with "on-chain" governance where all the important decisions are made by users who vote directly on the Polkadot Blockchain.

Ethereum's governance is a form of soft governance where a lot of the coordination is happening off-chain and support for a proposal is assessed before a feature is merged into the clients. Ultimately, however, the network participants decide on-chain by accepting or rejecting the new software.

So far governance has worked remarkably well, with Ethereum having by far the most active community of developers and researchers of all Blockchains and innovating on all fronts. Perhaps the biggest challenge in the coming years will be to master the migration from Proof-of-Work to Proof-of-Stake (a.k.a Ethereum 2.0) which will pave the way for faster and cheaper transactions and a new explosion of decentralized applications.

Do you have any questions about how Ethereum governance works? Tag us on Twitter @cryptotesters or join our Telegram to discuss!