EIP-6953: Network Upgrade Activation Triggers
Exhaustive list of network upgrade activation mechanisms
| Authors | Tim Beiko (@timbeiko) |
|---|---|
| Created | 2023-04-28 |
| Requires | EIP-2982, EIP-3675, EIP-6122 |
Table of Contents
Abstract
This EIP outlines the various network upgrade activation triggers used on Ethereum over time, from the proof-of-work era to the first post-merge network upgrade, Shanghai/Capella, across both the execution and consensus layers.
Motivation
This EIP aims to provide users and developers with a single source of truth for understanding the various upgrade activation patterns used throughout Ethereum’s history. It does not aim to be a comprehensive, ongoing record, of upgrades and their activations mechanism. Readers should assume that future upgrades use the mechanism described in the Post Merge Upgrades section, unless this EIP is superseded by another one.
Specification
Proof-of-Work Network Upgrades
During the proof-of-work era, network upgrades on Ethereum were triggered based on specific block numbers. The following upgrades followed this pattern:
| Upgrade Name | Activation Block Number |
|---|---|
| Frontier | 1 |
| Frontier Thawing | 200000 |
| Homestead | 1150000 |
| DAO Fork | 1920000 |
| Tangerine Whistle | 2463000 |
| Spurious Dragon | 2675000 |
| Byzantium | 4370000 |
| Constantinople | 7280000 |
| Petersburg | 7280000 |
| Istanbul | 9069000 |
| Muir Glacier | 9200000 |
| Berlin | 12244000 |
| London | 12965000 |
| Arrow Glacier | 13773000 |
| Gray Glacier | 15050000 |
Beacon Chain Launch
The Beacon Chain was launched following a set of conditions detailed in EIP-2982. The launch was activated once all the following conditions were met:
- The Beacon Chain deposit contract received at least
524288ETH from16384validators. - The
MIN_GENESIS_TIMEtimestamp of1606824000(Dec 1, 2020) had been exceeded. - A
GENESIS_DELAYof604800seconds had passed since the minimum validator count was exceeded.
Beacon Chain Upgrades
Beacon Chain upgrades are activated at specific epochs. The following upgrades followed this pattern:
| Upgrade Name | Activation Epoch |
|---|---|
| Altair | 74240 |
| Bellatrix | 144896 |
The Merge: Paris Upgrade
The Paris upgrade, the execution layer portion of “The Merge,” was triggered by a proof-of-work Total Difficulty value of 58750000000000000000000, as specified in EIP-3675. Note that the activation of the Bellatrix upgrade on the Beacon Chain was a pre-requisite for the Paris upgrade to successfully activate on the proof-of-work chain.
Post-Merge Upgrades
After The Merge, network upgrades are triggered at an epoch on the consensus layer (CL), which ideally maps to an historical roots accumulator boundary (i.e., a multiple of 7192 epochs). The epoch’s corresponding timestamp, rather than a block number, is then used on the execution layer (EL) as the activation trigger. The following upgrades followed this pattern:
| Upgrade Name | Activation Epoch | Activation Timestamp |
|---|---|---|
| Capella (CL) | 194048 |
|
| Shanghai (EL) | 1681338455 |
Note that epoch 194048 happened at timestamp 1681338455. In other words, the upgrades activated simultaneously on both the execution and consensus layers, even though they each used a different constant to trigger it.
Additionally, the use of timestamps on the execution layer resulted in changes to how nodes’ FORK_HASH and FORK_NEXT values are calculated. These are described in EIP-6122
Rationale
Blocks and Epochs
Blocks and epochs serve as natural trigger points for upgrades, as they represent the levels at which state transitions occur on Ethereum.
Terminal Total Difficulty
For the Terminal Total Difficulty mechanism, the rationale can be found in EIP-3675.
Timestamps
Due to the possibility of missed slots on the Beacon Chain, the execution layer cannot rely solely on block numbers to trigger upgrades in sync with the consensus layer.
Timestamps are guaranteed to map to a specific epoch, and in their Unix representation, timestamps will always be greater than the block numbers previously used. This allows for a reliable method to trigger upgrades on the execution layer post-merge, while also ensuring that a post-merge upgrade based on a timestamp can never use a value that is considered lower than the last block-triggered upgrade.
Security Considerations
None.
Copyright
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Tim Beiko (@timbeiko), "EIP-6953: Network Upgrade Activation Triggers," Ethereum Improvement Proposals, no. 6953, April 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6953.