Move ERCs to separate repository

[lightclient]

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 stack. 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. Less people are involved across the stack (for better or worse); yet the repository remains unified.

For years, we've considered separating the repository. This would allow ERC and EIP processes 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).

Ultimately, I believe it is finally time to separate these processes.

--

Proposal

I propose the following steps are taken to perform the separation:

1. All ERCs are removed from this repository and migrated to a new repo. The history should be intact so that repo should be fork of this one with the non-ERCs removed. I've written a script (see below) to perform this operation. Once this PR is approved, it should be executed immediately before merging.
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. Setup 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. Due to how deeply intertwined the processes are, I don't think we can have a conflict of numbers here. So I propose a document with the next available number be created so editors can use it to assign.

This is the bare minimum to separate the processes. There will then be a longer tail of changes that need to be made to remove references no longer make sense, update the website templates to not include categories that don't exist, etc.

I don't want to get bogged down with endless debate about every single faucet of the migration. If the migration is supported in the first place, we should make it happen even if it takes a bit of time to polish. If we wait for perfection, we will never be able to change.

Script

#!/bin/bash

src_repo="EIPS"
tgt_dir="ERCS"

cp -r $src_repo $tgt_dir

# Find and delete all ercs.
cd $src_repo
ercs=$(git grep -l "category: ERC" -- EIPS)
echo "ercs found: $(echo $ercs | wc -w)"
for file in $ercs; do
        echo "This file was moved to https://github.com/ethereum/ercs/blob/master/ercs/erc-$(basename $file | cut -d- -f2)" > $file
        rm -rf "assets/$(basename ${file%.*})"
done

# Find and delete non-ercs for new ercs repo.
cd ../$tgt_dir
others=$(git grep -L "category: ERC" -- EIPS)
echo "non-ercs found: $(echo $others | wc -w)"
for file in $others; do
        rm -rf $file
        rm -rf "assets/$(basename ${file%.*})"
done

# Rename ercs.
for file in $ercs; do
        mv -f $file "EIPS/erc-$(basename $file | cut -d- -f2)"
        mv -f "assets/$(basename ${file%.*})" "assets/erc-$(basename ${file%.*} | cut -d- -f2)" 2>/dev/null
done
git checkout EIPS/eip-1.md
mv EIPS ERCS

[eth-bot]

EIP Review Bot is running...

[github-actions]

The commit 4b4335e (as a parent of 36ddc29) contains errors.
Please inspect the Run Summary for details.

[GregTheGreek]

I like 👍

[cupOJoseph]

This is sorely needed for organizations sake, and to make application development more clear and accessible to developers who want to build on ethereum, and no longer need to work intimately with core consensus parts of it. The reality is, ethereum is much easier to build apps on now than it was when this EIP system was made, and the dev tool ecosystem has been growing exponentially for years. The seperation makes complete sense.

Running a simple script like that is a good way to kick things off. We can make new templates for the distinct repos as a new proposal afterwards. Let's get this in.

[xinbenlv]

The PR is making it sound like "oh because ERC and Core EIPs are in the same repo we can't make better editorial policy", and hence the proposal to split.

The actual problem is that the current EIP editorial policy are more made from the perspective by some editors, and we lack author voice in the process. And there are many restriction we want to relax, for both Core and other EIPs.

I know many ERC authors I talk to are unhappy with EIP restrictions. Don't that also apply to Execution and Consensus devs?

Consensus Layer is also utilizing the EIP process, the cracks are becoming more visible.

According to my debate with @lightclient on EIP Editor Channel of Discord, his policy stance is that he doesn't want the EIP editorial policy to relax for Core EIPs. Will you still support the splitting if you know the intent for splitting is so that the policy for Core EIP could remain the same? How does it solve the problem?

My question for Consensus Devs and perspective EIP authors:
Consensus EIP authors and developers, are you satisfied if the EIP editorial policy remain the same after the split?"
did you ask "what's blocking from us for relaxing the restriction in the current repo?"

My question to @lightclient: what's your policy solution to "Consensus Layer is also utilizing the EIP process"? Are they unhappy because the policy is too "relaxed" instead?

