# Post-Merge Hard Fork Coordination

_TL;DR: We should stick to using a single name for Ethereum hard-forks rather than separate hard forks for the execution and consensus layers._

It has been proposed that we keep network upgrades to the consensus layer and the execution layer **separate**. That is, we group a bunch of changes to EL into EL hard forks, named after cities such as "Shanghai", and we group CL changes into CL-specific hard forks, named after stars in the universe, such as "Altair". We argue this separation is harmful for Ethereum.

Users should not need to know about the distinction between the consensus layer / execution layer. The separation is useful for modularity in client development, as well as separation of responsibilities when it comes to software. However, this creates unnecessary confusion when it comes to network upgrades **if this terminology surfaces to users**.

Ethereum has gone through multiple hard forks in its history, and each of them has a big name associated with it, such as London, and Constantinople. This helps when it comes to **public awareness of the upgrade** as well as categorizing the changes contained within the upgrade.

It has been proposed that we keep separate hard fork names for consensus and execution layer changes. For example, if there is a breaking change in EL, but nothing on the CL side, we publicize the hard fork as an EL hard fork, and vice-versa. For example, we may have the "Chicago" hard fork in the EL scheduled for 2023/01, and the "Polaris" hard fork in the CL scheduled for 2023/02. The reasons why this is problematic are as follows:

### 1. Having CL and EL upgrades too close to each other is confusing

One example where the separation of CL and EL hard forks makes sense is when there is a breaking change in EL, but no change in CL. This is pretty straightforward for node operators as they will only need to upgrade their EL software. However, if there is a change in a data structure, such as an `ExecutionPayload`, both EL and CL will need to upgrade at the same time. This means _both_ will require a hard fork. If we have separate naming conventions for them, it is confusing to tell people the "Chicago" and the "Polaris" hard forks will take place at the same date and time.

Even if this is not the case, and instead we have separate upgrades, having them too close to each other can be tricky (it is already hard enough to get the network to be ready for ETH hard forks, let alone _two_ close to each other). Having them too far away from each other makes it so that operators have to perform a risky maneuver several times per year, only leading to more complexity.

### 2. There is only one "Ethereum", and single network upgrades have far easier optics for the public

From the perspective of a node operator, running a blockchain "node" is what everyone is used to. Even if we have a separation between EL and CL software, the combination of the two should be considered an "Ethereum node". In an ideal world, we would have an `ethereum` binary that operators can install and run all the underlying pieces they need to participate in the network. For example, `apt-get install ethereum && ./ethereum`. Knowing that there is an "Ethereum" upgrade coming is easier for users, node operators, and the public in general rather than multiple updates to EL and CL when people should not even need to know what those are.

### 3. Upgrade fatigue is dangerous

As a client development team, we at Prysmatic Labs have experienced the dangers of upgrade fatigue. Making too many announcements of upgrades reduces public anticipitation and urgency to act and be prepared for them. For example, having one, big scheduled upgrade for the year is a big deal. Having two, three, or more leads to a higher risk of operator negligence.

The ideal flow for network upgrades would be a single name, following the current Ethereum hard fork naming conventions, where there are clear guidelines on what node operators need to do to prepare. The node operator experience for Ethereum post-merge is already hard enough. Having large upgrades branded differently as CL or EL upgrades is confusing to the community.