⚠️ Review Meta

EIP-7723: Network Upgrade Inclusion Stages

Overview of the various stages Core EIPs go through before their activation in network upgrades.

Authors	Tim Beiko (@timbeiko)
Created	2024-06-12

This EIP is in the process of being peer-reviewed. If you are interested in this EIP, please participate using this discussion link.

Abstract
Motivation
Specification
Rationale
Backwards Compatibility
Security Considerations
Copyright

Abstract

Define the stages that Core EIPs go through in the process of planning network upgrades: Proposed for Inclusion, Considered for Inclusion, Scheduled for Inclusion, Declined for Inclusion and Included.

Motivation

This EIP proposes definitions for the various stages EIPs go through when planning network upgrades. Specifically, these are: Proposed for Inclusion, Considered for Inclusion, Scheduled for Inclusion, Declined for Inclusion and Included. It also provides context and guidelines around when and how EIPs should be moved from one stage to the next.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

All EIP statuses defined in this EIP only apply within the context of a single network upgrade. In other words, EIPs are Proposed, Considered, Declined and/or Scheduled in the context of a specific network upgrade. While an EIP cannot be Included in two network upgrades, an EIP being Declined for Inclusion in a previous upgrade does not prevent it from being Proposed, Considered, Declined or Scheduled for inclusion in any future upgrade.

Upgrade Meta EIPs

When planning a network upgrade, anyone MAY draft an Upgrade Meta EIP to list EIPs in various stages of consideration. This Meta EIP SHOULD include four categories in its specification section: Proposed for Inclusion, Declined for Inclusion, Considered for Inclusion and Scheduled for Inclusion. Even if a category is empty, it SHOULD be included in the initial draft for clarity.

When the Upgrade Meta EIP is moved to Last Call, the Proposed for Inclusion, Declined for Inclusion and Considered for Inclusion lists SHOULD be removed, leaving only Scheduled for Inclusion.

Before the Upgrade Meta EIP is moved to Final, the Scheduled for Inclusion stage MUST be renamed to Included and contain only EIPs that were activated in the upgrade.

Upgrade Devnets

When preparing a network upgrade, client developers typically implement EIPs first on an ephemeral test network (upgrade devnet) to verify client interoperability, before deploying to long-lived test networks. These upgrade devnets follow a naming convention of $upgradeName-devnet-$version (e.g. pectra-devnet-0 for the first upgrade devnet of the Pectra network upgrade, dencun-devnet-1 for the second upgrade devnet of the Dencun update, etc).

Since client developers’ ability to include EIPs in a network upgrade is constrained by what can be implemented and tested in these upgrade devnets, the Considered for Inclusion and Scheduled for Inclusion sections below propose aligning these statuses with EIPs’ implementation status in upgrade devnets.

Proposed for Inclusion

To formally propose the inclusion of a Core EIP in a network upgrade, someone MUST open a pull request against the Upgrade Meta EIP to add the EIP in the Proposed for Inclusion section. Reasonable pull requests SHOULD be merged in a timely fashion by the Upgrade Meta EIP author.

At this stage, implementation teams SHOULD review the EIP in the context of including it in the next upgrade.

Note that EIPs must be Proposed for Inclusion for each network upgrade. In other words, proposals do not “carry over” to the next upgrade if an EIP is not included in the one it was first proposed for.

Considered for Inclusion

Once client developers have reviewed an EIP which was Proposed for Inclusion, they MAY move it to the Considered for Inclusion stage. Once a decision is made by client teams to move an EIP to Considered for Inclusion, the Upgrade Meta EIP SHOULD be updated to reflect this.

Considered for Inclusion signals that client developers are generally positive towards the EIP. The EIP SHOULD be implemented in future Upgrade Devnets. Assuming it meets all the requirements for mainnet deployment it MAY be included in the network upgrade. This stage is similar to “concept ACK” in other open source projects, and is not sufficient to result in deployment to mainnet. An EIP MAY be moved from Considered for Inclusion to Declined for Inclusion if client teams are generally against including the EIP in the network upgrade.

Declined for Inclusion

At any time during the network upgrade planning process, client developers MAY move EIPs from any other stage to the Declined for Inclusion stage if client teams are generally against including the EIP in the network upgrade. Once a decision is made by client teams to move an EIP to Declined for Inclusion, the Upgrade Meta EIP SHOULD be updated to reflect this.

Declined for Inclusion signals that client developers wish to exclude the EIP from the current network upgrade and stop discussing its potential inclusion or implementation status in relation to this upgrade. An EIP which was Declined for Inclusion in a particular upgrade MAY still be Proposed for Inclusion in a subsequent upgrade. In exceptional circumstances, client developers MAY choose to move an EIP from Declined for Inclusion to Considered for Inclusion or Scheduled for Inclusion.

Scheduled for Inclusion

When client teams agree to implement an EIP in the next Upgrade Devnet, the EIP SHOULD move to the Scheduled for Inclusion stage, and the Upgrade Meta EIP SHOULD be updated to reflect this.

Scheduled for Inclusion signals that implementation and testing work are underway, and that, assuming no issues arise as part of this process, the EIP SHOULD be included in the network upgrade. An EIP MAY be moved from Scheduled for Inclusion to Declined for Inclusion if client teams are generally against including the EIP in the network upgrade. An EIP MAY also be moved from Scheduled for Inclusion to Considered for Inclusion if client teams are generally in favor of including the EIP in the network upgrade but cannot commit to including it in the next Upgrade Devnet.

Included

Once a network upgrade has been activated, all EIPs that were part of the upgrade MUST be moved to Included in the Upgrade Meta EIP, and the Proposed for Inclusion, Considered for Inclusion, Declined for Inclusion and Scheduled for Inclusion lists MUST be removed from the Meta EIP.

Included signals that the EIPs have been activated as part of the network upgrade.

Rationale

Formalizing the Proposed for Inclusion, Considered for Inclusion, Scheduled for Inclusion, Declined for Inclusion and Included stages provides better legibility to both Ethereum protocol maintainers and the community at large.

The specification tries to minimize steps which MUST be followed to align with Ethereum’s “rough consensus” governance model.

Assuming it is adopted, the process outlined in this EIP should be used for at least one full network upgrade cycle before moving to Last Call and at least two full network upgrades cycles before moving to Final. This way, the EIP can be updated to reflect changes made to the process over time.

Backwards Compatibility

This EIP does not directly change the Ethereum protocol. It extends and formalizes the current process of planning network upgrades.

Security Considerations

None.

Copyright

Citation

Please cite this document as:

Tim Beiko (@timbeiko), "EIP-7723: Network Upgrade Inclusion Stages [DRAFT]," Ethereum Improvement Proposals, no. 7723, June 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7723.