- Note: on July 5, 2022, the recommended releases for go-ethereum and Erigon were modified. See “Client Releases” for details.
- Sepolia will be the second of three public testnets to run through The Merge.
- The network will transition to proof-of-stake when the total difficulty on the proof-of-work chain exceeds 17,000,000,000,000,000, which is expected to occur around in the next few days.
- Post-merge, Sepolia will have a permissioned validator set, like existing proof-of-authority testnets. Goerli/Prater, which will merge at a later date, will maintain an open validator set to allow for stakers to test the transition.
Background
After years of work to bring proof-of-stake to Ethereum, we are now well into the final testing stage: testnet deployments!
With Ropsten already transitioned to proof-of-stake and shadow forks continuing regularly, Sepolia is now ready for The Merge. After Sepolia, only Goerli/Prater will need to be merged before moving to mainnet. Other testnets will be considered deprecated post-merge, as explained in a recent post.
The Merge is different from previous Ethereum upgrades in two ways. First, node operators need to update both their consensus layer (CL) and execution layer (EL) clients in tandem, rather than just one of the two. Second, the upgrade activates in two phases: the first at an epoch height on the Beacon Chain and the second upon hitting a Total Difficulty value on the execution layer.
Sepolia has already run through the Bellatrix upgrade on the Beacon Chain. We now announce the details of the second phase of the transition: hitting the Terminal Total Difficulty.
Upgrade Information
Timing
The Merge is a two-step process. It starts with a network upgrade on the consensus layer, triggered by an epoch height. This is followed by the execution layer’s transition from proof-of-work to proof-of-stake, triggered by a specific Total Difficulty threshold, called the Terminal Total Difficulty (TTD).
On June 20, 2022, at epoch 100, the Bellatrix upgrade prepared the Sepolia Beacon Chain for The Merge. At that point, CL clients began listening for a TTD value to be hit on the proof-of-work chain.
Because the hash rate of proof-of-work testnets is very volatile, the TTD value was first set to an exceedingly high value, 100000000000000000000000. At Sepolia’s current hash rate, it would take hundreds of years to reach this value.
With Bellatrix now live, an updated TTD value of 17000000000000000 has been chosen for the transition. It is expected to be hit within the next few days. When this new TTD is hit or exceeded, the execution layer part of the transition, codenamed Paris, will start. Again, note that hash rate on Sepolia is notoriously variable, so the actual time at which the Terminal Total Difficulty takes place may fluctuate.
Once the execution layer has exceeded the TTD, the next block will be solely produced by a Beacon Chain validator. We consider The Merge to have been completed once the Beacon Chain has finalized this block. Assuming normal network conditions, this should happen 2 epochs, or approximately 13 minutes, after the first post-TTD block is hit!
A new JSON-RPC block tag, finalized, returns the latest finalized block or an error if no such post-merge block exists. This tag can be used for applications to check if The Merge has been completed. Similarly, smart contracts can query the DIFFICULTY opcode (0x44), renamed to PREVRANDAO post-merge, to determine if The Merge has happened. We recommend infrastructure providers monitor overall network stability in addition to finalization status.
Client Releases
The following client releases support The Merge on the Sepolia testnet. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.
When choosing which client to run, validators should be especially mindful of the risks of running a majority client on both the EL and CL. An explainer of these risks and their consequences can be found here. An estimate of current EL and CL client distribution and guides for switching from one client to another can be found here.
Consensus Layer
Execution Layer
| Name | Version | Link |
|---|---|---|
| Besu | See “Besu Note” below | See “Besu Note” below |
| Erigon | v2022.07.01 | Download |
| go-ethereum (geth) | See “Geth Note” below | |
| Nethermind | 1.13.4 | Download |
Besu Note: to be compatible with the Sepolia merge, Besu users will need to perform a manual Terminal Total Difficulty override. To do so, users should run the latest Besu release, 22.4.3 as of the publication of this post, and do the following:
- If using TOML configuration files, add the following line: override-genesis-config=[“terminalTotalDifficulty=17000000000000000”]
- If starting the node using the CLI, add the following flag: –override-genesis-config=”terminalTotalDifficulty=17000000000000000″
More information about overriding the TTD can be found in the Ropsten TTD Announcement.
Geth Note: a regression introduced in go-ethereum v1.10.20 makes it unsuitable for use as part of the Sepolia merge. Users of Geth should instead run the master branch until a new release is out. Instructions to do so are available here.
Upgrade Specifications
Consensus-critical changes for The Merge are specified in two places:
- The consensus layer changes, under the bellatrix directory of the consensus-specs repository
- The execution layer changes, under the Paris spec in the execution-specs repository
In addition to these, two other specifications cover how the consensus and execution layer clients interact:
- The Engine API, specified in the execution-apis repository, is used for communication between the consensus and execution layers
- Optimistic Sync, specified in the sync folder of the consensus-specs repository, is used by the consensus layer to import blocks as the execution layer client is syncing and to provide a partial view of the head of the chain from the former to the latter
FAQ
As a node operator, what should I do?
Post-merge, an Ethereum full node will combine a consensus layer client, which runs the proof-of-stake Beacon Chain, and an execution layer client, which manages the user-state and runs the computations associated with transactions. These communicate over an authenticated port using a new set of JSON RPC methods called the Engine API. The EL and CL client authenticate each other using a JWT secret. Node operators should refer to their clients’ documentation for instructions about how to generate and configure these.
In other words, if you were already running a node on the Beacon Chain, you now also need to run an execution layer client. Similarly, if you were running a node on the current proof-of-work network, you will need to run a consensus layer client. For them to communicate securely, a JWT token must be passed to each client.
It is worth emphasizing that while they are both part of consensus layer client releases, running a Beacon Node is distinct from running a Validator Client. Stakers must run both, but node operators only need the former. This post explains the difference between both components in more detail.
Also, note that each layer will maintain an independent set of peers and expose its own APIs. The Beacon and JSON RPC APIs will both continue working as expected.
As a staker, what do I need to do?
Sepolia’s validator set is permissioned, so unless you have already been included as a Sepolia validator, no action is required.
Goerli/Prater’s transition to proof-of-stake, which will be announced at a later date, will be open to all validators. Below are some notes to prepare for this. Again, no action is required now.
As explained above, validators on the Beacon Chain will need to run an execution layer client after The Merge, in addition to their consensus layer clients. Pre-merge, this was strongly recommended, but validators could have outsourced these functions to third-party providers. This was possible because the only data required on the execution layer were updates to the deposit contract.
Post-merge, validators need to ensure that transactions in blocks that they create and attest to are valid. To do this, each beacon node must be paired with an execution layer client. Note that multiple validators can still be paired to a single beacon node & execution layer client combo. While this expands validators’ responsibilities, it also gives a validator who proposes a block the right to its associated transaction priority fees (which currently go to miners).
While validator rewards accrue on the Beacon Chain and will require a subsequent network upgrade to be withdrawn, transaction fees will continue to be paid, burned, and distributed on the execution layer. Validators can specify any Ethereum address as a recipient for transaction fees.
After updating your consensus client, be sure to set the fee recipient as part of your validator client configurations to ensure transaction fees are sent to an address you control.
If you have staked using a third-party provider, it is up to your selected provider to specify how these fees are allocated.
If you would like to test running a validator on post-merge Ethereum, instructions are available on the Ropsten staking launchpad.
As an application or tooling developer, what should I do?
With The Merge going live on Sepolia, now is the time to ensure that your product works as expected through the proof-of-stake transition and in a post-merge context. As explained in a previous post, The Merge will have only minimal impact on a subset of contracts deployed on Ethereum, none of which should be breaking. Additionally, the lion’s share of user API endpoints remain stable (unless you use proof-of-work specific methods such as eth_getWork).
That said, most applications on Ethereum involve much more than on-chain contracts. Now is the time to ensure that your front-end code, tooling, deployment pipeline and other off-chain components work as intended. We strongly recommend that developers run through a complete testing & deployment cycle on Ropsten (or Kiln) and report any issues with tools or dependencies to those projects’ maintainers. If you are unsure where to open an issue, please use this repository.
Additionally, you should note that all testnets aside from Sepolia and Goerli will be deprecated post-merge. If you are a user of Ropsten, Rinkeby or Kiln, you should plan to migrate to Goerli or Sepolia. More information about this can be found here.
As an Ethereum user or Ether holder, is there anything I need to do?
No. The Ethereum mainnet is not affected by this testnet. Subsequent announcements will be made on this blog before mainnet’s transition.
As a miner, is there anything I need to do?
No. If you are mining on the Ethereum mainnet or Sepolia, you should be aware that each network will operate entirely under proof-of-stake after The Merge. At that point, mining will no longer be possible on the network.
This is expected in the next few days on Sepolia and later this year for the Ethereum mainnet.
As a validator, can I withdraw my stake?
No. The Merge is the most complicated upgrade to Ethereum to date. To minimize risks of network disruptions, a minimal approach was taken which excluded any non-transition changes from this upgrade.
Withdrawals from the Beacon Chain will likely be introduced in the first upgrade after The Merge. Specifications for both the consensus and execution layers are in progress.
I have more questions, where can I ask them?
A Merge Community Call is scheduled for July 15, 14:00 UTC. Client developers and researchers will be available to answer questions from node operators, stakers, infrastructure & tooling providers and community members.
wen merge?
As of the publication of this post, the date for the Ethereum mainnet proof-of-stake transition has not been set. Any source claiming otherwise is likely to be a scam. Updates will be posted on this blog. Please stay safe!
Assuming no issues are found with Sepolia, once client testing is complete, Ethereum’s other EL testnet, Goerli, will run through The Merge with the Prater CL testnet. Once Goerli/Prater have successfully transitioned and stabilized, an epoch will be chosen for the Bellatrix upgrade on the mainnet Beacon Chain and a difficulty value will be set for the mainnet transition. Clients will then make releases that enable The Merge on mainnet. These will be announced on this blog and in other community publications.
This assumes no issues are found. However, if issues are found at any point in the process or test coverage is judged to be insufficient, these things will be addressed before continuing with the deployment process.
Only then will it be possible to estimate the exact date for The Merge.
In other words, 🔜.
Thank you to Justin Chrn for the cover image.
