Network Upgrade Inclusion Stages
相关视频
正文
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
, and Included
.
Motivation
When planning network upgrades, EIPs go through the Considered for Inclusion
and Included
stages. However, definitions for these terms are either outdated or non-existent.
Additionally, there isn't a formalized way for the Ethereum community to signal which EIPs they'd like to see included in a network upgrade, or for implementation teams to keep track of these.
This EIP proposes definitions for each of the following stages: Proposed for Inclusion
, Considered for Inclusion
, Scheduled 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.
Context: 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 three categories in its specification section: Proposed 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
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.
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, and that, 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 removed from Considered for Inclusion
if client teams are generally against including the EIP in the network upgrade.
Scheduled for Inclusion
When client teams decide to work on an EIP as part of a network upgrade, 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 removed from Scheduled for Inclusion
if client teams are generally against including the EIP in the network upgrade.
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
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
, 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
Copyright and related rights waived via CC0.