Rethink EIP numbering #6990
Comments
|
+1 on (1), weak -1 on (2), for the reason mentioned. It's nice to be able to tell that EIP-1153 is older than EIP-4844. That said, I could see doing (2) as part of a larger change, e.g. splitting out the ERCs & EIPs repositories and having one of the two "backfill" while the other one continues incrementing. For reference, as of today there are only ~600 EIPs, including ERCs, and the split seems to be roughly even between both categories. |
|
We've discussed this in multiple EIPIP meetings and are very close to automating number assignments with a bot. But, my +1 to option (1). |
|
We should go sequential from 10,000 and sell unused numbers below 10,000 (ideally with a Harberger tax to avoid squatting). Authors can always have a free sequential number (with less meme value and hence less need to attempt number sniping/gaming or even lunging) or pay for a lower number. This has been discussed previously: #5082 Recent examples where people wanted to claim a number and ideally would have had the opportunity to purchase it for the meme value:
|
|
+1 for going sequential, after a number that is recognizable. Preferably we can go sequential starting from 9000 instead of 10,000, to get some more 4 digit EIPs before we enter 5-digit territory. Note that the That range of a 1000 4-digit numbers is precious, and can last a few years, at which point we might even start a different process (e.g. EL/CL spec approach), and use the 10,000+ range. And yes, then we can say it's over 9000, easy to remember the new type of EIP numbering. |
|
I asked on EIPIP 29 (two years ago) to go sequential so obviously a big +1 from me. We're actually approaching that reality finally (or close to it) with a change in the review bot to automatically assign the EIP number, as Pooja said. @Pandapip1 has implemented the logic here. It was updated last week I think, but it had an issue so we disabled it until it is fixed. Should be able to try it again soon. Strongly disagree on back filling gaps. The number -> time relation is valuable. Also, development won't grind to a halt with an extra digit in proposals (will eventually happen anyways!). Also strongly against selling EIP numbers. |
I think this is a whole other can of worms 😅 If we are to consider this, then IMO we'd want a much broader community consensus than just EIP editors, as it feels like auctioning off a "public" resource for "private" gain.
Not sure we should waste another 2000 numbers (that's like 20 years of EIPs!), but I'm happy if we decide to start with a small bump to signal "as of X, EIPs go up sequentially". Something like 7000 or 7500 seems reasonable? |
|
EIPs are going sequential as soon as |
|
Oh, I'm fine not waiting! I'm saying that if we wait, or want to artificially add a minimum to highlight the new model, I wouldn't make it a large gap. |
Some EIP/ERC authors want special numbers and may game, snipe and lunge to get them. Automatic assignment will likely be abused so that some authors get the special number they want. [UPDATE checking the code for the automatic assignment, it adds a random number so number gaming is much harder, so less need for a large gap, could just start at 7000]
I want to see high quality EIP/ERCs via a fast, smooth, relatively pain free process. Funds could go to EF, Protocol Guild or some other public body with a mission to fund further improvements to the EIP/ERC process and EIP/ERC editing long term. I would be against any perception of private gains of public goods. |
|
Quick historical note that may be important. Years ago (sometime between 2017-2019) there were some bots spamming Ethereum repos with PRs and issues, which would cause the numbers to greatly rise. GitHub did stop the bots within a few days, and removed the spammed PRs/Issues, but I cannot recall if they were able to fix the numbering of PRs/Issues that was incremented or not. Therefore, there is a chance that spam attack has affected the numbering. Lastly, look up how Zcash does their ZIP numbering. I forgot, but I think it was neat. I am getting called to dinner by Lilit so I don't have time to look. |
|
Maybe we can also compare the Nostr Protocol‘s NIPs with it. They tried to have a sequential numbering from the begining, but inevitable race conditions or conflicts kept that from happening. So the existing PR-based numbering system is actually not that bad, the chronological relationship is partially preserved. |
|
From ZCash:
So, ZIPs only get a (manually assigned) number when they're merged. This is the same system that Python's PEPs use. A problem with this is that sometimes EIPs aren't merged for a long time but people already want to refer to them by some identifier. |
They aren't exactly going sequential. In the meantime, to avoid concurrency issues, it will be 'the top EIP number + a random number from 1 to 3', which is already far more dense. Once I can make sure that there won't be any concurrency issues, I can change the logic to be sequential.
Worry not. |
What do those look like? |
The random non-sequential nature should prevent most number gaming/sniping/lunging. |
|
|
I think being sequential starting from 9000 is pretty cool, so support @protolambda here. On a side note, numeric EIPs seem meh overall. How are users supposed to memorize that 1559 is fee burn and 4844 is kzg in one of many implementations? Titles like |
Disagree 😄! Users don't need to care about numbers: they can call it fee burn or danksharding. For protocol contributors, having the numbers helps be more succinct in communication, and put up several different proposals for a same feature, like was done for Withdrawals or SELFDESTRUCT removal. In these cases, using words may lead to more confusions than numbers. |
|
We need to be able to assign EIP/ERC numbers faster, as that is how EIP/ERCs are referenced externally in the core dev meetings, and in the wider community. Auto-assigning a non-numeric draft identifier (which can change as the title changes) at time of merging the PR delays the time until a numeric number is assigned making the EIP process worse. Ideally a number would assigned as early as possible. This could be a manual trigger such as adding a GitHub label before a PR is merged. |
|
(2) is better but there will be some legacy confusion until it is widely known that the "EIP number to GitHub PR number" correspondence no longer holds I think this change is desperately needed, (1) seems fine if that the best we can all agree to, (2) is better but if its a reach then let's just do (1) we can always do (1) now and then revisit (2) down the road (when we run out of numbers via method (1)) |
|
(2) -1 because it would lose the sequential attribute |
|
On topic - i think we should have an EIP that EIPs should be referred to by Number + Title. I'm a security researcher and constantly have to be looking up eips |
|
Per EIPIP meeting 85, we're going to track and assign number sequentially starting from 7500, unrelated to PR number. |
|
Just to confirm — EIP numbers are manually assigned by editors now? |
EIP/RIP/ERC numbers are manually assigned by editors and associates. I check most weekdays. |
Proposed Change
EIPs numbers are meaninglessly sparse due to the numbering system being based on github PR number (which also increases when issues are open).
We're quickly coming to EIP 10k and have far fewer than 10k EIPs.
This sparsity makes it less clear the lime relationship amongst EIPs and the colloquial use calling EIPs by their number is going to become more and more cumbersome as EIP numbers lengthen.
This is also something of a (not critical) security flaw. Someone could easily open and close thousands of issues in this repo to push EIP numbering even farther.
I recommend one of two options:
EDIT: Including ERCs, there are only 611 EIPs (thanks @timbeiko). This represents a 10x waste factor in the numbering system!
The text was updated successfully, but these errors were encountered: