Call for Input: Define "Meta" as only relating to processes (effectively excluding hardforks)

[SamWilsn]

Call for Input

Decision	Do we merge ethereum/EIPs#9153 ?
If Affirmed	EIP-1 is updated, hardfork EIPs reclassified as Informational.
If Rejected	No change.
Method	Rough Consensus
Deadline	January 17th, 2025

Background

#365

Checklist

I, the opener of this Call for Input, have completed the following:

• Filled in a descriptive title.
• Filled in the "Decision" field.
• Filled in the "If Affirmed" field.
• Filled in the "If Rejected" field.
• Filled in the "Method" field.
• Filled in the "Deadline" field to be thirty days from creation.
• Added any relevant background information (or removed the section.)
• Published a notice in writing to the usual channels frequented by EIP Editors (likely Discord.)
• Commented on this Call for Input, clearly stating my opinion (or abstention.)

[SamWilsn]

in favour

---

Anything that reduces the ambiguity of categories is a plus in my book.

[timbeiko]

The "Meta" category has been used for network upgrades since Homestead, for over 7 years now. We tried moving away from them from 2020-23, but reverted back as this felt like the clearest way to inform the community about upcoming upgrades and other important hard-fork related changes (e.g. reserved address space for rollups, the network upgrade process inclusion stages, etc.).

It's quite hard for the broader Ethereum community to keep track of protocol upgrades and other important changes. I think we should avoid constantly changing where information lives, and, if doing so, be very clear about the transition and its rationale. Looking at the current Meta EIPs, 13/15 of the Final ones concern hard forks or related processes, and so do 100% of the Draft + Review ones. Even for Stagnant/Withdrawn ones, 6/8 concern hard forks.

Given this, I'm opposed to merging https://github.com/ethereum/EIPs/pull/9153/files as-is and would rather explore other options such as:

• Redefining "Meta EIPs" in EIP-1 to reflect their common usage, and moving EIP process related EIPs to Informational
  • A variant of this is to consider a "Process" category, currently implied in EIP-1 ("Any meta-EIP is also considered a Process EIP.")
• Adding sub-categories to Meta EIPs to delineate between Network Upgrades and EIP Process
• Extracting process-related things into a separate type of resource than EIPs (e.g. Pages on eips.ethereum.org, similar to index.html)

At the very least, I think such a change should be broadly discussed in venues such as AllCoreDevs, Ethereum Magicians, etc. and have buy-in from more stakeholders than only EIP editors, as Meta EIPs are a fairly central hub of important information.

[abcoathup]

Opposed (I am an associate editor so don't get a vote)

---

My understanding of the EIP/ERC split was so that the EIP process could be more tailored to the needs of core devs. This change doesn't appear to do that.

Whilst my preference is to use strict definitions, given the long standing existing use of Meta EIPs for upgrades I don't think this change adds enough value, given the community are used to upgrade Meta EIPs.

If we really need, I would rather see a subcategory for network upgrades.

[poojaranjan]

The Ethereum network upgrade process is a good example of continuous improvement.

I have multiple examples in mind but from the last EIPIP meeting,

• Inclusion of Networking EIP in Upgrade EIP list: Historically, only Core EIPs were included in the Upgrade EIP list, but editors have agreed to add Networking EIPs, recognizing their importance in the upgrade process. Perhaps, EIP-1 will receive some edits to share this change with the community.

• Define "Meta" EIP as "Process Only": While the Upgrade EIP list has been categorized as Meta, editors believe "Informational" is a more suitable category unless the definition of "Meta" EIPs in EIP-1 is updated.

• Discussing EIP’s eligibility stages with EIP-7723: : Network Upgrade Inclusion Stages: This Meta EIP is in “Review” status in 2024, But, back in Nov 2019 when EIP-2378: EIPs Eligible for Inclusion was proposed as Meta EIP, the proposal could not move beyond “Draft”. I suppose the community is considering changes as per the requirement.

FWIW the change with ethereum/EIPs#9153 is unlikely to have any significant impact on information accessibility. Anyone searching for EIP-7600: Hardfork Meta - Pectra will still be able to access the list of proposals for Pectra upgrade seamlessly.

All Upgrade EIPs information will still be there except the proposed Call For Input will cement the original vision of Meta EIP mentioned in EIP-1 that “Any meta-EIP is also considered a Process EIP. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum’s codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them.”

This merge will also confirm that any proposal sharing information other than process will be added to the “Informational” type.

A little back history

• Upgrade Meta was introduced in Apr 2017 with documentation of EIP-606, EIP-607, EIP-608, EIP-609; from Homestead to Byzantium.

• EIP-2387 - Muir Glacier, was the last Upgrade EIP before discontinuation in Dec 2019. I suppose there was one more for EIP-2070 that is “Stagnant” today.

• EIP-7568: Hardfork Meta Backfill - Berlin to Shapella was added in Dec 2023, practically after the Merge when people started looking for a canonical place to follow the upgrade EIP.

Do I think the Upgrade EIP is helpful? Absolutely.

Does it need to be a “Meta” EIP?

• From a consumer's perspective, it doesn't matter as long as all EIPs are accessible in one place.
• From a process-oriented perspective, I would like to do what is documented and document what we decide to do.

This is not the first time a proposal’s Type or Category has been changed. For instance:

• EIP-3076: Slashing Protection Interchange Format was originally categorized as “Core” until it reached the “Review” status, after which it was moved to “Interface.”
• EIP-5069: EIP Editor Handbook was proposed in June 2022 as “Informational” but was changed to “Meta” in September 2023.
• In the last EIPIP meeting editors recommended moving EIP-7783 & EIP-7790 from "Informational" to "Core".

I’m not concerned about changing the process itself. My primary focus is ensuring clear communication about these changes to the community.

That said, I’ll support the decision either way—whether it involves approving this Call For Input or updating EIP-1 to refine the definition of a “Meta” EIP or adding a new Type/Category.

Lastly, I fully support sharing this discussion with the broader community, such as the All Core Developers (ACD) group. However, I encourage people to add comments to this Issue to consolidate thoughts in one place.

[poojaranjan]

Do we merge ethereum/EIPs#9153 ?

IMHO, the current definition of Meta EIP in EIP-1 is clear and will remain valid even after 'Upgrade EIPs' are reclassified as "Informational". I don't see any need to update the definition text.

An Informational EIP describes an Ethereum design issue, hardfork, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs (at the risk of forking the chain) or follow their advice.

I prefer using "network upgrade" instead of "hardfork" to update "Informational EIP".

[shemnon]

The concern I have with moving fork definitions to informational is that informational is supposed to be non-normative or advisory.

The definitions in these meta EIPS (a) define what goes into a "named" fork and (b) when those should be activated on specific networks. These also represent the consensus of All-core-devs, as it is discussed and selected as part of the ACD process.

I think what would be warranted is a new category, and because of the strong historical use of the term "meta" to refer to aggregate EIPs and fork definitions I think we should add a "process" category and move the process EIPS there. Possibly along these definitions

• A Process EIP describes a process surrounding Ethereum or proposes a change to (or an event in) a process—especially the EIP process itself. Examples include procedures, guidelines, and changes to decision-making processes.

• An Informational EIP describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs (at the risk of forking the chain) or follow their advice.

• A Meta EIP describes an Ethereum Network Upgrade (colloquially known as a hardfork), an aggregation of other EIPs relating to an upgrade, or any other meta-coordination issues relating to operational and proposed networks covered by the ACD and related processes (such as reservation of transaction types or smart contract addresses).

We can bikeshed the names, but I strongly feel the better approach is to split the current meta rather than moving some to informational.

[SamWilsn]

The concern I have with moving fork definitions to informational is that informational is supposed to be non-normative or advisory.

Hardfork EIPs are just a convenient way to organize EIPs into an index. We all organize around @timbeiko's Hardfork EIPs, but I wouldn't stop anyone else from making one (it would just go nowhere.) I could see the argument that they are compulsory to follow the chain, but that would put them closer to Core.

[shemnon]

How is a hard fork EIP going nowhere any different from a core EIP going nowhere? Bad core EIPs that were DOA have been proposed before, being an EIP that can be ignored really is orthogonal to what bucket it belongs in based on what change it is describing.

[SamWilsn]

I don't feel comfortable making this change if I am the only Editor in favour. I'm changing my vote to opposed and closing this.