- Ethereum is transitioning to proof-of-stake! This change, referred to as The Merge, requires initial activation on the Beacon Chain via the Bellatrix upgrade. Subsequently, the proof-of-work chain will shift to proof-of-stake upon reaching a designated Total Difficulty figure.
- The Bellatrix upgrade is set for epoch 144896 on the Beacon Chain — 11:34:47am UTC on Sept 6, 2022.
- The Terminal Total Difficulty value that triggers The Merge is 58750000000000000000000, anticipated between Sept 10-20, 2022.
- Note: as previously announced, the Kiln testnet is being retired. Operators will shut down on September 6, 2022.
Background
After years of diligent effort, Ethereum’s proof-of-stake upgrade is finally upon us! The successful transition of all public testnets is now accomplished, and The Merge has been slated for the Ethereum mainnet.
The Merge diverges from earlier network upgrades in two key aspects. Firstly, node operators must update both their consensus layer (CL) and execution layer (EL) clients simultaneously, instead of just one of them. Secondly, the upgrade unfolds in two stages: the first, known as Bellatrix, at an epoch height on the Beacon Chain, followed by the second, referred to as Paris, upon reaching a Total Difficulty benchmark on the execution layer.
Upgrade Information
Timing
The Merge is a two-phase procedure. The initial phase is a network upgrade, Bellatrix, on the consensus layer instigated by an epoch height. This is succeeded by the transition of the execution layer from proof-of-work to proof-of-stake, Paris, initiated by a specific Total Difficulty limit known as the Terminal Total Difficulty (TTD).
The Bellatrix upgrade is slated for epoch 144896 on the Beacon Chain — 11:34:47am UTC on Sept 6, 2022.
Paris, the execution layer’s segment of the transition, will be activated by the Terminal Total Difficulty (TTD) of 58750000000000000000000, expected between Sept 10-20, 2022. The precise date on which TTD is attained hinges on the proof-of-work hash rate. Estimates for the transition can be found at bordel.wtf and 797.io/themerge.
Upon the execution layer reaching or surpassing the TTD, the following block will be generated by a Beacon Chain validator. The Merge transition is regarded as complete once the Beacon Chain finalizes this block. Under typical network circumstances, this will occur 2 epochs (or approximately 13 minutes) after the first post-TTD block is minted!
A new JSON-RPC block tag, finalized, returns the latest finalized block or an error if no such post-merge block exists. Applications can utilize this tag to verify if The Merge has been finalized. In a similar vein, smart contracts can query the DIFFICULTY opcode (0x44) (renamed to PREVRANDAO post-merge) to ascertain if The Merge has taken place. We advise infrastructure providers to keep an eye on general network stability along with finalization status.
Client Releases
The following client releases facilitate The Merge on the Ethereum mainnet. Node operators are required to run both an execution and consensus layer client to maintain their presence on the network during and after The Merge.
When selecting which client to operate, validators should be particularly cautious of the risks associated with running a dominant client on both the EL and CL. An explanation of these risks and their implications can be located here. An overview of the current EL and CL client distribution alongside guides for switching from one client to another can be found here.
Consensus Layer
Warning: Nimbus version v22.9.0 is a critical upgrade that addresses a significant pre-TTD block production problem affecting users who restarted their node post-Bellatrix. It also enhances compatibility with Besu, Prysm, and slower block builders while providing a performance boost in block processing, particularly for those utilizing Raspberry Pi and similar hardware.
Warning: Lighthouse version v3.1.0 is a high-priority release containing a vital fix to ensure that Lighthouse does not attempt to generate invalid blocks. The –strict-fee-recipient flag for the Lighthouse Validator Client has also been determined to prevent block proposals during the period between the Bellatrix upgrade (Sept 6th) and the TTD date (anticipated Sept 15th). Presently, we are within that timeframe, and as such, all stakers using that flag are impacted. We strongly recommend that anyone utilizing the –strict-fee-recipient flag remove it and restart the Validator Client as soon as possible. This does not impact the –suggested-fee-recipient flag.
Alert: Prysm v3.1.1 is an essential update as it encompasses numerous vital corrections and functionalities for the merge.
Alert: Teku version 22.9.0 is a mandatory update.
Execution Layer
Alert: Besu 22.7.2 is a suggested release for Merge and Mainnet users. 22.7.1 remains compatible for the Merge. This version offers additional stability before the Merge with various fixes and enhancements in synchronization, peer connections, and logging.
Alert: Erigon version v2022.09.01-alpha addresses invalid block generation due to inadequate validation of digital signature components, block snapshot generation that occasionally takes place during the POS reversed header download, and numerous smaller bugs and security problems. All Erigon users are advised to upgrade to this or a later version prior to the Merge.
Alert: Geth version v1.10.22 contains a severe database issue; refrain from using this version, and if you have already upgraded, please move to v1.10.23 at your earliest convenience.
Upgrade Specifications
Changes that are critical for consensus regarding The Merge are described in two locations:
- The modifications of the consensus layer found under the Bellatrix directory within the consensus-specs repository
- The alterations in the execution layer outlined under the Paris spec in the execution-specs repository
Alongside these, two additional specifications explain the interaction between the consensus and execution layer clients:
- The Engine API, defined in the execution-apis repository, facilitates communication between the consensus and execution layers
- Optimistic Sync, detailed in the sync folder of the consensus-specs repository, is utilized by the consensus layer to import blocks while the execution layer client is synchronizing and to provide a partial perspective of the head of the chain from the former to the latter
Merge Bug Bounty Bonus
All bounties associated with Merge-related vulnerabilities have received a 4x multiplier from now until September 8th. Critical bugs are currently valued at up to $1 million USD.
For further details, please refer to the bug bounty program.
FAQ
As a node operator, what should I perform?
After the merge, an Ethereum full node is composed of a consensus layer (CL) client that operates the proof-of-stake Beacon Chain and an execution layer (EL) client that oversees the user-state and handles the computations linked to transactions. The EL and CL clients interact over an authenticated port utilizing a new assortment of JSON RPC methods referred to as the Engine API. The EL and CL clients validate one another using a JWT secret. Node operators should consult their clients’ documentation for guidance on how to create and configure this value.
In simpler terms, if you had been operating a node on the Beacon Chain, you now also must run an execution layer client. Similarly, if you were managing a node on the existing proof-of-work network, you will need to run a consensus layer client. For secure communication between them, a JWT token must be provided to each client. An update to the ‘Run a Node’ section on ethereum.org elaborates on these processes in greater detail.
It is essential to highlight that while both components are part of the consensus layer client releases, operating a Beacon Node is different from managing a Validator Client. Stakers must run both, but node operators only require the former. This article provides further clarification on the distinctions between the two components.
Additionally, note that each layer will sustain an independent set of peers and present its own APIs. The Beacon and JSON RPC APIs will both continue functioning as anticipated.
As a staker, what actions should I take?
As stated previously, validators on the Beacon Chain will be required to operate an execution layer client following The Merge, in addition to their consensus layer clients. Before the merge, it was strongly advised, though some validators have delegated these functions to external providers. This was feasible because the execution layer only required updates to the deposit contract data.
After the merge, validators must guarantee that user transactions and state transition blocks they create and attest to are valid. To achieve this, each beacon node must be connected to an execution layer client. Keep in mind that multiple validators may still be paired with a single beacon node & execution layer client combination. This broadens validators’ responsibilities while also allowing a validator proposing a block to claim its associated transaction priority fees (which currently go to miners).
Although validator rewards continue to accumulate on the Beacon Chain and will necessitate a future network upgrade for withdrawal, transaction fees will be settled, incinerated, and allocated on the execution layer. Validators may designate any Ethereum address as the beneficiary for transaction fees.
After updating your consensus client, ensure you configure the fee recipient within your validator client settings to confirm transaction fees are directed to an address under your control. If you have staked through a third-party service, it is the responsibility of your chosen provider to determine how these fees are distributed.
The Staking Launchpad features a Merge Readiness Checklist that stakers can utilize to confirm they have completed each phase of the process. EthStaker has also conducted Validator Preparation Workshops, with additional sessions on the horizon.
Stakers intending to operate a validator on a testnet as preparation for the mainnet proof-of-stake transition can do so on Goerli (now merged with Prater), which also offers a Staking Launchpad instance.
Why is the estimated date for the Terminal Total Difficulty so wide-ranging?
The additional difficulty per block is contingent upon the network hash rate, which is subject to fluctuations. If more hash rate contributes to the network, the TTD will be achieved more rapidly. Conversely, if hash rate exits the network, the TTD will be attained later. In the case of a significant decline in hash rate levels, a TTD Override may be organized similar to what was done on Ropsten.
As an application or tooling developer, what actions should I take?
As detailed in a previous article, The Merge will exert only minor influence on a portion of contracts deployed on Ethereum, none of which should be non-functional. Furthermore, the majority of user API endpoints remain consistent (unless utilizing proof-of-work specific methods such as eth_getWork).
That being said, most applications on Ethereum involve significantly more than merely on-chain contracts. Now is the ideal time to guarantee your front-end code, tooling, deployment pipeline, and other off-chain components function as expected. We highly recommend that developers engage in a thorough testing & deployment cycle on Sepolia or Goerli and report any complications with tools or dependencies to the maintainers of those projects. If you are uncertain where to file an issue, please utilize this repository.
Furthermore, be aware that all testnets other than Sepolia and Goerli will be phased out following the merge. If you are utilizing Ropsten, Rinkeby, or Kiln, you should prepare to transition to Goerli or Sepolia. Further details regarding this can be found here.
As an Ethereum user or Ether holder, is there anything required of me?
Whether you are engaging with Ethereum applications on-chain, holding Ether on an exchange, or in a self-custodied wallet, you are not required to take any action. If an application, exchange, or wallet you are utilizing provides additional guidance or recommendations, ensure these are actually coming from them. Remain vigilant against scams!
As a miner, is there anything I should do?
No. If you are mining on the Ethereum mainnet, please note that the network will transition entirely to proof-of-stake after The Merge. Subsequently, mining on the network will not be feasible.
What occurs if I am a miner or node operator and do not engage in the upgrade?
If you are operating an Ethereum client that has not been updated to the most recent version (as listed above), your client will synchronize to the pre-fork blockchain once the upgrade takes place.
You will find yourself stranded on an incompatible chain following the old protocols and will be unable to transmit Ether or function on the post-merge Ethereum network.
As a validator, am I permitted to withdraw my stake?
No. The Merge represents the most intricate upgrade to Ethereum thus far. To minimize the chances of network disruptions, a conservative strategy was adopted which excluded any non-transition alterations from this upgrade.
Withdrawals from the Beacon Chain will likely be incorporated in the initial upgrade following The Merge. Specifications for both the consensus and execution layers are currently under development.
I possess additional inquiries; where can I direct them?
Join client team developers, ETHStaker members, researchers, and more in the upcoming Merge Community Call on Friday, Sept 9 at 14:00 UTC!
Thank You
Ethereum’s evolution to proof-of-stake has been a long-awaited process. We extend our gratitude to everyone who participated in researching, defining, developing, evaluating, testing, identifying issues, rectifying, or elucidating all the elements that led us to The Merge.
There have been far too many contributors throughout the years to mention here, but you are known. Without all of you in the bazaar, this cathedral could not have been constructed.
when merge? Very 🔜.
Thanks to Joseph Schweitzer and Tomo Saito for providing the cover image for this article!