Abstract
Who governs Ethereum? Who decides what to change about the Ethereum protocol and when? How much of a say do end-users of the Ethereum protocol have in influencing the actions and decisions of Ethereum core developers? In this report, Christine Kim shines a light on Ethereum governance by giving a comprehensive overview of the processes and institutions involved in decision-making. She also discusses key events in Ethereum’s history where coordination between developers and the broader Ethereum community was urgently needed and controversially created.
Introduction
Ethereum is the world’s most sprawling blockchain, supporting over 4,000 decentralized applications (dapps) and attracting the highest number of developers, over 7,000, among any public blockchain platform. The network is expected to expand even further through the adoption and growth of Layer-2 scaling solutions like Arbitrum, Optimism, and Polygon. As the world’s first general purpose blockchain, Ethereum has retained its lead over other alternative Layer-1 competitors, boasting the highest market capitalization and network security, as defined by total value staked, of any general purpose blockchain. Aside from Bitcoin, Ethereum is the most important and valuable blockchain in the crypto ecosystem, which is why changes to the Ethereum protocol and the process through which changes are made have far-reaching and significant implications for the rest of the crypto industry.
Like Bitcoin, the governance process for Ethereum is based off-chain, spearheaded by the Ethereum Foundation, and conducted through online forums such as Discord, GitHub, Ethereum Magicians, and Zoom. No decisions are voted on by ETH holders through on-chain proposals or decentralized autonomous organizations (DAOs). On one hand, this ensures that the governance process for pushing code changes to the Ethereum protocol cannot be influenced by large ETH whale holders or exploited by malicious actors finding loopholes in governance-related smart contracts. On the other hand, off-chain forms of governance are difficult to audit and objectively evaluate because processes are intentionally opaque, subjective, and unstructured.
Unlike Bitcoin, Ethereum is well-versed in deploying hard forks, that is backwards-incompatible upgrades, that require the coordination of several thousands of users that run and operate Ethereum software. Over the course of 19 hard forks in the past 8 years, core developers have adapted the governance process of Ethereum to be more fast-moving and process driven, relying heavily on a weekly call series, known as the All Core Developers (ACD) calls, to discuss and keep track of governance decisions impacting the protocol of Ethereum.
This report dives into Ethereum governance, highlighting the processes, people, and forums involved in decision-making. Then, we discuss seven case studies illustrating Ethereum governance at work through unpacking the events of the DAO hard fork, the Parity multi-sig exploit, the Constantinople upgrade, ProgPoW, Afrigate, the Merge, and Shanghai.
EIPP: The Ethereum Improvements Proposals Process
The official process for upgrading Ethereum is known as the Ethereum Improvements Proposals (EIP) process. It is based off the Bitcoin Improvement Proposal (BIP) process, which is the standardized process for submitting code changes to the Bitcoin protocol. The BIP process was in turn inspired from Python’s PEP-0001 process, which outlines the model of governance for improvements to the coding language Python. BIPs and EIPs are documents that describe a new feature or change to Bitcoin and Ethereum, respectively. EIPs in specific are formatted according to a guideline and template defined by EIP-1.
There are three types of EIPs.
Standards Track: The bulk of EIPs are standards track EIPs that specify a code change to Ethereum requiring a hard fork, impacting Ethereum’s networking layer or execution API, or introducing new application-level standards and conventions. Standards track EIPs are further categorized under the names: core, networking, interface, and Ethereum Request for Comments (ERCs).
Core: Refers to code changes that require a network-wide upgrade to activate.
Networking: Refers to improvements around Ethereum’s peer-to-peer networking layer, also called “devp2p.”
Interface: Refers to code changes impacting Ethereum client API and RPC specifications.
ERCs: Refers to improvements relating to the application layer of Ethereum. There are ongoing discussions among Ethereum core developers to break apart ERCs from EIPs into a separate governance process.
Meta/Process: Meta EIPs do not propose a change to the codebase of Ethereum but rather describe a change to a process such as the decision-making process on EIPs.
Informational: Informational EIPs also do not propose a change to the codebase of Ethereum. They provide general guidelines and information about Ethereum that users can choose to ignore or follow.
Anyone with an interest in Ethereum can propose an EIP at any time. EIPs are submitted to the Ethereum EIP GitHub repo, where dedicated EIP editors are then tasked to review EIPs for technical soundness and correct formatting. As of May 2024, there are five EIP editors. The names and Github usernames of these editors are listed below:
Alex Beregszaszi (@axic)
Gavin John (@Pandapip1)
Greg Colvin (@gcolvin)
Matt Garnett (@lightclient)
Sam Wilson (@SamWilsn)
These individuals were appointed by current or emeritus EIP editors. New EIP editors are considered on a rolling basis. The five EIP editors listed above have the authority to grant new EIP editor privileges to applicants that meet the EIP editor criteria. The criteria to become an EIP editor can be found under EIP 5069: EIP Editor Handbook.
As a part of the EIP process, before submitting an EIP draft to EIP editors, the author is expected to create a “discussion-to” thread on the Fellowship of Ethereum Magicians forum, which is a website where anyone can create topics and discuss matters pertaining to Ethereum and Ethereum development. Alongside the Ethereum Magicians forum, an EIP may be posted for discussion on other online forums including Discord, ethresear.ch, and GitHub. If the proposed EIP is a core EIP, the EIP author will also present their proposal to Ethereum client teams for discussion during an ACD call. Ethereum client teams are the entities that build and maintain Ethereum client software.
The five major Ethereum consensus layer (CL) clients are Prysm, Lighthouse, Teku, Nimbus, and Lodestar. The four major execution layer (EL) clients are Geth, Nethermind, Erigon, and Besu. Representatives from these nine teams meet weekly over Zoom to discuss EIPs and their implementation in an Ethereum upgrade. After an EIP has been presented on one of these weekly meetings, that is ACD calls, the EIP author continues to source feedback and review on their proposal. The EIP author may revise their EIP according to community and client team feedback. EIPs that have gone through this process of review and have the support of client teams will be considered for implementation in a future Ethereum upgrade. Due to a high volume of EIPs, the proposals that have completed the review process are not guaranteed implementation in the next immediate Ethereum upgrade. Oftentimes, Ethereum client teams must choose between several EIPs that are equally technically sound and ready for implementation for inclusion in the next upgrade based on the proposal’s relative urgency and scope.
Over the past eight years, 61 core EIPs have been finalized and implemented on Ethereum, 57 core EIPs are actively in the process of drafting or review, and 143 core EIPs have been withdrawn or are considered inactive. Based on these numbers, 23% of core EIPs proposed by developers since the chain’s genesis have been activated in a hard fork upgrade.
In the next section of this report, we discuss in further detail both the people and the forums that are involved in the EIP process.
The People
There is a myriad of different groups that are involved in the governance of Ethereum. As the world’s most decentralized general purpose blockchain, no single user, individual, or organization has the power to change the protocol. However, collectively, every single user and stakeholder in the Ethereum ecosystem contributes to governance in big and small ways by sharing sentiment about the network on social media, operating software, contributing code, or simply interacting with a dapp on Ethereum. As there is no single company behind Ethereum, it is up to an ever evolving and changing group of ecosystem participants to apply use cases to the protocol, garner interest in the protocol, and ultimately, give the protocol value.
The collective will of users on Ethereum is rarely homogenous and growing too large to define without making sweeping generalizations. This report highlights four specific groups of stakeholders within the broader Ethereum community, which will henceforth in this report be referred to as “Community” with a capital “C”. The Community is defined as the amorphous group of individuals and entities that use, build, or develop Ethereum. Within the Community, there is the Ethereum Foundation, a non-profit set up by the original founders of Ethereum to steward the protocol’s growth and development. Then, we will discuss the role of Ethereum client teams in the Community. These are the developers that build Ethereum software and are arguably the most important decision-making in the EIP process. Then, we will define validator node operators, a relatively new group of stakeholders on Ethereum that are the primary implementors of code changes and finally, we will define dapp developers, the primary users of Ethereum that shape the use cases for the network and provide feedback to client teams about what code changes to prioritize based on end-users’ needs.
Ethereum Foundation
The Ethereum Foundation (EF) is the earliest and most prominent Ethereum-dedicated non-profit organization. It was created by the original founders of Ethereum, including Vitalik Buterin, Gavin Wood, Joseph Lubin, among others. At genesis, the EF was allocated the largest supply of ETH from the genesis block pre-mine, 12mn of a total 72mn ETH allocation.
However, over several market cycles since 2015, the total ETH holdings of the Foundation have dwindled and are estimated to hold less than 0.3% of total ETH supply as of April 2022. Like Ethereum, the structures and processes that govern the EF are difficult to define. Unlike traditional non-profits, the Ethereum Foundation does not have a clear organizational structure or role. As the Foundation website states the role of the EF “has evolved and changed its shape along with the growth of the Ethereum ecosystem.” More specifically, over the years, the EF’s prominence in the Community has waned as the number of stakeholders in the Community has grown, diluting the concentrated influence of the EF across more ecosystem participants.
As of May 2024, the EF continues to employ several Ethereum protocol researchers and developers in the Community, and lead organization around the ACD calls, as well as an annual Ethereum developer conference known as Devcon. The size of the organization in terms of the number of employees is unknown. The only members publicly named on the Foundation’s website are: Aya Miyaguchi (Executive Director), Vitalik Buterin (Co-Founder of Ethereum), and Patrick Storchenegger (Board Member). The most recent report by the EF about their operations and finances was published back in April 2022.
Client teams
Client teams build and maintain the software needed to run and connect to the Ethereum network. There are nine major Ethereum client teams, only one of which is directly maintained by the EF. The following is background on each of the Ethereum client teams:
1. Geth (EL): The oldest and most popular Ethereum software client, Go Ethereum or Geth in short, is funded exclusively by the Ethereum Foundation. Written in Golang, Geth is considered the most battle tested Ethereum client. The code is maintained by a team of 10 developers and is open sourced under a GNU Lesser General Public License (LGPL-3.0). An LGPL-3.0 license is a copyleft open-source license that requires users to open-source the code of any changes they make to the original code repository.
(As an aside, the main difference between an LGPL-3.0 and Apache 2.0 license is around derivative works. Under the Apache 2.0 license, the code can be forked and distributed without restrictions, whereas derivative works of code under an LGPL-3.0 license must remain free and open-source. Further, software licensed under Apache 2.0 can be combined with software licensed under other types, while LGPL-3.0 licensed software can only be compatible with other GPL-licensed software. Generally, the Apache License 2.0 is a more permissive license, while LGPL restricts use to exclusively encourage open-source development.)
2. Nethermind (EL): Founded in 2017, Nethermind is Ethereum’s second most popular EL client written in C#. It is built on an open-source computer software framework known as .NET Core. In August 2018, the team received a grant from the Ethereum Foundation to deliver the full client implementation. Over the years, the team has also received funding from various stakeholders in the Ethereum Community through platforms such as Gitcoin, as well as from independent contributors and partners. In July 2021, Nethermind announced a strategic partnership with Layer-2 scaling project Starkware to build a block explorer for Starkware's ZK-rollup StarkNet, among other StarkNet-related products. The Nethermind team is comprised of roughly 220 members across 55 countries. The Nethermind client is open sourced under the same license as Geth, a GNU Lesser General Public License.
3. Erigon (EL): Formerly known as TurboGeth, Erigon is a fork of the Geth client re-architected for faster sync speeds and disk-space efficiency. It was founded in 2017 and completed an alpha release in July 2020. The Erigon team, which is comprised of 10 developers, has received funding from a variety of contributors including the Ethereum Foundation and BNB Chain. Notably, the team has supported client software for other blockchains and sidechains including the BNB Smart Chain and Polygon. In addition, the team had in the past maintained an Ethereum client written in Rust called Akula and a client in C++ called Silkworm. The team has recently announced the creation of a new Ethereum CL client known as Caplin. The Erigon client is open sourced under the same license as Geth and Nethermind.
4. Besu (EL): Formerly known as Pantheon, Besu is an Ethereum client designed for use by enterprises and institutions. Launched in November 2018 by Ethereum venture studio Consensys, the project was rebranded and moved in 2019 to a new GitHub repository owned by the Hyperledger Foundation. (Consensys is a member of the Hyperledger Foundation.) The development team within Consensys that oversees building and maintaining the client is known as Consensys Quorum, formerly called Pegasys. Besu is written in Java and open sourced under the Apache 2.0 license. Consensys also funds the development of the Ethereum CL client Teku. As of October 2020, the Pegasys team, also known as the Protocol Engineering team, had over 70 members. In January 2023, Consensys announced an 11% reduction in their workforce from 900 to roughly 800 staffers.
5. Reth (EL): Short for Rust Ethereum, Reth is an experimental full-node implementation of the Ethereum EL designed for use by a broad base of users including MEV searchers, bridges, Layer-2s, and RPC node operators. Maintained by crypto VC firm Paradigm, the Reth client is written in Rust and open sourced under the Apache 2.0 license. Paradigm funds a core team of 8 developers to build Rust. However, the open-source codebase boasts over 90 contributors. In March 2024, the Rust team released Reth v0.2.0, the first major version in the client’s Beta release cycle.
6. Prysm (CL): Prysm is the most popular Ethereum CL client written in Golang and open sourced under the same license as Geth, Nethermind, and Erigon. It is maintained and developed by Prysmatic Labs, a blockchain infrastructure company that was founded in 2018 and initially funded through grants from the Ethereum Foundation, Gitcoin, Aragon, Spankchain, and others. In October 2022, the company was acquired by Offchain Labs, the company behind Ethereum Layer-2 scaling project Arbitrum. Prysmatic Labs employs roughly 12 staffers.
7. Lighthouse (CL): Lighthouse is the second most popular Ethereum CL client written in Rust and licensed under the same license as Besu, Apache 2.0. The client is maintained and developed by Sigma Prime, an information security and software engineering company based out of Sydney, Australia. Sigma Prime has received grants from the Ethereum Foundation, Consensys, Gitcoin, and others for their work on the Lighthouse client. The company was founded in 2018 and employs roughly 25 staffers.
8. Teku (CL): Maintained by the same team behind Besu (EL), Teku is Consensys’ institutional-focused CL client written in Java and open sourced under the same license as Besu and Lighthouse. Formerly called Artemis, Teku was introduced in 2020 and like Besu, is built and maintained by the Pegasys team. For more information on the Pegasys team, read the description of the Besu (EL) client.
9. Nimbus (CL): Written in Nim and licensed under the same license as Besu, Teku, and Lighthouse, Nimbus is designed for resource efficiency to make it easy for node operators to run Ethereum client software on resource-restricted devices such as phones and laptops. The Nimbus team, which is comprised of 10 staffers, is almost entirely funded by Status, a crypto wallet and Web3 browser, and the Ethereum Foundation. The Nimbus team also builds and maintains an EL client, also called Nimbus. The team was founded in 2018.
10. Lodestar (CL): Written in Typescript and licensed under a GNU Lesser General Public License v3.0., Lodestar is an Ethereum client focused on light client functionality. Light clients are a type of node, that is computer running Ethereum software and connecting to the Ethereum blockchain, that can easily sync to the chain without downloading the full chain history from genesis. The bandwidth and processing load for spinning up a light client are significantly smaller than full nodes. Lodestar is developed and maintain by ChainSafe, a blockchain research and development firm based out of Toronto, Canada. The project was initially funded in 2018 by Ethereum founder Vitalik Buterin. ChainSafe has since received grants through organizations like the Ethereum Foundation and Gitcoin. ChainSafe employs over 100 staffers.
The individuals that contribute to Ethereum client software are commonly referred to as Ethereum “core developers”. However, this term has also been used to describe Foundation employees and contractors who focus on upgrade testing or general protocol research efforts, rather than client development. Generally, any individual that is actively contributing to advancing an area of Ethereum’s core protocol, be it through research, client development, or upgrade testing, is referred to as an Ethereum core developer. The term core developers is a hotly debated subject in the Community, as no single person or entity has the authority to define this term or prevent it from being used liberally by anyone in the Community.
Validator node operators
The only types of node operators that the chain rewards through newly minted ETH are validator node operators. Since the Merge, validators replaced miners as the primary block producers of the network. Validators are created when a deposit of 32 ETH is staked on Ethereum. Once activated, a validator is randomly assigned responsibilities such as verifying transactions and appending new blocks to the canonical chain. In exchange for fulfilling these responsibilities, validators are rewarded through network issuance, transaction fees, and maximal extractable value (MEV). The collective amount of stake deposited by validators on Ethereum is a function of network security that ensures attacks on the network, such as double finality, cannot occur unless malicious actors control greater than 33% of total ETH staked.
Node operators are the group of individuals and entities that have the agency to implement or reject code changes that have been made to Ethereum software by client teams. As background, when a client team makes a backwards-compatible code change to software, the upgrade is called a “soft fork.” Conversely, a “soft fork” occurs when a backwards-incompatible change is pushed to client software. All node operators are required to upgrade their software before a certain block height to avoid being kicked off the network during the activation of a hard fork. Node operators that intentionally do not upgrade their software or run alternative, backwards-incompatible software during a hard fork will create a permanent chain split. Validators that are only operating on one version of Ethereum will then be penalized for inactivity on the other competing version. Through progressively increasing penalties, the staked ETH balances of active validators on each respective version of Ethereum eventually becomes sufficient to finalize the chain and progress the network forward.
In theory, node operators have the final say over what code changes are implemented on Ethereum and which are rejected. However, in practice, the likelihood of a permanent chain split occurring on Ethereum because of a disagreement between validator node operators is unlikely for a few reasons.
Ethereum has always had an ambitious development roadmap that from launch has envisioned major changes to the consensus protocol, fee dynamics, and user experience. The expectation of an ever-changing code base sets a precedence for validator node operators to normalize frequent upgrades, rather than reject them.
The growth of the decentralized finance (DeFi) ecosystem, including oracles and stablecoins, as well as the Layer-2 (L2) rollup ecosystem increases the costs of forking Ethereum as a permanent chain split would fragment on-chain liquidity and force several dapps and L2s that cannot duplicate operations to choose one network over the other.
The majority of ETH staked on Ethereum is staked through service providers that operate validator software on users’ behalf. This means that most users and entities earning rewards on Ethereum are not directly in control of nodes or the software upgrade made to nodes on their behalf. Stakers are a degree removed from implementing code changes prepared by Ethereum client teams and therefore, at times, may be less motivated to track or actively participate in decision-making around protocol development compared to staking services.
Despite these reasons, there have been instances in Ethereum’s history when Ethereum validator node operators have strongly influenced decisions about protocol upgrades. For example, the interests of users staking on Ethereum was the main factor influencing the prioritization of staked ETH withdrawals in the first upgrade after Ethereum’s transition to proof-of-stake. Further, before validators became the primary node operators of Ethereum, when nodes were primarily operated by miners, Ethereum underwent a permanent chain split despite the existence of an incredibly ambitious development roadmap that necessarily required frequent upgrades to achieve. This chain split, which created Ethereum Classic, was the first and so far, only major chain split on Ethereum that occurred early in Ethereum’s history in 2016 before the growth of the DeFi or L2 industries.
Validator node operators are an important group of stakeholders on Ethereum that are responsible for executing hard fork upgrades prepared by client teams. Their role as code executors in the governance process is a nuanced one that has been shaped by recent upgrades such as the Merge and Shanghai (which will be discussed in further detail later in this report), as well as the legacy of miners, the former primary node operators of Ethereum, that executed upgrades for the majority of Ethereum’s history since genesis to late 2022.
Dapp developers
In addition to the EF, client teams, and validator node operators, the dapp layer of Ethereum is the next most important and vocal focus group that influences code changes and hard fork upgrades. Dapp developers are the primary users of Ethereum, interacting with the Ethereum codebase to deploy smart contract code. Most end-users interact with dapps through a front-facing user interface (UI) that is supported by a wallet service, infrastructure provider, exchange, or the dapp developers themselves rather than directly through the Ethereum blockchain. Because of this, the needs of dapp developers are sometimes core to what drives Ethereum development, and the prioritization of certain code changes over others.
For example, the inclusion of EIP 1153 in the Cancun upgrade was driven largely by the efforts of two dapp protocol teams, Uniswap Labs and Optimism Labs. EIP 1153 introduces new cost-effective smart contract operations, TSTORE and TLOAD, for storing data in transactions that are discarded from Ethereum’s chain state after execution. During an ACD call where the code change was discussed, OP Labs’ cofounder Mark Tyneway highlighted that the EIP could potentially save end-users $3mn/year in gas costs on Uniswap alone. EIP 1153 was initially proposed in June 2018 and later proposed for inclusion in the Shanghai upgrade in November 2022. The EIP was then punted for inclusion in the following upgrade after Shanghai dubbed Cancun during a developer meeting on June 13, 2023. The EIP was activated on mainnet on March 13, 2024 as part of the Cancun upgrade.
In addition to EIP 1153, EIPs related to account abstraction have also been spearheaded primarily by dapp developers in recent months. Account abstraction is a feature that would allow smart contracts to make customizable and programmable authorizations for initiating transactions. On Ethereum, only externally operated accounts (EOAs) can send and receive cryptocurrency. EOAs unlike smart contracts cannot execute code. Enabling account abstraction has been a long-time goal of Ethereum core developers and dapp developers that recently has gained traction through a backwards-compatible EIP known as ERC 4337. Initially proposed by founder of Ethereum Vitalik Buterin in September 2021 the proposal remains in a draft stage but is actively being iterated on by various client teams, EF researchers, and dapp development teams such as Matter Labs, Polygon, Gelato, and more.
It is difficult to quantify the impact of the dapp developer community on client teams especially when the influence of developers shapes community sentiment as well. Alongside dapp developers, albeit to a lesser extent, end-users, as well as ETH holders, exchanges, and other blockchain infrastructure providers, all play some role in code change advocacy. Client teams are not immune to end-user signaling through Twitter and other social media forums as we discuss further in this report. Additionally, the individuals that make up client teams may also operate their own validator nodes and have side projects building different types of dapps and on-chain services. Therefore, while the interests of each focus group, that is client teams, validator node operators, and dapp developers, are distinct, the individuals that comprise these groups often overlap, making the stakeholders involved in the Ethereum governance process difficult to neatly categorize or define.
The Forums
The voices of Ethereum’s diverse groups of ecosystem stakeholders come together across a range of different forums. Some forums are used to draw consensus from client teams specifically rather than aggregating consensus from stakeholders across the entire Ethereum ecosystem. The primary language used across these forums is English. This may be because in general, English is considered the world’s most global language, spoken by the highest number of people. English is a key requirement for individuals and companies wanting to participate in the Ethereum governance process. However, the EF is working on initiatives to improve the communication of key decisions made through governance to non-English speaking communities by translating informational documents about Ethereum in several different languages. The ethereum.org website, run by the EF, has been translated into 55 languages. Additionally, Devcon has been purposefully located by the EF in areas of the world to expand Ethereum’s reach to a non-English speaking population. In 2022, Devcon VI was hosted in Bogota, Colombia.
The following is a list of the four main forums through which Ethereum development is discussed, organized, and executed. Aside from these forums, community discussions around Ethereum are also shared on social media platforms like Twitter and Reddit. However, the social media platforms, while popular, do not frequently host focused and in-depth discussions around Ethereum development or governance. Rather, they are used by Ethereum community members for sharing quick updates and information about Ethereum-related topics that can spark discussions but are not formally recognized as key governance forums in the decision-making process around EIPs.
Ethereum All Core Developers (ACD)
One of the most important forums for decision-making about Ethereum protocol development is the ACD calls. Organized by the Ethereum Foundation, the ACD calls started as early as November 2015, a few months after the launch of Ethereum. They are publicly recorded Zoom calls lasting roughly an hour and half. It is open for anyone in the Ethereum community to join but most frequently attended by EIP authors, client teams, Ethereum Foundation researchers, and the Ethereum Cat Herders. The ACD calls are open for any interested person to join either through the livestream or directly on Zoom.
From 2016 to 2021, the ACD calls were chaired by Ethereum Foundation employee Hudson Jameson. During this period, the ACD calls were held on a bi-weekly cadence. Jameson has since moved on from chairing the ACD calls and presently works as an advisor to various Ethereum projects, including Status, Chainlink, and the development team behind Polygon, Matic Labs. Starting in 2021, the Ethereum Foundation’s Tim Beiko stepped up to take over as Chair of the ACD calls. In parallel to these calls, from 2018 to 2022, Ethereum core developers focused on building Ethereum’s proof-of-stake consensus protocol have also organized around bi-weekly calls. These calls have been chaired by the Ethereum Foundation’s Danny Ryan.
Since the activation of the Merge in September 2022, the ACD calls have been renamed and formalized into two separate meeting series: All Core Developers Execution (ACDE) and All Core Developers Consensus (ACDC) calls. Each call happens on a bi-weekly cadence, which means there is now an ACD call hosted every week. ACDE calls are chaired by Tim Beiko and focus on protocol-level changes to the execution layer (EL) of Ethereum. ACDC calls are chaired by Danny Ryan and focus on protocol-level changes to the consensus layer (CL) of Ethereum.
The structure of ACD calls post-Merge reflects the dual network nature of Ethereum and the increasing protocol complexity around changing the protocol as it involves an increasing number of subject matter experts and network-specific client teams. ACD calls are focused on discussing the technical merits of EIPs. Though this is the goal, it is difficult at times to prevent discussions around the ethics or morals of a decision on ACD calls depending on the subject matter at hand. There have been over 250 ACD calls organized since 2015. Most have been recorded live and can be re-watched on YouTube.
ETHMagicians and Ethresear.ch
The agenda for ACD calls is often influenced by the discussion and conversations posted to the ETH Magicians and Ethresear.ch forums. These forums are where EIPs in an ideation or draft phase are discussed and circulated for feedback. Additionally, these forums also host in-depth discussions around non-technical issues about the Ethereum protocol such as what EIPs and initiatives should be prioritized for an upgrade over others based on community sentiment. While both forums are equally active, ETHMagicians is a more general forum than Ethresear.ch for discussing virtually any topic, technical or non-technical, about Ethereum. Ethresear.ch tends to feature early-stage research ideas about technical code changes to the protocol that once formalized are then posted to ETHMagicians for broader Community discussion.
ETHMagicians is organized by former Ethereum Foundation core developer Jamie Pitts and a pseudonymous developer for the Geth (EL) client known as “Lightclient”. Ethresear.ch is organized by multiple Ethereum Foundation employees including Hsiao-Wei Wang, Justin Drake, Danny Ryan, and Vitalik Buterin.
Discord
For day-to-day coordination on active EIPs being prepared for a forthcoming upgrade and urgent updates to client teams, there is a dedicated Discord chatroom where Ethereum core developers, researchers, and other members of the Ethereum community coordinate development in real-time. The Ethereum Research and Development Discord channel is where client teams and the broader Ethereum community are encouraged to work together to solve issues with the protocol, work on research initiatives, and ask questions. It is used as the primary communication channel during an Ethereum upgrade by client teams to communicate the health of the Ethereum network and coordinate the launch of upgrades on Ethereum test networks. It is also a forum for communicating and organizing community calls that run alongside ACD calls such as the ones for discussing technical details for EIP 4844, proto-danksharding, and changes to the EIP process.
From 2015 to 2018, the primary channel for asking questions about the Ethereum protocol and getting involved in the daily development of the protocol was through a chatroom known as Gitter. However, as the community of Ethereum and number of contributors to the protocol grew, there was a need for a more sophisticated way to organize multiple chatrooms on one forum. Hence, developers migrated communications to a shared Discord channel that as of July 2023 hosts over 50 separate chatrooms for a variety of niche subjects of Ethereum research and development. The Ethereum Research and Discord channel is the hub for asynchronous discussion of topics on ACD and tracking the active work of implementations of proposals raised on ETHMagicians or Ethresear.ch.
GitHub
Finally, the primary forum for drafting and documenting the state of the Ethereum codebase is GitHub. On GitHub, the organization page under the name “Ethereum” hosts hundreds of code repositories. These repositories feature code on draft versions of the protocol that are being worked on by Ethereum researchers and client teams for an upcoming upgrade, as well as historical records of ACD calls and copies of finalized EIP proposals. The repository hosts specifications detailing more than just the core protocol of Ethereum, including documentation around node APIs, the Solidity smart contract language, testing tools, and more.
Caption: The front page of the official Ethereum GitHub repository.
Source: GitHub
Ethereum core codebase, defined as the EL and CL specifications, changes month to month. Client teams and employees of the Ethereum Foundation are the primary individuals that have access to merging and updating the Ethereum GitHub repository. When a key decision is made on an ACD call or asynchronously on Discord, the actual change to the Ethereum specifications, that is the execution of governance decisions impacting Ethereum code, happens on GitHub. On GitHub, users can track changes made to Ethereum specifications and access the latest version of specifications. The merging of code changes to the official Ethereum GitHub repository is one of the most important steps signaling the finalization and implementation of decisions made on other governance forums.
While GitHub is a leading platform for open-source code development among computer programmers more broadly, Ethereum developers have discussed in the past the need to reduce reliance on this centralized platform, especially given instances where GitHub has shut down access to its platform due to pressure from governments. Alternatives to Gitcoin for decentralize development that could be explored by developers down the road include Radicle and Mango. Additionally, the Community is encouraged to host local copies of the Ethereum codebase on their devices given that the version control system, git, that underlies GitHub is a permissionless protocol that does not need to be hosted or managed through the website. Further, one of the motivations for hosting conversations about code changes on ETHMagicians and Ethresear.ch is to duplicate the explanation of issues and pull requests featured on GitHub across several other platforms.
Honorable Mentions
Aside from the main people and forums mentioned above, there are a handful of organizations and protocols that have made meaningful impacts on Ethereum development over the years.
The Ethereum Cat Herders
The Ethereum Cat Herders is a group of individuals funded by donations to create meeting notes, write informational blog posts, conduct community outreach, and create video content to educate the broader public about Ethereum. The group was created in January 2019 by prominent Ethereum community figureheads such as former ACD Chair Hudson Jameson and former core developer Lane Rettig. The group is led by Herder-in-Chief Pooja Ranjan, the founder of a blockchain publishing website known as EtherWorld. The Cat Herders is a decentralized group of “project managers” for Ethereum motivated to help coordinate network upgrades and improve communication from client team to the broader community. They conduct surveys and analysis on EIP activity and inform ways to improve the governance process around Ethereum code changes.
Related to their involvement in shepherding the EIP process through project management, they host EIP improvement calls every week and EIP office hours to keep track of the status of each EIP and move them through the stages of discussion, draft, review, last call, and final. They also host a weekly YouTube series featuring EIP authors and their proposed code changes called PEEPanEIP. The Ethereum Cat Herders works closely with EIP editors to refine the EIP process and make changes in accordance with group consensus.
Protocol Guild
Alongside the Ethereum Foundation and Ethereum Cat Herders, there is the Ethereum Protocol Guild which is a smart contract application designed to help fund Ethereum core development. Anyone can send fungible tokens to the smart contract, which is then distributed to a registry of addresses owned by individuals who are actively contributing to Ethereum protocol research or client development. As of June 2023, there are 142 individuals on the Protocol Guild registry from a variety of client teams including Geth, Erigon, Besu, Lighthouse, Lodestar, Nethermind, Prysmatic Labs, Teku, and Status. Over $17.8m has been distributed through the Protocol Guild as of May 2024, with funds actively donated by major dapp projects such as Uniswap, Ethereum Name Service, Ether.fi, Nouns DAO, and Moloch DAO.
The Protocol Guild accepts funds from any address and at any time. All funds are vested to the registry over time and proportionally distributed to members based on how long each member has been actively contributing to the Ethereum protocol. The Protocol Guild can be used as a proxy for evaluating the growth in the number of Ethereum core developers over time.
The Protocol Guild seeks to actively help fund all Ethereum core developers through voluntary donations automatically distributed to contributors, also known as Guild members. The Guild members are themselves responsible for keeping the registry of developers up to date by removing or adding new members.
Optimism’s Retroactive Public Goods Funding
A prominent contributor to the Protocol Guild is the Optimism Collective. Optimism is the second most valuable L2 built atop Ethereum, next to Arbitrum, with to $6.5bn worth of assets bridged on-chain. Optimism was launched in 2021 by a team of developers called OP Labs. OP Labs operates the software responsible for aggregating and ordering user transactions in a block known as the sequencer. While the intent is to decentralize this function over time, OP Labs has committed to giving all profits earned by their sequencer through transaction fees to public goods funding experiments. All sequencer revenues accrue to the Optimism Foundation, which is a nonprofit organization dedicated to growing the decentralized Optimism “Collective”. (Think of the OP Collective as Optimism’s version of the Ethereum Community.)
The Foundation redirects revenues to public goods projects voted on by OP token holders and other Collective members as defined by Optimism’s two-house governance model. Since 2021, the Optimism Foundation and the broader Collective has redistributed over 40mn OP tokens to various public goods initiatives. The top recipient of these distributions has been the Protocol Guild, receiving over 600,000 OP tokens over three funding rounds.
Gitcoin
The Protocol Guild is an effort to create a long-term funding mechanism for public goods considering a waning Ethereum Foundation budget and ever-growing ecosystem of end-users and dapps. Another example of a funding mechanism with long-term potential for supporting Ethereum core protocol development is Gitcoin. As mentioned, several client teams such as Nethermind, Prysmatic Labs, Lighthouse, and Lodestar have relied on Gitcoin in the past for parts of their funding. Gitcoin is designed to support coders and developers working on open-source software by helping them fundraise for their projects in cryptocurrency. For more background on public goods funding in crypto, read this Galaxy Research report.
Past Upgrades
Over the last eight years, Ethereum core developers have executed 19 backwards-incompatible, hard fork upgrades. These upgrades have varied in complexity, urgency, and controversy. One of these upgrades resulted in a permanent chain split. Another ejected an entire group of network stakeholders from network participation. Each upgrade has influenced the Ethereum governance process and shaped it into the multi-faceted process it is today involving several peoples, organizations, and forums. In this section, we will discuss seven major governance decisions in the eight-year history of Ethereum and further examine the people, organizations, and forums at play in the decision-making process.
Creating Consensus on Technical Issues
Most of the time, Ethereum core developers step in to push and implement code changes through the EIP process. In addition, they are the ones that make executive decisions for the blockchain at times when there is an unexpected and time-sensitive vulnerability that requires urgent action. The most contentious decision in Ethereum’s history, the DAO hard fork, stemmed from an unexpected bug in a smart contract application known as the DAO impacting many ETH holders. When deciding how to best address unexpected technical issues, Ethereum core developers are the main voices ideating, proposing, and ultimately implementing a solution. In the case of the DAO hack, the solution implemented by Ethereum client teams resulted in a permanent chain split, and the creation of a new Ethereum protocol, which illustrated an important characteristic of Ethereum, that is its permissionless nature that allows any group of users to fork the codebase and start a new version of Ethereum. The DAO hack also illustrated how Ethereum core developers are not always a homogenous group of individuals that share the same perspective on how the Ethereum codebase should evolve.
The following are three case studies depicting how Ethereum stakeholders came to consensus over technical issues:
Case Study 1: The DAO Fork
What happened: On June 17, 2016, a smart contract protocol known as The DAO controlling 15% of the total ETH supply at the time was hacked and drained of roughly 70% of its funds. The hack occurred less than a year into the launch of Ethereum. The DAO was designed to be an autonomous venture capital vehicle that would allow DAO token holders to vote on proposals and support various blockchain projects with the fund’s pooled capital. The DAO was the first decentralized autonomous organization of its kind. For more information about DAOs, read this Galaxy Research report. The DAO project became the largest crowdfunding event in history at the time, raising $150mn from over 11,000 contributors.
The DAO was hacked through an exploit known as a reentrancy bug that allows a malicious actor to withdraw money repeatedly from a smart contract at no cost. It occurs when the malicious actor makes an external call from the targeted smart contract to another smart contract. The untrusted smart contract then makes a call back to the original smart contract. Every time a call was initiated to the DAO contract by the contract of the hacker, the DAO smart contract failed to check and update its balances before approving a transfer of funds. This is how the DAO contract was slowly drained of most of its assets. As soon as the creators of the DAO caught on to the bug, they preemptively started to drain the DAO contract using the same technique as the hacker. The creators of the DAO managed to save 30% of DAO funds but the remaining 70% was in the control of the hacker(s).
Who was involved: The team behind the DAO project was a group of pseudonymous developers known as Slock.it. Slock.it envisioned the DAO to be a fundraising mechanism for bootstrapping other dapp ideas, one of the most notable dapp ideas from Slock.it at the time being a decentralized ride-sharing application. The Ethereum Foundation played a major role in communications about the DAO hack after the smart contract was exploited. On the Ethereum Foundation’s blog, Ethereum Foundation core developers proposed ideas for paths forward in the aftermath of the hack such as the implementation of a soft fork to mitigate the impacts of the hack on token holders. In 2016, miners were the individuals that were running Ethereum nodes and securing the Ethereum blockchain. Therefore, they were also the main proponents that would implement any code changes from Ethereum core developers through upgrades to their software. Due to the contentious nature of the issue, which centered around a fierce debate on smart contract code immutability, consensus on the best solution forward was difficult to garner from the Ethereum community. Ethereum stakeholders, including ETH holders and dapp developers, shared opinions across various forums including Twitter and Reddit. However, decision-making was primarily conducted through ACD calls, Gitter, and GitHub.
How the issue was resolved: The initial proposal to address the DAO hack through a backwards-compatible soft fork proposed by Geth (EL) developers Peter Szilagyi in an Ethereum Foundation blog post on June 24, 2016 was quickly abandoned after Ethereum core developers found out this could result in a DDOS attack vector on the broader network. After weeks of discussion, Ethereum core developers came to the consensus that the only technical solution to address the issue of lost funds from the DAO hack was through a hard fork upgrade that would allow Slock.it developers to reallocate all the capital in the DAO to a different smart contract not vulnerable to a reentrancy exploit.
The proposal to initiate a hard fork upgrade was first proposed by Stephan Tual, the founder of Slock.it and a developer employed by the Ethereum Foundation at the time. The proposal sparked debate on the principle of “code is law” and the extent to which Ethereum’s integrity as a blockchain rested on upholding this principle. Ethereum core developers organized a carbon vote on July 15, 2016, to decide whether the logic to initiate a hard fork should be opt-in by default with the next immediate software client release. A carbon vote is an on-chain mechanism for ETH holders to signal their preference for a governance proposal by submitting a zero-fee gas transaction. The DAO controversy was the first instance where Ethereum core developers relied on an on-chain carbon vote as a secondary measure for gathering consensus. 4.5% of total ETH supply at the time voted and 87% of the voting ETH supply voted in favor of making the hard fork opt-in by default for node operators.
About a month into the hack, the hard fork was scheduled by Ethereum client teams. The proposal had support from major community figureheads such as Vitalik Buterin and organizations like the Ethereum Foundation. Further, the client diversity of Ethereum at the time was extremely low. Despite there being six client implementations, 97% of node operators ran the Geth client, which is why it was easier to coordinate a client upgrade among client teams at the time.
By moving forward with the controversial hard fork proposal, client teams were leaving it up to miners and other node operators to either accept or reject their code changes. The hard fork was scheduled to activate on July 20, 2016, a few days after the carbon vote was completed on-chain. During the DAO hard fork, a subset of Ethereum node operators did not upgrade their nodes and created a permanent chain split. The version of Ethereum that did not accept the DAO hard fork upgrade is now known as Ethereum Classic. Ethereum Classic has continued to progress as a network alongside Ethereum over the years. However, it has experienced multiple 51% attacks due to a lack of security and user participation. For years after the DAO hack, the Ethereum network has outpaced Ethereum Classic in terms of adoption, miner participation, that is hashrate, and most importantly, value.
One of the main reasons why Ethereum maintained a lead over Ethereum Classic in the aftermath of the DAO hard fork was because most developer mindshare, that is client team developers, continued to build on Ethereum, rather than Ethereum Classic. Ethereum, since its launch, has been a blockchain with an ambitious development roadmap that many investors and stakeholders recognize requires a strong development team to spearhead. During the DAO hard fork, the main software development team was Geth and the consensus among Geth developers, which was influenced by the figureheads leading the Ethereum Foundation at the time such as Vitalik Buterin, was to execute the hard fork returning funds from the DAO hack to the DAO creators. This consensus among Geth developers and the Ethereum Foundation more broadly held a large influence over what the Ethereum community and the larger crypto industry viewed as the appropriate course of action for Ethereum.
Main takeaways: The DAO hack changed dapp developers’ approach to smart contract development in major ways. In a presentation a few months after the hack, Lefteris Kaperelli, a Slock.it developer, explained that one of the lessons all dapp developers should take away from the DAO hack is the need for decentralized applications to implement “a kill switch” to safeguard the application from unexpected hacks. The idea of implementing upgradeability in immutable applications and veto powers through multi-signature wallets and governance bodies has become widely popularized in the aftermath of the DAO hack and several others like it that occurred after the DAO. Today, most decentralized applications are upgradeable on Ethereum.
Regarding Ethereum’s governance, the DAO hack was the most contentious issue up until that point in Ethereum’s history. The issue illustrated how the Ethereum governance mechanisms move forward when unanimous consensus in the Ethereum community cannot be reached. It illustrated three main learnings:
The veto power in the decision-making process of Ethereum falls on the Ethereum client teams who decide what changes to make in Ethereum software. However, once an agreement is made and software released, it is up to node operators to either accept or reject code changes. At the time, the main Ethereum software client was Geth and the Geth team, along with the Ethereum Foundation and Vitalik Buterin, were all in favor of a hard fork solution. Therefore, they released the necessary software upgrade that activated a hard fork on Ethereum at block height 1,920,000.
The use of a carbon vote illustrated how off-chain governance processes can be reinforced through on-chain mechanisms. Though the carbon vote was non-binding, meaning it had no power to change the course of decision-making happening amongst developers over ACD calls and Gitter, it did reinforce the leaning of the Ethereum community towards executing a hard fork.
Finally, this case study illustrated the ability and authority of node operators on Ethereum to choose what version of the Ethereum protocol to run. Some chose to reject the DAO hard fork. However, as mentioned prior in this report, the growth of the decentralized finance (DeFi) industry since 2016 is making it increasingly more cost-prohibitive and technically challenging for alternative versions of the Ethereum protocol to co-exist due to a fragmentation of liquidity and dapp interoperability.
Case Study 2: The Parity Multi-Sig Exploit
What happened: In November 2017, Ethereum’s most widely used multi-signature (multi-sig) wallet developed by Parity technologies was accidentally exploited and 514,000 ETH, worth over $320mn, distributed across more than 580 user wallets became permanently frozen. The exploiter “devops199” alerted the Parity development team on GitHub that they had found a way to transfer ownership of smart contracts controlling Parity multi-sig wallets. Attempting to return ownership of contracts back to the Parity team, Devops199 accidentally triggered the “kill() function” linked to Parity’s code, effectively freezing the balances of Parity multi-sig users. The devastating exploit was one of two major bugs discovered in Parity’s multi-sig wallet in 2017.
Who was involved: As background, Parity Technologies was founded in 2015 by one of the co-founders of Ethereum, Gavin Wood. Over the years the company has built software clients for Bitcoin, Zcash, and Ethereum. At the time of the multi-sig exploit, the Parity software client was the second most popular Ethereum client used by node operators. Parity Technologies later retired support for the Parity client, renaming it to OpenEthereum, in 2019 and shifted focus to building their own Layer-1 blockchain, Polkadot. Polkadot launched on mainnet in May 2020."
How the issue was resolved: To unlock frozen user funds, the Parity development team proposed EIP 999 in April 2018. EIP 999 would restore the deleted code that was accidentally self-destructed by Devops199 through a hard fork upgrade. Despite the large swaths of Ethereum users impacted by the Parity multi-sig exploit, the code change was never implemented in an upgrade. The EIP was eventually withdrawn by Parity developers after intense community backlash and opposition to the proposed change.
Main takeaways: Despite Parity being the second most popular Ethereum client and the technical soundness of EIP 999 in the eyes of Ethereum core developers, the proposal failed to be implemented because implementation would have clearly resulted in another permanent chain split. Jutta Steiner, co-founder of Parity and CEO at the time, wrote in a blog post on April 26, 2018, that the company had “no intention to split the Ethereum chain” over EIP 999. The Parity multi-sig exploit is an important case study highlighting the limits of influence over Ethereum’s code base by Ethereum client teams. Despite being the most active participants in the Ethereum governance process, client teams are generally motivated to implement code changes that the majority of the Ethereum community will support and shy away from the ones that have a high probability of repeating the events of the DAO hack.
Like the DAO hack, the controversy around EIP 999 centered around debates over Ethereum’s code immutability. However, this time, the overwhelming consensus among Ethereum stakeholders, outside of the Parity client team, was to reject Parity’s proposed code change and preserve code immutability. Part of this consensus was drawn through a week-long on-chain carbon vote, which resulted in 55% of voters voting against the activation of EIP 999. The use of another carbon vote to gage broader community sentiment also sparked debate over the efficacy of on-chain voting in general in the Ethereum governance process. Many Ethereum developers and ETH holders argued that carbon votes are inaccurate and ineffective given the ability for ETH whales to skew voting results with their holdings. Aside from the informal carbon vote, which has historically never held much legitimacy in the governance process, EIP 999 underwent the formal EIP review process through which Ethereum client teams and the broader group of Ethereum core developers discussed the code change in earnest. Over the course of three months since the initial submission in April 2018, EIP 999 was rejected by multiple individuals for lack of community support.
Case Study 3: Constantinople
What happened: The sixth Ethereum upgrade known as Constantinople primarily reduced block issuance from 3 to 2 ETH, among a few other minor technical improvements to the Ethereum codebase. The scope of Constantinople was finalized in August 2018 and was scheduled to activate in January 2019. In addition to the block issuance reduction, also called EIP 1234, the other code changes included in the finalized scope of Constantinople were:
EIP 145: Creates a more efficient method of information processing known as bitwise shifting.
EIP 1052: Offers a means of optimizing large-scale smart contract code execution.
EIP 1283: Introduces a more equitable pricing method for changes made to smart contract data storage.
EIP 1014: Lays the groundwork for a certain type of scaling solution based upon state channels and "off-chain" transactions.
Less than 48 hours before the scheduled activation of the Constantinople upgrade, a blockchain security and audit firm known as Chain Security detected a bug in the upgrade code. EIP 1283 upon closer inspection would allow hackers to use the repriced storage operations to manipulate smart contract balances. The nature of the bug was similar to the exploit of the DAO in that it could create opportunities for malicious actors to launch a reentrancy attack on smart contracts.
Who was involved: Chain Security released a blog post on January 15, 2019 detailing the exact nature of the exploit. The same day Ethereum core developers convened over Gitter and an impromptu ACD call to discuss next steps. They quickly came to consensus over suspending the scheduled upgrade and deciding on a new upgrade date, as well as a software patch, on the next regularly scheduled ACD call, which would be held in three days on January 18, 2019. During the ACD call, developers came to a consensus about a patch for the upgrade and re-scheduled the hard fork for activation on February 28. Assisting with the last-minute communication to Ethereum miners and other node operators of these decisions were both the Ethereum Foundation and the Ethereum Cat Herders. Both groups issued blog posts and reached out to community stakeholders to alert them of last-minute changes to the hard fork schedule.
How the issue was resolved: Because the nature of the issue was technical, the Constantinople bug was resolved primarily amongst client teams. Ethereum core developers were quick to brainstorm the most effective solution and implement it among their software clients. Unlike the patch to the DAO hack, the solution to the Constantinople bug was not controversial but it did raise concerns around the testing process for EIPs and highlighted needs to bolster testing efforts around upgrades to ensure new code changes are adequately examined before deployment on mainnet. Once the bug was patched and a new hard fork date set, Ethereum miners and other node operators successfully upgraded their hardware without issue on February 28, 2019.
Main takeaways: The resolution of the Constantinople bug highlighted how quickly the Community can rally under short notice to change the Ethereum protocol on the fly, especially if motivated by network security concerns. Given the lack of contention around the issue itself, Ethereum node operators were able to revert to the old version of client software within the matter of 48 hours. In addition, core developers were able to successfully activate a patched version of the Constantinople upgrade in February 2019. The existence of a bug in the original upgrade code did not dissuade Ethereum developers from executing upgrades, but rather encouraged them to focus more time and resources on testing for future upgrades.
Creating Consensus on Social Issues
The decision-making process becomes considerably longer and more drawn out when the issue at hand arises from a dispute around the social values of Ethereum. The DAO bug was an example of a technical failure in a smart contract. However, the DAO hard fork represented a solution to a technical bug that challenged the value of “code is law” on Ethereum, which is why it created a high level of controversy and inaction by Ethereum core developers. There have been a handful of other instances in Ethereum’s governance history when Ethereum core developers have had to respond to social issues that are not technical in nature but speak to broader community values and beliefs.
In the two case studies below, Ethereum core developers deliberately choose to take a back seat in terms of leading development. They relinquish much of the decision-making process to the broader Ethereum community and as a result, the many voices of various Ethereum stakeholders collide and result in delayed resolutions to issues and proposals. Because social issues on Ethereum involve a greater number of voices than the number of core developers, creating consensus is difficult and often riddled with uncertain outcomes.
Case Study 4: ProgPoW
What happened: Programmatic proof-of-work (ProgPoW) is a proof-of-work mining algorithm designed to favor less efficient miners and discourage the effectiveness of specialized miners. Specialized miners refer to individuals or businesses operating specialized mining machines called Application Specific Integrated Circuits (ASICs). These machines are highly optimized to do a single task and cannot easily be repurposed for other tasks. Graphic Processing Units (GPUs) are computers that can do a range of different tasks and are therefore more widely used and cheaper to buy. The goal of ProgPoW was to make Ethereum ASIC resistant and prevent centralization of mining hashpower. The mining industry of Bitcoin over the course of a few years has become dominated by ASIC machines operated mainly by highly capitalized, publicly traded, and regulated public companies.
In April 2018, three years after the launch of Ethereum, the first Ethereum ASIC was released by mining hardware manufacturer Bitmain. Concerns among the Ethereum community of the inevitable centralization of hashpower due to the adoption of ASIC technology fueled research and development for ProgPow. The algorithm was proposed by a team of developers called “IfDefElse” on Ethereum Magicians in May 2018.
Though the proposal was technically sound in the view of Ethereum core developers, the Ethereum community was divided on the effectiveness of the algorithm to prevent ASIC dominance. Given that ASICs are simply specialized machines, it is difficult to build a mining algorithm for which a computer could not be optimized to some degree. The attempts to create ASIC-resistant mining algorithms from other blockchain projects in the industry such as Monero, Ravencoin, Horizen, Ethereum Classic, and others do not have a consistent track record of effectiveness. Given the nascency of ASICs on Ethereum at the time in 2018, there were also questions from the community of whether the issue was all that urgent for developers to address post haste in a hard fork upgrade ahead of other EIPs.
From February to March 2019, nearly a year after the initial EIP was proposed, Ethereum client teams with the help of the Ethereum Foundation and the Ethereum Cat Herders conducted multiple surveys to determine the level of support and consensus for ProgPoW.
Caption: Twitter survey hosted by the Ethereum Cat Herders to assess sentiment around ProgPoW.
Source: Twitter (@EthCatHerders)
The Ethereum Foundation organized two on-chain votes around ProgPoW. The first was designed similarly to the one conducted in the lead-up to the DAO hard fork. It calculated votes weighted by the amount of ETH held by a token holder. The second on-chain vote was targeted at surveying the sentiment of Ethereum miners around ProgPow by allowing independent miners and mining pools to input data into an extra field of mined blocks. Both votes revealed overwhelming support for the code change. Miners representing nearly half of Ethereum hashrate at the time participated in the second on-chain vote and 77% of participating miners voted in favor of ProgPoW.
Miners on Ethereum were largely in favor of the ProgPoW proposal, as most Ethereum miners at the time were GPU miners. However, dapp developers and other Ethereum stakeholders were not in favor of ProgPoW due to the concern that the implementation of the algorithm could cause a network split and reduce the value of ETH. Throughout this debate, prominent Ethereum core developers such as Vitalik Buterin and members of the Geth team repeatedly reiterated that they were neutral about the change and would implement whatever the community thought was best. On multiple ACD calls, Ethereum core developers approved ProgPoW for its technical soundness. Mining manufacturing companies such as Linzhi publicly opposed the upgrade.
Who was involved: IfDefElse was a team of three developers, two who remained pseudonymous and only one that revealed their personal identity. The public-facing member of IfDefElse was Kristy Leigh Minehan. At the time, she was the Chief Technology Officer for a blockchain infrastructure firm known as Core Scientific. Minehan attended several ACD calls and Ethereum conferences to explain the ProgPoW algorithm, though the controversy of it soon caused Minehan to retreat from the limelight. In many instances, Minehan was targeted and bullied for her project. She was accused of being hired by Nvidia and AMD engineers to sabotage ASIC mining manufacturers. Minehan no longer works on ProgPoW. She advises cryptocurrency companies such as asset management firm Valkyrie and cryptocurrency mining firm Merkle Standard.
How the issue was resolved: To address community concerns around the effectiveness of ProgPoW for ASIC-resistance, the Ethereum Cat Herders announced that they would be raising $100,000 to commission an independent, third-party audit of the ProgPow code. It took roughly six months from March 2019 to September 2019 for the Cat Herders to raise funds and commission the audit from blockchain security firm Least Authority. In September 2019, the results of the audit were released. The audit confirmed that the ProgPoW algorithm was accurate to its design and achieved its goal of encouraging greater ASIC resistance, though the audit did also warn that future hardware advancements may reduce the effectiveness of ProgPoW over time, as suspected. Once the audit was released, Ethereum core developers agreed to include the code change in an upcoming hard fork. However, continued pushback from members of the Ethereum community, particularly dapp developers, created controversy that discouraged Ethereum core developers from prioritizing ProgPoW for inclusion in an actual upgrade. The ProgPoW debate lasted roughly 2 years in the Ethereum community. In March 2020, during ACD #82, developers held their last public conversation around the code change. During that call, developers voiced their concerns around the lack of support from the Community for ProgPow and their decision as a result to exclude it from inclusion in the next immediate hard fork.
Main takeaways: ProgPoW did not address a technical bug, hack, or issue with Ethereum impacting a high number of ETH holders or the security of the Ethereum network itself. The main drivers of ProgPoW development were miners, whose voices have historically been weak and disregarded due to the efforts around forcibly removing miners from the network through transitioning Ethereum to PoS that have existed since Ethereum’s launch. Every time a change has been proposed by Ethereum core developers to reduce block issuance such as EIP 1234 or change it in a way that reduces miner revenue such as EIP 1559, the pushback from miners has never swayed the opinion or sentiment of Ethereum core developers. Therefore, the governance processes which are designed to review and progress changes from a technical merit standpoint did not help ProgPoW get activated and the individuals supporting the change were not influential in the Ethereum ecosystem.
Despite on-chain votes and the stamp of technical approval from Ethereum core developers, the ProgPoW debates were illustrative of how a group of network stakeholders can be powerless to change Ethereum without broader community support from end-users and dapp developers. Ethereum core developers were not opposed to the code change but found it difficult to prioritize a contentious upgrade at the expense of other code changes that were comparatively less contentious and garnered more support from Ethereum end-users. Additionally, the need for ProgPoW waned over time as Ethereum core developers turned their focus and attention to PoS and deprecating mining algorithms starting in early 2021.
Case Study 5: Afrigate
What happened: It is not often that an Ethereum core developer is driven out by the Ethereum community. However, as it was mentioned in the prior case study, there have been instances where intense social media bullying has caused certain EIP authors to retreat from public discourse. This was the case for Ethereum core developer Afri Schoedon, who was a developer for the Parity client built by Parity Technologies. Parity Technologies was founded by Gavin Woods, one of the co-founders of Ethereum, alongside Vitalik Buterin and six others. Alongside the Parity Ethereum client, Parity Technologies built an alternative general purpose blockchain known as Polkadot. Schoedon who has been a code contributor to Ethereum since 2015 and the primary coordinator for Ethereum hard forks tweeted on February 14, 2019, when the Polkadot protocol was under active development:
Caption: Ethereum core developer Afri Schoedon jokingly makes a meme of the Polkadot protocol.
Source: Google Webcache
Over the next 48 hours, Schoedon was bullied, criticized, and harassed for his tweet, which was clearly meant to be joke. Critics accused Schoedon on social media for having “conflicts of interest,” despite Schoedon reiterating that he has never had a direct involvement in the development of Polkadot. Schoedon clarified on Twitter that his meme was meant to stir discussion around the development of Serenity, which was the name for Ethereum’s transition to PoS at the time, not create a narrative of competition between Polkadot and Ethereum. However, the continued criticism caused Schoedon to delete many of his tweets and eventually, on February 19, announce that he would be leaving the Ethereum community. “I did not quit social media, I quit Ethereum. I did not go dark; I just left the community. I am no longer coordinating hard forks, building testnets, or contributing otherwise. I did not work on Polkadot, I never did, I worked on Ethereum. I did not hate Ethereum, I loved it,” tweeted Schoedon in one of his last tweets before deleting his Twitter account.
Who was involved: Though Schoedon was the primary one involved in the incident, other Etheruem core developers and community members rose to his defense in the aftermath of Schoedon’s departure. Schoedon moved on to help Ethereum Classic complete upgrades to improve their compatibility with Ethereum. As of July 2023, he continues to contribute to Ethereum in less public ways by contributing to the coordination of Ethereum test networks and often through the use of different pseudonyms.
How the issue was resolved: On an ACD call the next month after the incident on Twitter, Ethereum core developers announced their search for a new hard fork coordinator to replace the role of Schoedon. However, the search did not last long. In lieu of an acceptable candidate, developers agreed to split Schoedon’s role amongst multiple people. Since Schoedon’s departure, the responsibilities of a hard fork coordinator, which involves setting hard fork dates, choosing EIPs for hard forks, and leading testing efforts for upgrades, has since been spread out across multiple core developers and client teams. Additionally, in February 2019, 115 prominent Ethereum community members signed an open letter condemning the “toxic” behavior that resulted in Schoedon stepping down from his role as an Ethereum core developer. The letter reaffirmed the need for standards and norms of debate around Ethereum protocol development that promote values of respect, free speech, and privacy among participants. Former ACD Chair Hudson Jameson also hosted an AMA on Reddit to address the contention around Ethereum leadership and accountability. In March, the Ethereum client team ChainSafe hosted an in-person event in Paris to further discuss ways to acknowledge problems around the Ethereum governance process and ideate ways to improve it.
Main takeaways: Afri Schoedon, a prominent Ethereum core developer, leaving the Ethereum community was a wakeup call for Ethereum core developers, dapps developers, and end-users alike about the real effects of social media bullying on Ethereum governance. As an off-chain and rather loosely defined process of decision-making, Ethereum core developers whilst focused on technical issues and matters pertaining to Ethereum are not immune to the social debates and pressures of spearheading Ethereum development. Online bullying under any circumstance, related to Ethereum or not, is a harmful activity that negatively impacts the behavior and mindset of individuals that are targeted. Given that the decision-making process of Ethereum is heavily reliant on online mediums for discussion and debate, it is difficult to safeguard against this type of behavior. After all, this is not the only instance when a contributor to the Ethereum governance process has been harassed and ostracized within the community. However, the departure of Afri Schoedon was a catalyst for greater attention on the Ethereum governance process and the need for stronger norms and social values within this process to promote healthy and respectful discourse among participants.
Creating Consensus for the Upgrades to Proof-of-Stake
Since the launch of Ethereum, Ethereum stakeholders have long-awaited the transition to a proof-of-stake (PoS) consensus protocol. Therefore, in the years leading up to the Merge, there was little to no controversy or pushback from the community around the idea of upgrading Ethereum to PoS. However, there was controversy at different points through Ethereum’s history over the technical merits of implementing the transition through one method over another. Additionally, there was controversy at several points in the first six years of Ethereum’s existence over the urgency of this upgrade ahead of other initiatives such as improving the scalability and censorship-resistance of Ethereum.
Once technical debates on the transition to PoS were resolved among Ethereum client teams and the roadmap for activation finalized in the fall of 2022, the upgrade was welcomed with near unanimous excitement from Ethereum core developers and the broader Ethereum community. The code changes that were involved in transitioning Ethereum from PoW to PoS are among Ethereum’s most successful and transformative EIPs in history. No other upgrade has seen the same level of community alignment and excitement as the upgrades that completed Ethereum’s transition to PoS. The transition to PoS was a multi-year effort that in its initial phase of deployment relied on ETH holders to capitalize and bootstrap the protocol by staking their ETH without guarantees for when the ETH could be unstaked. Though delayed for its complexity and frequently mocked, as well as discouraged, from members of the Bitcoin community and Ethereum miners, the eventual transition to PoS known as the Merge solidified a strong narrative around Ethereum, and ether the asset, known as the “ultrasound money” narrative.
The following case studies dive into Ethereum’s transition to PoS and the governance processes involved in the two-part upgrade.
Case Study 6: The Merge
What happened: The transition to PoS went through several iterations. It became the most delayed upgrade in Ethereum’s history, initially expected to be ready 2 years after the launch of Ethereum. The decision to merge the existing Ethereum code base with the Beacon Chain, the CL of Ethereum, was a tough one as many Ethereum client teams were working on an upgrade that would replace Ethereum with the Beacon Chain. In 2018, the client teams building the transition to proof of stake was known as the Ethereum 2.0 team. They worked alongside another group of developers working on short-term initiatives for Ethereum known as Ethereum 1x from which ideas such as EIP 1559 and statelessness were developed. The efforts to advance PoS was largely separate and progressed in parallel to Ethereum core protocol development for most of its history leading up to the Merge upgrade. The Merge was activated on September 15, 2022.
Who was involved: The primary teams involved in making the Merge happen were a new suite of Ethereum client teams, many of which did not already build and maintain an existing Ethereum client. Prysmatic Labs, Lighthouse, and ChainSafe are examples of client teams that newly joined the Ethereum governance process through contributing to the development of Ethereum’s upgrade to PoS. The launch of the Beacon Chain in December 2020 was primarily advanced because of the effort of these relatively new PoS focused client teams. After the launch of the Beacon Chain, CL client teams started to engage and involve EL client teams in earnest regarding the transition. One of the primary figureheads spearheading plans for the Merge upgrade was Ethereum Foundation researcher Danny Ryan. He continues to lead Ethereum consensus layer development as the head of the ACDC calls.
How the issue was resolved: Leading up to the Merge activation date, there was an unprecedented amount of testing to ensure that the transition would happen smoothly. Ethereum core developers organized over 25 different testnet launches for the Merge. The following is an illustration of the shadow fork testnet launches that were organized by Ethereum core developers in the months leading up to Merge activation:
In addition, the bug bounty program funded by the Ethereum Foundation was quadrupled to $1mn, the highest amount ever funded by the organization, in the weeks leading up to Merge activation. The Merge required close coordination between CL and EL client teams, as well as validator node operators, the latter of which was not as well-versed as miners in upgrading node software. The nature of the upgrade also required more involvement from node operators to correctly configure client software in preparation for the Merge. The Ethereum Foundation and Ethereum Cat Herders were again front and center in reaching out to Ethereum stakeholders and educating the wider public about the nature of the upgrade. The Merge did create short-lived forks of Ethereum, but none continue to hold meaningful value or support significant levels of dapp activity.
Main takeaways: Due to the Merge, Ethereum has doubled in complexity as the protocol is now a combination of two networks that progress in tandem. This has created the need for separate governance processes to organize the code changes proposed for each of these networks, that is the EL and CL of Ethereum. As mentioned, there are two bi-weekly ACD calls for discussing the EIPs related to the EL and CL. However, there are other components of Ethereum software such as the Engine API that affect both the EL and CL for which there is no clear governance process for changing and updating. This has sparked new conversations around future updates to the EIP process to better organize changes to Ethereum considering the dual-network structure of the protocol. (These future changes to the EIP process will be discussed in more detail in the next section of this report.)
Case Study 7: Shanghai
What happened: The seventeenth hard fork on Ethereum was activated in April 2023. Called Shanghai, the upgrade activated staked ETH withdrawals from the Beacon Chain and thereby represented the completion of Ethereum’s transition to PoS. Ethereum core developers were quick to prepare the code changes necessary for Shanghai shortly after the completion of the Merge upgrade. Though there were several competing interests around what EIPs to prioritize for Shanghai, Ethereum core developers prioritized staked ETH withdrawals represented by EIP 4895 ahead of other EIPs largely due to the desires to appease the Ethereum staking community, which post-Merge had successfully become the primary security providers and node operators of Ethereum.
Who was involved: The collective voice of staking pools and ETH holders that had staked on the Beacon Chain influenced the decision of Ethereum core developers to prioritize EIP 4895 in Shanghai in an unprecedented way that was markedly different from the level of influence that miners historically have been able exert in the decision-making process. Ethereum client teams were again the gatekeepers synthesizing community sentiment and prioritizing which EIPs should be included in an upgrade over others. From October 28 to January 5, Ethereum core developers rigorously debated the scope of Shanghai over several ACD calls. The discussions highlighted differences in opinion among client teams over EIP priorities and the fact that consensus among Ethereum core developers is oftentimes not reached through a unanimous decision, but rather a rough majority vote. Once the scope and development timeline of Shanghai was set, Ethereum core developers went to work preparing and testing relevant code changes for activation.
How the issue was resolved: Shanghai was activated on April 12, 2023. Due to the success of the upgrade, there was an unprecedented influx in the amount of ETH being newly staked on Ethereum that far outpaced the amount of ETH being unstaked.
The Shanghai upgrade bolstered positive sentiment around Ethereum as a robust and full featured PoS consensus protocol. It also significantly de-risked the activity of staking by introducing staked ETH withdrawals, which subsequently led to an influx in staking inflows. As of May 14, 2024, 27% of total ETH supply is staked and the annualized inflation rate of Ethereum is trending below 1%. The consistently negative inflation rate and increasing staking rate since the activation of Shanghai has further bolstered positive sentiment around ETH as ultrasound money.
Main takeaways: The decision-making process around which EIPs to prioritize for Shanghai was notable for three main reasons.
It highlighted the influence of the Ethereum staking community, as the primary node operators and security providers of Ethereum, over the governance of the protocol.
It reaffirmed the role of Ethereum core developers as the primary gatekeepers synthesizing and coordinating upgrades for the protocol to achieve the ambitious development goals set out by Ethereum founders since the launch of Ethereum.
It further validated the ultrasound money narrative by completing Ethereum’s transition to PoS and triggering an influx of new staking inflows that has far outpaced staking outflows.
Future Upgrades
As evidenced by the seven case studies examined in this report, the Ethereum governance process is constantly evolving and loosely defined through the EIP process. Back in 2015, Ethereum was launched by a group of 8 co-founders with a four-stage development roadmap. The last stage of development was dubbed “Serenity” and represented the transition from a proof-of-work to a PoS consensus protocol. Fast forward to 2023, Ethereum has successfully completed its transition to PoS and now boasts a new 8-stage development roadmap with phase names that rhyme.
On rare occasions, decisions are made quickly through the exclusive efforts of Ethereum core developers and shared for implementation by Ethereum node operators under a quick upgrade turnaround window. Other times, decisions are relegated to the broader Ethereum community, which often results in delayed decision-making and contention between stakeholders. Through multiple upgrades and several contentious governance debates, Ethereum has evolved both as a protocol and as a social collective guided in large part by norms, values, and beliefs, rather than on-chain voting processes or mechanisms.
Despite the completion of Shanghai and the transition to PoS, which was originally envisioned by protocol founders to be Ethereum’s final major upgrade, there are a slew of future EIPs and initiatives that are expected to transform the Ethereum protocol in the months and years ahead. Most recently, through the Cancun/Deneb upgrade, Ethereum developers activated EIP 4844. Also known asprotodanksharding, EIP 4844 is a code change that introduced a new transaction type, called blobs, increased the data and storage requirements of Ethereum blocks, and created a new fee market for pricing blobs separately from regular transactions. For more information about EIP 4844, read this Galaxy Research report.
A few high-profile EIPs that developers are preparing for the next Ethereum upgrade, Pectra, include but are not limited to:
BLS signatures: Creates a new cost-effective operation for smart contract developers to use BLS signatures and SNARK verification in their code. There are many reasons for this including the ability to create more secure cryptographic proofs, better interoperability with the Ethereum Beacon Chain, and increased functionality of decentralized staking pools.
Increasing validator effective balance: Validator rewards accrue in proportion to a validator’s effective balance, which is presently capped at 32 ETH, which forces validator node operators to create new validators if they want to earn more staking rewards. To reduce the growth of the active validator set which puts a strain on the peer-to-peer networking layer of Ethereum, there are proposals to increase the effective balance of validators. For more information about the problem of validator set size growth, read this Galaxy Research report.
Execution Layer triggerable withdrawals: Allow validators to trigger exits and partial withdrawals via their execution layer (0x01) withdrawal credentials. This will support the creation of more trustless staking pool designs on Ethereum.
Other code changes that developers are considering for implementation at some point after the Pectra upgrade include:
Native account abstraction: Account abstraction is an improvement to the user experience that allows smart contract logic to control user-owned wallets. Smart contracts are not able to authorize transactions. However, externally owned account (EOAs) controlled by users can. The most prominent code change proposed to enable account abstraction is ERC 4337, which does not require a backwards-incompatible hard fork.
MEV related upgrades: Maximal extractable value (MEV) is the additional revenue that can be extracted by re-ordering user transactions within a block. There are many stakeholders involved in extracting MEV due to the lucrative amounts that can be earned. MEV strategies are not unlike certain trading strategies in traditional finance. For more information about MEV, read this Galaxy Research report.
MEV smoothing: MEV smoothing refers to smoothing out the distribution of MEV block rewards to validators to reduce reward volatility and discourage validators from trying to manipulate the consensus process to earn MEV.
MEV burn: Another strategy that goes one step further from MEV smoothing is to burn MEV revenues like the base fee on Ethereum. This would further reduce the inflation of Ethereum supply and reduce the incentives for validators to manipulate consensus for additional MEV revenue.
Enshrined PBS: MEV is currently earned on Ethereum through third-party marketplaces known as relays. To reduce the reliance on trusted entities that operate relays, there is ongoing research to implement the relay structure into the protocol of Ethereum itself. For more information about MEV relays, read this Galaxy Research report.
Single slot finality: Finality is defined on Ethereum as the point at which a block cannot be altered or replaced without penalizing at least 33% of total ETH staked. At present, finalization on Ethereum takes between 12 to 15 minutes. However, there are designs that Ethereum core developers are researching to achieve faster finality guarantees to improve the user experience through gradual increases in stake assurances within the 12-to-15-minute window.
Validator cap: Related to the initiative to reduce the growth of the active validator set, there are proposals to cap the number of validators at a certain level. Doing so would ensure that the networking layer of Ethereum can sustain fast levels of message propagation to support faster finality or lower the minimum amount of staked ETH needed to become a validator.
Issuance changes: Developers are also weighing changes to the issuance policies of Ethereum to prevent most of ETH supply becoming concentrated in liquid staking (or restaking) pools. Through issuance changes, developers hope to target an upper bound to staking participation and thereby also achieve minimum viable issuance, an idea that the protocol should not issue more tokens than what is needed for network security.
Verkle trees: At present, data about Ethereum accounts, transactions, and the blockchain state are stored using a structure known as the Merkle Patricia tree. The Merkle Patricia tree data structure allows users to easily verify a large amount of data by relying on a single cryptographic proof, representing the root of the tree. A Verkle tree data structure functions similarly to Merkle Patricia trees, however, computers can prove them more efficiently than Merkle trees.
While some of the EIPs listed above may not end up being implemented in an upgrade due to a lack of technical soundness or too much controversy, the number and scope of code changes that are being discussed for implementation are sweeping. The following is a visual representation of the development roadmap of Ethereum as summarized by Vitalik Buterin in December 2023:
Caption: Ethereum’s updated development roadmap as of December 2023
Source: Twitter (@vitalikbuterin)
Alongside code changes to the protocol of Ethereum, there are also efforts to update the EIP process to accommodate what appears to be a still more ambitious development roadmap on Ethereum’s horizon post-Merge. On recent ACD calls, developers have proposed removing ERCs from EIPs to a separate governance process as well as updating the numbering of EIPs to make them less cumbersome to track. These minor administrative changes have sparked fierce debate in the Community. It should come as no surprise then that none of the proposed changes to Ethereum’s governance process go so far as to recommending any governance processes move on-chain or become more rigid in terms of process in the near-future.
One major change to the EIP process worth highlighting for its future ramifications on Ethereum governance is the creation of a parallel to approval process for code changes implemented on Layer-2 rollups. The Rollup Improvement Proposal (RIP) process is meant to foster cooperation and coordination between upgrades on different rollups. RIPs are presented and discussed by rollup developers on a recurring meeting series known as the RollCalls. Ethereum protocol developers are weighing the extent to which the decisions on RollCalls should impact decisions on ACD calls, and vice versa, given that Ethereum developers are increasingly trying to pursue a rollup-centric development roadmap.
Outlook
As the case studies have shown, the successes, failures, and controversies of upgrades have not dissuaded Ethereum core developers from changing the code base. The frequency of upgrades is not slowing over time and the nature of changes being considered and implemented is becoming more ambitious, not less. Therefore, the role of Ethereum core developers in stewarding the protocol and achieving future upgrades on its development roadmap will remain highly elevated in terms of importance and impact.
Alongside Ethereum core developers, there is a growing group of stakeholders in the Community that are also important contributors to protocol governance. In a post about blockchain governance back in 2019, Vitalik Buterin acknowledged the concern of “ivory tower intellectuals” over taking the Ethereum governance process and affirmed that the best way to tackle this issue is to increase the number of institutions and organizations that take part in the governance process to further distribute it away from the powers of a single group.
The number of stakeholders actively involved in Ethereum governance has grown as the Ethereum dapp ecosystems has grown to include several L2 and DeFi protocols, as well as a new diversity of client teams through the Merge. Moreover, as the complexity of Ethereum’s protocol has increased, the groups of researchers and developers working on Ethereum has diversified across several parallel initiatives including those focused on scalability, MEV, account abstraction, EOF, and more.
Looking ahead, validator node operators should expect upgrades that may radically change their business models in the future. Given the expectation and reality of frequent upgrades on Ethereum, it is important for the Community to ensure that Ethereum core developers are not the main voices responsible for deciding what to upgrade about the Ethereum protocol and when. Further, as voiced by several Ethereum core developers such as Geth (EL) developer Péter Szilágyi, there is mounting concern about the complexity of the Ethereum protocol because of its ambitious development roadmap.
Complexity in the Ethereum protocol has several drawbacks, the main one being increased risk of technical bugs and failures. Therefore, while the EIP process is designed to facilitate code changes on Ethereum, it will be important for stakeholders in the decision-making process to gradually prioritize code ossification over code changes such that the need for active governance processes declines over time. This is especially important considering that there is mounting regulatory scrutiny on Ethereum, and the applications built atop the protocol. Though the interests of Ethereum protocol developers and the broader Community are the most influential in the governance process today, there are increasing pressures from regulators and law enforcement that also may influence and become an outsized voice influencing the design of Ethereum. To prevent regulatory capture of the Ethereum protocol, it is imperative that aspects of how Ethereum works become ossified beyond the ability for any stakeholder group or entity to change.
Conclusion
Ethereum governance is a complex maze of people, organizations, forums, and processes. Like the Community, the decision-making process is amorphous and difficult to define as it is primarily shaped by social norms and narratives, more so than formal rules or binding on-chain voting mechanisms. Despite numerous instances where decision-making about the future of the Ethereum protocol has stirred disagreement and division in the Community, Ethereum’s roadmap remains ever ambitious with a list of several EIPs that are already sparking debate and discussion in the Ethereum community.
With Ethereum core developers acting as the gatekeepers ultimately deciding the changes that are implemented through upgrades, it is likely that the Ethereum protocol will continue to change rather than ossify. There is also the concern of regulatory capture if a technology becomes too upgradeable as we have seen on a smaller scale with finance-focused dapps and DAOs. The regulatory concern around upgradeability of decentralized technologies is beyond the scope of this report but a possible area of research for future consideration.
Ethereum has come a long way as a technology and pushed the boundaries of what’s possible using blockchain technology. Additionally, Ethereum as a social community continues to raise new questions around the best forms of governance for decentralized and open-source technologies. As Ethereum core developers pursue an increasingly ambitious development roadmap that contains upgrades to expand the Ethereum ecosystem to several Layer-2 protocols, it will be important for all network stakeholders to consider the ways in which social norms, rather than defined processes, of Ethereum governance can and should continue to shape the future of Ethereum.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2024. All rights reserved.