Thank you @gcolvin @kdenhartog @fulldecent @Pandapip1 @xinbenlv @matt for sharing your perspectives - I appreciate the engagement here!
I think it’s worth it for me to take a step back and explain “where this is coming from”. The #1 thing that “keeps me up at night” here is that, today, we don’t have a single, unified, way to specify a change to the Ethereum protocol. I understand the historical reasons why this is the case, and think we generally made the right decisions to get us where we are. That said, in a post-Merge world, I feel like the specifications, and their associated processes, for Ethereum should also be “merged” (although I can live with minor differences, especially early on).
As many have noted in this thread, we’ve been circling this problem for a long time. My concern today is that the EIP process is very hard for some of Ethereum’s most important contributors - consensus-layer devs & researchers - to approach and engage with. After talking with several of them about this, my general impression is they feel the EIP process is high friction, not particularly well-suited to how they work and, most importantly, reluctant to change to accommodate them.
My rationale for splitting out ERC & EIPs is that this can be a first step to create a process for core protocol changes that works for both the execution and consensus layers. I feel pretty strongly this use the “EIP brand”, as it has very broad community recognition (see, e.g. EIP-4844 now, or EIP-1559. previously). Similarly, I think ERCs have achieved escape velocity as application standards (i.e. other chains even use $TOKEN-20/721 as their token standard, mimicking ERC-20 or ERC-721).
I appreciate there might be some technical overhead to splitting the actual repos and my goal isn’t to create needless work for anyone, but I do feel that integrating the consensus layer as part of the EIP process is critical to do relatively quickly, and we should be fine taking steps that aren’t as “clean” to make that happen. Given that, I’m skeptical that a short term solution here is “adding another layer of process” rather than “loosening some of our constraints to attract these people and iterate on a process from there”.
Another idea I’ve half-jokingly proposed is to myself become an EIP editor with the sole purpose of making life easier for CL folks who want to contribute
Hopefully this context helps! I’ll be on the EIPIP call this week to discuss this further, too
Now, here are a few more specific thoughts on the replies above.
I think some of the problems a fork per se might solve could also be solved within the repo by things like enforcing EIP vs ERC naming conventions, having separate ethereum/EIPs/EIP and ethereum/EIPs/ERC directories, adapting our requirements and templates to different needs, and other such.
I don’t have any issues with this, assuming we can then have more flexibility in updating the Core EIP processs. That’s the main thing I’m after with this proposal.
I do think that Core protocol changes will need a different process from application-layer standards. We already see this in EIP-1, which has a whole section on how Core EIPs are different.
I actually feel the exact opposite here: today, CL changes don’t even have EIPs. The number of eyeballs looking at the PR-by-PR changes to the consensus-specs is much lower than the number of eyeballs who can track EIPs X, Y, Z. I strongly agree with you that we should have a process which highlights changes to Ethereum, and that’s why I think we should be willing to “bend” most/all of our other standards for the purpose of having CL changes included in the EIP process.
That’s not the problem, though: the problem is CL EIPs don’t exist today.
While I agree at a high level, I do think there are some pretty important technical distinctions between application standards (opt-in) and core protocol changes (applied to all the network at a specific time). We already have separate specs for APIs, and I think that’s been a good thing. IMO specialization at the spec level doesn’t mean the community fragments, but instead that we can better support its different growing niches.
The main blocker is people who have the skills don’t have the desire to do this. I’m somewhat optimistic that if the EIP process was more accommodating to CL folks, we could get a couple of them to eventually join as (Core?) EIP editors.
I’m happy with that if we’re okay with them not explicitly following all existing rules. If it lowers frictions and helps us build a better process, sure!