Ethereum Governance

--- tags: ethorg --- # Ethereum Governance Ethereum Governance refers to how changes are made to the Ethereum protocol. Before diving into the topic, it is worth highlighting that while there are formal and informal processes for how changes get made to the Ethereum protocol, how the protocol is used is permissionless. In other words, for social and technical reasons, a high level of coordination is needed to make changes to Ethereum, but anyone wishing to use Ethereum or build an application on it is free to do so as they please, as long as they follow the rules of the protocol. ## Stakeholders There are various stakeholders in the Ethereum community, each of which plays a role in the governance process. Starting from the stakeholders closest to the protocol and zooming out, we have: * **Protocol Developers** (a.k.a. "Core Developers"): these people maintain the various Ethereum implementations (e.g. go-ethereum, Nethermind, Besu, Erigon at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar at the consensus layer); * **EIP Champions**: these people propose changes to the Ethereum protocol, in the form of Ethereum Improvement Proposals (EIPs); * **Miners/Validators**: these people run nodes which can add new blocks to the Ethereum blockchain; * **Node Operators**: these people run nodes which propagate blocks and transactions, rejecting any invalid transaction or block that they come across; * **Application/Tooling Developers**: these people write applications that are run on the Ethereum blockchain (e.g. DeFi, NFTs, etc.) or build tooling to interact with Ethereum (e.g. wallets, test suites, etc.); * **Application Users**: these people interact with applications on the Ethereum blockchain; * **Ether holders**: these people own the ETH token. Note: any individual can be part of multiple of these groups (e.g. a protocol developer could champion an EIP, and run a beacon chain validator, and use DeFi applications). For conceptual clarity, it is easiest to distinguish between them, though. ## Formal Process The formal process for introducing changes to the Ethereum protocol is as follows: 1. **Propose a Core EIP**: as described in [EIP-1](https://eips.ethereum.org/EIPS/eip-1#core-eips), the first step to formally proposing a change to Ethereum is to detail it in a Core EIP. This will act as the official specification for your change which, if accepted, **Protocol Developers** will implement. 2. **Present your EIP to Protocol Developers**: once you have a Core EIP, you should get feedback on it by **Protocol Developers**. This can be done by proposing it for discussion on an [AllCoreDevs call](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status), or asynchronously. After this, either your EIP will be considered for a future network upgrade, either some technical changes will be requested or it may simply be rejected if it is not a priority or the improvement is not large enough relative to the developement effort. 3. **[Optional] Gather Community Consensus for your EIP**: some EIPs are purely technical changes with little room for debate, but others can be more contentious. If your EIP is in the latter category, **Protocol Developers** will likely want to see strong evidence of overwhealming community support before proceeding with it. There is no "one size fits all" approach here, as each EIP is unique. 4. **EIP Included in Network Upgrade**: assuming your EIP has been approved, tested and implemented, it would then be scheduled as part of a network upgrade. Given the high coordination costs of network upgrades (everyone needs to upgrade at the exact same time), EIPs are generally bundled together in upgrades. 5. **Network Upgrade Activated**: after your network upgrade has been activated, your EIP will now be live on the Ethereum network. Note: network upgrades are usually activated on testnets prior to being activated on the Ethereum mainnet. This flow, while very simplified, gives an overview of the major stages for a protocol change to be activated on Ethereum. Now, let us look at the informal factors at play during this process. ## Informal Process ### Understanding Prior Work Before having an EIP which can be seriously considered for deployement on the Ethereum mainnet, **EIP Champions** are expected to make themselves familiar with prior work and proposals. This way, the EIP hopefully brings something new which hasn't been rejected before. The three main places to research this are the [EIP repository](https://github.com/ethereum/eips), [Ethereum Magicians](https://www.ethereum-magicians.org) and [ethresear.ch](https://www.ethresear.ch). ### Working Groups For larger initiatives, it is unrealistic to expect that the initial EIP will be included on the Ethereum mainnet as-is. In practice, these will require **EIP Champions** to work with a subset of **Protocol Developers** to specify, implement, test, iterate on and finalize their proposal. Historically, these working groups have involved several months (and sometimes years!) of work. Similarly, **EIP Champions** for such changes should involve relevant **Application/Tooling Developers** early in their efforts in order to gather end-user feedback and mitigate any deployement risks. ### Community Consensus Unfortunately, there is no clear playbook on how to handle contentious proposals. Because they have no way to force people to adopt network upgrades, **Protocol Developers** will generally avoid including EIPs who are contentious amongst various stakeholder groups. As the champion of a contentious EIP, you should try and build consensus, address objections and document community support for your proposal. Given the size and diversity of the Ethereum community, there isn't a single metric (e.g. a coin vote) which can be used, and **EIP Champions** are expected to adapt to the circumstances of their proposal. Beyond the security of the Ethereum network, which contentious forks may compromise, significant weight is usually placed on what **Application/Tooling Developers** and **Application Users** value, given that them using and developing on Ethereum is what makes the ecosystem attractive for other stakeholders. ## Beacon Chain Development The Ethereum governance process often trades off speed and efficiency for openness and inclusivity. In order to accelerate the development of the Beacon Chain, it was launched separately from the proof of work Ethereum network and followed its own governance practices. While the development of the specification and implementations has always been fully open source, the formal processes used to propose updates described above wasn't used. This allowed changes to be specified and agreed upon quicker by researchers and implementers. When the Beacon Chain is merged with the current Ethereum execution layer (eth1), the governance process to propose changes to either part of the system will be harmonized. ## Further Reading Governance in Ethereum isn't rigidly defined. Various community participants have diverse perspectives on it. Here are a few of them: * https://medium.com/coinmonks/how-ethereum-governance-works-71856426b63a * https://cryptotesters.com/blog/ethereum-governance * https://docs.ethhub.io/ethereum-basics/governance/