While each Ethereum upgrade—executed via a “hard fork”—inevitably touches many lanes within Ethereum’s roadmap, they’re typically weighted in a specific direction. For example, the Bellatrix upgrade was primarily designed to transition Ethereum’s consensus from Proof of Work (PoW) to Proof of Stake (PoS), while the recent Shanghai-Capella upgrade mainly targeted enabling validator withdrawals from the Beacon Chain.
With the upcoming Cancun-Deneb upgrade, there is a clear focus on improving Ethereum scalability through the creation of “data blobs”: a new transaction type intended to scale data availability for Layer 2 (L2) rollups. In addition to blob creation there are also important housekeeping upgrades, two of which we will break down in this post. Later in this series we will detail the more formational EIPs that will structurally change Ethereum.
Before any of that, however, let’s lay the groundwork for how an Ethereum hard fork (upgrade) is implemented.
Ethereum: A tale of two layers
The Ethereum network is divided into two main layers: the Execution Layer and the Consensus Layer. Prior to the Bellatrix upgrade—often described as “The Merge”—Ethereum’s Consensus Layer and Execution Layer operated independent of one another (to learn more about the Merge and its place in Ethereum’s roadmap, visit Consensys’ information hub for The Merge). In our post-Merge world these two layers run parallel to one another:
Execution Layer: This is the part of Ethereum that handles the execution of smart contract logic and is where transactions are processed and broadcast to the rest of the network. The execution layer is also responsible for maintaining the state of the Ethereum network and executing the Ethereum Virtual Machine (EVM) code; in short, it's where all the computational work happens. Execution layer hard forks are named after the cities that have previously hosted Devcon: Berlin -> London ->Shanghai -> Cancun -> Prague -> Osaka -> Bogotá.
Consensus Layer: This layer is responsible for the agreement on the state of the network among all nodes. It ensures that all transactions and smart contracts are validated and agreed upon via Proof of Stake (PoS). Each consensus layer upgrade is given the name of a star, with the names chosen in alphabetical order based on the first letter: Altair -> Bellatrix -> Capella -> Deneb -> Electra -> (F)unknown.
How and when do upgrades to Ethereum’s layers occur?
Each Ethereum layer undergoes separate upgrades, but the client teams for each layer synchronize the timing of each Ethereum hard fork. Therefore, while the forthcoming Cancun and Deneb upgrades are technically distinct, they are implemented simultaneously. As a result, the portmanteau 'Dencun' is sometimes used to refer to this combined upgrade.
These upgrades do not follow a strict timeline or cadence due to Ethereum’s decentralized nature and plethora of client teams. Nevertheless, recent hard forks have shipped roughly every 8 to 12 months.
Before going live on mainnet, each hard fork is battle tested through a series of testnets; similarly, Cancun and Deneb will be subjected to a local testnet before activation on the main Ethereum network . The testing roadmap is likely to follow the pipeline shown below—although even this timeline is not absolute—with the Cancun and Deneb hard forks expected to go live on Ethereum Mainnet sometime in January: