Participating Projects

Purposes, goals, or scope: Broadly speaking, the Ethereum project aims to build a scalable, decentralized, censorship resistant, general purpose blockchain computer that is capable of running a variety of applications. There is no singular, official, sanctioned project goal. Different organizations, groups, and classes of users have different goals, so in a sense the goal of Ethereum is to be a “big tent” and serve as many of these groups as possible.

Metrics to measure success: Transaction volume, total fees paid, number of (active) accounts, number of useful, successful businesses and applications built on the platform, count of active users of those applications, total value secured by the platform (including both the market capitalization of ether as well as value held by layer two applications such as DeFi).

- Ethereum Foundation
- ConsenSys
- investors
- DAOs (e.g., Moloch DAO)
- Ethereum Cat Herders
- core developers/All Core Devs
- companies

Users are generally identified by account addresses derived from public/private keypairs, which may optionally be mapped to human-readable names using a service such as the Ethereum Name Service (ENS). Note that the mapping from participants and users to accounts is not one-to-one: one user often controls many accounts, and many users may share a single account such as a multisignature wallet smart contract. There are no restrictions on who can participate: anyone who has the technical chops and can pay the necessary gas fees may participate.

If we interpret the “project’s software code” to mean the layer one code, the only privileged groups delineated in software are miners and stakers, who have the exclusive ability to collate transactions into blocks, propose those blocks to the network, collect fees and rewards associated with those blocks and the transactions they contain, and vote on which valid blocks to include and which chain to extend (implicitly, through the act of mining/validating). Mining (on Eth1) and staking/validating (on Eth2) is permissionless and anyone, anywhere may participate by investing in the required expertise and equipment and connecting it to the network.

Miners have the ability to control one network parameter, maximum gas per block (a.k.a. block size), by nudging the parameter up or down slightly with each new block they produce. All interaction is mediated by the protocol and the P2P network itself.

From the perspective of the layer one code, other than miners, all network participants are equal peers: they can synchronize data, independently verify transactions, and submit new transactions.

Note, however, that certain large, influential applications running on the platform (i.e., at layer two) do have power over the project’s software code in the sense that they can influence public opinion over which version of the software is the most legitimate, e.g., which version to support in case of a contentious hard fork.

The Ethereum ecosystem is complex and there are many important informal groups, including:

- Ethereum Cat Herders
- Core researchers and developers (including those that are and are not affiliated with the coordinating entities listed above)
- Investors (both individuals and institutions)
- Exchanges, and other infrastructure providers
- For-profit businesses built on Ethereum
- Application developers
- Community organizers
- DAOs

Note that many ecosystem participants are in fact members of many of these groups, and there is considerable overlap among them.

I am not aware of any groups constituted through contractual arrangements or based on geography/choice of law (other than the coordinating entities listed above).

The only behaviors encouraged intrinsically (by the protocol itself) are mining/staking/validating, since miners and validators receive transaction fees and block rewards. The broader project, ecosystem, and community extrinsically incentivize many behaviors at the social layer, such as:

- buying and holding (“hodling”) ETH coins
- being active on online forums, such as Twitter, Reddit, and Discord
- speaking publicly in support of Ethereum (as a technology, platform, investment, etc.), and speaking negatively about projects perceived as competitors
- “preaching the gospel” by convincing new folks (“normies”, “nocoiners”) to join the project, ecosystem, and community (“red pilling”)
- contributing to grants, supporting worthwhile projects
- creating and distributing memes
- attending community events (virtually or in person)
- contributing to the software and/or building applications on the platform (via grants, bounties, and social status)
- testing new software (testnets, Eth2)

These “social layer” contributions are incentivized via economic mechanisms (e.g., grants, bounties), social status (e.g., scarce speaking slots at events), and enactment and enforcement of group norms, solidarity, and shared values.

The sole intrinsic reward mechanism, i.e., mining, is working as designed. Overall hashpower committed to the protocol and network continues to rise, which is part of the network effect and virtuous feedback loop that increases protocol security and, in turn, increases the number and diversity of projects that can be built and operated on the platform. It’s important to note that mining is subject to certain externalities, such as the cost and availability of GPUs, and the state of specialized mining hardware (ASICs). Also, this mechanism is on the verge of undergoing a phase transition as the Ethereum network transitions from proof of work mining to proof of stake, so the medium to long term outlook is unclear.

Also, demand (in terms of transactional throughput) has far outstripped supply for the past year, which has caused fees to skyrocket and caused many classes of transaction and application to no longer be viable.

There is no universally agreed-upon set of metrics to measure the effectiveness of governance, but some possibilities include:

- whether community members who submit proposals that are ultimately rejected feel that the process was legitimate
- the degree of constructiveness of public discourse, overall level of network security and amount of value secured
- how quickly and reliably the protocol and its maintainers respond to the perceived needs of project stakeholders (by, e.g., approving and incorporating new EIPs)
- how quickly the project is able to carry out its long-planned upgrade to Ethereum 2 and how well that upgrade meets the evolving needs of project stakeholders
- transaction throughput and total fees collected
- number of new accounts created
- number and diversity of new ecosystem participants and new applications developed
- total project market capitalization

