Title: Proposal__Forking_ERCs_from_EIPs_Repository
Category: Magicians

Author: timbeiko
Date: 2023-02-01T18:35:32.436Z

TL;DR

We should fork the EIP repo to create an ERC-only one, with ERCs displayed at ercs.ethereum.org

Editors would be granfathered in both repos, free to resign on either side
The processes can evolve independently, to suit the need of EIP vs. ERC authors, and welcome CL contributors to EIPs
To avoid name collisions, EIPs get even numbers, and ERCs get odd ones.


Background
ERCs are distinct from EIPs in that they concern themselves with the application layer, rather than consensus or client-related changes.
Over the years, this has led to friction and awkwardness in determining how EIP statuses should be interpreted for each type of EIP, what standards should EIP editors apply when reviewing ERCs vs. EIPs, and even how we should render their names 
In addition, with The Merge behind us, there is now a desire to harmonize the EL & CL specifications processes. EL & CL teams currently have very different approaches to specifications, and it is to be expected that how EIPs are used in the context of network upgrades may change to accomodate CL practices, leading to further divergence between EIPs (especially Core EIPs) and ERCs.
Finally, the concept of “ERC editors” has come up frequently, and been stated as a “blocker” to separting out EIPs from ERCs. That said, ERCs do get reviewed today. By forking the repository, EIP editors would automatically be ERC editors as well (and free to resign from this). If this leads to no ERC editors, then it will be a strong signal to the community to step up and invest in this.

Proposal

1. Fork ethereum/eips to create ethereum/ercs

Start from the same repository, and do not handle any major changes before the separation.

2. Create ercs.ethereum.org to render ERCs
Re-use all templates and styling from eips.ethereum.org - the website should look “the same”, minus the content.

3. Update EIPs repo to remove mentions of ERCs
Add a link to ercs.ethereum.org as part of the landing page, and do the same thing for ERCs repo.
Note that the ERCs repo will probably require a larger overhaul, but that can happen gradually.

4. Avoid Number Collisions by using Odd/Even Numbers for ERCs/EIPs
We don’t want ERC6000 and EIP6000 - going forward, EIPs would use the even number closest to the PR number by default, and ERCs would use the closest odd number. Historical EIPs/ERCs would be not be changed, e.g. ERC20 & EIP-1559 both break that rule.

5. Allow Both Processes to Evolve Independently
Once the split is done, both EIPs and ERCs can evolve in independent directions to best suit the needs of their users.
It’s important to remember that while there are constraints EIP editors can impose, the goal of the EIP and ERC processees should be to serve authors. If EIP and ERC authors have different goals with their specifications, the processes should accomodate them differently.

Author: SamWilsn
Date: 2023-02-01T18:46:53.109Z

Playing devil’s advocate a bit here, but what benefits does this change bring?
I see a bunch of drawbacks that need to be addressed:
We already have separate editor sets for both EIPs and ERCs. @Pandapip1 (plus me, a little) is mostly responsible for ERCs today. Anyone wanting to join as a pure Core EIP editor would be able to do just that.
This split would necessitate duplicating our CI systems, and having to maintain them both separately.
Similarly, I could easily see this duplicating all the meta/governance processes. Twice the meetings for editors that handle both ERC and non-ERC proposals.
Nothing here mentioned how we’d handle non-Core EIPs. I’d guess that we’d have to have Meta ERCs (at least ERC-1), and Meta EIPs still? Then there are still Interface, Networking, and Informational EIPs. Where do they go?

Author: timbeiko
Date: 2023-02-01T18:56:18.880Z

SamWilsn:

Playing devil’s advocate a bit here, but what benefits does this change bring?


I think the main benefit is that it provides a clearer “scope” for what the EIP process should accommodate, and can ideally help couple it more closely with the EL and CL specs.
Beyond that, I think it would highlight that the process can change, which has been a source of concern from CL folks about engaging with the EIP process: they fear that it is too bureaucratic and that coupling CL changes with EIPs will needlessly slow them down. Or, that the process won’t be able to accommodate their needs.



 SamWilsn:

This split would necessitate duplicating our CI systems, and having to maintain them both separately.
Similarly, I could easily see this duplicating all the meta/governance processes. Twice the meetings for editors that handle both ERC and non-ERC proposals.


I agree this isn’t great - esp. the second point (machines are easier to duplicate than humans!). It might not be worth splitting the “meta governance” at first, until there is clearly a need for it.



 SamWilsn:

Nothing here mentioned how we’d handle non-Core EIPs. I’d guess that we’d have to have Meta ERCs (at least ERC-1), and Meta EIPs still? Then there are still Interface, Networking, and Informational EIPs. Where do they go?


I think Meta make sense across both, yes! For simplicity, I think you just keep all other categories in EIPs, possibly duplicating some? The Networking EIPs are all related to client software, so EIPs. Interface is split, so perhaps duplicate? Informational, not sure…!

Author: xinbenlv
Date: 2023-02-02T16:24:13.316Z

I can resonate with many points said by @timbeiko . But forking is a big decision.
Before going down the route of a repo and process forking, have we evalutate the options to elect more Core EIP Editors? @timbeiko
I have seen Yellow Paper drifted to obsolete and was quite a pity. I wonder what has blocked EL/CL from step up to continue editing Yellow Paper and the like?
EIP Editing faces its challenge today in lacking governance and a clear pathway to its membership. If more EL/CL developers join as Core EIP Editor, this could be resolved. ( FYI @kdenhartog who discussed this with me)
Meanwhile, the EthMagics will be meeting in person in ETHDenver on Mar 2nd, I like to invite you to join the conversation and meet with other EIP contributors and share your proposal if time works for you!

Author: timbeiko
Date: 2023-02-02T19:32:52.558Z

xinbenlv:

Before going down the route of a repo and process forking, have we evalutate the options to elect more Core EIP Editors? @timbeiko


I’ve been trying to get more editors for a few years now  One thing I think is important, esp. for Core EIPs, is that editors have a lot of context around what’s happening in the protocol, and so if we can get people in or close to client teams, that’s ideal.
One barrier for CL teams to engage more has been that they feel the EIP process is very bureaucratic and not tailored to their needs, so I think this separation would make CL folks more willing to engage.



 xinbenlv:

I have seen Yellow Paper drifted to obsolete and was quite a pity. I wonder what has blocked EL/CL from step up to continue editing Yellow Paper and the like?


I think the YP is a bigger can of worms: the math-heavy notation makes it hard to approach, it always “lags” behind as an official spec (i.e. at Fork X, the “spec” for the EL is “YP + EIPs in Fork X”), and post-merge, it doesn’t even have any notion of PoS…! My suggestion for it would be to do one final update to it, pre-Merge, and mark it as deprecated.



 xinbenlv:

EIP Editing faces its challenge today in lacking governance


This might be controversial, but I think the EIP process might have too much governance today  If we look to what CLs do, there is much less friction, and client developers seem to really enjoy it. IMO, there’s value to some of the friction of the EIP process, but if it has a narrower scope (i.e. just consensus-related changes), we might be able to loosen constraints given we’re operating in a smaller domain.



 xinbenlv:

Meanwhile, the EthMagics will be meeting in person in ETHDenver on Mar 2nd, I like to invite you to join the conversation and meet with other EIP contributors and share your proposal if time works for you!


I won’t be there in person, but happy to join virtually if that’s possible

Author: gcolvin
Date: 2023-02-02T23:55:59.899Z

I hate to wade into this, as we’ve been having this conversation for years and have yet to fork – I fear we will just rehash the same old arguments, on top of new arguments   So, wishing to only get my toes damp, (but knowing that my whole body will likely be getting wet) and repeating some points already made above and elsewhere by myself and others …
First an observation – our process was initially modeled to a large extent on the IETF process.  They have been managing the evolution and specification of the entire Internet for many years now within a single editorial process.  I don’t see that our project is at anything close to that scale.

We should fork the EIP repo to create an ERC-only one, with ERCs displayed at ercs.ethereum.org

I don’t think simply forking the repos will solve the problems you bring up, @timbeiko – most of which I agree are problems – and will cause more problems as well, as noted by others 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.

The processes can evolve independently, to suit the need of EIP vs. ERC authors, and welcome CL contributors to EIPs

I don’t think our users needs are so disparate we need separately evolving processes – I think that will just get us an even more confusing set of processes which would only get worse over time.

To avoid name collisions, EIPs get even numbers, and ERCs get odd ones.

We’ve already lost an editor to disagreements over numbering.

EL & CL teams currently have very different approaches to specifications, and it is to be expected that how EIPs are used in the context of network upgrades may change to accomodate CL practices, leading to further divergence between EIPs (especially Core EIPs) and ERCs.

Again, I don’t think the changes should be so great as to require separate repos.  I think that would only complicate matters.  Better to work on harmonizing the approaches.  These are layers of Ethereum, not entirely separate protocols.  For the most part the same client teams are working on both layers.

Finally, the concept of “ERC editors” has come up frequently, and been stated as a “blocker” to separting out EIPs from ERCs. That said, ERCs do get reviewed today. By forking the repository, EIP editors would automatically be ERC editors as well (and free to resign from this). If this leads to no ERC editors, then it will be a strong signal to the community to step up and invest in this.

I think the signal is already pretty loud, and having diverging teams will only make things worse.
I’ve suggested before, as I think @anett has, that we need to lean more heavily on the Magicians.  ERCs cover a much wider range of interest and expertise than EIPs so it’s not a surprise that not many people are interested or qualified to review them all.  IETF proposals are vetted by established working groups before they get to Draft stage.  Rings of Magicians were intended to do the same, but haven’t really taken off.  But one way or another I think we need to encourage and support peer review to take a load off the more more permanent editorial staff.

It’s important to remember that while there are constraints EIP editors can impose, the goal of the EIP and ERC processes should be to serve authors. If EIP and ERC authors have different goals with their specifications, the processes should accomodate them differently.

I totally agree on the goal.  But for all the reasons above and more I don’t think having multiple diverging processes and teams of people is the way to go.
So how do we get a better consensus on what the needs are and how best to serve them?

Author: gcolvin
Date: 2023-02-02T23:59:28.431Z

As for the Yellow Paper, that’s also been discussed a lot over the years.  My take remains that I’d rather see it improved than deprecated.  I think our Executable Spec may often better serve as a guide to creating and modifying clients – programmers mostly know how to port code  But as a program in an imperative language it’s not a good way to define Ethereum as a state transition function.  That’s what math is for, and the math in the Yellow Paper is not all that advanced – sets, tuples, boolean logic – it’s just not very well presented.   And there are in fact mathematicians and logicians doing important work on Ethereum who would struggle just as hard with a Python program as some programmers would struggle with the math. Yes, it’s going to lag the actual protocol, but that seems to me less of problem when we have an executable spec that is co-developed with the other clients.  Is the Foundation too poor to find the resources for this?

Author: kdenhartog
Date: 2023-02-03T00:03:28.719Z

Personally, I think the direction this is heading is similar to what I’m looking for in trying to propose utilizing the IETF process more. Looking at what @gcolvin got in right as I was typing this up, it sounds like he’s suggesting we’ve been trying to move in this direction, but we’ve never been able to quite get there yet. I think this is the time to hammer out what it might look like so that we can make it easier for people to participate. This isn’t the first time I’ve heard of people leaving the EIP process to standardize work elsewhere because they found the process of EIPs too much of a headache.
Essentially the way IETF handled this issue in the past is to create specialized areas of development that have domain specific experts who participate in areas which are led by “Area Directors”. These AD’s essentially would be like EIP editors for specific areas and their primary goal is to help keep areas focused on specific pieces of work and to help form working groups that can move specific RFCs forward. This allows people to be able to focus on areas relevant to them and ignore areas that are not. For example, I’m primarily interested in wallet related EIPs and ERC related EIPs, so I’d just focus on tracking these specific areas. Others may only be interested in a specific EIP so they may only pay attention to communications in a specific WG. This would allow for communications to happen a bit more independently of each other and help reduce the beauacracy of non contentious pieces of work so they can move quickly, but also get robust review from specific people who are directly affected by a particular EIP.
It’s my opinion that we should be trying to emulate a structure like this so that we don’t actually need to fork. Instead we establish areas of expertise that are governed independently by experts of that area. Additionally, we can utilize this org structure to add in things like broad reviews (such as privacy and security) as well so that we’re able to catch breaking changes that happen independent of the WG work. This isn’t a perfect proposal, but I think the problem we’re faced with is actually one that’s solvable if we’re willing to start specializing work rather than trying to clobber everything on to each other and overwork editors like we’re currently encountering.
Here’s just a strawman proposal of what this might look like:
Screenshot 2023-02-03 at 12.59.11 PM738×611 37.3 KB

Author: fulldecent
Date: 2023-02-03T01:18:14.446Z

This proposal will result in even less eyeballs on important EIP decisions, which could be catastrophic. And therefore it must be rejected.
EIPs are already accepted, implemented, and “decided” on with minimal community involvement. A recent consensus change was decided by only Ethereum Foundation and announced on Ethereum.org blog with an effective date of +24 hours. Imagine if that change received even less attention than it already did and was announced even MORE last minute (like one hour before change). That would be catastrophic.
Now that the merge is complete, decisions are centralized even further. Every upgrade decision is held ransom with a cut-throat mechanism… because forking is no longer possible. Or to be specific, forking now costs each validator USD 50,000 to support. (To caveat here and avoid confusion, using a new network ID/chain ID is not a fork, it is a new product.)
Now that we have established EIPs are not receiving enough attention, let’s please accept the fact that ERCs are more popular, get more press and more attention than EIPs. Because they are written by individuals writing applications and are easier to understand. This is the creator economy working!

Alternate proposal
So here is an alternate proposal that still allows people who don’t care about ERCs from having to see them:

Create a new RSS feed and button on eips.ethereum.org.
When you subscribe on that feed (or the associated email list, yes we need an email list) you will not be bothered with ERCs.


Tenets
We are one community. ERCs/EIPs are ETHEREUM IMPROVEMENT proposals. As in the whole community—the clients, the applications, the JSON RPC, we even have proposals for how to make proposals and a proposal explaining that you shouldn’t use a certain opcode while not removing that opcode. All of these things are in one sandbox with one community. And so our IMPROVEMENT proposals should live together. In the end, we are all improving the same thing.

Author: EvanVanNessEth
Date: 2023-02-03T07:25:50.637Z

I made this proposal years ago and people got mad at me.

Author: Pandapip1
Date: 2023-02-06T03:42:37.601Z

I agree with @kdenhartog that the IETF structure is probably the way to go. I think we should get rid of the standard track type, and replace it with “core” and “ERC” (yes, this turns interface and networking EIPs into ERCs).Then, I propose we replace “category” with “categories”. Final EIPs can have categories added to them, and if authors from >5 Final EIPs come together, they can create a new category and add it to those EIPs, ensuring that the list of categories is up to date. The categories that will be displayed on the nav bar will be the five categories that maximize the number of EIPs discoverable.

Author: xinbenlv
Date: 2023-02-06T13:10:17.617Z

timbeiko:

I’ve been trying to get more editors for a few years now 


You are not alone. I definitely resonate a lot of frustration with you and EL/CL devs.
QQ: when you tried to get more editors for EL/CL, what has blocked your candidate from being admitted as editors?
How about this: admit everyone / a few members of EL/CL spec who currently has merge power of that repo as new Core EIP Editors and let them merge Core EIP PRs? @timbeiko

Author: matt
Date: 2023-02-06T16:10:42.482Z

Thanks for writing up this proposal @timbeiko!
This is one of the longest debated topics among editors. In the very early days (circa 2017), we thought that EIPs and ERCs could coexist in the same repository and be driven by various “rings” (e.g. working groups of magicians). Interest in rings dried up and we went several years without much coordinated work on EIPs outside core.
In mid-2020, I proposed to revive the concept and more closely follow the IETF organization structure by having working groups tackle specific topics / domains, each equipped with a champion who would be able to hold the group accountable and ensure progress (something I felt that was missing from the early rings).
Unfortunately this still did not gain traction. It eventually led to more serious discussions about bumping ERCs out of the repository entirely, to allow application developers more opportunity to self-organize. Because EIPs are critical to the core Ethereum protocol, we have generally been hesitant to grant individuals editorship who are not actively engaged with the protocol and strongly aligned with the philosophical interests of Ethereum.
And so, although many app devs are extremely talented and have great application-layer vision, it often felt inappropriate to include them as EIP editors because of the sensitivity of the position relative to Ethereum’s governance process. Plus, there simply were not many candidates who seriously pursued editorship in the first place.
In the intervening years, the EIP process has changed substantially. In some ways we are much better off than before. The work by @SamWilsn and @Pandapip1 on improving the CI infrastructure has led to much more consistency across EIPs, and generally the review quality is rather strong. In other ways, we have created a system that developers want to avoid at all costs due to arduous requirements, nitpicking, and poor communication about expectations.
–
This is the long winded way of saying that EIPs are at a local (I hope) minimum of relevance. There are a lot of issues and we can’t fix them all at once. I think that splitting the repositories down the line of “app standards in this repo, core in this one” is the best first step. We should focus on the one EIP type that we are good at, core EIPs. They’re also arguably the most important type. Applications can and will create standards outside the EIP process. I think it is paramount that we eventually work with them to develop open standards with the community, but it is something we have been failing to do for over 6 years now.
IMO it’s easy to think that this change will drastically affect the community, but the reality is that they don’t care and are extremely amenable to change. I am really impressed with how quickly we were able to change many processes / naming schems that felt deeply embedded into the core of Ethereum: eth2 → EL+CL, ERC → EIPs → and now back again, ACD → ACED (okay I’m still not sold on this one, sorry Tim), etc.
It will certainly be an inconvenience in the beginning, but I believe we will come out the other side with a better scoped organizational structure to begin engaging more contributors who do care about the ecosystem and its core processes.

Author: timbeiko
Date: 2023-02-06T19:58:50.368Z

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.



 gcolvin:

I totally agree on the goal. But for all the reasons above and more I don’t think having multiple diverging processes and teams of people is the way to go.


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.



 fulldecent:

This proposal will result in even less eyeballs on important EIP decisions, which could be catastrophic. And therefore it must be rejected.


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.



 fulldecent:

So here is an alternate proposal that still allows people who don’t care about ERCs from having to see them:


That’s not the problem, though: the problem is CL EIPs don’t exist today.



 fulldecent:

We are one community. ERCs/EIPs are ETHEREUM IMPROVEMENT proposals.


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.



 xinbenlv:

QQ: when you tried to get more editors for EL/CL, what has blocked your candidate from being admitted as editors?


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.



 xinbenlv:

How about this: admit everyone / a few members of EL/CL spec who currently has merge power of that repo as new Core EIP Editors and let them merge Core EIP PRs? @timbeiko


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!



 matt:

ACED (okay I’m still not sold on this one, sorry Tim)


*ACDE

Author: kdenhartog
Date: 2023-02-07T03:08:51.605Z

Cross referencing this post because I think it’s highly relevant to this discussion as well:




How do we address editors being overworked with a better governance method and what does it look like? Process Improvement


    I generally think we will need to get to that point as well. Something interesting about the W3C is that they have a small team of full time staff and then for the rest of their team, they’ve got fellows which are paid by W3C members (who are their employers) but spend 80% of their time just doing W3C related work. 

For me I don’t think the answer is that we need more editors, but rather that we should distribute their responsibilities to more people. From a governance perspective this is also…
  

One thing that’s clear to many of us here is that we need to find a process to move forward still and from the sounds of @matt we’ve actually tried to land one something similar to what I’ve proposed. As dumb as this sounds, I think part of the issue of why this might not have worked in the past is simply in how we’re using github, FEM, Discord, and Twitter to organize discussions and move work forward. As I’ve heard it put best “We shape our tools and then our tools shape us”. In this case, I think because we’ve tried to keep the “EIP process” within a single repository inside github that’s forced a lot of the processes we have today. For example, discussions moved to FEM because it was too hard to find the relevant discussions in the GH issues (I assume - please correct me if I’m wrong @matt). Also, editors ended up being core to the process because they were the ones who had merge rights in the repo. So, I think as we look at these changes we need to also evaluate how we’re using the tools to make this work.
For this reason, I don’t think my proposal in that linked post is best to do this in one large sweeping change. Instead my hope is that it is a “guiding plan” that we can iteratively implement and improve (or ignore in some cases) as we come across problems we need to solve.
For this specific problem (and I think it rings true for core devs and wallet devs alike) I think the first simplest step forward that we take is to form GH orgs for “ethereum-core” and “ethereum-standard-contracts” where we can start to create repos for EIPs to move forward. We could then turn the EIP repo in the “Ethereum” org into a landing page of sorts for finalized EIPs and a way to redirect to the other EIP areas. This way we’re still all within the “EIP brand”, but we’ve also got a bit more space to specialize and cultivate independent communities which we can cross pollinate in due time.
Also, I intentionally didn’t mention “ethereum-wallets” because I’m hesitant what to propose for wallets right now. Many are going multichain (not just EVM based, but also Solana or UTXO) these days so keeping this work only under the Ethereum umbrella could actually harm this area of development. We can figure out what to do for wallets a bit later, but it would be good to see what people think for them specifically once we’ve worked through getting the core/CL community and ERC community sorted first and learned what works and what hasn’t.

Author: SamWilsn
Date: 2023-02-07T05:16:07.469Z

kdenhartog:

discussions moved to FEM because it was too hard to find the relevant discussions in the GH issues


Discussions are on FEM because we try to minimize dependence on GitHub itself, and to aggregate discussion for each EIP into a single persistent thread instead of over multiple PRs and issues.

Author: sbacha
Date: 2023-02-07T13:33:14.195Z

How does removing something that is not even relevant to CL teams help them feel more comfortable in contributing to the EIP process?
Its Not the EIP process that is bureaucratic, its ACD. There its been said.
Adding a even odd numbering system makes things even less coherent.
If wanting to make such processes more accessible, maybe adding a “fast lane” shepherding process to expedite things would be beneficial. Give each CL team one such indulgence per quarter so that they can use it for things they want to prioritize getting through.

Author: xinbenlv
Date: 2023-02-08T00:53:11.051Z

Thanks @timbeiko for triggering this serious and important discussion and taking time to patiently respond to me.  Sorry I have been quite busy recently and thus delayed to put down my responses in detail.




 timbeiko:

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!


That’s a good compromise to me. Having two sets of EIP editors and if necessary two editing/merging rules sounds much less controversial and better backward compatible than “forking the ERC out of EIP”. If you wanna make it an alternative proposal, I will co-sign the petition with you, including allow the Core EIP has its own editing rules ignoring all other existing rules. I am also happy to see the ERC EIP Editors / workgroup form from a group of people who specialize in smart contract and application building too.
If you don’t have time to draft this alternative proposal, I am happy to draft it too. Let me know how you like to do it. @timbeiko




 timbeiko:

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.


Yeah. I feel sad that is the case and this is huge room of improvement for us as a community. We need to be able to attract contributors. I am in favor of making the EIP process more accommodating to “adopters”: CL/EL client devs of course, and also dApp developers, each in their working group.




 timbeiko:




 xinbenlv:

EIP Editing faces its challenge today in lacking governance


This might be controversial, but I think the EIP process might have too much governance today  If we look to what CLs do, there is much less friction, and client developers seem to really enjoy it. IMO, there’s value to some of the friction of the EIP process, but if it has a narrower scope (i.e. just consensus-related changes), we might be able to loosen constraints given we’re operating in a smaller domain.


Your complaint is not controversial - I agree with you a lot.
You probably use “EIP Governance” to mean the “restriction before merging”. In that, I totally agree that it’s too much restriction.
When I use the “lack governance”, I mean something different. I will address this in a separate response.




 timbeiko:




 xinbenlv:

I have seen Yellow Paper drifted to obsolete and was quite a pity. I wonder what has blocked EL/CL from step up to continue editing Yellow Paper and the like?


I think the YP is a bigger can of worms: the math-heavy notation makes it hard to approach, it always “lags” behind as an official spec (i.e. at Fork X, the “spec” for the EL is “YP + EIPs in Fork X”), and post-merge, it doesn’t even have any notion of PoS…! My suggestion for it would be to do one final update to it, pre-Merge, and mark it as deprecated.


Wearing my developer hat I understand the execution-spec and the like are better than YP. Wearing my PhD student hat, I however understand the academia needs something like YP, just like @gcolvin mentioned. The problem with YP lack of updates is not inheriting to YP itself, it’s a living testimony of that we haven’t foster a good enough open contributor culture to YP and a room of improvement. We can discuss this later.

Author: Pandapip1
Date: 2023-02-08T17:33:10.521Z

timbeiko:

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.


It’s not in the scope of the EIPs repo to care about which EIPs are implemented where. IMO a core EIP that doesn’t get included should still be finalized in the EIPs repository, assuming it was extensively tested.
The process need not be different for Core EIPs and ERCs. Core EIP authors want their spec to be included as fast as possible in order to maximize visibility, to get discussion started, and to allow suggestions and proposal forks to be made. The same motivation is true for ERC authors. Therefore, the idea of splitting the repository makes absolutely no sense.

Author: polarpunklabs
Date: 2023-02-08T18:06:58.076Z

Apologies for my likely superficial perspective here, but I just caught this issue by chance.
However, I can’t help but wonder are the EIP volunteers or paid? (Will follow up depending on answer).

Author: timbeiko
Date: 2023-02-08T18:31:00.847Z

polarpunklabs:

However, I can’t help but wonder are the EIP volunteers or paid? (Will follow up depending on answer).


Mostly volunteers, though “it depends”. Ethereum Cat Herders offered some stipends to some (and still might?), others do this as part of their “day job”, etc.

Author: matt
Date: 2023-02-08T23:16:40.000Z

Random twitter poll points to community being okay with splitting them up: https://twitter.com/lightclients/status/1623372648783953920?s=20&t=fqctjq_WIOreSee7JPNNdA

Author: MariusVanDerWijden
Date: 2023-02-09T15:32:41.027Z

I am very pro splitting EIPs and ERCs. I don’t have the capacity to read the whole thread but I wanted to respond to a few points.



 SamWilsn:

Playing devil’s advocate a bit here, but what benefits does this change bring?


I think the biggest advantage is focus. Right now I never look at the EIPS, only if I am forced to (when I have to implement something, …). I never have the urge to go and lock what cool new EIPs are currently being drafted, because there are 92 open PRs, most of them concerning ERCs.



 fulldecent:

This proposal will result in even less eyeballs on important EIP decisions, which could be catastrophic. And therefore it must be rejected.


I disagree with this. In my opinion splitting the processes will actually increase the number of eyeballs on the EIPs. Right now no one looks at them (except the EIP editors) and as I said earlier this is because of so much spam and unnecessary or useless proposals.



 Pandapip1:

Core EIP authors want their spec to be included as fast as possible in order to maximize visibility, to get discussion started, and to allow suggestions and proposal forks to be made. The same motivation is true for ERC authors.


The intentions and goals might be the same, but the audiences are very different. EIPs are meant to be discussed and reviewed by core devs, while ERCs are used by the greater community to establish standards. They require different processes and have completely different audiences imo.
I think EIPs are a tool and as a tool they should serve the core dev community. They are not doing a great job at that (I think everyone can agree on that). Splitting the repos into two will be a great step in the right direction imo. It will allow us to focus while giving the greater community a shelling point for their proposed standards as ERCs. Historically having the same process for both might’ve made sense when we had 20 proposals, but with >4000 proposals its just not practical anymore.
I also like some of the other proposals, like creating an RSS feed and mailing list, but they should be secondary to us splitting the repos.

Author: polarpunklabs
Date: 2023-02-09T19:26:11.682Z

Since it’s a role that does not have the same prestige as a client developer (broadly speaking) I think it is more like a job than a volunteer role The struggle to get volunteers speaks to this. I think like the website there should be a few people who are paid to do EIPs, funded by the EF. Just my 2c.

Author: fulldecent
Date: 2023-02-09T21:14:18.998Z

Okay, here is the solution to everyone’s issues:


github.com/ethereum/EIPs








Website: Rewrite index with filters


master ← fulldecent:focus-on-eips



          opened 09:10PM - 09 Feb 23 UTC




            fulldecent
          



+324
-110






New features:

- Clear presentation
- Focus on the content
- Filters

![ou…t](https://user-images.githubusercontent.com/382183/217939959-66fad508-5f3f-419a-bc38-26674b593a49.gif)


https://youtu.be/gzZqgACuULQ






And a full narrated YouTube explaining it: https://youtu.be/gzZqgACuULQ
Don’t have time to click that button? Here is a gif, you’re already watching it…

Author: SamWilsn
Date: 2023-02-10T22:37:38.019Z

The biggest reason to split the repositories is that it will make it easier for the processes to diverge, both in governance and technical stuff (like CI.) Sure, we can have the processes diverge in the same repository, but it makes the tooling simpler if we also split the repositories.

Author: SamWilsn
Date: 2023-02-10T22:41:54.644Z

MariusVanDerWijden:

I think the biggest advantage is focus. Right now I never look at the EIPS, only if I am forced to (when I have to implement something, …). I never have the urge to go and lock what cool new EIPs are currently being drafted, because there are 92 open PRs, most of them concerning ERCs.


Our bots do add tags to the PRs to make them easier to search (eg. Core Only) but I do very much see your point here.

Author: Pandapip1
Date: 2023-02-12T17:14:10.858Z

MariusVanDerWijden:

I never have the urge to go and lock what cool new EIPs are currently being drafted, because there are 92 open PRs, most of them concerning ERCs.


FYI - you can filter PRs easily. For example, to view only new Core EIPs, you can use:
https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ac-new+label%3At-core
EDIT: Wow, I missed sam’s comment above. Great minds think alike, I guess.

Author: gcolvin
Date: 2023-02-14T05:25:39.541Z

A meta-comment on these recurring split-the-repo discussions:
My old psychology mentor had a (tautological) maxim: “If a situation calls for a person to do something they can’t do then they will do something they can do, if they do anything at all.”
It seems to me that we have social problems that we don’t know how to solve, so we are trying to solve technical problems instead.

Author: SamWilsn
Date: 2023-02-15T04:12:12.937Z

gcolvin:

something they can’t do


Come to a decision.



 gcolvin:

something they can do


Fork it!

Author: gcolvin
Date: 2023-02-17T04:16:36.085Z

Pandapip1:

It’s not in the scope of the EIPs repo to care about which EIPs are implemented where. IMO a core EIP that doesn’t get included should still be finalized in the EIPs repository, assuming it was extensively tested.


I think you brought this up in the last EIPIP meeting, @Pandapip1.  For core EIPs the original concept of Final really was running on the mainnet. Up until then the specification must be open to change – otherwise what is deployed might intentionally not match the Final spec.

Author: Pandapip1
Date: 2023-02-23T20:32:01.666Z

gcolvin:

I think you brought this up in the last EIPIP meeting, @Pandapip1. For core EIPs the original concept of Final really was running on the mainnet. Up until then the specification must be open to change – otherwise what is deployed might intentionally not match the Final spec.


Just because that was the original thought doesn’t mean that the process can’t change to support a competing idea, especially if circumstances have changed. The Ethereum mainnet is weakly subjective now, and we have stated as a goal that we want to remove as many subjective traces as possible from the EIP process!

Author: gcolvin
Date: 2023-03-16T16:46:54.213Z

I guess it doesn’t matter that much when we call it Final, because it rarely happens that the behavior of what is deployed is different than specified.  If it is, then that can be handled with an Errata

Author: sbacha
Date: 2023-03-24T06:00:02.091Z

I am 100% for splitting the repository, on the condition that the ERC repo can facilitate external links or require some code to be included i. The proposals.
The main issue with ERCs – there is not a formal way to describe the interface for contracts. Have a standard repo –– this will lead to a canonical ABI definition –– can have semantic rules around this. Can run some specific unit tests against this, etc.
Some clear principles or rules governing what basic terms/definitions are for included code, eg:
(this is an example, not an accurate representation/definition!)
Abstract ABI: a generated contract ABI interface; as described in the ABI generated artifact; is called an ABI definition. Each ABI definition has an associated ABI identifier; e.g. constant, inputs, outputs, stateMutability, payable, type, name (which may be implicit in the case of Contract).
Instead of “Final” how about: conclusive? Additionally a state that can communicate that this relevant EIP/ERC is no longer valid/useful or has been replaced would be “Moribund”

Author: gcolvin
Date: 2023-03-26T17:33:19.051Z

After years of these discussions, I remain 100% opposed to splitting the repos..

Author: sbacha
Date: 2023-04-03T08:32:37.828Z

Fwiw I think splitting the repos would have the w benefit of making package management for smart contracts more viable. If the ERC repo has some constraints, it could be much more easily adopted by developers seeing that its being supported.

Author: xinbenlv
Date: 2023-06-22T11:30:55.137Z

Cross posting this PR by @matt for more awareness
https://github.com/ethereum/EIPs/pull/7206

Author: timbeiko
Date: 2023-06-22T16:55:58.061Z

We discussed this on ACDE164 and client devs were strongly in favour. We agreed to discuss how to move this forward on the next EIPIP call.

Author: xinbenlv
Date: 2023-06-23T21:26:13.137Z

Putting here a few examples where ERC / Core EIP will benefit knowledge from each other.


ERC-4337 as consideration for create2 shadowing in driving precompile adoption Add EIP: Precompiled for secp256r1 Curve Support by ulerdogan · Pull Request #7212 · ethereum/EIPs · GitHub


ERC-2098 as inspiration for deciding design about v component in verification. https://github.com/ethereum/EIPs/pull/7212#discussion_r1240413986

Author: gcolvin
Date: 2023-07-31T23:54:05.285Z

@shemnon  We are at the end of Last Call, and as a Meta proposal I have no big problems with this – moving this EIP to Final doesn’t necessarily mean we merge Move ERCs to separate repository by lightclient · Pull Request #7206 · ethereum/EIPs · GitHub, and it lays out that proposal well.  Thanks.
I think our fundamental disagreement starts here:

For years, we’ve considered separating the repository. This would allow ERC and EIP processes to evolve more naturally due to the independence.

Although you speak of repositories and processes, the deeper issues are around people and governance.  In particular, does splitting the repositories mean splitting the Editors into separate organizations?  It’s your proposal, so I’m not asking you to change your intent.  However,

If you intend to split the Editors into two organizations you should be explicit.  This is the only change I really want to see before this goes to Final.

It is of course the organizational split that I most object to.
I think the most insightful comment on this is from @bumblefudge here.  In part:

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 … bifurcating the process might be trading ONE can of worms for TWO …

I do think there are some misunderstandings of the Pain relief work in progress that might be worth correcting. In particular, you write:

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 known governance checkpoints.

I am trying to reduce overhead by saying that the Core Developers are already a de facto working group.  And I’ve said in a few places that I’m trying to reduce the friction by getting the Editors “out of the workflow business”.  A working group itself defines it own governance and the stages of its own processes.  So I’ve proposed a separate working-group-status header to use for those governance checkpoints. (We could allow working groups to use the existing Status header instead.)
As I wrote here:

I’m proposing that once an EIP is a Draft the Core Developers will have full control – in the sense that the EIP need not meet Editorial standards again until it goes to Final, which can happen after the upgrade. And the standards for Draft should be reasonably low. That way the Editors should never be in the position of blocking an upgrade.

And I’m slightly off on not meeting Editorial standards – minimal standards on format are needed to be sure the draft renders OK on https://eips.ethereum.org.

Author: shemnon
Date: 2023-08-02T22:33:48.298Z

gcolvin:

We are at the end of Last Call, and as a Meta proposal I have no big problems with this – moving this EIP to Final doesn’t necessarily mean we merge Move ERCs to separate repository by lightclient · Pull Request #7206 · ethereum/EIPs · GitHub , and it lays out that proposal well. Thanks.


You insisted I write an EIP but I resisted on the premise that it would be meaningless and you would move the goalposts in the end.  That just happened



 gcolvin:

Although you speak of repositories and processes, the deeper issues are around people and governance. In particular, does splitting the repositories mean splitting the Editors into separate organizations? It’s your proposal, so I’m not asking you to change your intent.


It’s Tim’s and lightclient’s proposal, which I fully support.  I’m being a functionary in conforming to your process needs.
But splitting the org has always been part of the proposal.  From the top of this very thread…



 timbeiko:

TL;DR

We should fork the EIP repo to create an ERC-only one, with ERCs displayed at ercs.ethereum.org
Editors would be granfathered in both repos, free to resign on either side
The processes can evolve independently, to suit the need of EIP vs. ERC authors, and welcome CL contributors to EIPs
To avoid name collisions, EIPs get even numbers, and ERCs get odd ones.



Editors will be grandfathered in to both repos, processes can evolve independently.  Was there specific wording you want to see?  Please propose it so I can get it right in one pass.



 gcolvin:

I think the most insightful comment on this is from @bumblefudge here . In part:

But notice the subtle slide from “split the repos” to “split the editorial processes into two separate deciding bodies with different processes.”



It’s not a shift.  It’s literally in the tl;dr from the very beginning.  Separate independent processes.



 gcolvin:

And I’ve said in a few places that I’m trying to reduce the friction by getting the Editors “out of the workflow business”.


Then what do the editors do?  Seriously, what EIP work have you done outside of governance and workflow debates since January?  Editors who are not editing EIPs are not really editing.  Perhaps we need to rename them “reviewers” to make it clear the work we do need from them.

Author: gcolvin
Date: 2023-08-02T23:48:51.997Z

Moving files doesn’t change anything about how persons organize themselves.  I don’t object to moving the files.  I object to splitting up the Editors into separate organizations.   I’m leaving it to the other Editors to decide whether they want to do that.

Author: shemnon
Date: 2023-08-03T00:31:05.691Z

The original proposal was to both split org and repo.  That you are willing to accept half of it does not change the original intent of the proposal.

Author: gcolvin
Date: 2023-08-03T05:34:22.791Z

I do not question your intent, Danno.  My only ask is that you be more explicit from the start:

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

Processes can also evolve within an organization.  Your intent is to split the Editors into two independent organizations, so please say so here.  That’s all.