EIP-7723: Network Upgrade Inclusion Stages

EIPs
1

Discussion for Add EIP: Network Upgrade Inclusion Stages by timbeiko · Pull Request #8662 · ethereum/EIPs · GitHub

1 Like
2

client developers

Client developers isn’t a defined term. (I’m not a core dev :smile:)

There is a mix of client developers, client teams and implementation teams. We should standardize on a single term e.g. client team, so when decision making is referred to client teams refers to multiple teams.

Proposed for Inclusion

The pull request SHOULD be merged in a timely fashion by the Upgrade Meta EIP author.

There is no explicit gate keeping mentioned. To avoid spam proposals we should add something which allows the Upgrade Meta EIP author to not merge unreasonable EIP proposals. e.g. “Reasonable pull requests SHOULD be merged in a timely fashion…”
Otherwise the Upgrade Meta EIP could have lots of spam such as changing the gas token to the latest meme token.

We may want to have multiple Upgrade Meta EIP authors to make this a quick process. to get PFId, but the flip side is some gate keeping is required.

Considered for Inclusion

Scheduled for Inclusion

I thought the proposed intent of the new CFI status was that a single client team could make an EIP CFId but rough consensus was required for SFI.

I assume intentionally the how (rough consensus) and where (All Core Devs or async in a public forum) of the decision making process isn’t specified in this EIP.

There should be a path to remove an EIP from CFI & SFI.
“An EIP MAY be removed from Considered for Inclusion if client teams are generally against including the EIP in the network upgrade.”

“An EIP MAY be removed from Scheduled for Inclusion if client teams decide to no longer work on an EIP as part of the network upgrade.”

2 Likes
3

Thanks for the feedback!

I’ve gone back and forth on single vs. multiple terms here, and opted for multiple to highlight that there isn’t really a single “body” involved. Client developers includes ppl who aren’t necessarily part of the core client team, and “implementation teams” includes things like testing/devops/etc.

To avoid spam proposals we should add something which allows the Upgrade Meta EIP author to not merge unreasonable EIP proposals. e.g. “Reasonable pull requests SHOULD be merged in a timely fashion…”

Good point. Will update!

We didn’t explicitly agree to that yet, so I’d rather have the EIP be “vague but true” than “precise but false” :smile: Will update if that changes.

There should be a path to remove an EIP from CFI & SFI.

Good point. I’ll also make it more explicit that this happens by default at each upgrade.

2 Likes
4

@timbeiko

Scheduled for Inclusion

When client developers decide to work on an EIP as part of a network upgrade,

Minor quibble. Using the term client developers as the gate for SFI implies that only 2 client developers (potentially independent) are required to SFI an EIP. So an EIP could be forced in, but there is protection against this as there is now a removal path that the EIP could be removed if client teams are generally against.

Otherwise LGTM.

1 Like
5

Copying over feedback by @dapplion on the PR:

I am not sure we need 3 states. Status CFI and SFI sound confusing. If an EIP is CFI should clients implement it already or not? If not, what’s the point of this status? Also, historically clients have implemented EIPs at different times depending on their priorities, regardless of overall consensus.

I assume all EIPs in existence are meant to be included eventually, so all EIPs are automatically Proposed for Inclusion. Following the proposed work-flow of doing PRs against the meta-EIP, the existence of this PR already shows intent for the EIP to be scheduled.

Why not have a single list: Scheduled for Inclusion? Consider the following flow:

  • EIP is drafted
  • EIP champion opens PR to the meta-EIP (= shows intent to be scheduled)
  • Client developers, community members, and affected stakeholders can signal positive intent on the PR / forum
  • Once rough consensus forms for inclusion, the PR is merged. At this point the EIP is expected to be implemented by clients

We already have 3 “statuses”: people do propose the EIPs (e.g. here), and we use CFI & Included in Meta EIPs. The goal of this EIP is to make the first “implicit” status explicit, and have the nomenclature reflect that it is possible for Included EIPs to be removed from forks before they ship.

If an EIP is CFI should clients implement it already or not? If not, what’s the point of this status?

Historically, CFI meant some clients started implementations but it was not mandatory for all teams to do so (which is what happens at Included). The point of the status is to highlight which of the many proposed EIPs will possibly end up in the devnets/fork. The original intent was to mirror Concept ACK in Bitcoin.

I assume all EIPs in existence are meant to be included eventually, so all EIPs are automatically Proposed for Inclusion.

I don’t think this is the case. First, in practice, most EIPs are not included (nor should they be). Second, PFI (and CFI/SFI) is a per-fork signal. Even if an EIP is to eventually be included, there’s value in signalling that it is proposed (by the champion) and considered (by client teams) for a specific fork.

Why not have a single list: Scheduled for Inclusion?

A couple reasons:

  • We want to discriminate between “proposals by the community” (PFI) and “things client teams want to implement” (CFI+SFI)
  • I want to avoid Github being a load-bearing part of Ethereum’s governance process. It’s fine to have code there because you can easily migrate it elsewhere, but using Github-native artifacts like PRs/Issues for governance carries heavy platform risk. If the PR itself is the “PFI signal”, then the .md file on its own doesn’t store the list of community proposals.
1 Like
6

good point! changed that to “teams”

2 Likes
7

That’s a very strong argument. I agree that my suggestions rely excessively on Github artifacts which could disappear.

  • We want to discriminate between “proposals by the community” (PFI) and “things client teams want to implement” (CFI+SFI)

I see the argument to have a per-fork signal of inclusion (PFI). You are right that some EIPs exist before they are ready to be included. However, I’m not sold on the need to have the two distinct lists (CFI+SFI). Having to maintain the two lists sounds like it would incur additional governance cost.

1 Like
8

But we already have two lists: CFI and Included :smile: ! So, I don’t think it would be much different than what we have today, aside from PFI.

1 Like
9

What’s missing from the way we currently categorize EIPs is a way to differentiate between a weaker commitment to explore and hone a feature that we like vs a strong commitment that a feature will be landed.

I’ve seen that CFI is currently being used as both CFI and SFI and that leads to confusion and a hesitancy to CFI EIPs that are merely being considered. The benefit of CFI + SFI is that it practically relaxes the requirements for EIPs to be CFI’d by adding this missing “stronger” CFI (SFI).

To take a chapter out of the javascript process (The TC39 Process):
Getting an EIP PR merged is like stage 0. This is a strawman proposal that has merely been edited for basic grammar.
Moving to PFI is analogous to stage 1. This is a signal that the EIP/feature is trying to be “taken seriously” but lacks peer review.
CFI is like stage 2. This is a signal that the EIP is well received by clients and that pending timing and the outcome of design iteration, it may be included eventually.
SFI is like stage 3. This is a signal and commitment that the EIP will be landed. Likely the design is also more baked.
Included is like stage 4.

1 Like