Ethereum merge preview: Ropsten testnet merge details are here

On May 30, the core developer of Ethereum, Tim Beiko, released the Ropsten merger announcement, saying that a new beacon chain has been launched. Below is the full text of the announcement:

  • Ropsten will be the first long-term testnet to run through The Merge
  •  New Ropsten Beacon Chain Launches May 30, 2022, Providing Consensus for the Network
  •  Ropsten Beacon Chain will be upgraded to merge compatible protocol rules (Bellatrix) at slot 24000 on June 2, 2022
  •  Thereafter, select Total Terminal Difficulty (TTD) 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 about Ropsten Merge’s exact Terminal Total Difficulty (TTD) will be posted to this blog on June 3, 2022. Users should expect to have their clients provisioned within a few days after the TTD value is determined.

background

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

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

Following the Ropsten transition, two other testnets (Goerli and Sepolia) will transition to proof-of-stake before shifting their focus to mainnet. Other testnets, such as Rinkeby and Kovan, may be independently maintained and upgraded by the community, but are 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 successively, not just one of them. Second, the upgrade is activated in two stages: the first stage is at the slot height of the beacon chain, and the second stage is when the execution layer reaches the total difficulty value.

Given these circumstances, the Ropsten network, which is planned to be deprecated after The Merge, will continue to function through an upgrade that was done during development earlier than previous network upgrades, which will allow the community more time to familiarize themselves with the upgrade process.

Note: The client versions listed below are not suitable for transitioning to Proof of Stake from the Ethereum mainnet.

Upgrade information

time

The Merge needs to be done in two steps. It starts with a network upgrade at the consensus layer and is triggered by slot height. Next is the transition of the execution layer from proof-of-work to proof-of-stake, triggered by a specific total difficulty threshold, called Total Terminal Difficulty (TTD).

On June 2, 2022, at slot 24000, the Bellatrix upgrade will prepare the Ropsten Beacon Chain for The Merge. At that time, the CL client 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 volatile, the initial TTD value should be set to a very high value, 100000000000000000000000. At Ropsten’s current hash rate, it would take about 250 years to reach this value.

Once the Bellatrix upgrade occurs on the Beacon chain, a new TTD value needs to be re-selected and informed, 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, is initiated. It is also important to note that the variable hash rate on Ropsten is well known, so the actual time at which the terminal total difficulty occurs may be uncertain.

When the execution layer exceeds the TTD, the next block will be generated entirely by beacon chain validators. Once the Beacon Chain completes this block, we consider The Merge to be complete. Assuming normal network conditions, the process will take approximately 2 periods, or about 13 minutes, when completing the first post-TTD block.

Eventually, 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 the app to check if The Merge is complete. Likewise, a smart contract can query DIFFICULTY OpCode (0x44) (renamed PREVRANDAO after merging) to determine if The Merge has occurred. We recommend that infrastructure providers monitor overall network stability and end state.

client version

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

As mentioned above, the total difficulty value of the terminal for the following versions is hardcoded as 10000000000000000000000 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 risk of the validator running a majority of clients on the 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 guidance for switching from one client to another.

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

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

Geth Note: The latest go-ethereum (geth) version, Sharblu (v1.10.18), has a Ropsten TTD value of 43531756765713534. For compatibility with Ropsten Merge, the TTD used now is 1000000000000000000000000, geth users must:

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

upgrade specification

The Merge’s consensus key changes refer to two aspects:

  •  Consensus layer changes under the bellatrix directory of the consensus specification repository
  •  The execution layer changes according to the Paris spec in the execution specification repository,

In addition to this, two other specifications cover how the consensus layer 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 performing 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 the consensus layer client that runs the proof-of-stake beacon chain and the execution layer client that manages user state and runs transaction-related calculations. They communicate over ports that require authentication 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 customers’ documentation for instructions on how to generate and configure these files.

In other words, if you already have a node running on the beacon chain, you now also need to run an execution layer client. Likewise, if you are running a node on the current proof-of-work network, you will also need to run a consensus layer client. In order for them to communicate securely, the JWT token must be delivered 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 not the same as running a validator client. Pledgers must run both, but node maintainers only need to run the former. This article explains the difference between the two in detail.

Also, note that each layer will maintain a separate set of peers and expose its own API. Both Beacon and JSON RPC APIs will continue to function as expected.

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

What do I need to do as a staker?

As mentioned above, validators on the beacon chain need to run execution-layer clients after The Merge in addition to consensus-layer clients. This is strongly recommended before merging, but validators can outsource these functions to third-party vendors. This is possible since the only data required by the execution layer is the update of the deposit contract.

After merging, validators need to ensure that they create and prove transactions on the block are valid. To do this, each beacon node must be paired with an execution layer client. Note that multiple validators can still be paired with a single beacon node and execution layer client combination. While this expands the responsibilities of validators, it also empowers validators who propose blocks to receive priority fees for their associated transactions (which currently belong to miners).

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

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

If you use a third-party provider for staking, it’s up to the provider you choose to allocate these fees.

The testnet upgrade is the final stage for validators to ensure their setup is working and issues are resolved.

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

As an app or tool developer what should I do?

With The Merge live on Ropsten, now is the time to make sure your product transitions through Proof of Stake and works properly post-merger. As explained in the previous article, The Merge has minimal impact on the subset of contracts deployed on Ethereum and none of them should be split. Also, the maximum 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 frontend code, tooling, deployment pipelines, and other off-chain components are working properly. We strongly recommend that developers 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.

What do I need to do as an Ethereum user or ETH holder?

No. The Ethereum mainnet is not affected by this testnet. Follow-up announcements will be made on this blog ahead of the mainnet transition.

What do I need to do as a miner?

No. If you mine on the Ethereum mainnet or Ropsten, you should know that after The Merge, each network will operate entirely under the proof-of-work mechanism. At that time, mining will not be possible on the network.

Expected to be around June 8, 2022 on Ropsten and on the Ethereum mainnet later this year, you will no longer be able to mine.

As a validator can I get my stake back ?

Can’t. The Merge is the most complex upgrade to Ethereum to date. To minimize the risk of network outages, we have adopted a minimal approach that excludes 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 layer and execution layer are under development.

Where can I ask more questions ?

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

When will it be merged?

As of this writing, no date has been set for the Ethereum mainnet proof-of-stake transition. Any unofficially published source could be a scam. Subsequent updates will be posted on this blog. Please stay vigilant!

Assuming that Ropsten finds no issues, other testnets for Ethereum 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. The client will then release a new version enabling The Merge on mainnet. This information will be explained in this blog and other community announcements.

So far, no problems have occurred. However, if any issues are discovered during the process or the test coverage is deemed insufficient, those issues will be resolved before continuing with the deployment process.

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

To be continued.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/ethereum-merge-preview-ropsten-testnet-merge-details-are-here/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-05-31 23:14
Next 2022-05-31 23:16

Related articles