Add EIP: Hardfork Meta Backfill - Berlin to Shapella

EIPS/eip-meta-hardfork-meta.md

@@ -0,0 +1,91 @@
+---
+title: Hardfork Meta Backfill, from Berlin to Shapella
+description: Pointers to specifications used for the network upgrades from Berlin to Shapella.
+author: Tim Beiko (@timbeiko)
+discussions-to: https://ethereum-magicians.org/t/hardfork-meta-backfill/1692
+status: Draft
+type: Meta
+created: 2023-12-01
+requires: 2070, 2982, 6122, 6953
+---
+
+## Abstract
+
+Between the Berlin and Shapella hard forks, Meta EIPs were abandoned in favor of other ways to track changes included in Ethereum network upgrades. This EIP aggregates the specifications for these upgrades. Specifically, it covers the Beacon Chain launch (Serenity Phase 0), Berlin, London, Altair, Arrow Glacier, Gray Glacier, The Merge (Paris + Bellatrix) and Shapella (Shanghai + Capella). 
+
+## Motivation
+
+For many years, Ethereum used Meta EIPs to document network upgrades. Recently, consensus has formed around using them again. This EIP aggregates the network upgrades who did not have Meta EIPs and links out to their specifications.
+
+## Specification
+
+The network upgrades below are listed in order of activation. Upgrades to Ethereum's execution layer are marked "[EL]", and those to Ethereum's consensus layer are marked "[CL]". 
+
+### Beacon Chain Launch - Serenity Phase 0 [CL]
+
+The full specifications for the Beacon Chain at launch can be found in the [`v1.0.0` release of the `ethereum/consensus-specs` repository](https://github.com/ethereum/consensus-specs/blob/v1.0.0). Additionally, [EIP-2982](./eip-2982.md) provides context on the Beacon Chain design and rationale for its mainnet parametrization. 
+
+### Berlin [EL]
+
+The set of EIPs included in Berlin were originally specified in [EIP-2070](./eip-2079.md), but then moved to the [`berlin.md`](https://github.com/ethereum/execution-specs/blob/8dbde99b132ff8d8fcc9cfb015a9947ccc8b12d6/network-upgrades/mainnet-upgrades/berlin.md) file of the `ethereum/execution-specs` repository. 
+
+### London [EL]
+
+The set of EIPs included in London are specified in the [`london.md`](https://github.com/ethereum/execution-specs/blob/8dbde99b132ff8d8fcc9cfb015a9947ccc8b12d6/network-upgrades/mainnet-upgrades/london.md) file of the `ethereum/execution-specs` repository. 
+
+### Altair [CL]
+
+The full specifications for the Altair network upgrade can be found in the [`v1.1.0` release of the `ethereum/consensus-specs` repository](https://github.com/ethereum/consensus-specs/blob/v1.1.0).
+
+### Arrow Glacier [EL]
+
+The set of EIPs included in Arrow Glacier are specified in the[`arrow-glacier.md`](https://github.com/ethereum/execution-specs/blob/8dbde99b132ff8d8fcc9cfb015a9947ccc8b12d6/network-upgrades/mainnet-upgrades/arrow-glacier.md) file of the `ethereum/execution-specs` repository. 
+
+### Gray Glacier [EL]
+
+The set of EIPs included in Gray Glacier are specified in the[`gray-glacier.md`](https://github.com/ethereum/execution-specs/blob/8dbde99b132ff8d8fcc9cfb015a9947ccc8b12d6/network-upgrades/mainnet-upgrades/gray-glacier.md) file of the `ethereum/execution-specs` repository. 
+
+### The Merge 
+
+The Merge was the first upgrade to require coordination between the execution and consensus layers. The consensus layer first activated the Bellatrix upgrade, which was followed by the activation of Paris on the execution layer.
+
+#### Bellatrix [CL]
+
+The full specifications for the Bellatrix network upgrade can be found in the [`v1.2.0` release of the `ethereum/consensus-specs` repository](https://github.com/ethereum/consensus-specs/blob/v1.2.0).
+
+#### Paris [EL]
+
+The set of EIPs included in Paris are specified in the [`paris.md`](https://github.com/ethereum/execution-specs/blob/8dbde99b132ff8d8fcc9cfb015a9947ccc8b12d6/network-upgrades/mainnet-upgrades/paris.md) file of the `ethereum/execution-specs` repository. 
+
+### Shapella 
+
+The Shapella upgrade was the first upgrade to activate at the same time on both the execution and consensus layers. To enable this, the upgrade activation mechanism on the execution layer was changed to use timestamps instead of blocks. This is described in [EIP-6953](./eip-6953) and [EIP-6122](./eip-6122).
+
+#### Shanghai [EL]
+
+The set of EIPs included in Shanghai are specified in the[`shanghai.md`](https://github.com/ethereum/execution-specs/blob/8dbde99b132ff8d8fcc9cfb015a9947ccc8b12d6/network-upgrades/mainnet-upgrades/shanghai.md) file of the `ethereum/execution-specs` repository. 
+
+#### Capella [CL]
+
+The full specifications for the Capella network upgrade can be found in the [`v1.3.0` release of the `ethereum/consensus-specs` repository](https://github.com/ethereum/consensus-specs/blob/v1.3.0).
+
+
+## Rationale
+
+The EIP repository is well known within the Ethereum community, and Meta EIPs have historically been useful to clearly list the EIPs included in a specific network upgrade.
+
+While the specification process for the execution and consensus layers differ, there is value in having a single, harmonized, list of EIPs included in each upgrade, and for the lists for both layers to be part of the same repository.
+
+Re-introducing Hardfork Meta EIPs enables this, and allows for de-duplication in cases where an EIP affects both the execution and consensus layer of Ethereum. This EIP covers the upgrades which did not use a Hardfork Meta EIP. 
+
+## Backwards Compatibility
+
+No backward compatibility issues found.
+
+## Security Considerations
+
+None.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).