EIP-7723: Network Upgrade Inclusion Stages

EIPs EIPs Meta
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.
2 Likes