EIP-7568 Hard fork meta backfill: Berlin through Shapella (Hardfork Meta Backfill - Berlin to Shapella)
Final · Other · EIP status Final · created 2023-12-01
A documentation-type meta EIP that consolidates and links the specification locations of past network upgrades, from the Beacon Chain launch through Shapella, that proceeded without a meta EIP. It does not change the network rules itself.
Why it is needed
Ethereum long organized what changes went into each network upgrade through documents called meta EIPs. However, after the Muir Glacier hard fork this practice was abandoned, and upgrade contents were instead tracked as scattered files and releases in other repositories. As a result, checking what changes were included in the Beacon Chain launch, Berlin, London, Altair, Arrow Glacier, Gray Glacier, the Merge, and Shapella required searching across separate execution layer and consensus layer repositories. As consensus has recently formed around reviving meta EIPs, this EIP fills the gap by collecting the specifications of the upgrades that lacked one.
What changes
Today
- Upgrades after Muir Glacier tracked their specifications as files and releases scattered across multiple repositories, without a meta EIP.
- Finding out which EIPs went into which upgrade required separately searching the execution layer and consensus layer repositories.
After EIP-7568
- This single EIP now lets you check the specification locations for all eight upgrades from the Beacon Chain launch through Shapella.
- The change lists from both layers are linked together within the well-known EIP repository.
Who is affected
- Developers and researchers: Gain an official starting point for finding the EIPs and specifications included in past upgrades.
- Client teams: Can reference execution layer and consensus layer specifications from a single harmonized list.
- Ordinary users: There is no direct change in behavior. This is a record-keeping EIP that does not change protocol rules.
In depth
The lapse and restoration of meta EIPs
After the Muir Glacier hard fork, meta EIPs were abandoned and the changes included in upgrades were tracked by other means. Consensus has recently formed around reviving meta EIPs, and this EIP is a backfill document that collects and links the specifications of upgrades that lacked one. The targets are the Beacon Chain launch (Serenity Phase 0), Berlin, London, Altair, Arrow Glacier, Gray Glacier, the Merge (Paris + Bellatrix), and Shapella (Shanghai + Capella), listed in order of activation, with the execution layer marked [EL] and the consensus layer marked [CL].
Specification locations for execution layer upgrades
The list of EIPs included in Berlin was originally specified in EIP-2070, then moved to the berlin.md file in the ethereum/execution-specs repository. London, Arrow Glacier, Gray Glacier, Paris, and Shanghai likewise have their included EIP lists specified in the london.md, arrow-glacier.md, gray-glacier.md, paris.md, and shanghai.md files of the same repository.
Specification locations for consensus layer upgrades
Consensus layer specifications are managed as releases in the ethereum/consensus-specs repository. The Beacon Chain launch (Serenity Phase 0) has its full specification in the v1.0.0 release, Altair in v1.1.0, Bellatrix in v1.2.0, and Capella in v1.3.0. The design background of the Beacon Chain and the rationale for setting mainnet parameters are described separately in EIP-2982.
The Merge: the first joint upgrade across both layers
The Merge was the first upgrade that required coordination between the execution layer and the consensus layer. Bellatrix activated first on the consensus layer, followed by Paris on the execution layer. The Bellatrix specification is in the consensus-specs v1.2.0 release, and the list of EIPs included in Paris is in execution-specs' paris.md.
Shapella and timestamp-based activation
Shapella (Shanghai + Capella) was the first upgrade to activate at the same point in time on both the execution layer and the consensus layer. To make this possible, the execution layer's upgrade activation criterion was changed from block number to timestamp, a change described in EIP-6953 and EIP-6122.
Why reconsolidate into a meta EIP
The EIP repository is well known to the Ethereum community, and meta EIPs were useful for clearly listing which EIPs were included in a given upgrade. Although the specification processes for the execution layer and the consensus layer differ, there is value in keeping the EIPs for each upgrade in a single harmonized list within the same repository. Reviving the hard fork meta EIP also reduces duplicate listings when a single EIP affects both layers.
Status and compatibility
This EIP's status is finalized as Final. As a record-keeping document pointing to existing specifications, it raises no backwards compatibility issues and has no security considerations. Since it does not represent a change to be included in a specific fork, it is also not subject to core developer call inclusion decisions.