How Ethereum governance works

Perhaps “works” is a strong word…

Participants

• Ethereum Client Developers — Anyone who maintains an Ethereum client. This includes Geth, OpenEthereum, and Nethermind developers as well as Besu developers and the people who maintain the Ethereum Classic forks of those clients (in the case of ETC fork maintainers, their involvement is a bit special and I won’t be getting into that here today).
• Users — People who use Ethereum to transact. This includes people using dapps, people sending/receiving money, etc.
• User Delegates — Often times users will delegate their decision making power to a third party. Infura and centralized exchanges are two incredibly common delegates. Popular dapps are another class of common user delegates, where users will go to whatever chain their favorite dapp is developed on. When we talk about users making decisions, often times this is delegated to somewhere else but ultimately it is still the user’s decision in the end.

Process

Every client has its own set of developers that have their own motivations, desires, etc. The developers of each of those products decide among themselves what they want to put in their client, when they want to release their client, and what features it will have when an update is released.

The All Core Dev calls are entirely optional for client developers, but in the past client developers have expressed a desire to remain compatible with each other so they usually send a representative to the call to try to coordinate with other client developers.

Eventually, each client team will release whatever client updates they see fit, which (ideally) will be compatible with other clients and have fork block numbers that align with other clients. If the clients release compatible code that shares a fork block trigger, then the clients will be able to communicate with each other when run by users.

Once the clients are released, the client developers and/or their supporters will advertise/announce it to users who will choose whether to update their client or not, or possibly switch clients. Users often delegate this decision to third parties like Infura or centralized exchanges, but ultimately the user can decide what ruleset they want to transact on. In the case of a delegated vote, if they disagree with their delegate they can often switch providers (this is a bit trickier with custodial delegates because the custodian may refuse to give you your money on a chain that the custodian disagrees with).

Who Makes the Decisions?

There is no single decision maker here. Anyone can release a client, announce a client, fork a client (they are all open source), etc. and users can choose to use whatever client they want.

The core developers of each client have a particular set of things that they individually care about, and they usually express that to the other client developers. If all of the client developers agree to develop the same feature, then things go smoothly and they’ll coordinate on release timelines.

If client developers don’t agree on what features to release or when, then some of them may develop, announce, and launch a different feature set. We saw this previously with the ETH/ETC split where not all of the client developers agreed on how to proceed, and so we ended up with two different sets of clients that were maintained by different groups of people.

How Is Disagreement Handled?

1. None of the core developers thinks it is a good idea and they all decide not to integrate it into a client they maintain.
2. Some of the core developers think it is a good idea but are unwilling to fork over it while others think it is a bad idea and are willing to fork over it.
3. Some of the core developers think it is a good idea and are willing to fork while others think it is bad and unwilling to fork.
4. Some core devs think it is a good idea and are willing to fork and others think it is bad and are willing to fork.
5. All core developers think it is a good idea.

• In the case of 1 and 5, things go very smoothly.
• In the case of 2 and 3, there is usually discussion to try to come to consensus by understanding the root cause of people’s disagreement and trying to find a viable solution to those problems if possible, but if “rough consensus” is not achieved then the side with the stronger belief may win out.
• In the case of 4, we have a chain split like ETH/ETC.

How Can Users Get Involved?

As a user of Ethereum, you can choose whether to run a given client or not, which means you can choose to simply not upgrade if you don’t think the change is good. You are also welcome to, and in fact encouraged, to try to convince other people (in the appropriate venues) to join you in running a different client if you think that is best.

If you are technically minded, you can also participate by proposing new technical ideas to the core developers (e.g., via https://ethresear.ch). You can also participate in client development either by joining an existing team, maintaining your own fork, or building a new client from scratch.

How do Developers Decide What Code To Write?

Every Ethereum client developer has their own motivations, some of which are well known and some of which are private. Some of these motivations are financial (e.g., they are being sponsored by someone else, who has their own motivations) and some of these motivations are altruistic (e.g., they want to build a more censorship resistant future).

However, because of the “users decide what to run” feature mentioned above, the core developers usually build software that they believe users will want to run now and in the future. Most of the Ethereum client developers are not interested in writing software that no one uses, so ultimately they are usually guided by what they think users want, or what will benefit users.