Call for Input: Forcibly withdraw EIP-7675

[SamWilsn]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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

[g11tech]

umm why can't we just have a new genesis meta EIP and put it in final status after a ✔️ review from key clients

similarly for previous forks, or a meta eip that says: eips activated till ...X fork where X is the the fork previous to when we started having meta EIPs (cancun?)

[SamWilsn]

umm why can't we just have a new genesis meta EIP

We totally can! Your idea being that we have multiple genesis EIPs that:

• Link to the previous genesis EIP
• List all the EIPs that have been activated since genesis

I think that would be reasonable, but I don't understand the benefit of this over listing it in the hardfork EIP.

put it in final status after a ✔️ review from key clients

This requires a definition of "key client" and I'm somewhat uncomfortable with that. Final should just mean the document is done being edited (and only customarily means deployed on the network.)