EIPs & Network Upgrade Process Requirements

[timbeiko]

The discussion around EIP-2315 and Berlin (see #263) has raised questions about updating EIP statuses as we move EIPs through the network upgrade process.

We want more community awareness about EIPs as they get closer to being included in an upgrade, and subsequently deployed on testnets & mainnet so that any issues are raised early in the process.

Berlin's EIPs currently range from being in DRAFT to REVIEW and LAST CALL, despite blocks having been set for the upgrade.

One proposal on discord was to only allow EIPs to be brought up on AllCoreDevs after they have the REVIEW status. Historically, we've also moved EIPs to LAST CALL when blocks were set for upgrades. We could potentially move this earlier in the process (ex: when an EIP is decided to be included in an upgrade). Other suggestions are welcome!

[axic]

Prior to the reorganisation, EIP-1 said this:

Accepted (Core EIPs only) -- This status signals that material changes are unlikely and Ethereum client developers should consider this EIP for inclusion. Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the EIP process.

The wording above ("This status signals that material changes are unlikely") is similar to that of review and last call of today's EIP-1:

Review - An EIP Author marks an EIP as ready for and requesting Peer Review.

Last Call - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (review-period-end), typically 14 days later.

While it is not written down anymore (where should it be written done in the first place?), one would assume that Review or Last Call would be an appropriate status for something considered for a hard fork.

[poojaranjan]

This is unfortunate that we ended up in this distress situation. I understand this is a fairly new process and we need to encourage authors to follow the process as documented in Shedding light on the Ethereum Network Upgrade Process. I've always been advocating changing the status to Review once approved by the ACD and also mentioned it in the core devs meetings. I make sure to specifically talk about the "Status" on the PEEPanEIP but I think, we've to be more aggressive on creating awareness about the new process.

I hope we all make an effort to follow the process and avoid landing in such a situation in the future.

[poojaranjan]

The above model was agreed upon by the EIPIP group in Q4 2020 and shared in the ACD meeting 100.

Berlin is the first upgrade where we're following the process. After giving some more thoughts, I'd like to propose further edits to EIP statuses as below:

I want to propose this because

• A proposal is supposed to be in the Last call for 14 days.
• After Final, there can't be any spec change so let's wait till it is deployed on the mainnet. (I was convinced by Micah)

[timbeiko]

Following up here, this feels better suited for EIPIP than for AllCoreDevs, at least until we agree on a proposal. @axic @poojaranjan would you be fine if we bring this up then?

My 2c:

• Whenever the final list of EIPs is set for a fork, we move all the EIPs in it to Last Call
• The "Testing Green Light" phase does not represent anything that actually happens. Testing is a gradual, not binary process. I think we should rename that to "Network Upgrade Spec Final", as per my point above.

[poojaranjan]

Agreed, this is more of a process discussion. Added to the EIPIP Meeting 30 Agenda.

We can share the agreement in the upcoming ACD meeting.

[poojaranjan]

Updated the process based on the agreement on EIPIP meeting 30

[holgerd77]

@poojaranjan sorry, I've missed somewhat this whole CFI discussion and definition process and just in the process of catching up a bit 😄 , short question: where are actually the artifacts of these EIPIP discussions and meetups, so e.g. this diagram from above respectively a general description of the process and the phases, all that stuff? 🤔

I've looked into the https://github.com/ethereum-cat-herders/EIPIP repo, but I am just finding the call notes there. Or are you just still early in the process and haven't published something "officially" and things are still in discussion or in flow?

[poojaranjan]

@holgerd77

Consider For Inclusion (CFI) is a new term for already existing Eligible for Inclusion (EFI) since Istanbul. (Ref: EIP-2378)

From the EIPIP meeting, the original proposal of Selection of EIPs for network upgrade was updated and proposed CFI to be in two steps - applied, approved.

Consider for Inclusion (CFI) applied is the first stage to signal that a proposal is aspiring for the upcoming network upgrade.

CFI approved: This lists EIPs that obtain rough consensus by clients, and with the submission of well-formed PR, it will be considered by the Core Developers. Clients may independently start implementing the proposals at their convenience. This can be tracked in the Eth1.0 spec project board.

Splitting EIP & Network upgrade process was a long discussion. You may catch up on some last discussion here that led to the current process, which is open to continuous improvement.

Having said that, the network upgrade process is documented in a blog - Shedding light on the Ethereum Network Upgrade Process. It has a simple definition for the terms used in the above diagrams.

Note: The blog will be updated after the ACD meeting if there is no objection to the changes agreed in the last EIPIP meeting.

(I'll be happy to take more questions related to the EIP standardization process and Network upgrade process if that helps. )

[holgerd77]

@poojaranjan ah, I honestly thing a blog is not the right format for this. Respectively - otherwise framed - it's great that you are doing this blog to educate on people but this definitely also needs some written down specification. A blog post just won't work as a solid and stable reference with a specification one can get orientation from and where PRs can be targeted against to improve on the specs.

Sorry for this right-out criticism - I am generally more cautious on stuff like this - but when thinking a bit more about this now I get very much convinced that this is THE blocker hindering the EIPIP process to fully enfold its potential. For me as a dev this just doesn't feel "existing" in such a floating format, compared to the specs written down in e.g. the eth1.0-specs repo or also the EIP-1 specification.

[poojaranjan]

@holgerd77
Appreciate your feedback. You're correct, that a blog isn't the best place to document such a process. It is a better candidate for a Meta EIP (Process EIP) rather than a blog.

The process was proposed and being iterated as a Meta EIP.

While the decoupling of the EIP standardization & Network upgrade process was taking place, another decision was taken - to keep everything related to the network upgrade out of the EIP GitHub repo. It was then decided to add a part of the proposal to the readme section of Eth1.0 spec and details to be published in form of a blog. And thus the Pull Request documenting the process as a Meta EIP could never be merged.

From a developers' point of view, I agree that having more information in GitHub would be helpful. I think it's a good suggestion to add more info to the Readme section.

[holgerd77]

@poojaranjan thanks for your openness here! 🙂

[timbeiko]

@poojaranjan @holgerd77 what do you think about moving a large part of that PR to the eth1-specs repo directly? Happy to take a stab at it.

[holgerd77]

@timbeiko I would be a big fan of that! 👍

@poojaranjan would you think this would be a good place to be?

[poojaranjan]

Sure! I would love to see it at a place with high visibility :)
Thanks, @timbeiko!

[timbeiko]

Closing this given that ethereum/execution-specs#24 was merged and ethereum/execution-specs#23 was opened.