Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-7723: CFI/SFI & Devnets #9126

Merged
merged 5 commits into from
Dec 18, 2024
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions EIPS/eip-7723.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,27 +23,33 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S

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.

### Context: Upgrade Meta EIPs
### 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](#considered-for-inclusion) and [Scheduled for Inclusion](#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.
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 moved from `Considered for Inclusion` to `Declined for Inclusion` if client teams are generally against including the EIP in the network upgrade.
`Considered for Inclusion` signals that client developers are generally positive towards the EIP. The EIP **SHOULD** be included 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.
timbeiko marked this conversation as resolved.
Show resolved Hide resolved

### Declined for Inclusion

Expand All @@ -53,9 +59,9 @@ At any time during the network upgrade planning process, client developers **MAY

### 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.
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.
`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

Expand Down
Loading