Rethink EIP numbering
djrtwo opened this issue · 23 comments
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:
- From the latest EIP assigned, start assigning purely sequentially (+1) from there
- (controversial) Go back and fill in all of the gaps leading up to the latest EIP assigned. This hurts the meaningfulness of the time relationship between EIPs but is a nice use of a scarce resource
EDIT: Including ERCs, there are only 611 EIPs (thanks @timbeiko). This represents a 10x waste factor in the numbering system!
+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.
I am not super familiar with the algorithm used in the bot, @Pandapip1 may fill in.
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).
Funds raised should be used to fund EIP editing.
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
They could be sold as NFTs ENS style. AAA.erc.ethereum.eth and BBB.eip.ethereum.eth
Recent examples where people wanted to claim a number and ideally would have had the opportunity to purchase it for the meme value:
- @timbeiko had wanted to claim 6666: #6953 (comment)
- @owocki & @zscole wanted to claim 6969: #6969 (comment)
- I wanted to claim 4888: #4888 (review)
+1 for going sequential, after a number that is recognizable.
-1 on going back and filling gaps. It tells a history that's worth preserving.
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 EIPS dir in the EIPs repo only has 614 files; we don't actually use that many EIP numbers.
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.
We should go sequential from 10,000 and sell unused numbers below 10,000 (ideally with a Harberger tax to avoid squatting). Funds raised should be used to fund EIP editing.
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.
Preferably we can go sequential starting from 9000 instead of 10,000
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 eip-review-bot has the kinks worked out. Why should we wait for a special number?
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.
@SamWilsn Why should we wait for a special number?
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] Starting at 10,000 and offering a mechanism to get lower numbers reduces the desirability of special numbers above 10,000. Otherwise there needs to be a process where EIP editors can manually assign a number, but using sequential numbers means there are no spare numbers to assign to.
@timbeiko 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.
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:
When the ZIP draft is complete, the ZIP Editors will assign the ZIP a number (if that has not already been done) and one or more Categories, and merge the pull request to the ZIPs git repository. The ZIP Editors will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or not in keeping with the Zcash philosophy.
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.
EIPs are going sequential as soon as eip-review-bot has the kinks worked out. Why should we wait for a special number?
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.
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.
Worry not. eip-review-bot will assign you a non-numeric EIP number in the meantime!
Worry not. eip-review-bot will assign you a non-numeric EIP number in the meantime!
What do those look like?
I can change the logic to be sequential.
The random non-sequential nature should prevent most number gaming/sniping/lunging.
What do those look like?
eip: draft-eip_title_with_underscores
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 eip-fee-burn or eip-proto-danksharding seem way easier to remember and reason about than numerics.
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?
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
(1) -1. The numbering system now shows the PR number as well as the sequence. But, if changed to a purely sequential system, it would deliver less information. I agree that knowing the PR numbers would not deliver much information to devs and users. Still, as a whole, it shows and proves that the improvements originated from the community and flexes open-source software CHADness to Ethereum haters.
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.