Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call for Input: Forcibly withdraw EIP-7675 #374

Open
9 tasks done
SamWilsn opened this issue Dec 18, 2024 · 11 comments
Open
9 tasks done

Call for Input: Forcibly withdraw EIP-7675 #374

SamWilsn opened this issue Dec 18, 2024 · 11 comments

Comments

@SamWilsn
Copy link
Collaborator

SamWilsn commented Dec 18, 2024

Call for Input

Decision

Do we merge ethereum/EIPs#9154 ?

If Affirmed

EIP-7675 is forcibly moved to Withdrawn.

If Rejected

No change.

Method

Rough consensus

Deadline

January 17th, 2025

Background

EIP-7675 is a list of retroactively applied EIPs. Because this list can be appended to forever, it violates EIP-5069's scope of work:

[We don't] Track Registries: We want all proposals to eventually become immutable, but a registry will never get there if anyone can keep adding items.

Instead, I would propose that retroactively applied EIPs are listed in the next hardfork EIP (in their own section.)

Checklist

I, the opener of this Call for Input, have completed the following:

  • Filled in a descriptive title.
  • Filled in the "Decision" field.
  • Filled in the "If Affirmed" field.
  • Filled in the "If Rejected" field.
  • Filled in the "Method" field.
  • Filled in the "Deadline" field to be thirty days from creation.
  • Added any relevant background information (or removed the section.)
  • Published a notice in writing to the usual channels frequented by EIP Editors (likely Discord.)
  • Commented on this Call for Input, clearly stating my opinion (or abstention.)
@SamWilsn
Copy link
Collaborator Author

In Favour


We don't have a good process for ensuring lists/registries stay up to date, nor do we have a good process for transferring ownership of an EIP if the maintainer disappears. For those reasons, I think we should continue to avoid "list" type EIPs.

For this specific case, I think these retroactive EIPs can be listed in the next hardfork EIP.

@timbeiko
Copy link

@SamWilsn I agree that it's not ideal to have "registry" EIPs, but given this is fairly important information that's currently not tracked anywhere. If we do withdraw the Meta EIP, we should make sure to retroactively add these EIPs to the "right" hard forks as part of the same PR.

That said, I'm not sure what the correct hard fork to add these changes in would be. We agreed on AllCoreDevs recently to add non-Core EIPs to Hard Fork Meta EIPs, so we could include these in the Meta EIP for the fork at which they were accepted by ACD.

This still feel a bit wrong, as, unlike a non-consensus change that goes live sometime before the hard fork's activation, these EIPs are effectively added to the genesis rules for the network, which doesn't have an EIP defining it.

If we were to do this, what do you think it would look like in EELS? Would you add a note in both the "decision hard fork" and genesis.py?

@SamWilsn
Copy link
Collaborator Author

The neat thing about retroactive EIPs (IMO) is that it doesn't matter when they are documented, because the always apply from some point in the past. We could put EIP-2681 in Cancun's fork EIP or in Prague's and effectively it makes no difference.

In EELS we apply the change to all forks and pretend it was there forever.

@abcoathup
Copy link

In favour (As an associate editor I don't have a vote)


Retroactive EIPs should be included in specific upgrade Meta EIPs after they have been agreed.

  • Upgrades have the most attention of the community
  • Avoids maintaining registry EIPs and dealing with ownership issues

A simple option would be to move the current retroactive EIPs from EIP-7675 and include them in a Retroactively activated EIPs section in Meta EIP-7600 Pectra. In a similar section to non-consensus changing EIPs.

@timbeiko
Copy link

We could put EIP-2681 in Cancun's fork EIP or in Prague's and effectively it makes no difference.

I'd be curious to hear from client teams here, but I can imagine for some of them it may make a difference whether they are enabled from genesis or not? At the very least, there's value in having a common place where these constants are set, vs. having to search through the fork history.

@bumblefudge
Copy link

why not just ship this one informative EIP and going forward do an informative EIP for each nonfork core change? if the problem is avoiding registry risk, just call this one exhaustive for now and cut paste the format into a new informational next time?

@timbeiko
Copy link

Another solution to this is to add an upgrade field to the header of Core EIPs, corresponding to their mainnet activation upgrade. For all of these, we could just make it Genesis.

@abcoathup
Copy link

add an upgrade field to the header of Core EIPs

I really like this as a solution. Easy to parse to create lists of EIPs and when they were activated.

@SamWilsn
Copy link
Collaborator Author

SamWilsn commented Dec 21, 2024

Problem with this approach is that either the individual EIP author can pick whatever hardfork they want, or editors have to pick it.

The advantage to what we have now is that it's permissionless to create a hardfork meta and editors don't need to decide anything. Core devs choose whatever hardfork EIP they want to follow (aka Tim's)

@g11tech
Copy link

g11tech commented Dec 23, 2024

this functionality can just be provided by the web rendering without need of anyone updating it

same goes for other statuses (in review, rejected etc)

@poojaranjan
Copy link
Member

poojaranjan commented Dec 23, 2024

to add an upgrade field to the header of Core EIPs

Yes, it is possible with rendering and is already available at EIPsInsight
eg EIP-140, EIP-1559, EIP-6110.

The website features a chart displaying data for each network upgrade, along with a CSV download option listing all EIPs included in an upgrade. This can be particularly useful for client developers. However, the chart currently includes data only for network upgrades. Core EIPs activated asynchronously were not officially part of any network upgrade and are excluded from the list. I believe adding them should not be an issue.

network_upgrades.csv

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants