Galaxy Hardcore Report: Seven Case Studies to Understand Ethereum Governance Process
Original title: The Ethereum Government
Original author: Christine Kim, Galaxy
Original translation: Tao Zhu, Golden Finance
Who governs Ethereum? Who decides when and what changes are made to the Ethereum protocol? How much say do the end users of the Ethereum protocol have in influencing the actions and decisions of Ethereum core developers? In this report, Christine Kim sheds light on the Ethereum governance issue by providing a comprehensive overview of the processes and institutions involved in the decision-making process. She also discusses key events in Ethereum's history where coordination between developers and the broader Ethereum community was both urgently needed and controversial.
Ethereum is the world's largest blockchain, supporting more than 4,000 decentralized applications (dapps) and attracting more than 7,000 developers. The network is expected to scale further as Layer 2 scaling solutions such as Arbitrum, Optimism, and Polygon gain adoption and growth. As the world’s first general-purpose blockchain, Ethereum has consistently outpaced other Layer 1 alternative competitors, with the highest market cap and network security (defined by total staked value) 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 by which those changes are made, have far-reaching and significant implications for the rest of the crypto industry.
Like Bitcoin, Ethereum’s governance process is based off-chain, led by the Ethereum Foundation and conducted through online forums such as Discord, GitHub, Ethereum Magicians, and Zoom. ETH holders do not make any decisions through on-chain proposals or Decentralized Autonomous Organization (DAO) votes. On the 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 using vulnerabilities in governance-related smart contracts. On the other hand, off-chain forms of governance are difficult to audit and objectively evaluate because the process is intentionally opaque, subjective, and unstructured.
Unlike Bitcoin, Ethereum is very good at deploying hard forks, which are backwards-incompatible upgrades that require coordination of thousands of users running and operating the Ethereum software. Over the course of 19 hard forks over the past 8 years, core developers have adapted Ethereum's governance process to be more fast-paced and process-driven, relying heavily on a weekly series of conference calls, the so-called All Core Developers (ACD) calls, to discuss and track governance decisions affecting the Ethereum protocol.
This report takes a deep dive into Ethereum governance, focusing on the processes, people, and forums involved in the decision-making process. We then discuss seven case studies to illustrate the Ethereum governance process by analyzing the DAO hard fork, the Parity multi-signature vulnerability, the Constantinople upgrade, ProgPoW, Afrigate, Merge, and the Shanghai upgrade.
The official process for upgrading Ethereum is called the Ethereum Improvement Proposal (EIP) process. It is based on the Bitcoin Improvement Proposal (BIP) process, which is a standardized process for submitting code changes to the Bitcoin protocol. The BIP process is in turn inspired by Python's PEP-0001 process, which outlines a governance model for improving the Python coding language. BIPs and EIPs are documents that describe new features or changes to Bitcoin and Ethereum, respectively. Specifically, EIPs are formatted according to the guidelines and templates defined by EIP-1.
There are three types of EIPs.
· Standards Track: Most EIPs are Standards Track EIPs, which specify code changes to Ethereum that require a hard fork, affect Ethereum’s network layer or execution API, or introduce new application-level standards and contracts. Standards Track EIPs are further divided into the following names: Core, Network, Interface, and Ethereum Request for Comments (ERC).
· Core: Refers to code changes that require a full network upgrade to activate.
· Network: Refers to improvements to Ethereum’s peer-to-peer network layer, also known as “dev p2p”.
· Interface: Refers to code changes that affect Ethereum’s client API and RPC specifications.
· ERC: Refers to improvements related to Ethereum’s application layer. Ethereum core developers are discussing separating ERC from EIP into a separate governance process.
· Meta/Process: Meta EIPs do not propose changes to Ethereum's codebase, but rather describe changes to processes (e.g., the decision-making process for an EIP).
· Informational: Informational EIPs also do not propose changes to Ethereum's codebase. They provide general guidelines and information about Ethereum that users can choose to ignore or follow.
Anyone interested in Ethereum can propose an EIP at any time. EIPs are submitted to the Ethereum EIP GitHub repository, and then a dedicated EIP editor reviews the EIP for technical soundness and correct formatting. As of May 2024, there are five EIP editors. The names and Github usernames of these editors are as follows:
· Alex Beregszaszi (@axic)
· Gavin John (@Pandapip 1)
· Greg Colvin (@gcolvin)
· Matt Garnett (@lightclient)
· Sam Wilson (@SamWilsn)
These individuals are appointed by a current or honorary EIP Editor. New EIP Editors will be considered on a rolling basis. The five EIP Editors listed above have the authority to grant new EIP Editor privileges to applicants who meet the EIP Editor criteria. The criteria for becoming an EIP Editor can be found in EIP 5069: The EIP Editor Handbook.
As part of the EIP process, before submitting a draft EIP to the EIP Editors, the author needs to create a "Discussion" topic on the Fellowship of Ethereum Magicians forum, a website where anyone can create topics and discuss issues related to Ethereum and Ethereum development. In addition to the Ethereum Magicians forum, EIPs can 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 the Ethereum client team for discussion during the ACD call. The Ethereum client team is the entity that builds and maintains the Ethereum client software.
The five main Ethereum Consensus Layer (CL) clients are Prysm, Lighthouse, Teku, Nimbus, and Lodestar. The four main Execution Layer (EL) clients are Geth, Nethermind, Erigon, and Besu. Representatives from these nine teams meet weekly via Zoom to discuss EIPs and their implementation in Ethereum upgrades. After an EIP is proposed during a weekly meeting (i.e., the ACD call), the EIP author continues to collect feedback and review their proposal. EIP authors may modify their EIP based on feedback from the community and client teams. EIPs that go through this review process and receive support from client teams will be considered for implementation in future Ethereum upgrades. Due to the large number of EIPs, proposals that complete the review process are not guaranteed to be implemented in the next Ethereum upgrade. Typically, Ethereum client teams must choose between several equally technically sound and ready-to-implement EIPs for inclusion in the next upgrade, based on the relative urgency and scope of the proposals.
Over the past eight years, 61 core EIPs have been finalized and implemented on Ethereum, 57 core EIPs are in draft or under review, and 143 core EIPs have been withdrawn or deemed invalid. Based on these numbers, 23% of the core EIPs proposed by developers since the chain's inception have been activated in hard fork upgrades.
In the next section of this report, we will discuss the people and forums involved in the EIP process in further detail.
There are countless different groups involved in the governance of Ethereum. As the world's most decentralized general-purpose blockchain, no single user, person, or organization has the power to change the protocol. However, in general, every user and stakeholder in the Ethereum ecosystem contributes to governance in ways big and small by sharing opinions about the network on social media, operating the software, contributing code, or simply interacting with dapps on Ethereum. Since there is no single company behind Ethereum, it is up to an evolving and changing group of ecosystem participants to apply use cases to the protocol, generate interest in it, and ultimately give it value.
The collective will of Ethereum users is rarely homogenous and becomes too large to define without making sweeping generalizations. This report focuses on four specific stakeholder groups within the broader Ethereum community, referred to in this report as “Community” with a capital “C.” Community is defined as an amorphous group of individuals and entities that use, build, or develop Ethereum. Within the community, there is the Ethereum Foundation, the non-profit organization established by Ethereum’s original founders to manage the growth and development of the protocol. We will then discuss the role of Ethereum client teams in the community. These are the developers who build the Ethereum software and are arguably the most important decision-makers in the EIP process. We will then define validator node operators, a relatively new stakeholder group on Ethereum who are the primary implementers of code changes, and finally, we will define dapp developers, who are the primary users of Ethereum who shape the network’s use cases and provide feedback to client teams on which code changes to prioritize based on the needs of end users.
Ethereum Foundation
The Ethereum Foundation (EF) is the earliest and most famous non-profit organization focused on Ethereum. It was created by the original founders of Ethereum, including Vitalik Buterin, Gavin Wood, Joseph Lubin, etc. At Genesis, EF received the largest ETH supply from the genesis block pre-mine, accounting for 12 million of the total 72 million ETH allocation.
However, the total amount of ETH held by the Foundation has been decreasing over several market cycles since 2015, and is estimated to hold less than 0.3% of the total ETH supply as of April 2022. As with Ethereum, the structure and processes governing the EF are difficult to define. Unlike traditional non-profit organizations, the Ethereum Foundation does not have a clear organizational structure or roles. As stated on the Foundation's website, the EF's role "evolves and changes shape as the Ethereum ecosystem grows." More specifically, the EF's prominence in the community has gradually diminished over the years as the number of community stakeholders has grown, weakening the EF's centralized influence over more ecosystem participants.
As of May 2024, the EF continues to employ several Ethereum protocol researchers and developers in the community, and leads the organization around the ACD call, as well as the annual Ethereum developer conference Devcon. The size of the organization in terms of headcount is unknown. The only members publicly listed on the Foundation's website are: Aya Miyaguchi (Executive Director), Vitalik Buterin (Ethereum co-founder), and Patrick Storchenegger (Board Member). The Foundation's most recent report on its operations and finances was published in April 2022.
Client Teams
Client teams build and maintain the software needed to run and connect to the Ethereum network. Ethereum has nine major client teams, only one of which is directly maintained by the Ethereum Foundation. Here's some background on each Ethereum client team:
1. Geth (EL): The oldest and most popular Ethereum software client, known as Go Ethereum or Geth for short, is funded solely 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 the GNU Lesser General Public License (LGPL-3.0). The LGPL-3.0 license is a copyrighted open source license that requires any changes made by users to the original code repository to be open sourced.
(By the way, the main difference between the LGPL-3.0 and Apache 2.0 licenses is in derivative works. Under the Apache 2.0 license, code can be forked and distributed without restriction, while derivative works of code licensed under the LGPL-3.0 license must remain free and open source. In addition, software licensed under Apache 2.0 can be combined with software licensed under other types of licenses, while software licensed under LGPL-3.0 is only compatible with other GPL-licensed software. In general, the Apache License 2.0 is a more permissive license, while the LGPL restricts usage specifically to encourage open source development.)
2. Nethermind (EL): Founded in 2017, Nethermind is Ethereum's second most popular EL client, written in C# and based on an open source computer software framework called .NET Core. The team behind Nethermind is bootstrapped and was initially funded by the Ethereum Foundation. Over the years, the team has also received funding from the Ethereum community [JA 1] and from independent contributors and partners through Gitcoin. In July 2021, Nethermind announced a strategic partnership with Layer 2 scaling project Starkware. The Nethermind team consists of approximately 220 members from 55 countries. The Nethermind client is open source under the same license as Geth (GNU Lesser General Public License).
3. Erigon (EL): Formerly known as TurboGeth, Erigon is a fork of the Geth client that has been redesigned to improve synchronization speed and disk space efficiency. It was founded in 2017 and completed its alpha version in July 2020. The Erigon team consists of 10 developers and has received funding from multiple contributors including the Ethereum Foundation and BNB Chain. Notably, the team supports client software for other blockchains and sidechains, including BNB Smart Chain and Polygon. In addition, the team has maintained an Ethereum client written in Rust, Akula, and a client written in C++, Silkworm, in the past. The team recently announced the creation of a new Ethereum CL client called Caplin. The Erigon client is open source under the same license as Geth and Nethermind.
4. Besu (EL): Formerly known as Pantheon, Besu is an Ethereum client designed for enterprise and institutional use. The project was launched by Ethereum startup studio Consensys in November 2018, and was renamed and moved to a new GitHub repository owned by the Hyperledger Foundation in 2019. (Consensys is a member of the Hyperledger Foundation.) The development team within Consensys responsible for building and maintaining the client is called Consensys Quorum, formerly known as Pegasys. Besu is written in Java and is open source 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) has more than 70 members. In January 2023, Consensys announced that it would reduce its headcount from 900 to about 800, a reduction of 11%.
5. Reth (EL): Reth, short for Rust Ethereum, is an experimental full node implementation of Ethereum EL designed to be used by a wide range of users, including MEV searchers, bridges, Layer 2, and RPC node operators. The Reth client is maintained by crypto venture capital firm Paradigm, written in Rust, and open sourced under the Apache 2.0 license. Paradigm funded a core team of 8 developers to build Rust. However, the open source codebase has over 90 contributors. In March 2024, the Rust team released Reth v 0.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 founded in 2018 and initially funded by the Ethereum Foundation, Gitcoin, Aragon, Spankchain, and others. In October 2022, the company was acquired by Offchain Labs, the company behind the Ethereum Layer 2 scaling project Arbitrum. Prysmatic Labs employs approximately 12 people.
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 in Sydney, Australia. Sigma Prime has received funding from the Ethereum Foundation, Consensys, Gitcoin, and others for its work on the Lighthouse client. The company was founded in 2018 and has approximately 25 employees.
8. Teku (CL): Maintained by the same team behind Besu (EL), Teku is Consensys' institution-focused CL client, written in Java and open sourced under the same license as Besu and Lighthouse. Formerly known as Artemis, Teku was launched in 2020 and, like Besu, is built and maintained by the Pegasys team.
9. Nimbus (CL): Written in Nim and licensed under the same terms as Besu, Teku, and Lighthouse, Nimbus is designed to be resource efficient, making it easy for node operators to run Ethereum client software on resource-constrained devices such as mobile phones and laptops. The Nimbus team consists of 10 employees and is funded almost entirely 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 the GNU Lesser General Public License v3.0, Lodestar is an Ethereum client focused on light client functionality. A light client is a node, i.e. a computer running Ethereum software and connected to the Ethereum blockchain, that can easily sync to the chain without downloading the full chain history from genesis. The bandwidth and processing load to launch a light client is significantly less than a full node. Lodestar is developed and maintained by ChainSafe, a blockchain R&D company based in Toronto, Canada. The project was initially funded by Ethereum founder Vitalik Buterin in 2018. ChainSafe has since received funding through organizations such as the Ethereum Foundation and Gitcoin. ChainSafe has over 100 employees.Individuals who contribute to Ethereum client software are often referred to as Ethereum "core developers". However, the term is also used to describe Foundation employees and contractors who focus on upgrade testing or general protocol research work rather than client development. Generally speaking, any individual who actively contributes to advancing an area of the Ethereum core protocol, whether through research, client development, or upgrade testing, is referred to as an Ethereum core developer. The term core developer is a hotly debated topic in the community, as no single individual or entity has the power to define the term or prevent anyone in the community from using it freely.
Validator Node Operator
The only type of node operator that is rewarded with newly minted ETH is a validator node operator. Since the merge, validators have replaced miners as the network's primary block producers. A validator is created when 32 ETH is staked on Ethereum. Once activated, validators are randomly assigned duties, such as validating transactions and appending new blocks to the blockchain. In exchange for performing these duties, validators are rewarded through network issuance, transaction fees, and Maximum Extractable Value (MEV). The total amount of stake deposited by validators on Ethereum is a function of the security of the network, ensuring that attacks on the network cannot occur unless a malicious actor controls more than 33% of the total staked ETH.
Node operators are a group of individuals and entities who have the power to implement or reject code changes made to the Ethereum software by client teams. For background, when a client team makes a backwards-compatible code change to the software, the upgrade is called a "soft fork". Conversely, a "soft fork" occurs when a backwards-incompatible change is pushed to the client software. All node operators must upgrade their software by a certain block height to avoid being kicked off the network during a hard fork activation. Node operators who intentionally do not upgrade their software during a hard fork or run an alternative backwards-incompatible software will create a permanent chain split. Validators who only run on one version of Ethereum will be penalized for being inactive on another competing version. By gradually increasing penalties, the staked ETH balances of active validators on each Ethereum version will eventually be enough to drive the network forward.
In theory, node operators have the final say over which code changes are implemented on Ethereum and which are rejected. In practice, however, a permanent chain split on Ethereum due to disagreements between validator node operators is unlikely for a number of reasons.
· Ethereum has always had an ambitious development roadmap that envisioned significant changes to the consensus protocol, fee dynamics, and user experience from launch. The expectation of an ever-changing codebase sets a precedent for validator node operators to regulate frequent upgrades rather than reject them.
· The growth of the decentralized finance (DeFi) ecosystem (including oracles and stablecoins) and the L2 ecosystem has increased the cost of forking Ethereum, as a permanent chain split would fragment on-chain liquidity and force multiple dapps and L2s that cannot operate reproducibly to choose one network over another.
· Most of the ETH staked on Ethereum is staked through service providers that operate validator software on behalf of users. This means that most users and entities that receive rewards on Ethereum do not directly control nodes or the software upgrades that are made to them on their behalf. Stakers are somewhat distant from implementing the code changes prepared by Ethereum client teams, and therefore may not be as actively following or participating in protocol development decisions as staking services at times.
Despite these reasons, Ethereum validator node operators have strongly influenced protocol upgrade decisions in Ethereum’s history. For example, in the first upgrade after Ethereum transitioned to Proof-of-Stake, the interests of staked Ethereum users were the main factor influencing the priority of staked ETH withdrawals. In addition, before validators became the main node operators of Ethereum, when nodes were mainly operated by miners, Ethereum experienced a permanent chain split despite a very ambitious development roadmap that necessarily required frequent upgrades to achieve. This chain split produced Ethereum Classic, the first and so far only major chain split in Ethereum’s history, which occurred in the early days of Ethereum in 2016, when the DeFi or L2 industry had not yet developed.
Validator node operators are an important stakeholder group on Ethereum, responsible for executing hard fork upgrades prepared by client teams. Their role as code enforcers in the governance process is nuanced, one that is impacted by recent upgrades such as Merge and Shanghai (discussed in detail later in this report), as well as the legacy of miners, Ethereum’s former primary node operators, who executed upgrades for most of Ethereum’s history from its inception until the end of 2022.
Dapp Developers
Beyond EF, client teams, and validator node operators, Ethereum’s dapp layer is the next most important and vocal focus group influencing 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 front-end user interfaces (UIs) supported by wallet services, infrastructure providers, exchanges, or dapp developers themselves, rather than directly through the Ethereum blockchain. Because of this, the needs of dapp developers are sometimes at the heart of what drives Ethereum development and why certain code changes take precedence over others.
For example, the inclusion of EIP 1153 in the Cancun upgrade was driven primarily 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 the Ethereum chain state after execution. During an ACD call to discuss the code change, OP Labs co-founder Mark Tyneway highlighted that the EIP has the potential to save end users $3 million/year in gas costs on Uniswap alone. EIP 1153 was originally proposed in June 2018 and later proposed for inclusion in the November 2022 Shanghai upgrade. The EIP was activated on the mainnet as part of the Cancun upgrade on March 13, 2024.
In addition to EIP 1153, dapp developers have largely taken the lead in proposing EIPs related to account abstraction in recent months. Account abstraction is a feature that allows smart contracts to have customizable and programmable authorization for initiating transactions. On Ethereum, only Externally Operated Accounts (EOAs) can send and receive cryptocurrency. Unlike smart contracts, EOAs cannot execute code. Enabling account abstraction has been a long-standing goal of Ethereum core developers and dapp developers, and has recently gained traction through a backwards-compatible EIP known as ERC 4337. The proposal was originally proposed by Ethereum founder Vitalik Buterin in September 2021 and is still in the draft stage, but is being actively iterated by various client teams, EF researchers, and dapp development teams such as Matter Labs, Polygon, Gelato, and others.
It is difficult to quantify the influence of the dapp developer community on client teams, especially when developer influence also affects community sentiment. In addition to dapp developers, end users and, to a lesser extent, ETH holders, exchanges, and other blockchain infrastructure providers all play a role in code change advocacy. As we discuss further in this report, client teams are not immune to the influence of signals sent by end users via Twitter and other social media forums. In addition, the individuals who 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 (i.e., client teams, validator node operators, and dapp developers) are distinct, the individuals who make up these groups often overlap, making it difficult to neatly categorize or define the stakeholders involved in the Ethereum governance process.
The voices of the Ethereum ecosystem’s stakeholder groups converge on a range of different forums. Some forums are specifically designed to generate consensus from client teams rather than aggregating consensus from stakeholders across the Ethereum ecosystem. The primary language used in these forums is English. This is probably because, in general, English is considered the most global language in the world, with the largest number of speakers. English is a key requirement for individuals and companies looking to participate in the Ethereum governance process. However, EF is working to improve communication of key decisions made through governance to non-English speaking communities by translating information documents about Ethereum into several different languages. The ethereum.org website, operated by EF, has been translated into 55 languages. Additionally, EF intentionally locates Devcon in various locations around the world to expand Ethereum's reach to non-English speaking populations. In 2022, Devcon VI was held in Bogota, Colombia.
Below is a list of the four main forums where Ethereum development is discussed, organized, and performed. In addition to these forums, community discussions around Ethereum are also shared on social media platforms such as Twitter and Reddit. However, social media platforms, while popular, do not often host centralized, in-depth discussions about Ethereum development or governance. Instead, Ethereum community members use them to share quick updates and information about Ethereum-related topics that can spark discussion but are not officially recognized as key governance forums in the EIP decision-making process.
All Core Developers (ACD)
One of the most important decision-making forums regarding Ethereum protocol development is the ACD call. ACD calls are organized by the Ethereum Foundation and have been happening since November 2015, a few months after Ethereum launched. They are publicly recorded Zoom calls that last about an hour and a half. It is open to anyone in the Ethereum community, but is most frequently attended by EIP authors, client teams, Ethereum Foundation researchers, and Ethereum Cat Herders. ACD calls are open to anyone interested and can be joined via livestream or directly on Zoom.
From 2016 to 2021, the ACD calls were chaired by Ethereum Foundation employee Hudson Jameson. During this period, ACD calls were held biweekly. Jameson has since ceased to chair the ACD calls and currently serves as an advisor to various Ethereum projects, including Status, Chainlink, and Matic Labs, the development team behind Polygon. Starting in 2021, Tim Beiko of the Ethereum Foundation took over as chair of the ACD calls. Meanwhile, from 2018 to 2022, Ethereum core developers focused on building Ethereum's proof-of-stake consensus protocol also organized biweekly calls. These calls were chaired by Danny Ryan of the Ethereum Foundation.
Since the merger launch in September 2022, the ACD calls have been renamed and formalized into two separate meeting series: the All Core Developers Execution (ACDE) and All Core Developers Consensus (ACDC) calls. Each call is held bi-weekly, meaning there will now be an ACD call held weekly. ACDE calls are hosted by Tim Beiko and focus on protocol-level changes to the Ethereum Execution Layer (EL). ACDC calls are hosted by Danny Ryan and focus on protocol-level changes to the Ethereum Consensus Layer (CL).
The combined ACD call structure reflects the dual-network nature of Ethereum and the increased protocol complexity around changing the protocol as it involves an increasing number of subject matter experts and network-specific client teams. ACD calls primarily discuss the technical merits of EIPs. While this is the goal, it is sometimes difficult to avoid discussions around the morality or ethics of decisions on ACD calls, depending on the matter at hand. Over 250 ACD calls have been organized since 2015. Most are recorded live and can be rewatched on YouTube.
ETHMagicians and Ethresear.ch
The agenda for the ACD calls is often influenced by discussions and conversations posted on the ETH Magicians and Ethresear.ch forums. These forums are where EIPs that are in the ideation or draft stage are discussed and circulated for feedback. Additionally, these forums host in-depth discussions around non-technical issues around the Ethereum protocol, such as which EIPs and initiatives should be prioritized for upgrades based on community sentiment. While both forums are equally active, ETHMagicians is a more general forum than Ethresear.ch, where nearly any technical or non-technical topic about Ethereum can be discussed. Ethresear.ch tends to showcase early research ideas on technical code changes to the protocol, which, once formalized, are posted to ETHMagicians for broader community discussion. 
ETHMagicians is organized by former Ethereum Foundation core developer Jamie Pitts and anonymous developers of the Geth (EL) client "Lightclient". Ethresear.ch is organized by multiple Ethereum Foundation employees, including Hsiao-Wei Wang, Justin Drake, Danny Ryan, and Vitalik Buterin.
Dissent
For day-to-day coordination of active EIPs in preparation for upcoming upgrades and providing urgent updates to client teams, there is a dedicated Discord chatroom where Ethereum core developers, researchers, and other members of the Ethereum community can coordinate development in real time. The Ethereum Research and Development Discord channel is a place where client teams and the broader Ethereum community are encouraged to work together to solve protocol issues, conduct research initiatives, and ask questions. During Ethereum upgrades, client teams use it as the main communication channel to convey the health of the Ethereum network and coordinate the launch of upgrades on Ethereum test networks. It is also a forum for communication and organizing community calls that run in parallel with ACD calls, such as calls discussing the technical details of EIP 4844, proto-danksharding, and EIP process changes.
From 2015 to 2018, the primary channel for asking questions about the Ethereum protocol and participating in the day-to-day development of the protocol was through a chatroom called Gitter. However, as the Ethereum community and the number of protocol contributors grew, a more sophisticated way to organize multiple chatrooms on a single forum was needed. As a result, the developers migrated communications to a shared Discord channel, which as of July 2023 hosts over 50 separate chatrooms for various niche topics in Ethereum research and development. The Ethereum Research and Discord channels serve as hubs for asynchronous discussion of ACD topics and for tracking active work on the implementation of proposals raised on ETHMagicians or Ethresear.ch.
GitHub
Finally, the main forum for drafting and documenting the state of the Ethereum codebase is GitHub. On GitHub, an organization page called "Ethereum" hosts hundreds of code repositories. These repositories contain code for draft versions of the protocol that Ethereum researchers and client teams are developing for upcoming upgrades, as well as a history of ACD calls and copies of final EIP proposals. The specifications hosted by this repository not only detail Ethereum's core protocol, but also include documentation on node APIs, the Solidity smart contract language, testing tools, and more.
Image description: Ethereum official GitHub homepage. Source: GitHub
The Ethereum core codebase (defined as the EL and CL specifications) changes every month. The Ethereum Foundation's customer teams and employees are the primary individuals with the authority to merge and update the Ethereum GitHub repository. While key decisions are made asynchronously on ACD calls or Discord, actual changes to the Ethereum specifications (i.e., the execution of governance decisions that affect Ethereum code) occur on GitHub. On GitHub, users can track changes made to the Ethereum specifications and access the latest versions of the specifications. Merging code changes to the official Ethereum GitHub repository is one of the most important steps, marking the finalization and implementation of decisions made on other governance forums.
While GitHub is the leading open-source code development platform among the wider community of computer programmers, Ethereum developers have discussed in the past the need to reduce their reliance on this centralized platform, especially in light of GitHub shutting down access to its platform due to government pressure. Gitcoin alternatives for decentralized development that developers could explore in the future include Radicle and Mango. Additionally, given that the version control system GitHub relies on, git, is a permissionless protocol that does not need to be hosted or managed through a website, the community is encouraged to host local copies of the Ethereum codebase on their devices. Additionally, one of the motivations for hosting conversations about code changes on ETHMagicians and Ethresear.ch is to replicate issue explanations and pull requests on GitHub on several other platforms.
In addition to the major figures and forums mentioned above, there are a number of organizations and protocols that have had a meaningful impact on the development of Ethereum over the years.
The Ethereum Cat Herders
The Ethereum Cat Herders is a donation-funded group of individuals who create meeting minutes, write informative blog posts, conduct community outreach, and produce video content to educate the general public about Ethereum. The group was founded in January 2019 by prominent Ethereum community leaders such as former ACD Chair Hudson Jameson and former core developer Lane Rettig. The group is led by Herder-in-Chief Pooja Ranjan, founder of blockchain publishing site EtherWorld. The Cat Herders is a decentralized group of Ethereum "project managers" formed to help coordinate network upgrades and improve communication between client teams and the broader community. They conduct surveys and analysis on EIP activity and inform how to improve the governance process around Ethereum code changes.
In addition to participating in shepherding the EIP process through project management, they host weekly EIP Refinement Calls and EIP Office Hours to track the status of each EIP and shepherd them through the discussion, drafting, review, last call, and final stages. They also host a weekly YouTube series featuring EIP authors and their proposed code changes, called PEEPanEIP. The Ethereum Cat Herders work closely with the EIP editors to refine the EIP process and make changes based on group consensus.
Ethereum Protocol Guild
In addition to the Ethereum Foundation and the Ethereum Cat Herders, there is the Ethereum Protocol Guild, a smart contract application created to help fund Ethereum core development. Anyone can send fungible tokens to a 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. As of May 2024, the Protocol Guild has distributed over $17.8 million, 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 at any time. All funds vest in the registry over time and are distributed to members in proportion to how long each member has actively contributed to the Ethereum protocol. The Protocol Guild can be used as a proxy for assessing the growth of the number of Ethereum core developers over time.
The Protocol Guild is committed to actively funding all Ethereum core developers through voluntary donations, which are automatically distributed to contributors (also known as guild members). Guild members themselves are responsible for keeping the developer registry updated by removing or adding new members.
Retroactive Public Goods Funding for Optimism
A prominent contributor to the protocol guild is the Optimism Collective. Optimism is the second most valuable L2 on Ethereum, behind Arbitrum, with $6.5 billion worth of on-chain assets. Optimism was launched in 2021 by a development team called OP Labs. OP Labs operates the software responsible for aggregating and ordering user transactions in blocks called sequencers. While the intention is to decentralize this function over time, OP Labs has pledged to use all profits from its sequencer through transaction fees to fund public goods experiments. All sequencer revenue goes to the Optimism Foundation, a nonprofit dedicated to developing a decentralized Optimism “Collective.” (Think of the OP Collective as the Ethereum community for Optimism.)
The Foundation redistributes revenue to public goods projects voted in by OP token holders and other Collective members, as defined by Optimism’s bicameral governance model. Since 2021, the Optimism Foundation and the broader Collective have redistributed over 40 million OP tokens to various public goods initiatives. The largest beneficiary of these allocations has been the Protocol Guild, which received over 600,000 OP tokens over three funding rounds.
Gitcoin
Given the Ethereum Foundation’s reduced budget and the growing ecosystem of end users and dapps, the Protocol Guild is committed to creating a long-term funding mechanism for public goods. Another example of a funding mechanism with long-term potential to support Ethereum core protocol development is Gitcoin. As mentioned earlier, several client teams such as Nethermind, Prysmatic Labs, Lighthouse, and Lodestar have relied on Gitcoin in the past for a portion of their funding. Gitcoin aims to support programmers and developers working on open source software, helping them raise funds for their projects in cryptocurrency.
Over the past eight years, Ethereum core developers have executed 19 backwards-incompatible hard fork upgrades. These upgrades varied in complexity, urgency, and controversy. One of these upgrades resulted in a permanent chain split. Another expelled an entire group of network stakeholders from network participation. Each upgrade has impacted the Ethereum governance process and shaped it into the multifaceted process it is today, involving multiple people, organizations, and forums. In this section, we discuss seven major governance decisions in Ethereum's eight-year history and further examine the people, organizations, and forums that played a role in the decision-making process.
Reaching 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 also make executive decisions for the blockchain when unexpected and time-sensitive vulnerabilities arise that require urgent action. The most controversial decision in Ethereum’s history was the DAO hard fork, which stemmed from an unexpected bug in the smart contract application DAO that affected many ETH holders. When deciding how best to resolve unexpected technical issues, Ethereum core developers are the primary voices in conceiving, proposing, and ultimately implementing solutions. In the case of the DAO hack, the solution implemented by the Ethereum client team resulted in a permanent chain split and the creation of a new Ethereum protocol, illustrating an important feature of Ethereum, its permissionless nature, which allows any group of users to fork the codebase and launch a new version of Ethereum. The DAO hack also illustrates that Ethereum core developers are not always a homogenous group of individuals who share the same views on how the Ethereum codebase should evolve.
Below are three case studies that describe how Ethereum stakeholders came to consensus on technical issues:
Case Study 1: The DAO Fork
What Happened: On June 17, 2016, The DAO, a smart contract protocol that controlled 15% of the total ETH supply at the time, was hacked and approximately 70% of its funds were stolen. The hack occurred less than a year after Ethereum was launched. The DAO was designed to be an autonomous venture capital vehicle, allowing DAO token holders to vote on proposals and use the fund’s pooled capital to support various blockchain projects. The DAO was the first decentralized autonomous organization of its kind. The DAO project became the largest crowdfunding campaign in history at the time, raising $150 million from more than 11,000 contributors.
The DAO hack was carried out via a vulnerability known as a reentrancy vulnerability, which allowed a malicious actor to repeatedly withdraw funds from the smart contract for free. This happens when a malicious actor makes an external call from the target smart contract to another smart contract. The untrusted smart contract then calls back to the original smart contract. Each time the hacker's contract initiated a call to the DAO contract, the DAO smart contract was unable to check and update its balance before approving the transfer of funds. This is how the DAO contract was slowly drained of most of its assets. Once the creators of the DAO discovered this vulnerability, they preemptively began draining the DAO contract using the same techniques as the hacker. The creators of the DAO managed to salvage 30% of the DAO funds, but the remaining 70% was under the control of the hacker.
Actors: The team behind the DAO project was a group of anonymous developers called Slock.it. Slock.it envisioned the DAO as a fundraising mechanism to bootstrap other dapp ideas, and one of Slock.it's most notable dapp ideas at the time was a decentralized application. The Ethereum Foundation played a major role in the communication about the DAO hack after the smart contract was exploited. On the Ethereum Foundation's blog, Ethereum Foundation core developers proposed ideas for the future path forward after the hack, such as implementing a soft fork to mitigate the impact of the hack on token holders. In 2016, miners were individuals who ran Ethereum nodes and secured the Ethereum blockchain. Therefore, they were also the main supporters of implementing any code changes from Ethereum core developers by upgrading the software. Due to the controversial nature of the issue and the heated debate surrounding the immutability of smart contract code, it was difficult to reach a consensus from the Ethereum community on the best solution. Ethereum stakeholders, including ETH holders and dapp developers, shared opinions on various forums such as Twitter and Reddit. However, decision-making is mainly made through ACD conference calls, Gitter, and GitHub.
How the problem was solved: Geth (EL) developer Peter Szilagyi made an initial proposal to solve the DAO hack problem through a backwards-compatible soft fork in an Ethereum Foundation blog post on June 24, 2016, but the proposal was quickly abandoned after Ethereum core developers discovered that this could lead to DDOS attacks on the wider network. After weeks of discussion, Ethereum core developers reached a consensus that the only technical solution to the problem of the loss of funds from the DAO hacker was through a hard fork upgrade, which would allow Slock.it developers to reallocate all funds in the DAO to other smart contracts that are not vulnerable to reentrancy attacks.
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 a debate about the principle of "code is law" and the extent to which the integrity of Ethereum as a blockchain depends on adhering to this principle. Ethereum core developers organized a Carbon vote on July 15, 2016 to decide whether the logic for initiating a hard fork should be opted in by default in the next upcoming software client release. Carbon voting is an on-chain mechanism where ETH holders can indicate their preference for a governance proposal by submitting a zero-fee gas transaction. The DAO controversy was the first time Ethereum core developers relied on on-chain Carbon voting as a secondary measure to gather consensus. 4.5% of the total ETH supply participated in the vote at the time, and 87% of the voted ETH supply voted in favor of making the hard fork opt-in by default for node operators.
About a month after the hack, the Ethereum client team scheduled the hard fork. The proposal was supported by major community leaders such as Vitalik Buterin and organizations such as the Ethereum Foundation. Additionally, Ethereum had extremely low client diversity at the time. Despite having six client implementations, 97% of node operators ran the Geth client, which is why it was easier to coordinate client upgrades between client teams at the time.
By moving forward with a contentious hard fork proposal, the client team gave miners and other node operators the discretion to accept or reject their code changes. The hard fork was scheduled to take place on July 20, 2016, just 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, resulting in a permanent chain split. The version of Ethereum that did not accept the DAO hard fork upgrade is now known as Ethereum Classic. Over the years, Ethereum Classic has continued to evolve as a parallel network to Ethereum. However, it has experienced multiple 51% attacks due to a lack of security and user engagement. In the years following the DAO hack, the Ethereum network has surpassed Ethereum Classic in terms of adoption, miner participation (i.e. hash rate), and most importantly, value.
One of the main reasons why Ethereum is still ahead of Ethereum Classic after the DAO hard fork is that the majority of developers (i.e., client team developers) continue to develop on Ethereum instead of Ethereum Classic. Since its launch, Ethereum has been a blockchain with an ambitious development roadmap, and many investors and stakeholders recognize that this requires a strong development team to take the lead. During the DAO hard fork, the main software development team was Geth, and the consensus among Geth developers to perform a hard fork to return the funds from the DAO hack to the DAO creators was influenced by figureheads such as Vitalik Buterin who were leading the Ethereum Foundation at the time. This consensus between Geth developers and the Ethereum Foundation had a huge impact on what the Ethereum community and the larger crypto industry believed was the appropriate course of action for Ethereum.
Key Takeaway: The DAO hack has largely changed the approach of dapp developers to smart contract development. In a talk a few months after the hack, Slock.it developer Lefteris Kaperelli explained that one lesson all dapp developers should take away from the DAO hack is that decentralized applications need to implement a “kill switch” to protect the application from accidental hacks. The idea of implementing upgradability in immutable applications and veto power through multi-signature wallets and governance bodies has gained popularity following the DAO hack and other similar incidents. Today, most decentralized applications can be upgraded on Ethereum.
Regarding Ethereum’s governance, the DAO hack was by far the most contentious issue in Ethereum’s history. The issue illustrates how Ethereum’s governance mechanisms can move forward when the Ethereum community cannot reach a unanimous consensus. It illustrates three main lessons:
· The veto power in Ethereum’s decision-making process falls on the Ethereum client team, who decide what changes are made to the Ethereum software. However, once an agreement is reached and the software is released, node operators can accept or reject code changes. At the time, the main Ethereum software client was Geth, and the Geth team, the Ethereum Foundation, and Vitalik Buterin all supported the hard fork solution. As a result, they released the necessary software upgrades to activate the Ethereum hard fork at block height 1,920,000.
· The use of carbon voting illustrates how off-chain governance processes can be strengthened by on-chain mechanisms. While carbon voting is non-binding, meaning it has no power to change the decision-making process of developers through ACD calls and Gitter, it does strengthen the Ethereum community's inclination to execute a hard fork.
· Finally, this case study illustrates the power and authority of node operators on Ethereum to choose which version of the Ethereum protocol to run. Some chose to reject the DAO hard fork. However, as mentioned earlier in this report, the growth of the decentralized finance (DeFi) industry since 2016 has led to fragmentation of liquidity and dapp interoperability, making it increasingly costly and technically difficult for alternative versions of the Ethereum protocol to coexist.
Case Study 2: Parity Multi-Sig Vulnerability
What Happened: In November 2017, Ethereum’s most widely used multi-signature (multi-sig) wallet developed by Parity technologies was accidentally exploited, permanently freezing 514,000 ETH worth more than $320 million in more than 580 user wallets. The exploiter “devops 199” alerted the Parity development team on GitHub that they had found a way to transfer ownership of the smart contract that controlled the Parity multi-sig wallet. While attempting to return ownership of the contract to the Parity team, Devops 199 accidentally triggered the "kill() function" associated with the Parity code, effectively freezing the balances of Parity multi-signature users. The devastating vulnerability was one of two major vulnerabilities discovered in Parity's multi-signature wallet in 2017.
Actors: Background: Parity Technologies was founded in 2015 by Ethereum co-founder Gavin Wood. Over the years, the company has built software clients for Bitcoin, Zcash, and Ethereum. At the time of the multi-signature vulnerability, the Parity software client was the second most popular Ethereum client used by node operators. Parity Technologies later discontinued support for the Parity client in 2019, rebranded it as OpenEthereum, and shifted its focus to building its own Layer 1 blockchain, Polkadot. Polkadot launched on mainnet in May 2020.
Problem Solution: In order to unlock frozen user funds, the Parity development team proposed EIP 999 in April 2018. EIP 999 will restore the deleted code that Devops 199 accidentally self-destructed through a hard fork upgrade. Although a large number of Ethereum users were affected by the Parity multi-signature vulnerability, the code changes were never implemented in the upgrade. After strong community opposition and opposition to the proposed changes, Parity developers ultimately withdrew the EIP.
Main conclusion: Despite Parity being the second most popular Ethereum client and EIP 999 being technically sound in the eyes of Ethereum core developers, the proposal failed to be implemented because it became clear that implementation would result in another permanent chain split. On April 26, 2018, Parity co-founder and CEO Jutta Steiner wrote in a blog post that the company had “no intention of splitting the Ethereum chain over EIP 999.” The Parity multi-signature vulnerability is an important case study that highlights the limited influence Ethereum client teams have over the Ethereum codebase. Despite being the most active participants in the Ethereum governance process, client teams generally tend to implement code changes that the majority of the Ethereum community would support and steer clear of those that would most likely repeat the DAO hack.
As with the DAO hack, the controversy surrounding EIP 999 centered on the debate over Ethereum code immutability. This time, however, the overwhelming consensus among Ethereum stakeholders outside of the Parity client team was to reject Parity’s proposed code changes and retain code immutability. Part of this consensus was achieved through a week-long on-chain carbon vote, which resulted in 55% of voters voting against activating EIP 999. The use of another carbon vote to gauge broader community sentiment has also sparked debate about the effectiveness of on-chain voting in the Ethereum governance process. Many Ethereum developers and ETH holders believe that carbon voting is inaccurate and invalid due to the ability of ETH whales to use their holdings to skew voting results. In addition to informal carbon voting (which historically has never had much legitimacy in the governance process), EIP 999 has also undergone a formal EIP review process, through which the code change is seriously discussed by Ethereum client teams and the broader Ethereum core developer community. In the three months since it was first submitted in April 2018, EIP 999 has been rejected by multiple parties due to a lack of community support.
Case Study 3: Constantinople
What Happened: The sixth Ethereum upgrade, Constantinople, primarily reduced block issuance from 3 ETH to 2 ETH, in addition to making a number of other minor technical improvements to the Ethereum codebase. The scope of Constantinople was finalized in August 2018, and was scheduled to launch in January 2019. In addition to the block issuance reduction (also known as EIP 1234), other code changes included in the finalized scope of Constantinople include:
· EIP 145: Creates a more efficient method of information processing called bitwise shifting.
· EIP 1052: Provides a way to optimize large-scale smart contract code execution.
· EIP 1283: Introduces a fairer pricing method for changes to smart contract data storage.
· EIP 1014: Lays the foundation for some type of scaling solution based on state channels and "off-chain" transactions.
With less than 48 hours before the Constantinople upgrade was scheduled to go live, a blockchain security and auditing firm called Chain Security discovered a bug in the upgrade code. Upon closer inspection, EIP 1283 would allow hackers to manipulate smart contract balances using repriced storage operations. The nature of the vulnerability is similar to that of the DAO in that it could create opportunities for malicious actors to launch reentrancy attacks on smart contracts.
Participants: Chain Security published a blog post on January 15, 2019, detailing the exact nature of the vulnerability. On the same day, Ethereum core developers discussed next steps via Gitter and an impromptu ACD call. They quickly reached a consensus to pause the planned upgrade and decide on a new upgrade date and software patch at the next regularly scheduled ACD call, which would take place three days later on January 18, 2019. During the ACD call, the developers reached consensus on the upgrade patch and rescheduled the hard fork to activate on February 28. The Ethereum Foundation and the Ethereum Cat Herders assisted in communicating these decisions to Ethereum miners and other node operators at the last minute. Both organizations published blog posts and contacted community stakeholders to alert them to the last-minute change in the hard fork plan.
How the issue was resolved: Due to the technical nature of the issue, the Constantinople vulnerability was primarily addressed among client teams. Ethereum core developers quickly brainstormed the most effective solution and implemented it in their software clients. Unlike the DAO hack patch, the solution to the Constantinople vulnerability was not controversial, but it did raise concerns about the EIP testing process and highlighted the need to strengthen upgrade testing efforts to ensure that new code changes are adequately checked before deployment on the mainnet. Once the vulnerability was patched and a new hard fork date was set, Ethereum miners and other node operators successfully upgraded their hardware on February 28, 2019.
Key Takeaways: The resolution of the Constantinople vulnerability highlights how quickly the community can come together to make changes to the Ethereum protocol on the fly, especially for network security reasons. Due to the lack of controversy surrounding the issue, Ethereum node operators were able to revert to an older version of the client software within 48 hours. Additionally, core developers were able to successfully activate a patched version of the Constantinople upgrade in February 2019. The presence of a bug in the original upgrade code did not prevent Ethereum developers from performing the upgrade, but instead encouraged them to focus more time and resources on testing future upgrades.
Building Social Consensus
When issues stem from disputes surrounding Ethereum’s social values, the decision-making process becomes more lengthy and drawn out. The DAO bug is an example of a technical failure of smart contracts. 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 caused a high level of controversy and inaction from Ethereum’s core developers. There are a handful of other examples in Ethereum’s governance history where Ethereum’s core developers have had to respond to social issues that were not technical but concerned broader community values and beliefs.
In the two case studies below, Ethereum’s core developers deliberately chose to take a backseat in leading development. They handed over much of the decision-making process to the broader Ethereum community, and as a result, the numerous voices of various Ethereum stakeholders clashed, leading to delays in the resolution of issues and proposals. Because social issues on Ethereum involve more voices than the number of core developers, consensus is difficult to reach and often fraught 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 disincentivize the efficiency of professional miners. Professional miners are individuals or businesses that operate specialized mining machines called Application Specific Integrated Circuits (ASICs). These machines are highly optimized to complete a single task and cannot be easily repurposed for other tasks. Graphics Processing Units (GPUs) are computers that can perform a range of different tasks and are therefore more widely used and cheaper to purchase. The goal of ProgPoW is to make Ethereum ASIC-resistant and prevent the centralization of mining hash power. For several years, the Bitcoin mining industry has been dominated by ASIC machines operated primarily by well-capitalized, publicly traded, and regulated public companies.
In April 2018, three years after the launch of Ethereum, mining hardware manufacturer Bitmain released the first Ethereum ASIC. The Ethereum community is concerned that the adoption of ASIC technology will lead to the inevitable centralization of hash power, which has driven the research and development of ProgPow. The algorithm was proposed by a development team called "IfDefElse" on Ethereum Magicians in May 2018.
While the proposal is technically feasible in the eyes of Ethereum core developers, the Ethereum community is divided on the effectiveness of the algorithm in preventing ASIC dominance. Given that ASICs are just specialized machines, it is difficult to build a mining algorithm that computers cannot be optimized to some extent. Other blockchain projects in the industry (such as Monero, Ravencoin, Horizen, Ethereum Classic, etc.) have attempted to create ASIC-resistant mining algorithms, but their effectiveness records have been inconsistent. Given that ASICs were still in their infancy on Ethereum in 2018, the community also questioned whether the issue was really that urgent and whether developers should solve it as soon as possible through hard fork upgrades before other EIPs.
In February and 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.
A Twitter survey hosted by Ethereum Cat Herders to gauge sentiment towards ProgPoW. Source: Twitter (@EthCatHerders)
The Ethereum Foundation organized two on-chain votes around ProgPoW. The first vote was designed similarly to the vote that took place before the DAO hard fork. It counted votes weighted by the amount of ETH held by token holders. The second on-chain vote was designed to survey Ethereum miners on ProgPow by allowing independent miners and mining pools to enter data into additional mined block fields. Both votes showed that miners were overwhelmingly supportive of the code change. Miners who accounted for nearly half of Ethereum's hash rate at the time participated in the second on-chain vote, and 77% of the participating miners voted in favor of ProgPoW.
Miners on Ethereum mostly supported the ProgPoW proposal, as most Ethereum miners at the time were GPU miners. However, dapp developers and other Ethereum stakeholders did not support ProgPoW because they were concerned that the implementation of the algorithm could cause the network to split and reduce the value of ETH. Throughout the debate, well-known Ethereum core developers such as Vitalik Buterin and members of the Geth team repeatedly reiterated that they were neutral on the change and would implement whatever the community thought was best. In multiple ACD calls, Ethereum core developers recognized the technical soundness of ProgPoW. Mining manufacturing companies such as Linzhi publicly opposed the upgrade.
Participants: IfDefElse is a team of three developers, two of whom use pseudonyms and only one developer has revealed his personal identity. The public member of IfDefElse is Kristy Leigh Minehan. At the time, she was the CTO of a blockchain infrastructure company called Core Scientific. Minehan participated in several ACD conference calls and Ethereum conferences to explain the ProgPoW algorithm, although the controversy surrounding the algorithm soon caused Minehan to fade from the spotlight. In many cases, Minehan was the target of attacks and bullying because of 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 provides consulting services to cryptocurrency companies such as asset management company Valkyrie and cryptocurrency mining company Merkle Standard.
How the problem was solved: To address community concerns about the effectiveness of ProgPoW against ASICs, the Ethereum Cat Herders announced that they would raise $100,000 to commission an independent third party to audit the ProgPow code. From March to September 2019, Cat Herders spent about six months raising funds and commissioning blockchain security company Least Authority to conduct the audit. In September 2019, the audit results were announced. The audit confirmed that the design of the ProgPoW algorithm was accurate and achieved the goal of encouraging greater resistance to ASICs, although the audit also warned that, as people speculated, future hardware advances could reduce the effectiveness of ProgPoW over time. After the audit was released, Ethereum core developers agreed to include the code changes in the upcoming hard fork. However, continued opposition from Ethereum community members (especially dapp developers) sparked controversy and prevented Ethereum core developers from prioritizing the inclusion of ProgPoW in the actual upgrade. The ProgPoW debate lasted for about 2 years in the Ethereum community. The last public discussion of the code change took place during ACD #82 in March 2020. During that call, developers expressed their concerns about the lack of community support for ProgPow and the decision to exclude it from the next hard fork.
Main conclusion: ProgPoW does not address technical vulnerabilities, hacks, or issues with Ethereum that would affect the security of a large number of ETH holders or the Ethereum network itself. The primary drivers of ProgPoW development are miners, whose voices have historically been weak and ignored by efforts to forcibly remove miners from the network by transitioning Ethereum to PoS that have existed since Ethereum launched. Each time Ethereum core developers have proposed reducing block issuance (e.g. EIP 1234) or making changes in a way that would reduce miner revenue (e.g. EIP 1559), miner opposition has never swayed the opinions or sentiment of Ethereum core developers. As a result, the governance process designed to review and advance changes on technical merits did not help ProgPoW get activated, and individuals who support the change have no influence in the Ethereum ecosystem.
Despite on-chain voting and technical approval from Ethereum core developers, the ProgPoW debate illustrates the powerlessness of a group of network stakeholders to change Ethereum without broader community support from end users and dapp developers. Ethereum core developers are not opposed to code changes, but they find it difficult to prioritize controversial upgrades at the expense of other code changes that are relatively less controversial and have more support from Ethereum end users. Moreover, as Ethereum core developers turned their attention to PoS and deprecated mining algorithms starting in early 2021, the need for ProgPoW waned.
Case Study 5: Afrigate
What Happened: It is not common for Ethereum core developers to be expelled from the Ethereum community. However, as mentioned in the previous case studies, there have been cases where intense social media bullying has led certain EIP authors to withdraw from public discussions. This was the case with Ethereum core developer Afri Schoedon, a developer of the Parity client built by Parity Technologies. Parity Technologies was founded by Gavin Wood, one of the co-founders of Ethereum, along with Vitalik Buterin and six others. In addition to the Parity Ethereum client, Parity Technologies has built another general-purpose blockchain called Polkadot. Schoedon, who has been a code contributor to Ethereum since 2015 and was the lead coordinator of the Ethereum hard fork, tweeted on February 14, 2019, when the Polkadot protocol was under active development:
Afri Schoedon, Ethereum core developer, jokingly made 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 as a joke. Critics accused Schoedon of a "conflict of interest" on social media, though Schoedon reiterated that he had never been directly involved in the development of Polkadot. Schoedon clarified on Twitter that his meme was meant to stir up discussion around the development of Serenity, the name of Ethereum's transition to PoS at the time, rather than to create a narrative of competition between Polkadot and Ethereum. However, continued criticism led Schoedon to delete many of his tweets and ultimately announce on February 19 that he was leaving the Ethereum community. "I didn't quit social media, I quit Ethereum. I didn't go incognito; I just left the community. I no longer coordinate hard forks, build testnets, or make other contributions. I don't work for Polkadot, I never worked for Polkadot, I work for Ethereum. I don't hate Ethereum, I love it," Schoedon said in his last tweet before deleting his Twitter account.
Participants: Despite Schoedon's role as a major player in the incident, other Ethereum core developers and community members came to his defense following his departure. Schoedon continued to help Ethereum Classic with upgrades to improve its compatibility with Ethereum. As of July 2023, he continues to contribute to Ethereum in a less public way, contributing to the coordination of the Ethereum test network, often using different pseudonyms.
How the issue was resolved: In an ACD call the month after the Twitter incident, Ethereum core developers announced that they were looking for a new hard fork coordinator to replace Schoedon's role. However, the search did not last long. With no suitable candidates available, the developers agreed to split Schoedon's role among multiple people. Since Schoedon's departure, the responsibilities of the hard fork coordinator, which include setting the hard fork date, selecting the EIP for the hard fork, and leading the testing effort for the upgrade, have been dispersed among multiple core developers and client teams. In addition, in February 2019, 115 well-known Ethereum community members signed an open letter condemning the "harmful" behavior that led to Schoedon's resignation as an Ethereum core developer. The letter reiterated the need for standards and norms around Ethereum protocol development debates that are designed to promote respect, freedom of speech, and privacy values among participants. Former ACD Chairman Hudson Jameson also hosted an AMA on Reddit to address the debate around Ethereum leadership and accountability. In March, the Ethereum client team ChainSafe held a live event in Paris to further discuss how to acknowledge problems in the Ethereum governance process and propose ways to improve it.
Main content: The departure of Afri Schoedon, a well-known Ethereum core developer, from the Ethereum community has sounded the alarm for Ethereum core developers, dapp developers, and end users to realize the real impact of social media bullying on Ethereum governance. As an off-chain and fairly loosely defined decision-making process, Ethereum core developers, while focusing on technical issues and matters related to Ethereum, are not immune to social debate and the pressure to lead Ethereum development. Cyberbullying in any context, whether or not it is related to Ethereum, is a harmful activity that can negatively impact the behavior and mindset of the targeted individuals. Given that Ethereum’s decision-making process relies heavily on online media for discussion and debate, it is difficult to guard against this behavior. After all, this is not the only example of contributors to the Ethereum governance process being harassed and excluded within the community. However, Afri Schoedon’s departure has brought a sharper focus on the Ethereum governance process and the need to establish stronger norms and social values in this process to promote healthy and respectful dialogue between participants.
Reaching Consensus for Proof-of-Stake Upgrade
Ethereum stakeholders have been anticipating the transition to a Proof-of-Stake (PoS) consensus protocol since Ethereum launched. As such, in the years leading up to the merge, there was little debate or opposition from the community to the idea of upgrading Ethereum to PoS. However, at various times in Ethereum’s history, there has been debate about the technical merits of achieving the transition via one method over another. Additionally, at several points in Ethereum’s first six years of existence, there has been debate about the urgency of the upgrade and whether it took precedence over other initiatives, such as improving Ethereum’s scalability and censorship resistance.
Once the Ethereum client teams resolved the technical arguments for the transition to PoS and finalized a roadmap for activation in the fall of 2022, Ethereum core developers and the broader Ethereum community were almost unanimous in welcoming the upgrade. The code changes involved in transitioning Ethereum from PoW to PoS have been one of the most successful and transformative EIPs in Ethereum’s history. No other upgrade has garnered the same level of community support and excitement as Ethereum’s transition to PoS. The transition to PoS was a multi-year effort that, in its initial stages of deployment, relied on ETH holders to capitalize and bootstrap the protocol by staking ETH, with no guarantees of when ETH could be unstaked. Although delayed due to its complexity, and often mocked and discouraged by members of the Bitcoin community and Ethereum miners, the eventual transition to PoS (known as the merge) solidified a powerful narrative for Ethereum and Ethereum assets, known as the “ultrasonic money” narrative.
The following case studies take a deep 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 Ethereum’s launch. The decision to merge the existing Ethereum codebase with the Beacon Chain (CL for Ethereum) was a difficult one, as many Ethereum client teams were working on upgrades that would replace Ethereum with the Beacon Chain. In 2018, the team building the client transitioning to Proof of Stake became known as the Ethereum 2.0 team. They worked alongside another group of developers working on Ethereum's short-term plan, called Ethereum 1x, from which ideas like EIP 1559 and statelessness were developed. For most of history before the merge upgrade, efforts to advance PoS were largely separate and running in parallel with Ethereum core protocol development. The merge was initiated on September 15, 2022.
Participants: The main teams involved in implementing the merge are a group of new Ethereum client teams, many of which have not built and maintained existing Ethereum clients. Prysmatic Labs, Lighthouse, and ChainSafe are examples of client teams that are new to the Ethereum governance process and have contributed to Ethereum's upgrade to PoS. The launch of Beacon Chain in December 2020 was largely due to the efforts of these relatively new PoS-focused client teams. After the launch of Beacon Chain, CL client teams began to seriously participate and involve EL client teams in the transition. Danny Ryan, a researcher at the Ethereum Foundation, was one of the main leaders of the Merge upgrade program. He continues to lead Ethereum consensus layer development as the head of ACDC.
How the problem was solved: An unprecedented amount of testing was carried out before the Merge activation date to ensure that the transition went smoothly. Ethereum core developers organized more than 25 different testnet releases for Merge. The following is a note from a shadow fork testnet release organized by Ethereum core developers a few months before the Merge activation:
In addition, in the weeks leading up to the Merge activation, the Ethereum Foundation’s funded bug bounty program quadrupled to $1 million, the highest amount ever funded by the organization. The Merge required close coordination between the CL and EL client teams and validator node operators, who were not as skilled as miners in upgrading node software. The nature of the upgrade also required greater involvement from node operators to properly configure client software in preparation for the Merge. The Ethereum Foundation and Ethereum Cat Herders once again became central to connecting Ethereum stakeholders and educating the broader public about the nature of the upgrade. The Merge did create short-lived forks of Ethereum, but none of them continue to have meaningful value or support significant dapp activity.
Main takeaway: Ethereum’s complexity doubled as a result of the Merge, as the protocol is now a combination of two networks evolving in tandem. This necessitated separate governance processes to organize code changes proposed for each network (i.e. Ethereum’s EL and CL). As mentioned earlier, there are two ACD calls every two weeks to discuss EIPs related to EL and CL. However, there are other components of the Ethereum software, such as the engine API that affect EL and CL, which do not have a clear governance process for changing and updating. This has sparked new discussions about future updates to the EIP process to better organize changes to Ethereum given the protocol's dual network structure. (These future changes to the EIP process are discussed in more detail in the next section of this report.)
Case Study 7: Shanghai Upgrade
What Happened: Ethereum’s seventeenth hard fork was initiated in April 2023. This upgrade, known as the Shanghai upgrade, activated staked ETH withdrawals on the beacon chain, thus representing the completion of Ethereum’s transition to PoS. Soon after the merge upgrade was completed, Ethereum core developers quickly prepared the code changes required for the Shanghai upgrade. Despite multiple conflicts of interest surrounding which EIPs to prioritize for the Shanghai upgrade, Ethereum core developers prioritized staked ETH withdrawals represented by EIP 4895 over other EIPs, primarily because they wanted to appease the Ethereum staking community, which has successfully become Ethereum’s primary security provider and node operator after the merge.
Participants: The collective voice of staking pools and ETH holders staked on the beacon chain influenced the Ethereum core developers’ decision to prioritize EIP 4895 for the Shanghai upgrade in an unprecedented way, which is significantly different from the level of influence that miners are able to exert in the decision-making process. Once again, Ethereum client teams acted as gatekeepers, synthesizing community sentiment to determine which EIPs should be included in the upgrade. From October 28 to January 5, Ethereum core developers engaged in a heated debate over the scope of the Shanghai upgrade in several ACD calls. The discussions highlighted the divergence of opinion among client teams on EIP priorities, and how consensus among Ethereum core developers was often reached not through unanimous decisions but rather through rough majority votes. Once the scope and development timeline for the Shanghai upgrade were determined, Ethereum core developers began preparing and testing the relevant code changes for activation.
How the issue was resolved: The Shanghai upgrade was activated on April 12, 2023. As a result of the upgrade's success, Ethereum saw an unprecedented influx of newly staked ETH, far exceeding the amount of ETH unstaked.
The Shanghai upgrade reinforced positive sentiment toward Ethereum as a robust and fully-featured PoS consensus protocol. It also significantly reduced the risk of staking activity by introducing a staked ETH cashout feature, which subsequently led to a massive influx of staked funds. As of May 14, 2024, 27% of the total ETH supply is staked, and Ethereum's annualized inflation rate is trending below 1%. The continued negative inflation rate and rising staking rate since the launch of the Shanghai upgrade have further strengthened people's positive sentiment towards ETH as an ultrasonic currency.
Key Takeaways: The decision-making process of which EIPs to prioritize for the Shanghai upgrade is noteworthy for three main reasons.
· It highlights the influence of the Ethereum staking community on protocol governance as Ethereum’s primary node operators and security providers.
· It reaffirms the role of Ethereum core developers as the primary gatekeepers who synthesize and coordinate upgrades to the protocol to achieve the ambitious development goals set by Ethereum’s founders since Ethereum’s launch.
· It further validates the ultrasonic currency narrative by completing Ethereum’s transition to PoS and triggering a large amount of new staking inflows (far exceeding staking outflows).
As demonstrated by the seven cases studied in this report, the Ethereum governance process is constantly evolving and is loosely defined through the EIP process. Ethereum was launched back in 2015 by eight co-founders with a four-stage development roadmap. The final stage of development was called “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 has a new 8-phase development roadmap with rhyming names.
In rare cases, decisions are made quickly through the exclusive efforts of Ethereum core developers and shared implementation by Ethereum node operators under a fast upgrade turnaround window. Other times, decisions are delegated to the broader Ethereum community, which often leads to delayed decisions and arguments between stakeholders. Through multiple upgrades and several contentious governance debates, Ethereum has evolved into a protocol and a social collective that is largely guided by norms, values, and beliefs rather than on-chain voting processes or mechanisms.
Despite the completion of the Shanghai upgrade and the transition to PoS (which the protocol founders originally envisioned as Ethereum’s last major upgrade), there are a large number of future EIPs and initiatives that are expected to change the Ethereum protocol in the months and years to come. Most recently, with the Cancun/Deneb upgrade, Ethereum developers activated EIP 4844. EIP 4844, also known as protodanksharding, is a code change that introduces a new transaction type called a blob, increases the data and storage requirements for Ethereum blocks, and creates a new fee market for pricing blobs separately from regular transactions.
Some of the 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. This is done for a number of reasons, including the ability to create more secure cryptographic proofs, better interoperability with the Ethereum Beacon Chain, and enhanced functionality for decentralized stake pools.
· Increased validator effective balance: Validator rewards accrue in proportion to a validator’s effective balance, currently capped at 32 ETH, which forces validator node operators to create new validators if they want to earn more staking rewards. In order to reduce the growth of the active validator set, which puts pressure on Ethereum’s peer-to-peer network layer, it has been proposed to increase validator effective balances.
· Execution layer triggerable withdrawals: Allow validators to trigger exits and partial withdrawals via their execution layer (0x 01) withdrawal credentials. This will support the creation of more trustless staking pool designs on Ethereum.
Other code changes that developers are considering implementing 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 cannot authorize transactions. However, user-controlled externally owned accounts (EOAs) can. The most prominent code change proposed to implement account abstraction is ERC 4337, which does not require a backwards-incompatible hard fork.
· MEV-related upgrades: Maximum extractable value (MEV) is the additional income that can be extracted by reordering user transactions within a block. Since lucrative amounts can be obtained, there are many stakeholders involved in extracting MEV. MEV strategies are not different from certain trading strategies in traditional finance.
· MEV smoothing: MEV smoothing refers to smoothing 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 destruction: Another strategy that goes one step further than MEV smoothing is to destroy MEV income, such as the base fee on Ethereum. This will further reduce the inflation of Ethereum's supply and reduce the incentive for validators to manipulate consensus to obtain additional MEV income.
· Enshrined PBS: MEV is currently acquired on Ethereum through third-party marketplaces called relays. In order to reduce reliance on trusted entities operating relays, research is currently underway to implement the relay structure into the protocol of Ethereum itself.
· 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 the total staked ETH. Currently, finalization on Ethereum takes 12 to 15 minutes. However, Ethereum core developers are working on designs for faster finality guarantees that would improve the user experience by incrementally increasing stake guarantees over a 12 to 15 minute window.
· Validator Cap: Related to the move 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 Ethereum’s network layer can maintain fast message propagation to support faster finality or lower the minimum amount of staked ETH required to become a validator.
· Issuance Changes: Developers are also considering changing Ethereum’s issuance policy to prevent a large portion of ETH supply from being concentrated in liquid staking (or re-staking) pools. With the issuance changes, developers hope to set a cap on staking participation, thereby achieving a minimum viable issuance, i.e. the protocol should not issue more tokens than is necessary for the security of the network.
· Verkle Trees: Currently, data about Ethereum accounts, transactions, and blockchain state is stored using a structure called a Merkle Patricia tree. The Merkle Patricia tree data structure allows users to easily verify large amounts of data by relying on a single cryptographic proof, which represents the root of the tree. Verkle tree data structures function similarly to Merkle Patricia trees, however, computers can prove them more efficiently than Merkle trees.
While some of the EIPs listed above may not be implemented in the upgrade due to insufficient technical reliability or being too controversial, the number and scope of code changes being discussed for implementation are enormous. The following is a visual representation of the Ethereum development roadmap summarized by Vitalik Buterin in December 2023:
Latest development roadmap for Ethereum as of December 2023, source: Twitter (@vitalikbuterin)
In addition to code changes to the Ethereum protocol, efforts are also being made to update the EIP process to accommodate what appears to be a more ambitious development roadmap for Ethereum after the merger. In a recent ACD call, developers proposed removing ERC from EIP to a separate governance process and updating the numbering of EIPs to make them easier to track. These minor management changes have sparked heated debate in the community. It is therefore unsurprising that none of the proposed changes to Ethereum’s governance process suggest any governance process will move on-chain or become more rigorous in terms of process in the near term.
One major change to the EIP process worth highlighting for its future implications for Ethereum governance is the creation of a parallel process to the code change approval process implemented on Layer 2 rollups. The Rollup Improvement Proposal (RIP) process is designed to facilitate cooperation and coordination between different rollup upgrades. Rollup developers present and discuss RIPs in a regular meeting series called RollCalls. Ethereum protocol developers are weighing the extent to which decisions on RollCalls influence decisions on ACD calls, and vice versa, as Ethereum developers increasingly attempt to pursue a rollup-centric development roadmap.
As the case studies demonstrate, the successes, failures, and controversies of upgrades have not stopped Ethereum core developers from making changes to the codebase. The frequency of upgrades has not slowed over time, and the nature of the changes being considered and implemented has become more ambitious, not less. As a result, the role of Ethereum core developers in managing the protocol and implementing future upgrades on its development roadmap will remain highly valued in terms of importance and influence.
In addition to Ethereum core developers, there is a growing number of stakeholders in the community who are also important contributors to protocol governance. In a 2019 article on blockchain governance, Vitalik Buterin acknowledged the concerns of “ivory tower intellectuals” about taking over the Ethereum governance process, and affirmed that the best way to address this is to increase the number of institutions and organizations involved in the governance process to further decentralize it away from the power of a single group.
As the Ethereum dapp ecosystem continues to grow, including multiple L2 and DeFi protocols, as well as new and diverse client teams formed through Merge, the number of stakeholders actively participating in Ethereum governance is also growing. Furthermore, as the complexity of the Ethereum protocol has increased, the teams working on Ethereum research and development have diversified into multiple parallel initiatives, including those focused on scalability, MEV, account abstraction, EOF, and more.
Looking forward, validator node operators should expect upgrades that could radically change their business models in the future. Given the expectation and reality of frequent Ethereum upgrades, the community must ensure that Ethereum core developers are not the primary voice in deciding when the Ethereum protocol is upgraded. Furthermore, as expressed by several Ethereum core developers, such as Geth (EL) developer Péter Szilágyi, there are growing concerns about the complexity of the Ethereum protocol due to its ambitious development roadmap.
The complexity of the Ethereum protocol has several disadvantages, the primary one being an increased risk of technical bugs and glitches. Therefore, while the EIP process is designed to facilitate code changes on Ethereum, it is important for stakeholders in the decision-making process to gradually prioritize code ossification over code changes so that the need for active governance processes decreases over time. This is particularly important given the increasing regulatory scrutiny of Ethereum and the applications built on top of the protocol. While the interests of Ethereum protocol developers and the broader community are most influential in today’s governance process, there is also growing pressure from regulators and law enforcement, which can also influence and become a powerful voice influencing Ethereum’s design. In order to prevent the Ethereum protocol from coming under regulatory control, certain aspects of how Ethereum operates must be rigidified to the point where they cannot be changed by any one stakeholder group or entity.
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 influenced by social norms and narratives rather than formal rules or binding on-chain voting mechanisms. While decisions about the future of the Ethereum protocol have sparked disagreements and divisions in the community, Ethereum’s roadmap remains ambitious, listing several EIPs that have already sparked debate and discussion in the Ethereum community.
Since Ethereum core developers act as gatekeepers and ultimately decide on changes that are implemented via upgrades, it is likely that the Ethereum protocol will continue to change rather than ossify. There are also concerns about regulatory capture if a technology becomes too upgradeable, as we have seen with smaller-scale finance-focused dapps and DAOs. Regulatory concerns around the upgradeability of decentralized technologies are beyond the scope of this report, but may be an area of research to consider in the future.
Ethereum as a technology has made great strides and pushed the boundaries of what is possible with blockchain technology. Furthermore, Ethereum as a social community continues to raise new questions about the best forms of governance for decentralized and open source technologies. As Ethereum core developers pursue an increasingly ambitious development roadmap that includes upgrades that expand the Ethereum ecosystem to multiple Layer 2 protocols, all network stakeholders must consider how the social norms of Ethereum governance (rather than established processes) can and should continue to shape Ethereum's future.
Original link
Recommended
The Wall Street Journal: How is AI Trading Stealing the Limelight from Cryptocurrency?
Aug 15, 14:00
Tencent Still Has a Dream
Aug 15, 11:27
To Catch North Korean Hackers, They Set Up a Fake Project
Aug 15, 10:00
From Litigation to Settlement: Positive Signal Released by HTX's Negotiation with FCA
Aug 14, 19:32
11,742 Shipping Addresses Exposed Alongside Trezor Orders
Aug 14, 19:01
Founder Interview: FOMO Creator Explains How They Added 30,000 Users in One Day and Became One of the Fastest-Growing Crypto Apps
Aug 14, 18:37