Part 4: Upgrades

Upgrade History


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 follows, with more detailed descriptions in the next sections.

Name Epoch Date (UTC) Comments Spec tag
Phase 0 0 2020-12-01 12:00:23 The genesis configuration v1.0.0
Altair 74240 2021-10-27 10:56:23 Sync committees and economic reforms v1.1.0
Bellatrix 144896 2022-09-06 11:34:47 Merge-readiness upgrade v1.2.0
Capella 194048 2023-04-12 22:27:35 The next planned upgrade TBD
Deneb TBD TBD The next-but-one upgrade TBD

The Merge was a special kind of upgrade in that it was not a 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.2.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.2.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 state roots (SLOTS_PER_HISTORICAL_ROOT slots), and the sync committee period (EPOCHS_PER_SYNC_COMMITTEE_PERIOD). 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.

Created by Ben Edgington. Licensed under CC BY-SA 4.0. Published 2023-07-01 13:14 UTC. Commit d859d30.