Ethereum Ropsten Testnet Merge Coming Soon: What to Watch Out For?

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

On May 31, Ethereum core developer Tim Beiko released the Ropsten merger announcement, saying that a new beacon chain has been launched today and it is expected that The Merge will be carried out on the Ropsten network around June 8, thereby converting to the PoS consensus.

According to the announcement, the merger is divided into two steps: it starts with a network upgrade on the consensus layer, triggered by the slot height 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 2, slot height 24000, the Bellatrix upgrade will prepare the Ropsten beacon chain for The Merge. At that time, the CL client will begin monitoring the TTD value on the proof-of-work chain.

Second, a PoW total difficulty value, the Terminal Total Difficulty (TTD), is chosen to trigger the consensus transition. The TTD should be chosen before June 2 or 3 to avoid miners disrupting the transition again, and will be announced on ethereum.org. When this new TTD value is reached or exceeded on Ropsten, the execution layer part of the transition (codenamed Paris) will start.

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

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 individually by the community but no longer monitored by client developers.

Tim Beiko points out 8 things to watch out for:

1. After the merger, if you run a node/validator on the beacon chain, you must now also run an execution client. Similarly, if you run a node on the PoW chain, you *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 a node (i.e. "read" from the chain), you only need a beacon node and no validator client.

4. Similarly, if you run a validator, you need to run a validator client. It is important to note that multiple validators can be run on a single EL <> CL combination.

5. After the merger, validators receive priority fees from transactions, which happens at the execution layer, so these fees are not locked on the beacon chain. To get them, you need to set a "fee recipient" address when launching a validator - make sure the individual has the key to it.

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

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

8. If you are an application/tool ​​developer, The Merge will basically not make any difference.

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

• For Node Operators

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

It is worth emphasizing 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 operators only need the former.

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

• For Pledgers

Validators on the beacon chain will need to run an execution layer client in addition to the consensus layer client after the merge. This is highly recommended before the merge, but validators can outsource these functions to third-party providers. This is possible 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 in the blocks 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 with a single beacon node and execution layer client combination. While this expands the responsibilities of validators, it also gives validators who propose blocks the right to receive priority fees for their associated transactions (currently belonging to miners).

While validator rewards accumulate on the beacon chain and require a subsequent network upgrade to withdraw, transaction fees 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 addresses you control. It is highly recommended that mainnet validators run merges on Ropsten and other testnets before the Ethereum mainnet transitions to proof-of-stake.

The merge is the most complex upgrade to Ethereum to date. To minimize the risk of network disruption, validators cannot withdraw staked ETH during this period.