---

I must voice I strong opposition to this PR.

1. I am strongly against moving ERCs out of this repo. The author pain comes from the editorial policy and it needs fixing. Splitting doesn't fix the editorial policy. And both Core EIP authors and ERC authors are all pained by the constraint of editorial policy.
2. I am less against if you are only proposing Core EIPs need to be splitted, by all means go ahead splitting Core EIPs. I think Interface, Network, and Meta could stay in this repo. Feel free to start something like coreeip.ethereum.org if you want.

[lightclient]

I don't have the energy to fight you or the other opposing editors anymore. Every minute change takes months or years of argument. I am confident that with the separation, the processes can evolve more fluidly.

Until then, everyone will remain disengaged because their time is better spent elsewhere.

[abcoathup]

EIPs should be easy to create & update for core devs. Unfortunately it is not.

The best worst option to quickly improve the situation for core devs is splitting, so I (as a non editor) am in favor of just getting on with it now.

[xinbenlv]

@abcoathup I agree with your intention but the proposer of this PR is actually trying to split so he could keep the policy strict and hard for core dev, the opposite to your reason supporting the split. Check my comment above for details.

[MikeMoldawsky]

The separation makes sense as it reduces noise and helps standardize the approval process, which MUST be different.

However, a subtle yet important point is that some ERCs serve as a proof-of-concept for a future EIP. This means these ERCs should get core developers' "eyeballs" (feedback) as soon as possible to avoid unnecessary development cycles.

So a general +1 for the direction, but we need to understand that the 2 repos will be tightly coupled and offer a solution.

(Naive solution would be a PR tag in the new repo).

[wschwab]

@xinbenlv from a different angle, does splitting out the ERCs make things worse than they are right now for Core EIPs? If I'm understanding your position correctly (no guarantees), your point seems to be that the editorial process for Core also needs to be updated, but even if that is the case, is it a reason to prevent splitting off the ERCs?

A side note about ordering: this is likely obvious, but a number of ERCs are known widely by number, in particular the token ERCs (20, 721, 1155). I hope this isn't only my opinion, but my opinion is that no matter what numbering scheme is implemented for ERCs (assuming they're split off), these numbers should be reserved for these ERCs. There are other ERCs where I could see this being the case (165, 1167 as examples) too.

Thanks for getting this moving @lightclient !

[MariusVanDerWijden]

I have voiced my strong support for this proposal in the past multiple times.
The ERC and EIP process have evolved to mean very different things imo.
ERCs are used as a shelling point for applications and often also as a marketing tool.
This huge influx of PRs makes it almost impossible for core devs to just randomly go into the repo and review some core EIPs.
Out of the current 132 PRs only 15 are marked core.
I remember Micah said back in the day that the EIP editors don't have enough time to do qualitative reviews of the EIPs because of the huge influx of new PRs, so he started to only check syntactic issues (no urls, headlines okay, ...)
I hope that with the split more core devs will be actively involved in the EIP process again, which will increase the quality of EIPs again. Discussion usually leads to better EIPs and to finding issues earlier. Right now you need to specifically talk to people to get any eyeballs on your EIP.

[abcoathup]

@abcoathup I agree with your intention but the proposer of this PR is actually trying to split so he could keep the policy strict and hard for core dev, the opposite to your reason supporting the split. Check my comment above for details.

@xinbenlv according to core devs the status quo isn't working. The process needs to fit the needs of its users. ERCs and EIPs are very different beasts, they operate at different layers and have different users. ERCs are noisy and lead to a noisy repo. The noise can act as a barrier to being involved in core EIPs.

If EIPs need strict linking rules, and ERCs want broader linking rules, then this is an example of where trying to keep EIPs and ERCs in the one repo under the same rules impacts both.

I've been checking the repo most week days for the last two years. Keeping ERCs and EIPs in the same repo hasn't led to massive improvements for EIPs, so it is time to do something different. I don't want to be sat here in two years time and we haven't made progress. So my vote is for change.

[xinbenlv]

@MariusVanDerWijden

"Split to let Core focus" is a reasonable rationale, but if core EIPs want a different repo to focus, what do you think about Network and Interface EIPs? Should they stay with Core or Stay with ERCs? What if consensu just wanna look at consensus exe just wanna look at exe? Shall there be further split?

The eips.ethereum.org site has listed Core EIP by its category, there are also RSS feed by category, and github PR are categorized by type. If Core wants engage, there are tools to do so.

I feel the real problem blocking core devs and many other is still the EIP process is very daunting for them to even beging to edit / author, and this split doesn't help. We really need to fix the EIP process.

[xinbenlv]

Thank you for your response @abcoathup

@xinbenlv according to core devs the status quo isn't working. The process needs to fit the needs of its users.

Earlier you cited @michaelsproul 's tweet as a supporting evidence for the process being hard for Core Devs. Yet I think the proposal to split intend to keep it hard for Core Devs

ERCs and EIPs are very different beasts, they operate at different layers and have different users.

The differences apply to Interface and Network EIPs and likely also exist between Consensus and Execution layers to some extend.

If EIPs need strict linking rules, and ERCs want broader linking rules, then this is an example of where trying to keep EIPs and ERCs in the one repo under the same rules impacts both.

It seems at least in @michaelsproul 's case, he was complaining about link policy too strict.

I have not hear many complaints by core dev that "authoring EIP is too easy", or "the restriction is too loose". Rather, everyone complaint I hear from core authors or other are the process being too restrictive.

I've been checking the repo most week days for the last two years. Keeping ERCs and EIPs in the same repo hasn't led to massive improvements for EIPs,

4337 was an ERC attempt over two unsuccessful prior attempts to achive AA at Core level. Does it count as as an example that different level discussion benefit the Ethereum ecosystem?

so it is time to do something different. I don't want to be sat here in two years time and we haven't made progress. So my vote is for change.

Yes we really need to change, and really need to make process.

But splitting which doens't make any policy improvment in thr first place,
sounds to me a way to avoid improving the EIP process for core.

[xinbenlv]

For full context. Similar proposal has been also discussed in FEM

https://ethereum-magicians.org/t/proposal-forking-ercs-from-eips-repository/12804/6

[timbeiko]

A side note about ordering: this is likely obvious, but a number of ERCs are known widely by number, in particular the token ERCs (20, 721, 1155). I hope this isn't only my opinion, but my opinion is that no matter what numbering scheme is implemented for ERCs (assuming they're split off), these numbers should be reserved for these ERCs. There are other ERCs where I could see this being the case (165, 1167 as examples) too.

Agreed, @wschwab. I don't think any existing number would be changed (ERC-20 would remain ERC-20). We'd just need to figure out a scheme to number future EIPs/ERCs

[gcolvin]

A side note about ordering: this is likely obvious, but a number of ERCs are known widely by number, in particular the token ERCs (20, 721, 1155). I hope this isn't only my opinion, but my opinion is that no matter what numbering scheme is implemented for ERCs (assuming they're split off), these numbers should be reserved for these ERCs. There are other ERCs where I could see this being the case (165, 1167 as examples) too.

Agreed, @wschwab. I don't think any existing number would be changed (ERC-20 would remain ERC-20). We'd just need to figure out a scheme to number future EIPs/ERCs

A problem is that, yes, overlapping use of ERC and EIP have have caused confusion for a long time now. Going forward the confusion could remain for a long time. Numbering schemes can't help that.

[gcolvin]

As an editor I am currently blocking consensus on this change and will not approve merging this PR. I've rgued why in many places recently and many times over the yeas.

[lightclient]

Per ACD #164, we're going to move forward with this. We'll discuss more of the specifics on EIPIP next week.

[xinbenlv]

Thanks for discussing this with CoreDevs.

Personally I will respect consensus of the community.

I will try to collect feedback from ERC authors on next AllERCDevs which is happening on next Thursday. If there is no objection from ERC authors, I will not attempt to block it on my side.

Can we hold the discussion on EIPIP until after the AllERCDevs?

[lightclient]

I think you should seek out ERC authors who disapprove of this before EIPIP next week.

[xinbenlv]

The AllERCDevs time runs regularly, so I would appreciate there is a chance to speak in a live meeting so more people are aware of.

