Part 4: Upgrades
Upgrade History
Introduction
Through an open process in February 2021 we decided that beacon chain (consensus layer) upgrades would be named after stars. We're taking them in English alphabetical order, with the first being Altair. The genesis configuration remains Phase 0 due to its origin in the now defunct three-phase plan for delivering Ethereum 2.0.
A summary of upgrades to date is below, with more detailed descriptions in the following sections.
| Name | Epoch | Date (UTC) | Comments | Spec tag | Release name |
|---|---|---|---|---|---|
| Phase 0 | 0 | 2020-12-01 12:00:23 | The genesis configuration | v1.0.0 | Cosmic Egg |
| Altair | 74240 | 2021-10-27 10:56:23 | Sync committees and economic reforms | v1.1.0 | The Great Machine |
| Bellatrix | 144896 | 2022-09-06 11:34:47 | Merge-readiness upgrade | v1.2.0 | Ailuropoda melanoleuca1 |
| Capella | 194048 | 2023-04-12 22:27:35 | Withdrawals enabled | v1.3.0 | Gamlum2 |
| Deneb | TBD | TBD | EIP-4844 data availability | TBD | TBD |
| Electra | TBD | TBD | TBD | TBD | TBD |
The Merge was a special kind of upgrade in that it was not a manual hard fork. The protocol changes required to support the Merge were done in the Bellatrix upgrade. The Merge itself happened nine days later without any further intervention, simultaneously with the execution layer's Paris upgrade.
The consensus layer specifications are written incrementally. Thus, each version (such as the current Bellatrix v1.3.0 version) contains the unchanged specs for previous versions, plus a separate set of documents detailing the changes for the new version. Thus, to build Bellatrix, for example, you need the Phase 0 specs, the Altair "diff" specs on top of that, and the Bellatrix "diff" specs on top of that, all with the same GitHub release tag (in this case, v1.3.0).
The consensus specs repo contains some other, unreleased, versions such as das (data-availability sampling), custody_game, and sharding. These reflect different research directions and are in varying states of currency.
Upgrade timing
Under proof of work, upgrades (with the exception of the Merge) were performed at block heights that had been chosen several weeks in advance. Due to changes in hash power, predicting their timing was difficult - they could occur several hours, or even a day or two, adrift from their target time.
Under proof of stake, we have the luxury of being able to time network upgrades to the second. Nevertheless, we aim to do upgrades on 256-epoch boundaries. These boundaries correspond both to the batching interval of block and state roots (SLOTS_PER_HISTORICAL_ROOT slots), and the sync committee period (EPOCHS_PER_SYNC_COMMITTEE_PERIOD epochs). Having the protocol not change in the middle of these periods will make it easier to verify proofs using their data later.
A period of 256 epochs is around 27 hours, so we get about one opportunity per day to perform an upgrade.
- Gamlum may have been a goat-related ancient name for Capella.↩
- Ailuropoda melanoleuca is the formal name of the giant panda.↩