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.
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).
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.
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.
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.
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.
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.
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.
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.
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?"
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.
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:
Some process change ERC may want to adopt:
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.
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.
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.
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 and related rights waived via CC0.