Also, I've asked in the channel of AllWalletDevs to see if they have any opinion or not.

[gcolvin]

Per ACD #164, we're going to move forward with this. We'll discuss more of the specifics on EIPIP next week.

No, we are not. The Core Devs do not control the EIP organization and process.

The core devs had at most a day or so of warning to discuss a contentious decision that is not theirs to make. I learned very little in that meeting as to what their pain points actually are, just that given a single proposal that purports to fix them they approved.

So I am still blocking consensus. We need to fix problems, but absent a fairly complete plan as to what needs fixing and how splitting repos will actually help and not harm my objections remain unanswered. Blocking consensus means that if I cannot be convinced to support or at least acquiesce I will resign.

[bumblefudge]

I cannot speak to the procedural best step forward, but my read on the situation is that:

1.) Most people tend to agree that CORE and higher-level/EIP discussion have slightly different process needs and fairly distinct communities/inputs/fora they respond to. However tightly or loosely coupled, however many editors they have in common, most seem to agree that separating them will improve the quality-of-life and signal-to-noise ratio for people only interested in, or confident speaking up about, one of the two sides of the coin.

For example, as a veteran of app-level/EIP-level companies, and organizer of the CAIP process at CASA, I can say that if the process split in two, I would volunteer to be a committed/every-PR editor of a segregated EIP process, and would prefer a "weekly digest/overview" of CORE issues, which honestly I'm not qualified to speak on.

2.) But notice the subtle slide from "split the repos" to "split the editorial processes into two separate deciding bodies with different processes." I think the pushback comes from the distance between those two changes. This PR only splits the repos, with a sort of implicit promise that the processes can evolve separately down the road, and if I'm reading correctly the objections, it's the uncertainty of this future step that is giving people pause, and/or the "overpromising" that severing the process helps both halves work better in the near future.

I think the question of how the EIP process or the CORE process is "stricter" or more editorially involved kind of presumes two different bodies of editors committing to more or less editorial power and responsibility... so bifurcating the process might be trading ONE can of worms for TWO, even if it also activates a broader pool of willing editors like myself to clean up the two messes separately 😅

3.) Would objectors prefer...
A.) ...those next steps be worked out explicitly before the trigger is pulled?
B.) ...if there were advance commitments (like mine) to be editors help quorum be reached for both proposed editorial bodies? presumably every current editor that wants LESS responsibility than they currently have for one of the two processes should be met by one net-new volunteer like myself?
C.) ...walletDevs and coreDevs arrive at some kind of consensus or list of requests/requirements at their next meeting(s) and document their results in this thread?
D.) ...current editors and/or randos like me use "request changes" to fine-tune the two versions of EIP-1s before merging?

[xinbenlv]

As my commitment to my own principle of "I'll follow the consensus despite I might hold minority view.", I put together a list of task items i think could be used as a starting point of discussing "How to split": Task list for ERC/EIP Split. Please feel free to edit.

[bumblefudge]

As my commitment to my own principle of "I'll follow the consensus despite I might hold minority view.", I put together a list of task items i think could be used as a starting point of discussing "How to split": Task list for ERC/EIP Split. Please feel free to edit.

Because I have absolutely no chill, I jumped in and annotated this to-do list. If this is overstepping my role as a pro-active rando, feel free to ignore my annotations, throw out half of them, edit them unrecognizably etc before during or after today's call. But I thought it might be a net-positive contribution to the efficiency of today's call-time to put the low-hanging fruit on paper and get us to a gameplan sooner. Thanks to everyone who's put in so much time and thought so far.

[Pandapip1]

LGTM

[Scamreno]

Thx

[Sulthanmh]

Yes

[F153]

#7206

[GIgako19929]

Move

[GIgako19929]

Thank you for the comprehensive and detailed proposal for EIP-8. The changes outlined to ensure forward compatibility for the devp2p, RLPx Discovery, and RLPx TCP Transport Protocols are well-explained and necessary for future protocol upgrades. I appreciate the inclusion of test vectors and the rationale behind each change. This will undoubtedly aid in the smooth implementation and adoption of these enhancements.