Ethereum Merge Preview: Ropsten Testnet Merge Details Are Here

On May 30, Ethereum core developer Tim Beiko released the Ropsten merger announcement, saying that a new beacon chain has been launched and is expected to be merged on the Ropsten network around June 8, thereby converting to PoS consensus. The following is the full text of the announcement:

• Ropsten will be the first long-term testnet to run through The Merge

• The new Ropsten beacon chain will be launched on May 30, 2022, providing consensus for the network

• Ropsten beacon chain will upgrade to merge-compatible protocol rules (Bellatrix) on June 2, 2022 at slot 24000

• After this, a Terminal Total Difficulty (TTD) is chosen to activate The Merge on the Proof of Work chain. Node maintainers will need to manually set the TTD value on their clients.

• Another announcement regarding the exact Total Terminal Difficulty (TTD) for Ropsten Merge will be posted to this blog on June 3, 2022. Users should expect to have their clients configured to work in a short period of time, within a few days of the TTD value being finalized.

background

After years of working on bringing Proof of Stake to Ethereum, we are now entering the final testing phase: testnet deployment!

After testing the client running on Kintsugi, Kiln, and a number of shadow forks, the client team is now ready to run Ropsten - the initial proof-of-work testnet - via The Merge. In preparation, a Ropsten beacon chain has been launched to provide consensus for the network.

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

The Merge differs from previous Ethereum upgrades in two ways. First, node maintainers need to update their consensus and execution layer clients in tandem, rather than just one or the other. Second, the upgrade is activated in two phases: the first at the beacon chain slot height, and the second when the execution layer reaches the total difficulty value.

In light of these circumstances, the Ropsten network, which was scheduled to be deprecated after The Merge, will continue to operate through an upgrade that is being completed during development and earlier than previous network upgrades, which will give the community more time to familiarize themselves with the upgrade process.

NOTE: The client versions listed below are not suitable for Ethereum mainnet's transition to Proof of Stake.

Upgrade information

time

The Merge is a two-step process. It starts with a network upgrade at the consensus layer, triggered by slot height. Next comes the transition from proof-of-work to proof-of-stake at the execution layer, triggered by a specific total difficulty threshold, called 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 time, CL clients will be subject to the TTD value on the proof-of-work chain.

Since the hash rate of the proof-of-work testnet is very unstable, the initial TTD value should be set to a very high value, 1000000000000000000000000. At Ropsten's current hash rate, it will take about 250 years to reach this value.

Once the Bellatrix upgrade occurs on the Beacon chain, a new TTD value will need to be reselected and communicated, which is expected to be reached in a few days. Users will then need to configure their nodes with this new value.

When this new TTD is reached or exceeded on Ropsten, the execution layer portion of the transition, codenamed Paris, will be initiated. It is also important to note that hashrate on Ropsten is notoriously variable, so the actual time when the terminal total difficulty occurs may be uncertain.

When the execution layer exceeds TTD, the next block will be generated entirely by the beacon chain validators. Once the beacon chain completes this block, we consider The Merge to be complete. Assuming normal network conditions, this process takes about 2 periods, or about 13 minutes, to complete the first block after TTD.

Finally, a new JSON-RPC block tag returns the last completed block, or an error if no such post-merge block exists. This tag can be used by applications to check if The Merge has completed. Similarly, smart contracts can query the DIFFICULTY OpCode (0x44) (renamed PREVRANDAO after the merge) to determine if The Merge has occurred. We recommend that infrastructure providers monitor overall network stability as well as the final status.

Client version

The following client versions support The Merge on the Ropsten testnet. Node maintainers must be running both the execution layer and consensus layer clients to remain on the network during and after The Merge.

As mentioned above, the terminal total difficulty value of the following versions is hardcoded to 10000000000000000000000000, and needs to be manually updated after activating the Bellatrix upgrade on the beacon chain.

When choosing which client to run, special attention should be paid to the risks of validators running majority clients on EL and CL. An explanation of these risks and their consequences can be found here, as well as an estimate of the current distribution of EL and CL clients and a guide to switching from one client to another.

Note: If you previously downloaded a version of the Ropsten client with a TTD of 43531756765713534, you must either update your version as specified here or manually overwrite the TTD to 10000000000000000000000000.

Lodestar Note: The Ropsten TTD value of the latest Lodestar version v0.37.0 is 43531756765713534. In order to be compatible with Ropsten Merge, the TTD used now is 10000000000000000000000000. Lodestar users need to manually override this value.

Geth Note: The latest go-ethereum (geth) version Sharblu (v1.10.18) has a Ropsten TTD of 43531756765713534. To be compatible with Ropsten Merge, the TTD used is now 100000000000000000000000000, and geth users must:

• Build from the latest master branch of the source code

• Use the latest Docker image

• Manually override TTD by running the following command when starting the client: --override.terminaltotaldifficulty 1000000000000000000000000.

Upgrade Specifications

The key changes in the consensus of The Merge refer to two aspects:

• The consensus layer has changed under the bellatrix directory of the consensus specification repository

• The implementation layer changes according to the Paris spec in the implementation spec repository.

In addition to this, two other specifications cover how consensus and execution layer clients interact:

• The Engine API specified in the execution-apis repository is used for communication between the consensus layer and the execution layer.

• Optimistic Sync, specified in the sync folder of the consensus specification repository, is used by the consensus layer to import blocks when the execution layer client syncs and provides a partial view of the chain head from the former to the latter.

FAQ

As a node maintainer , what should I do?

After the merger, Ethereum full nodes will combine consensus layer clients that run the proof-of-stake beacon chain and execution layer clients that manage user state and run transaction-related computations. They communicate over authenticated ports using a new set of JSON RPC methods called the Engine API. EL and CL clients authenticate each other using JWT keys. Node maintainers should refer to their client's documentation for instructions on how to generate and configure these files.

In other words, if you already run a node on the beacon chain, you now also need to run an execution layer client. Similarly, if you run a node on the current proof-of-work network, you also need to run a consensus layer client. In order for them to communicate securely, JWT tokens must be transmitted to each client.

It is important to emphasize that while they are both part of the consensus layer client version, running a beacon node is different from running a validator client. Stakers must run both, but node maintainers only need to run the former. This post explains the difference between the two in detail.

Also, please note that each tier will maintain an independent set of peers and expose its own API. Both the Beacon and JSON RPC APIs will continue to function as expected.

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

What do I need to do as a staker?

As mentioned above, validators on the beacon chain will need to run an execution layer client in addition to the consensus layer client after The Merge. It is highly recommended to do this before the merge, but validators can outsource these functions to third-party vendors. This is feasible because the only data required by the execution layer is updates to the deposit contract.

After the merger, validators need to ensure that the transactions they create and prove on the block are valid. To do this, each beacon node must be paired with an execution layer client. It is important to note that multiple validators can still be paired with a single beacon node and execution layer client combination. While this expands the responsibility of the validator, it also gives the validator who proposed the block the right to receive the priority fees for its associated transactions (currently belonging to the miner).

While validator rewards are earned on the beacon chain and require a subsequent network upgrade to withdraw, transaction fees will continue to be paid, burned, and distributed on the execution layer. Validators can specify any Ethereum address as the recipient of transaction fees.

After updating your consensus client, be sure to set the fee recipient as part of your validator client configuration to ensure transaction fees are sent to an address you control.

If you use a third-party provider for staking, it is up to your chosen provider to decide how these fees are allocated.

The testnet upgrade is the final stage for validators to ensure their setup is working properly and iron out issues.

We strongly recommend that mainnet validators run The Merge on Ropsten and other testnets before the Ethereum mainnet transitions to Proof of Stake.

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

With The Merge live on Ropsten, now is the time to make sure your products are transitioning through Proof of Stake and working properly after the merge. As explained in the previous post, The Merge has minimal impact on the subset of contracts deployed on Ethereum, none of which should be broken apart. Additionally, the lion’s share of user API endpoints remains 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 make sure your front-end code, tooling, deployment pipelines, and other off-chain components work properly. We strongly encourage developers to run a full test and deployment cycle on Ropsten (or Kiln), and report any issues with tools or dependencies to the maintainers of those projects.

As an Ethereum user or ETH holder, what do I need to do?

No. Ethereum mainnet is not affected by this testnet. A follow-up announcement will be made on this blog prior to the mainnet transition.

What do I need to do as a miner?

No. If you mine on Ethereum mainnet or Ropsten, you should be aware that after The Merge, each network will run entirely on Proof of Work. At that time, it will no longer be possible to mine on the network.

It is expected that around June 8, 2022 on Ropsten and later this year on Ethereum mainnet, you will no longer be able to mine.

As a validator , can I get my stake back ?

No. The Merge is the most complex upgrade to Ethereum to date. To minimize the risk of network disruption, we took a minimalist approach that excluded any non-transitional changes in this upgrade.

Withdrawals from the beacon chain will likely be introduced in the first upgrade after The Merge. Specifications for the consensus and execution layers are being developed.

Where can I ask more questions ?

The Merge community hotline is scheduled to be launched at 14:00 UTC on June 3. Client developers and professionals will answer questions from node maintainers, stakers, infrastructure and tool vendors, and community members.

When will the merger take place?

As of the time of this posting, there is no confirmed date for the Ethereum mainnet Proof of Stake transition. Any source that does not release this information is likely a scam. Subsequent updates will be posted on this blog. Please stay alert!

Assuming Ropsten does not find any issues, Ethereum’s other testnets will run through The Merge once client testing is complete. 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 release new versions to enable The Merge on the mainnet. This information will be explained in this blog and other community announcements.

So far, no issues have arisen. However, if any issues are discovered during the process or if the test coverage is deemed insufficient, these issues will be addressed before continuing with the deployment process.

Only then will it be possible to estimate the exact date of The Merge.

To be continued.