- For the last testnet proof-of-stake transition, Goerli will merge with Prater. The combined Goerli/Prater network will retain the Goerli name post-merge.
- Bellatrix, the Prater upgrade readying it for The Merge will happen at epoch 112260, expected at 12:24PM UTC on August 4, 2022.
- After Bellatrix is activated, the Goerli/Prater merge will happen when Goerli hits a total difficulty of 10790000, expected between August 6-12, 2022.
- Post-merge, Goerli's validator set will remain open for individual stakers to run testnets validators. Stakers who wish to start a Goerli/Prater validator can do so at the Prater Launchpad.
Background
After years of work to bring proof-of-stake to Ethereum, we are now well into the final testing stage: testnet deployments!
After several devnets, shadow forks and merges on deprecated testnets, Sepolia was recently transitioned to proof-of-stake. Now, only one more testnet remains: Goerli, and its associated Beacon Chain, Prater.
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, named Bellatrix, at an epoch height on the Beacon Chain and the second, named Paris, upon hitting a Total Difficulty value on the execution layer.
Upgrade Information
Timing
The Merge is a two-step process. It starts with a network upgrade, Bellatrix, 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, Paris, triggered by a specific Total Difficulty threshold, called the Terminal Total Difficulty (TTD).
The Bellatrix upgrade is scheduled for epoch 112260 on the Prater Beacon Chain, expected at 12:24PM UTC on August 4, 2022. Paris, the execution layer's portion of the transition, will trigerred by reaching a Terminal Total Difficulty (TTD) of 10790000 on Goerli, expected between August 6-12, 2022.
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 across the Goerli & Prater testnets. 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
| Name | Version | Link |
|---|---|---|
| Lighthouse | Geardude Clockberg (v2.4.0) | Download |
| Lodestar | v0.41.0 | Download |
| Nimbus | v22.7.0 | Download |
| Prysm | v2.1.4-rc.0 | Download |
| Teku | 22.7.0 | Download |
Execution Layer
| Name | Version | Link |
|---|---|---|
| Besu | 22.7.0-RC3 | Download |
| Erigon | 2022.07.04-alpha | Download |
| go-ethereum (geth) | v1.10.21 | Download |
| Nethermind | 1.13.5 | Download |
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 (CL) client, which runs the proof-of-stake Beacon Chain, and an execution layer (EL) 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. Summary instructions for running a node on the Goerli/Prater network can be found here.
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?
The Goerli/Prater Merge is your last opportunity to ensure that your validators are correctly configured before the mainnet transition. Running through the transition now is strongly recommended to avoid any unexpected issues on mainnet.
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.
The Prater Staking Launchpad has a Merge Readiness Checklist that stakers can use to ensure they have gone through each step of the process. The EthStaker team is also hosting a Merge Validator Preparation Workshop on July 29.
Why is the estimate for the Terminal Total Difficulty date so broad?
The volatility in incremental difficulty per block makes estimating a window for the TTD harder than with a block or epoch height, hence the wider expected range. Users should note that this will also be the case for mainnet's transition due to changes in proof-of-work hash rate.
As an application or tooling developer, what should I do?
With The Merge going live on Goerli, now is your last chance 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 Sepolia, 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, you should be aware that the network will operate entirely under proof-of-stake after The Merge. At that point, mining will no longer be possible on the network.
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?
The EthStaker community has set up a discord channel to answer staker and node operator questions. You can join their discord here and then use the #goerli-prater channel for assistance. As mentioned above, EthStaker will also host a Merge Validator Preparation Workshop on July 29.
Additionally, a Merge Community Call is scheduled for August 12, 14:00 UTC. Client developers and researchers will be available to answer questions from node operators, stakers, infrastructure & tooling providers and community members. Note that this community call is expected to happen after the Goerli/Prater merge.
wen merge?
As of the publication of this post, the time 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 during the Goerli/Prater merge, once clients have feature-complete releases, a slot height will be chosen for the Bellatrix upgrade on the mainnet Beacon Chain and a total 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.
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, š.