ERC/EIP Repository split

Abstract

Describes the motivation and rational for splitting the EIP repositories into an EIP repository, targeting core ethereum changes and an ERC repository, targeting application layer specifications.

Motivation

Long ago when the EIPs repository was created, there was a vision of a single home for all standards related to Ethereum. The community was small and most people were interacting at every level of the ecosystem. It made sense to combine application standards with core consensus changes.

Since then, the ecosystem has grown. Today, the chasm between application development and core development is wide. Fewer people are involved across the ecosystem (for better or worse); yet the repository remains unified.

For years, we've considered separating the repository. This would allow ERC and EIP specifications to evolve more naturally due to the independence. But it's always difficult to reach critical threshold to make a change like this happen. Each time we get lost in the details of the migration and the debate grinds progress to a halt.

Now that the Consensus Layer is also utilizing the EIP process, the cracks are becoming more visible. There are changes we could make to the process that might benefit them more, but because we also need to ensure the quality of ERCs, we are restricted.

There are also many more efforts to catalyze applications around the ERC process. Attempts have been made to develop working groups and review groups for certain ERC "categories" (a distinction that doesn't even technically exist because of the unified repo).

Specification

This specification only details with the initial mechanism of the split. The particulars of how each repository will govern itself is out of scope for this EIP, as it is the motivating point of this EIP that the divergent needs of the community will require highly divergent methods.

1. All ERCs and Interface-category EIPs are removed from this repository and migrated to a new repo. The history should be intact so that repo should be forked of this one with the non-ERCs removed.
2. The new ERCs repository goes live and includes the changes from the script.
3. Setup ercs.ethereum.org subdomain and update the CI to point to the ERCs repo.
4. Set up a redirect for ERCs on eips.ethereum.org to go to the new website.
5. Create a unified document for editors to assign EIP/ERC numbers. EIPs and ERCs will no longer be based on an initial PR number but on a number incremented by the EIP editors of their respective repositories. EIPs will be assigned even numbers and ERCs will be assigned odd numbers. The exact timing of this migration is a policy decision of the editors.

The EIP repository will be associated with core protocol changes, specifically the kind that would be discussed in one of the AllCoreDevs calls; whereas the ERC repository will be affiliated with all remaining areas such as smart contract application interfaces, wallet standards, DeFi protocol standards, and all other such improvements that do not require core protocol changes.

This association is to persist across any other process changes the EIP editors may introduce such as working groups, topic groups, expert groups, special interest groups, splitting of the process, or other such changes. Any sub-groupings that includes core protocol changes would be associated with the EIP repository and other sub-groupings are associated with the ERC repository. Any such process change are out of scope of this EIP and are independent of the structural changes to the repositories specified in this EIP.

There may be further structural changes to repository layouts to accommodate more sub-groupings. Such proposals are out of scope of this EIP.

Rationale

There are two major communities served by the EIP process that are highly divergent and very differentiated in their needs.

Let's consider the impact of specification ambiguity, the impacts are different based on the community. The core protocol community has a low tolerance for difference of implementation and a high penalty for specification ambiguity. An improperly implemented part of a new spec could cause the ethereum mainnet to split, possibly costing millions to billions of value lost to node operators as well as community members using the services offered by the Ethereum protocols. A poorly specified solidity interface, however, can be adapted and implemented in multiple compatible ways across any smart choosing to implement it. A missing RPC API (such as a configuration option specifying the number of decimals in the chains native currency) can have limited to zero impact on the rest of the community not choosing to use that wallet.

Timeframe for delivery of a feature is also similarly differentiated. A Core protocol EIP adjusting the gas cost for transaction data needs to be rolled out at a specific time uniformly across the network. Whereas a new RPC to support new semantics to gas estimation would not need uniform rollout across the Ethereum clients, and in fact would also need to be rolled out by service provides that provide RPC services for Ethereum networks. Wallets can use early support as a differentiating factor in their appeal to community members.

To address this divergence the AllCoreDevs call has adopted a lifecycle for EIPs different from the Draft -> Review -> Last Call -> Final lifecycle of the EIP repository. It would best be described as Draft -> Eligible for Inclusion -> Considered for Inclusion -> Testnet -> Mainnet. The EIPs also get slotted for a fork in the third step, a consideration that simply does not apply to a smart contract or wallet standard.

Several alternatives have been proposed, but the actual implementation only further underscores the specialization that each side of the split encounters.

Alternative: Working Groups

One repeated concern of editors is that they often lack the technical experience to adequately judge if an EIP is complete and sound. Considering that EIPs covers wide variety of topics such as elliptic curve cryptography, VM performance, DeFi market dynamics, compression protocols, NFT Royalties, and consensus protocols it is impossible for a single editor to provide sensible feedback on every one of those topics.

When examining how the core protocol and ERC communities would approach the working group process, however, it underscores how different they would handle it. For core protocol change the working group would be one of the two AllCoreDevs meetings, either AllCoreDevs-Execution or AllCoreDevs-Consensus. And sometimes both. There is no EIP that would be shipped in mainnet that would not first be extensively considered by one of these two groups.

ERC proposals have no such standing groups. Wallet impacting changes may go through the AllWalletDevs group, but it is entirely possible for a wallet or group of wallets to collaborate on a protocol outside AllWalletDevs. Smart contract APIs have no such standing meeting.

The Working Group model, however, would be a critical social signal for the ERC community. It would signal a critical mass for a particular proposal issue if enough experts could get together to agree to review a set of changes.

While working groups are excellent for the ERC community, it is overhead for the core protocol community that would only add friction to an already established process with know governance checkpoints.

Alternative: Specialized Editors

This alternative has already been implemented with the introduction of the eip-editors.yml file. This allows for different groups of editors to review different types of EIPs.

There has been no measurable impact on the divergence of the community. Most categories have a significant overlap with other categories.

This alternative does not address the governance and workflow issues that the Core Protocol Developers would want to implement. All subgroups would still be subject to the same workflow as other groups.

Alternative: Pain unrelated to process divergences

This is a catch-all for a number of proposals, from allowing discord links in discussion-to to allowing more freedom in external links.

While the theory that this may reduce the total amount of pain felt by users and editors, bringing the pain level down to a more acceptable level, this does not address the core divergence issue. Many of these pain relief proposals should probably be done anyway, weather or not the EIP repository splits.

Alternative: Replace EIP Editors with AI Chatbots

Nobody wins in this proposal. We would instead end up debating training sets, competing implementations, and whether to use commercial providers. And that's if things go well.

AI chatbots, however, would not be able to compartmentalize the divergent needs of the multiple groups if all adjudication were to be handled with one model or one chat session. Higher quality output would be received if separate training repositories were used for each major functional area.

Alternatives are not Mutually Exclusive

It is critical to note that most of the discussed alternatives all have merits and address important pain points. The adoption of a split should not be viewed as a rejection of those alternatives. To quote a famous internet meme "Why Not Both?"

Objection: This splits the ethereum community

One objection is that splitting the repository would result in the community no longer being able to say "we are all of us Ethereum Magicians."

First it is important to note that such splits are already occurring. The AllCoreDevs call has split into a Consensus and Execution layer call. ACD calls no longer discuss client issues like wallet apis, the AllWalletDevs call has adopted those issues and has grown into user experience issues. Cross chain issues have been adopted by the Chain Agnostic Improvement Process (CAIP) group.

Rather than splitting this should be viewed as "sharding", where a sub-community of interest rallies around a shared sub issue, and by gathering are able to increase the total scope of the community. CAIP is a perfect example where operating separate from EIPs have allowed them to strengthen the ethereum community.

Is a single cell organism weakened when it grows large and then splits into two? Is an animal weakened when cells split and specialize into different tasks? It is this very act of division and specialization that allows it to accomplish the things that would be impossible as a single uniform cell.

Objection: This should be an EIP-1 proposal

Since this is directly impacting the ERC process it should be documented in EIP-1 first.

As the old programming adage goes: "Refactor first before adding any new features." Adding new processes specific to the post-split governing docs would only confuse the existing process, adding special cases for one class of EIPs that don't apply to another. It is precisely this kind of problem the proposed split is aiming to change.

This is also valid grounds for a Meta category EIP, as how many and which repository to put a proposal in is core to the "procedures, guidelines, [and] changes to the decision-making process".

Some process changes that can be expected in a Core Protocol EIP may include:

• Changing the work flow to add the Eligible for Inclusion/Considered for Inclusion stages to a pre-last-call EIP.
• Adding test net and mainnet steps to the lifecycle
• Adding a "fork" header to the RFCs section, for EIPs that are (or will be) implemented in a specific fork
• Changing the testing section to a header link to reference tests

Some process change ERC may want to adopt:

• A strong working group model and adding an optional "forming working group" step editors may require.
• Add an "outdated" or "replaced" lifecycle step for EIPs that are abrogated by future specs.
• Deputize single-eip reviewers for specific EIPs

Objection: Structural changes to a repository and process changes do not need to be bundled.

It is possible to split the structure of the repositories separately from any EIP process changes related to this. Bundling the changes is unnecessary and such structure and process changes should be handled independently.

To accommodate this objection this EIP has been revised to only address structural changes in the repository and can be adapted to any other, independent, process changes and mapped onto those outcomes.

Backwards Compatibility

Old Links

Old ERC links pointing to the old url https://eips.ethereum.org/ will continue to work. Redirect instructions will be put into place to redirect to the new ERC repos for their corresponding location.

Stray Proposals

ERC community members may continue to post new ERCs in the EIP proposal. Editors will be able to redirect them to the new repository. ERCs that do not respond to editor requests would not be merged anyway.

Security Considerations

This proposal only addresses the EIP and ERC proposal process and is not expected to expose any new attack surfaces by virtue of its adoption.

Copyright

Copyright and related rights waived via CC0.