Important feedback from a senior, core Ethereum contributor (who is more involved and up to date than I am):

> I think we have a bunch of recent examples showing that we’ve made controversial changes: 1559, rejecting a block reward increase, prioritizing the merge, etc. This is hard to measure, but it also seems like we are moving away from a “tyranny of structurlessness” mode where both core devs and the community are starting to better appreciate their respective powers (e.g. core devs _can_ propose anything, but community adoption is most important, and miners will tend to follow that because the community drives the ETHUSD price). Here’s an ACD call which had a bunch of controversial decisions shot down: https://github.com/ethereum/pm/issues/288

These costs are substantial, on the order of millions of dollars per year. The lion’s share of these costs are borne by the coordinating entities listed above, especially the Ethereum Foundation and ConsenSys. Directly or indirectly, most of this funding originated with the pre-mine (tens of millions of ETH coins minted prior to genesis and sold or endowed to individuals and organizations that were early project supporters). As a result, it can be thought of as a “tax”, paid upfront, on all holders of ETH. Some degree of ongoing infrastructure and public goods spending is borne by private entities, especially teams of application developers and the investors that back them, but this is small relative to the first category. The infrastructure cost of miners is paid by network users via transaction fees, and in the form of inflation (block rewards, a.k.a., miner subsidies) by all holders of ETH.

Importantly, EIP-1559 will change the dynamics by which transaction fees contribute to overall network value, as a portion of these fees will be burnt, reducing the total outstanding supply of ether and adding deflationary pressure.

There’s also a positive trend here as more projects that issue tokens on Ethereum, and capture significant value at layer two, contribute to ongoing maintenance and development of shared infrastructure via initiatives such as Moloch Grants, Gitcoin CLR (constrained liberal radicalism) grants and quadratic voting.

Formally, a decision is deemed legitimate if it follows the standard, proper, accepted governance process: a proposal is first introduced in the form of an EIP, it’s then debated among the core developers from various teams, it’s then developed, tested, and incorporated into the various client implementations, then scheduled for inclusion into a regular network upgrade hard fork release (or an emergency bugfix upgrade), and then, finally, a majority of miners, full node operators, and exchanges download and install the update. (Note that not all classes of decisions need to follow precisely this process, but big decisions that impact the protocol must.)

Informally, a decision may be deemed legitimate for entirely different, social reasons, e.g., because it was put forth by a person or an individual in a position of authority and influence. The only real litmus test of whether a governance decision is deemed legitimate by a majority of stakeholders is whether they choose to continue to support the fork chain after a network upgrade hard fork (vs. remaining on the old chain, initiating a counter-fork, moving to another chain, etc.).

There are different categories of governance proposals: broadly, “core” and “non-core” proposals. In theory, anyone may introduce a proposal of either category using the relevant public repository on GitHub.

In practice, the vast majority of “core” proposals that are ultimately adopted are introduced by a very small number of project insiders, technocrats with both the necessary technical know-how and social connections required to shepherd a proposal through to acceptance and inclusion (the membership of this group does evolve considerably over time). There’s a vast “graveyard” of proposals from stakeholders without this power that will never see the light of day. The set of people who have proposed “non-core” proposals that were adopted by the community is much broader and more diverse.

Regarding process, see previous bullet point.

The core devs, and other participants in the EIP and “all core devs” mechanisms.

All of the stakeholder groups listed in #9. None has exclusive executive power; each has veto power over one stage in the governance “pipeline,” so in practice all must align to execute policy.

There is no explicit interpretive mechanism. There are informal, social mechanisms. One such mechanism is what all of the projects built and operated on Ethereum coordinate around as being the “true” Ethereum (especially when a network upgrade hard fork occurs).

Another such mechanism is the “court of public opinion,” i.e., when individuals with clout weigh in on questions of governance and interpretation.

There is a semiformal system of checks and balances among the stakeholders in the “approval pipeline” described in #9. Each stakeholder group has the ability to veto or block decisions earlier in the pipeline: e.g., if core devs approve, implement, and release a proposal that a majority of network participants disagree with, they may choose not to upgrade to the new release, and/or to explicitly remove the change (a phenomenon known as a “user-activated fork”). In practice, this has never actually happened.

In theory, the governors of the system, i.e., the technocratic council of core developers, are accountable to all stakeholders, but in practice there is no formal mechanism for enforcing this accountability.

Any subgroup of disgruntled or disenfranchised stakeholders always holds the power to execute their own fork and, in effect, to “fire the governors.”

The EIP and “all core devs” mechanisms rely on a system of signalling known as rough consensus. Rather than explicit voting, it relies on a trusted, unelected moderator who entertains debate on a topic until all concerns have been addressed, or until such time as he or she unilaterally decides to end debate on a topic. The moderator then summarizes their understanding of the will of the group with respect to the topic at hand. This mechanism is informal and is not strictly binding, though in practice its outcome is adhered to in the vast majority of cases.

In addition, multiple tools are used for informal “sentiment gathering” among all stakeholder groups including opinions expressed on social media, polls, and “coin voting” (where each nonbinding vote is weighted by the number of coins held in the account that cast the vote). Additionally, recent outreach on the part of groups such as the Cat Herders via surveys, 1:1 meetings and infrastructure community calls has proven to be helpful in collecting community feedback.

The only exception to decisions made by ordinary processes (as described above) are emergency hotfixes and upgrades, such as those deployed in 2016 in the wake of the DAO attack and the Shanghai DoS attacks. In such emergency situations, where user funds and/or the integrity of the network itself are at risk, extraordinary processes, such as a council of core project developers and representatives of major stakeholder groups, may be put in place which bypass the standard, slow EIP process. After the crisis is past, the outcome of this process will still be retrofitted into existing governance mechanisms: e.g., an EIP that explains what happened and why will be written, approved, and added to the project archives. It’s also worth noting that no such extraordinary procedure has occurred since 2016.

It should also be noted that the nascent Eth2 network, still in a development phase, has a different decision making process (for choosing features and performance improvements) that is less rigid and formalized than that of Eth1. This may change as the network matures and Eth1 and Eth2 are merged into a single, production network.

Retroactive, irregular state transactions, such as those that revert past, valid transactions, or those that alter account balances or state, are verboten and cannot happen without a contentious hard fork (e.g., the hard fork that mitigated the DAO attack).

Certain aspects of the social governance of Eth1, such as the EIP process itself, the role of the core devs, and the role of the Ethereum Foundation, evolve gradually but are unlikely to change dramatically without a contentious hard fork, since there is no mechanism to enact such a change and one has never occurred before.

However, the launch of Eth2 represents an extraordinary opportunity to introduce large changes, since it’s an entirely new network.

Introducing new client implementations, new R&D staff, and new participants in the EIP, core devs, and governance process makes changing the project harder because a greater variety of interests must be considered and more people must be convinced to support changes. In general, as the overall value hosted by the network increases, making changes becomes harder since more is at stake.

By contrast, the transition to Eth2, which is an entirely new network designed, engineered, and launched from scratch, makes certain types of changes, such as the transition from proof of work to proof of stake, much easier. Indeed, many of the changes being included in Eth2 could not have been made on top of the existing network.

The EIP process has continued to evolve gradually since inception, change that is visible in, e.g., the edit history of EIP-1, the “meta-EIP” that explains and governs the EIP process itself. Most of these changes have been slight, for instance altering the way that EIPs are categorized, approved, and merged. Changes that are currently under consideration include retiring the category of “Meta EIPs” (those that describe processes, not code), and separating ERCs (those that describe standards and conventions) from EIPs.

• Any present inquiry into Ethereum governance is complicated by the fact that there are actually two Ethereums: Eth1 (“EthPoW”) and Eth2. These two networks are almost entirely distinct, they’re worked on by different groups of people, and they are governed separately. The plan is to merge the two in the medium term (months to years). This will take time and it’s unclear exactly how and when this will take place, but work is progressing (including a number of experiments running merged testnets) and community sentiment is solidifying. It’s also unclear, once this merger is complete, how the resulting network will be governed and what will happen to existing governance mechanisms. Teams working on both networks are collaborating on developing a governance process for a “post merge” Ethereum.
• What do you consider the sources/roots of the network’s governance legitimacy/authority? The evolving network upgrade governance process. The project’s founders. The Ethereum Foundation. A shared vision and set of values. The total network value. There is no one source that is universally agreed-upon.
• When and how do participants have ‘skin in the game’ (exposure)? (E.g. financial, reputation, legal, etc) Ether holders have financial skin in the game. Developers have reputation at stake, and possibly legal liability. All stakeholders have reputation at stake.
• What are the costs of exiting the network? (eg. loss of data, time, money, status, connectivity) For developers, sunk cost into experience, code, and tooling that may not interoperate well elsewhere. Transaction fees associated with exchanging ether for other coins or tokens. Loss of social status. Lack of access to the robust Ethereum financial ecosystem, including DeFi, and loss of liquidity. Loss of access to popular, useful Ethereum-based applications. Loss of composability with existing smart contracts and applications on Ethereum.
• How are conflicts resolved? Lots of bickering and arguing on social media. The EIP and all core devs processes, including peripheral community meetings that include more stakeholders and breakout sessions to drill down into controversial topics. Sometimes, a small number of influential individuals weighs in.
• How are potential future changes communicated to participants in the network? Blog posts from EF and the Cat Herders, communication from individuals very involved in governance such as all core devs moderators, and others on social media, releases from various core teams, articles in third party media channels. The regular all core devs meeting is considered a quasi-official, preferred channel for announcements.
• Does this network facilitate transparency with regard to the use of governance powers? How do these mechanisms operate? To some extent. EIPs are all public, as are the all core devs calls where they are debated and, in theory, decisions are made. (In practice, many significant decisions are still made behind closed doors.) The code for all major client implementations is open source and the development process is visible on GitHub (or similar platforms).
• Many more details are available in this talk.