Proposal to have "Considered for Inclusion" reset after each upgrade

[timbeiko]

As part of separating the EIP process from the network upgrade process, a set of stages were created to track progress of EIPs towards mainnet, they are:

• Considered for Inclusion (CFI)
• "Devnets" (i.e. YOLO, Aleut, etc.)
• Testnets
• Mainnet

CFI is intended for core developers to signal support for an idea before it is fully fleshed out. Given how much things change between network upgrades, I propose that this status resets between upgrades (i.e. an EIP which was CFI for Berlin would not automatically be CFI for London). We already implicitly do this, but I wanted to ask before going ahead and archiving past CFI EIPs.

The CFI list is tracked here. The pre-London/Shanghai list includes the following EIPs: 663, 2711 (likely superseded by 3074), 2398, 2046, 1985, 1380. EIP-2537 was also CFI pre-Berlin, but it had enough interest for someone to propose it for London. IMO that should be the minimum bar we expect to move something over to CFI again for the next upgrade.

Doing this will help keep the eth1-specs repo clean and not have stagnant EIPs pile up in the CFI column.

[holgerd77]

CFI is intended for core developers to signal support for an idea before it is fully fleshed out. Given how much things change between network upgrades, I propose that this status resets between upgrades (i.e. an EIP which was CFI for Berlin would not automatically be CFI for London). We already implicitly do this, but I wanted to ask before going ahead and archiving past CFI EIPs.

Yes, this makes a lot of sense, I would support this.

The CFI list is tracked here.

Not sure if it is just me, but I am personally not getting along so well with these GitHub Projects overviews and I have some tendency to overlook content which is organized by this tool. Just as some low-level feedback, if there are more voices like this one might want to change here.

[timbeiko]

Not sure if it is just me, but I am personally not getting along so well with these GitHub Projects overviews and I have some tendency to overlook content which is organized by this tool. Just as some low-level feedback, if there are more voices like this one might want to change here.

I kind of agree. What would you prefer to see? A .md file?

[holgerd77]

I kind of agree. What would you prefer to see? A .md file?

Yes. Also a lot more transparent regarding the work process with PRs tracking the changes and allow for discussion.

Yes, I am just live-thinking a bit, I think especially this last point is pretty important. I am just realizing that I would trust this list a lot more if it wouldn't be just items moved around at some PIT from someone with admin permissions but instead has some transparent change process (meant as structural criticism being totally independent from the persons actually doing it). If it is in the repo than it will likely also become more of an official point of reference leaving the character of an internal planning tool (not sure but if this planning site actually is made more for your internal tracking to not loose oversight. In that case you might also want to keep as-is).

If you want to change this it might also become a good habit to just do a PR after each ACD wrapping up and integrate the things discussed. Think this would make things super transparent and beautiful, if one can always trace and reference the condensed accepted changes on CFI from a call.

Maybe you want to ask on next ACD if this format change makes sense since the topic is already on the agenda?

Just had a look at the current content structure, I think it would have some value to keep this generally on one page (first thought if a) a new directory cfi would make sense or b) if this should be organized by HF as well with london-cfi or something but discarded both ideas on second thought).

So I would have a first tendency to something simple like:

---

/network-upgrades/considered-for-inclusion.md

Some short intro text ("This is the currently considered list of EIPs..., see also CFI process [link]")

Targeted Hardfork: London (this is important to have the context on future linking of old change PRs)

Considered for Inclusion (CFI)

EIP	Description	Author(s)	Proposal	CFI Decision	Date
EIP-3403	Partial removal of refunds	Vitalik Buterin, Martin Holst Swende	#277	ACD 108	2021-03-19

(not sure if the "Authors" list is necessary here)

"Devnets" (i.e. YOLO, Aleut, etc.)

Testnets

Mainnet

---

And maybe it's worth to have a separate archive file where old CFI lists are moved once a HF has been executed:

/network-upgrades/considered-for-inclusion-archive.md

Some short intro text

Berlin

• List with old Berlin CFI EIP links

---

Does this make sense?

Just as some first inspiration for a possible structure. 😄

[holgerd77]

Also //cc-ing here @poojaranjan and @axic for notice and eventual feedback

[timbeiko]

@holgerd77 thanks for the comment!

Generally agreed with a .md over the Github project. Project was there before I took over, but I can move it to a .md for London. A few thoughts:

1. Berlin: I don't think we should do anything here. It's already done, let's iterate going forward vs. archive history.
2. Timing: I can own doing a PR after AllCoreDevs, but the notes won't be up yet. I can link to the call agenda, if that works.
3. "Proposal": One thing I want to avoid is EIP champions to have to do two proposals: one for CFI and one for upgrade inclusion. So I think asking of champions to propose for upgrade inclusion, and CFI being the first necessary, but not sufficient, step for that, makes sense.
4. Organization: I think a folder per upgrade makes sense, which has links to the CFI list and intergration testnets, vs. our current structure of separating upgrades vs. integration testnets vs. (soon) CFI. In other words, I'd like to see this:

eth1-specs/network-upgrades/berlin
.../berlin/berlin.md # spec
.../berlin/YOLOv2.md # client integration testnet
.../berlin/YOLOv3.md # client integration testnet
eth1-specs/network-upgrades/london
.../london/london.md #spec
.../london/cfi.md #CFI list 
.../london/aleut.md # client integration testnet 

[timbeiko]

Also, for clarity, when we discuss this on AllCoreDevs, we need to get confirmation that the following EIPs are CFI for London:

• EIP-3074 Proposal to include EIP-3074 in London #260
• EIP-2537 BLS-12381 London Inclusion #269
• EIP-2677 Proposal to include EIP 2677 ( Limit size of initcode) in London #271
• EIP-3403 EIP-3403 - Partial Removal of Refunds #277

Alongside the two that are already included (1559 & 3238).

We should also agree on the status for EIP-3198 (BASE FEE opcode): we agreed to put it in Aleut, but it was not clear what the associated status would be.

[shanelightowler]

What would be process for getting an EIP that has had its CFI status cleared (after an upgrade) back into CFI status? Would that be the responsibility of the EIP champion, or is there another (possibly collective/ACD?) role that gathers EIPs from those available to be restored to CFI status prior to an upgrade? Just wondering as it kind of implies that in some cases an EIP champion may be required to re-state the case for the EIP on multiple occasions. I personally think that would be a good thing as the discussion around inclusion should always be contextual, and the context changes over time - i.e. what is needed for the overall roadmap at that point in time. This may help to avoid scenarios like 2315 for Berlin.

[timbeiko]

@shanelightowler yes, I think the champion should re-state that they want their EIP considered for inclusion again for a new upgrade. The champion could change from upgrade to upgrade, but I don't want "AllCoreDevs" to own this because if the EIP does not have at least a strong champion, that's a very strong signal it may not be valuable enough.

It's not a huge ask to re-state this, and it already happened naturally for EIP-2537, see: #269

[timbeiko]

Opened a separate issue to discuss the markdown vs. Github project stuff in the eth1-specs repo: ethereum/execution-specs#23

[timbeiko]

We agreed on ACD111 to do this 🎉 ! I will close this issue and update the CFI project board.