Ropsten Merge Announcement | Ethereum Foundation Blog

• Ropsten will be the first longstanding testnet to run through The Merge
• A new Ropsten Beacon Chain was launched on May 30, 2022 to provide consensus to the network
• The Ropsten Beacon Chain will upgrade to merge-compatible protocol rules (Bellatrix) at slot 24000, expected on June 2, 2022
• After this, a Terminal Total Difficulty (TTD) will be chosen to activate The Merge on the proof-of-work chain. Node Operators will need to manually set this value on their clients.
• June 3 update: the exact Terminal Total Difficulty for the Ropsten Merge is 50000000000000000. A subsequent announcement explains how node operators and stakers can ensure their clients are ready for the upgrade. Please update your client’s TTD before June 7, 2022.

Background

After years of work to bring proof-of-stake to Ethereum, we are now entering the final testing stage: testnet deployments!

Having tested client implementations on Kintsugi ?, Kiln ?? and many shadow forks, client teams are now ready to run Ropsten — the oldest proof-of-work testnet — through The Merge. In preparation, a Ropsten Beacon Chain has been launched to provide consensus to the network.

After the Ropsten transition, two more testnets (Goerli and Sepolia) will be transitioned to proof-of-stake before focus shifts to mainnet. Other testnets, such as Rinkeby and Kovan, may be maintained and upgraded separately by the community but will no longer be monitored by client developers.

The Merge is different from previous Ethereum upgrades in two ways. First, node operators need to update both their consensus and execution layer clients in tandem, rather than just one of the two. Second, the upgrade activates in two phases: the first at a slot height on the Beacon Chain and the second upon hitting a Total Difficulty value on the execution layer.

Given these circumstances, the Ropsten network, which is intended to be deprecated after The Merge, will run through the upgrade earlier in the development process than previous network upgrades. This will give the community more time to become familiar with the upgrade process.

Note: Client releases listed below will not be suitable for the Ethereum mainnet’s transition to proof-of-stake.

Upgrade Information

Timing

The Merge is a two-step process. It starts with a network upgrade on the consensus layer, triggered by a slot 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 2, 2022, at slot 24000, the Bellatrix upgrade will prepare the Ropsten Beacon Chain for The Merge. At that point, CL clients will begin 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 will first be set to an exceedingly high value, 100000000000000000000000. At Ropsten’s current hash rate, it would take ~250 years to reach it.

Once the Bellatrix upgrade has happened on the Beacon Chain, a new TTD value, which is expected to be reached a few days later, will be chosen and announced. Users will then need to configure their node with this new value. Instructions for doing so with each client are available here.

When this new TTD is hit or exceeded on Ropsten, the execution layer part of the transition, codenamed Paris, will start. Again, note that hash rate on Ropsten 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 Ropsten testnet. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.

As mentioned above, the following releases have a hardcoded Terminal Total Difficulty value of 100000000000000000000000 which will need to be manually updated after the Bellatrix upgrade has been activated on the Beacon Chain.

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.

Note: if you had previously downloaded a client release with a Ropsten TTD of 43531756765713534, you must either update your release or manually override the TTD to 100000000000000000000000 as specified here.

Consensus Layer

Lodestar Note: the latest Lodestar release, v0.37.0, has an outdated Ropsten TTD value of 43531756765713534. To be compatible with the Ropsten Merge, which now uses a TTD of 100000000000000000000000, Lodestar users will need to manually override this value. Instructions about doing so can be found on the team’s release announcement post.

Execution Layer

Geth Note: the latest go-ethereum (geth) release, Sharblu (v1.10.18), has an outdated Ropsten TTD value of 43531756765713534. To be compatible with the Ropsten Merge, which now uses a TTD of 100000000000000000000000, geth users must either:

• Build from source on the latest master branch
• Use the latest Docker image
• Manually override the TTD, by running the following command when starting the client: –override.terminaltotaldifficulty 100000000000000000000000.

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.

Finally, remember to check back on June 3rd for an announcement on this blog of the final Ropsten TTD value.

As a staker, what do I need to do?

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.

Testnet upgrades are the last chance for validators to ensure their setups work as expected and resolve issues. Information about running a validator on the Ropsten Beacon Chain in preparation for The Merge can be found on the Ropsten staking launchpad.

We strongly recommend that mainnet validators run through The Merge on Ropsten and other testnets before the Ethereum mainnet transitions to proof-of-stake.

As an application or tooling developer, what should I do?

With The Merge going live on Ropsten, 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.

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 Ropsten, 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 around June 8, 2022 on Ropsten 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 June 3, 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 Ropsten, once client testing is complete, Ethereum’s other testnets, will run through The Merge. Once Goerli and Sepolia have successfully transitioned and stabilized, a slot height will be chosen for the Bellatrix upgrade on the 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, ?.