Ethereum Ropsten testnet merger is imminent: what to pay attention to?

Ethereum public testnet Ropsten is moving to proof-of-stake, one of the final preparations before the main Ethereum blockchain can switch to proof-of-stake consensus.

On May 31st, the core developer of Ethereum, Tim Beiko, released the Ropsten merger announcement, saying that a new beacon chain has been launched today.

According to the announcement, the merger is a two-step process: it starts with a network upgrade on the consensus layer, triggered by slot heights on the beacon chain. The second is the transition of the execution layer from proof-of-work to proof-of-stake, triggered by a specific total difficulty threshold, called the Terminal Total Difficulty (TTD).

First, on June 2nd, with a slot height of 24000, the Bellatrix upgrade will prepare the Ropsten Beacon Chain for The Merge. At that time, the CL client will start monitoring the TTD value on the proof-of-work chain.

Second, choose a PoW total difficulty value, i.e. Total Terminal Difficulty (TTD), to trigger consensus switching. The TTD should be chosen by June 2 or 3 to avoid miners disrupting the transition again and will be announced on When this new TTD value is reached or exceeded on Ropsten, the execution layer portion of the transition (codenamed Paris) will kick in.

Once the execution layer exceeds the TTD, the next block will be generated entirely by beacon chain validators. Once the beacon chain completes this block, the merge is considered complete.

Following 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 independently maintained and upgraded by the community, but are no longer monitored by client developers.

Tim Beiko points out 8 things to watch out for:

1. After the merger, if there is a node/validator running on the beacon chain, an execution client must now also be running. Likewise, if running a node on a PoW chain, *must* run a consensus layer client.

2. EL <> CL nodes communicate using an authenticated port, for which a JWT token needs to be set.

3. The consensus layer client actually consists of two things: a beacon node and a validator client. If you only want to run one node (i.e. “read” from the chain), you only need a beacon node, no validator client.

4. Again, if you run the validator, you need to run the validator client. Note that it is possible to run multiple validators on a single EL <> CL combination.

5. After merging, validators get priority fees from transactions, which happens at the execution layer, so these fees are not locked on the beacon chain. To get them, a “fee receiver” address needs to be set up when starting the validator – making sure the individual has its key.

6. If staking in a certain mining pool, now is the time to start asking how they plan to distribute these fees.

7. If you want to setup a validator on Ropsten to run all of this yourself, there is an example to help get started.

8. If it’s an application/tool ​​developer, then The Merge basically doesn’t change anything.

In the Ropsten merger announcement, some frequently asked questions are also listed.

  • For node operators

If you already have a node running on the beacon chain, you now also need to run an execution layer client. Likewise, running a node on the current proof-of-work network would require running a consensus layer client. In order for them to communicate securely, the JWT token must be passed to each client.

It’s worth emphasizing that while they’re both part of the consensus layer client version, running a beacon node is different from running a validator client. Pledgers must run both, but node operators only need the former.

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

  • for pledgers

In addition to the consensus layer client, the validator on the beacon chain also needs to run the execution layer client after Merge. Before merging, this is highly recommended, but validators can outsource these functions to third-party providers. This is possible because the only data required by the execution layer is the update of the deposit contract.

After merging, validators need to ensure that the transactions in the blocks they create and prove 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 accumulate 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 the consensus client, be sure to set it as the fee recipient as part of the validator client configuration to ensure transaction fees are sent to addresses that are personally controlled. It is highly recommended to have mainnet validators run merges on Ropsten and other testnets before the Ethereum mainnet transitions to proof-of-stake.

The merger is the most complex upgrade to Ethereum to date. To minimize the risk of network disruption, as a validator, staked ETH cannot be withdrawn during this time.

Posted by:CoinYuppie,Reprinted with attribution to:
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 11:23
Next 2022-05-31 11:24

Related articles