Ethereum today consists of two chains. One is what we used to know as the Mainnet chain, i.e., Execution Layer secured by PoW consensus, and another chain is Consensus Layer or Beacon Chain, which is also a Mainnet secured by novel PoS consensus mechanism. The Beacon chain is already up and running for a year and a half, proving its sustainability and security. The Merge is bringing these two chains together by hot-swapping consensus mechanism from PoW to PoS. Two hard forks are needed to bring these two chains together. Their names are Bellatrix (Consensus Layer) and Paris (Execution Layer). The order of these hard forks in the context of The Merge rollout does matter. In this article, we will get a complete idea of Bellatrix and Paris Upgrade.

Table of Content

• What is the Bellatrix upgrade?
• How was the name decided?
• Expected Changes
  • Beacon Chain
  • Validator responsibilities
  • Networking
  • Fork Choice
• What is the Paris upgrade?
• How was the name decided?
• How does the Merge transition happen?
  • Why use TTD instead of Block Number?
  • What happens if TTD hits before Bellatrix?
  • How is TTD Override done?

What is the Bellatrix Upgrade?

Bellatrix is a Consensus Layer upgrade that prepares the beacon chain for The Merge.

As we know, mainnet hard forks are triggered by reaching a specific block number, but on the beacon chain, there is no notion of block numbers, but there are slots. Also, the beacon chain is time-sensitive as it has its logical clock, which is tightly coupled to the actual clock. So, all beacon chain hard forks are triggered by a fork epoch(a span of slots) which is predictable for up to a second.

Upgrades on the Consensus Layer side, i.e., beacon chain, are highly deterministic as we can predict the exact moment when the hard fork on the beacon chain goes up. So, we can say that Bellatrix part of The Merge will be highly deterministic regarding rollout and transition.

So, for Bellatrix to happen on the beacon chain, a client upgrade is required to bring the Bellatrix logic on it. It might seem that the only Consensus Layer client needs to be updated, but it's not correct. Bellatrix compatible ethereum client will be the combination of the beacon chain clients and the Execution Layer clients. Every ethereum node is represented by the two parts, the Consensus Layer part and the Execution Layer part, which communicate via Engine API. Engine API is an interface that is used for communication between Consensus Layer and Execution Layer.

So, if we summarize this, then:

• CL clients contain the Bellatrix changes and wait for Bellatrix Epoch.
• EL clients contain the Paris changes and expose the Engine API interface that is used for communication between CL and EL.

When Bellatrix Upgrade hits the Consensus Layer, CL clients are producing the updated BeaconBlocks, containing the ExecutionPayload structure, and the blocks will be coming with empty ExecutionPayload until The Merge transition. CL clients also monitor the Execution Layer for the TTD event to produce the first PoS block on top of a terminal PoW block. EL clients also monitor the network for the TTD event.

Bellatrix also includes an Optimistic Sync support, i.e., a sync approach used by clients post-Merge.

What is Optimistic Sync?

In order to provide a syncing execution engine with a partial view of the head of the chain, it may be desirable for a consensus engine to import beacon blocks without verifying the execution payloads. This partial sync is called an optimistic sync.

How was the Name Decided?

In the Proposal: Use B-star name for The Merge (at least for CL) #430, it was announced that the name for the next CL hard fork, i.e. The Merge would be Bellatrix 🦸‍♀️. Also, as we know that all CL upgrades are with star names, whereas EL upgrades are with city names. Also, there are so many cases where developers use the terminology merge but not about The Merge in code. Also, it was funny to see a The Merge PR with a DO NOT MERGE label. Here is the list of other Cool “B-” star names that were shortlisted.

What is Bellatrix?

It is about 20 million years-old and shines the 3rd brightest in its home constellation and 27th overall in the night sky. It is one of the four stars that are used in celestial navigation.

So this proves how decentralized Ethereum is. Everything is done with fair voting and consensus. So we can see how much discussion is done in deciding a particular name.

Expected Changes

Beacon Chain

This upgrade adds transaction execution to the beacon chain as part of the Bellatrix upgrade and updates penalty parameters to their planned maximally punitive values.

Bellatrix updates a few configuration values to move penalty parameters to their final maximum security values. As a result, the spec does not override previous configuration values but instead creates new values and replaces usage throughout.

The function get_inactivity_penalty_deltas is also modified to use INACTIVITY_PENALTY_QUOTIENT_BELLATRIX, and it returns the inactivity penalty deltas by considering timely target participation flags and inactivity scores. The function slash_validator is modified to use MIN_SLASHING_PENALTY_QUOTIENT_BELLATRIX and it slashes the validator with index slashed_index. Also, the function process_slashings is modified to use PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX, which is used in Epoch processing.

The function initialize_beacon_state_from_eth1 is modified for pure Bellatrix testing only. These modifications include:

• Using BELLATRIX_FORK_VERSION as the current fork version.
• Using the Bellatrix BeaconBlockBody when constructing the initial latest_block_header.
• Initialization of latest_execution_payload_header. If execution_payload_header == ExecutionPayloadHeader(), then the Merge has not yet occurred. Else, The Merge starts from genesis and the transition is incomplete.

Validator Responsibilities

Most of the validator responsibilities will remain unchanged, as seen in Altair Upgrade.

The two notable changes in Bellatrix Upgrade are Transition Block Handling and the addition of ExecutionPayload. Also, It should be noted that a validator must not propose or attest to a block that isn't valid, i.e., hasn't yet passed the beacon chain state transition and execution validations. In future upgrades, an execution Proof-of-Custody will be integrated to prevent outsourcing execution payload validations.

It is also recommended that validators call prepare_execution_payload as soon as input parameters become known and make subsequent calls to this function when any of these parameters are updated.

get_payload function is added to the ExecutionEngine protocol for use as a validator. The body of this function is implementation-dependent. The Engine API may be used to implement it with an external execution engine.

Networking

Here are some modified constants in Bellatrix Upgrade.

View this post on Instagram

A post shared by EtherWorld (@etherworld.co)

Each gossipsub message will now have a maximum size of GOSSIP_MAX_SIZE_BELLATRIX. Clients must reject fail validation messages over this size limit. Likewise, clients must not propagate messages larger than this limit. With the addition of ExecutionPayload to BeaconBlocks, there is a dynamic field, i.e., transactions that can validly exceed the GOSSIP_MAX_SIZE limit. Also, a single transaction can quickly be filled with data at the cost of 16 gas per byte, creating a valid ExecutionPayload of ~2 MiB. Thus there was a need to increase the max gossip message size.

Also, a global maximum uncompressed byte size, i.e., MAX_CHUNK_SIZE_BELLATRIX will now be applied to all method response chunks. This is done as the ExecutionPayload type can cause BeaconBlocks to exceed the 1 MiB.

This upgrade will also allow blocks with invalid execution payloads to propagate across gossip and via RPC calls. This is done as we know that optimistic nodes must listen to block gossip to obtain a view of the head of the chain. Therefore, optimistic nodes must propagate gossip blocks. Furthermore, if optimistic nodes propagate blocks via gossip, then they must respond to requests for the parent via RPC. Therefore, optimistic nodes must send optimistic blocks via RPC.

Fork Choice

It introduces the transition process from the last PoW block to the first PoS block. The notify_forkchoice_updated is added here to the ExecutionEngine to signal the fork choice updates. This function performs three main tasks:

• It re-organizes the execution payload chain and corresponding state to make head_block_hash the head.
• It updates the safe block hash with the value provided by safe_block_hash parameter.
• It applies the finality to the execution state.

What is Fork Choice?

All blockchains have the possibility of temporary disagreement. This can be due to:

• Malicious behavior, i.e., a block proposer publishing two different blocks at the same time.
• Network latency, i.e., a block being delayed by a few seconds, causing it to be broadcasted around the same time as the next block that gets published by someone else.

In such cases, a mechanism is needed to choose which chain represents the actual history and state of the system. Fork Choice describes the mechanism for how to decide what is the canonical chain if there are multiple conflicting versions of the chain to choose from.

What is the Paris Upgrade?

Paris Upgrade deploys two EIPs, i.e, EIP-3675 for PoS consensus upgrade and EIP-4399 for Supplant DIFFICULTY with PREVRANDAO.

Unlike a regular PoW network hard fork, Paris is triggered by reaching a decided amount of TTD. So, when the PoW chain reaches a certain amount of TTD, Execution Layer clients stop processing the PoW chain, and the PoW chain stops. So, total terminal difficulty denotes the last PoW block. Then, on the PoS side, i.e., the Consensus Layer comes into the picture, producing the block on top of the terminal PoW block, which is the first PoS block. So, the Execution part of this first PoS block will follow the two Paris upgrade EIPs, and this will also be the first Paris block. So, Paris is not activated on the terminal PoW block but the first PoS block.

Paris’ rules are taking effect since the first PoS block in the system.

Paris Upgrade is less predictable and deterministic than the Bellatrix Upgrade because developers use the total terminal difficulty, which is affected by hash power fluctuations in the network. So, when developers say that TTD will hit in four weeks, it doesn't mean that they are anticipating, but they are predicting that, according to their predictions, TTD will happen after four weeks. This is because developers assume that the hash power will remain the same, but if hash power increases, then the TTD will hit much earlier than expected, and also, if the hash power goes down, the same TTD can take eight weeks.

How was the Name Decided?

In the EL Merge Client Release Naming Breakout Room #491
, it was announced that the EL client codename would be Paris🗼. This was decided on the responses received on the FEM, Twitter Poll, and General discussion in the community meeting organized.

✨EL Merge Client Release Naming ✨

The Merge = EL + CL

Earlier, you decided "Bellatrix" for CL clients. Now is the time to choose an EL client name.

Send❤️ at https://t.co/R9DPnyrqFB

Check out shortlists 📒https://t.co/LDR3iWee0A

Vote for your favorite name👇

— Ethereum Cat Herders (@EthCatHerders) March 10, 2022

Here is the list of other the proposed names for EL clients specs on the nominations received on FEM Discussion thread.

What is the significance of Paris?

It's the city where the first large Ethereum community conferences were organized, i.e., EthCC and EDCON.

So again, we can see how decentralized Ethereum is. Everything is done with fair voting and consensus. So we can see how much discussion is done in deciding a particular name. So, if someone doubts Decentralization in Ethereum, they should create their blockchain.

How does the Merge transition happen?

Firstly, Nodes are upgraded to be compliant with Bellatrix (CL part) and Paris (EL part). Then we wait for the Bellatrix fork epoch to happen. After the epoch is hit, CL clients are now waiting for a terminal PoW block. Once a terminal PoW block reaches TTD, the Beacon chain proposer builds the first PoS block on top of a terminal PoW block, and Paris is activated on the Execution Layer.

Why we use TTD instead of Block Number?

In the PoW network, the canonical chain is backed by the highest amount of work, i.e., the chain with the highest total difficulty value, but not the chain with the highest block number. The PoS chain must be built on top of a block that reached the TTD value.

Total difficulty is the amount of work put into the network. So higher the total difficulty would be, Higher the amount of work that has been put into a particular chain and vice versa. This is why the PoS chain should take the heaviest PoW chain, i.e., the chain with the highest total difficulty.

But if we use the highest block number, then a minority hash power chain, i.e., with 10% of hash power, can reach a particular block number faster and hijack the transition to The Merge upgrade. Although, this attack requires some communication between the proposer and the miner. So that's why we use the terminal total difficulty instead of block number.

What happens if TTD hits before Bellatrix?

EL clients monitor the chain for TTD. So, when TTD is reached, PoW blocks processing is stopped. EL clients do not process PoW blocks after a terminal PoW block and follow The Mergetransition. This is done for security reasons to prevent a user who has forgotten to upgrade their nodes. After The Merge happens, PoS Ethereum will be the only canonical chain. If someone has forgotten to upgrade their nodes and they are still following the PoW chain, and if somebody is building this chain, then that user will be following the incorrect chain, i.e., the old PoW chain, which is not Ethereum anymore. So that's why a client would stop processing PoW blocks after The Merge transition, which will help prevent following the wrong chain due to client misconfiguration.

Let's say developers have picked a TTD value. So, the network is upgraded and expecting Bellatrix_fork_epoch. Let's say there is enormous amount of hash power put in this network which makes makes the TTD happen before the Bellatrix. It means that EL clients will just stop processing any PoW block and the EL chain will now wait for Bellatrix and it will stop. It is not a security but a liveness failure. When Bellatrix_fork_epoch happens on the CL side, the first proposer of after bellatrix will basically start the transition process and will create the first PoS block, but what we will see is chain is just not progressing. This scenario can’t happen on the Mainnet as there is no hidden hash power capable of significantly accelerating the TTD event than expected.

But it can easily happen on testnets, and this is what we have almost seen on Ropsten.

Ropsten TTD issue

So, Ropsten was going to switch to PoS on June 8th but unexpectedly the palindromic number for TTD, i.e., 43531756765713534 was hit on 26th May at Block 12308106 which resulted in Ropsten getting shut because there was no Beacon Chain launched and The Merge could not happen.

This incident occurred because someone purchased a significant amount of hash power for Ropsten, i.e., 20x the usual hash rate. This increase caused TTD to be met earlier than expected.

What measures were taken to resolve Ropsten TTD issue?

So, to fix this issue, a group of client developers, researchers and test engineers agreed to update the TTD to an incredibly large number, i.e., 100000000000000000000000.

Just reached TTD on ropsten, we decided to push TTD, so if your node is stuck, please use `--override.terminaltotaldifficulty 100000000000000000000000` to unstuck it and run `debug.setHead("0xBBCE88")` in the console to force the node to sync the correct chain https://t.co/Cnerlol0JY

— MariusVanDerWijden (@vdWijden) May 26, 2022

How is TTD Override done?

Both EL and CL clients must be upgraded or restarted for TTD Override.

• The first option here is cut client releases with the new TTD value but this hits the release pipeline of each client and will take more time to upgrade their clients.
• The second option that is easier and is less complicated in terms of time complexity is using the a specific CLI argument to set the new TTD value which requires a client restart. Both clients CL part and EL part is required to be restarted with the new TTD value. This option is supported by all clients and has been tested on several Shadow Forks and on the Ropsten Merge.

Conclusion

These upgrades are still actively in development. The exact specification has not been formally accepted as final and details are still subject to change.

Resources

• ethereum/consensus-specs
• ethereum/execution-specs
• PEEPanEIP#73:TheMerge transition - Paris, Bellatrix & TTD with Mikhail Kalinin

Related Videos

• Ethereum: The Great Renaming
• Proof of Work
• Proof of Stake
• How to Join Kintsugi testnet?
• Kintsugi Fuzzer Issue
• What is Kiln Testnet?
• How to Join Kiln Testnet?

Related Articles

• The Evolution of Ethereum Testnets
• Ropsten testnet Merge
• Sepolia Testnet Merge
• An overview of expected changes with the Ethereum Merge upgrade
• Ethereum Rinkeby Testnet will be deprecated soon!
• Ethereum Testnets after The Merge
• MEV in DeFi
• Everything about NFT Drop for The Merge Testers
• Ethereum Mainnet Shadow Forking: An Overview
• How to Join Ethereum Merge Kintsugi Testnet?
• Ethereum Merge Kiln Testnet
• Ethereum's roadmap for 2022 and beyond!