Proposal: Forking ERCs from EIPs Repository

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.

1 Like

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

2 Likes

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.

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.

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.

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.

2 Likes

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.

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

And a full narrated YouTube explaining it: New EIPs homepage PR 6483 - YouTube

Don’t have time to click that button? Here is a gif, you’re already watching it…

out

3 Likes

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.

1 Like

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.

2 Likes

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.

1 Like

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.

3 Likes

Come to a decision.

Fork it!

1 Like

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!

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

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”

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

1 Like

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.

2 Likes

Cross posting this PR by @matt for more awareness

2 Likes

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.

2 Likes

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

  1. 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

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

3 Likes

@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.