EIP-7723: Network Upgrade Inclusion Stages

EIPs EIPs Meta
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.”

3 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.

3 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.

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

2 Likes
10

Who is responsible for taking actions? For example:

an Upgrade Meta EIP MUST be drafted

Who does this? EIP Editors? Client teams? I’d like the document to specify who is responsible for each action that takes place.

In a similar vein, who gets to decide when we are “planning a network upgrade”? Can anyone come in and open a Meta EIP for an upgrade and then client teams pick whichever document they are following, or is there a specific process that Editors can enforce so that only probable fork documents get merged?

Once a decision is made by client teams […]

How do EIP Editors know when a decision has been made?

11

Anyone can create an Upgrade Meta EIP, it is documenting community PFI EIPs, client dev CFI EIPs and all core devs SFI EIPs.

Though in practice, without including an author from EF Protocol Support or multiple client teams then it is unlikely to go very far.

As for any EIP, changes are the responsibility of the EIP author(s). EIP Editors don’t need to do anything.

12

This approach is fine, but I’d still like it written out in the proposal.

Then the proposal should be worded differently.

1 Like
13

I purposefully didn’t make this explicit to not imply something like “the ACD coordinator should create the Meta EIP”. I think it’s fine to leave open-ended, and in the case where I didn’t do so, someone would feel like they could step up and do it?

Why do EIP editors “need” to know this? Is it because you wouldn’t want to move something to Last Call / Final if it wasn’t clear that “a decision was made”? WDYT of using a similar phrasing as in the SFI section?

Once client developers have reviewed an EIP which was Proposed for Inclusion , they MAY move it to the Considered for Inclusion stage. The Upgrade Meta EIP MUST be updated to reflect this.

14

As I see it, the only two options are “Editors” or “anyone”. If it is indeed “anyone”, I’d like that to be clear in the document.

I’m concerned about ambiguity.

For example, you use “MUST” here:

the Upgrade Meta EIP MUST be updated to reflect this

We can’t force authors to take an action, so Editors have to enforce this requirement. That means Editors need to know when a decision has been made.

Similarly, is “a decision is made” a necessary condition to move an EIP into to “Considered for Inclusion”, or can an EIP author move it before a decision is made?

1 Like
15

@SamWilsn what do you think of the EIP being explicit about actors for MUST statements, but ambiguous for SHOULD?

For example, from the EIP:

When planning a network upgrade, an Upgrade Meta EIP MUST be drafted to list EIPs in various stages of consideration.

I’d swap MUST for SHOULD here, as it’s a bit murky to define when we start planning a network update and it doesn’t really matter who authors the EIP.

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.

In this case, I think the MUST is justified, and it would be good for Editors to block the transition if this isn’t the case.

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.

Similarly, I think is is good to keep as a MUST if we want EIP champions to use this as the standard way to propose changes.

Once a decision is made by client teams to move an EIP to Considered for Inclusion , the Upgrade Meta EIP MUST be updated to reflect this.
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 MUST be updated to reflect this.

These become SHOULD.

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.

Keep as a MUST, because it’s easy for editors to judge (and worst case, correct) this.

16

I think we should avoid passive voice here mostly. Something like:

When planning a network upgrade, anyone MAY draft an Upgrade Meta EIP to list EIPs in various stages of consideration.

Yeah, we can add eipw rules for these.

1 Like
17

Thanks @SamWilsn! Added your suggestions in MUST -> SHOULD by timbeiko · Pull Request #8859 · ethereum/EIPs · GitHub