Ropsten Merge: A New Era for Ethereum Unfolds

• Ropsten will be the initial enduring testnet to undergo The Merge
• A fresh Ropsten Beacon Chain was initiated on May 30, 2022, to offer consensus for the network
• The Ropsten Beacon Chain will enhance to merge-compatible protocol guidelines (Bellatrix) at slot 24000, anticipated on June 2, 2022
• Subsequently, a Terminal Total Difficulty (TTD) will be established to trigger The Merge on the proof-of-work chain. Node Operators will be required to manually configure this value on their clients.
• June 3 update: the definitive Terminal Total Difficulty for the Ropsten Merge is 50000000000000000. A following announcement clarifies how node operators and stakers can ensure their clients are prepared for the upgrade. Kindly update your client’s TTD before June 7, 2022.

Background

After extensive effort to implement proof-of-stake on Ethereum, we are now entering the concluding testing phase: testnet rollouts!

Following trials of client versions on Kintsugi 🍵, Kiln 🔥🧱 and numerous shadow forks, client teams are now prepared to execute Ropsten — the oldest proof-of-work testnet — during The Merge. To facilitate this, a Ropsten Beacon Chain has been initiated to deliver consensus to the network.

Post the Ropsten transition, two additional testnets (Goerli and Sepolia) will be transitioned to proof-of-stake prior to shifting focus to the mainnet. Other testnets, such as Rinkeby and Kovan, may be preserved and upgraded independently by the community but will no longer be overseen by client developers.

The Merge differs from earlier Ethereum upgrades in two significant ways. Firstly, node operators must update both their consensus and execution layer clients simultaneously, as opposed to just one. Secondly, the upgrade triggers in two stages: the first at a specific slot height on the Beacon Chain and the second when a Total Difficulty level is reached on the execution layer.

Considering these factors, the Ropsten network, intended to be retired post The Merge, will go through the upgrade earlier in the development timeline than previous network upgrades. This will allow the community additional time to acclimatize to the upgrade procedure.

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

Upgrade Information

Timing

The Merge involves a two-step procedure. It commences with a network upgrade on the consensus layer, initiated by a slot height. This is succeeded by the execution layer’s shift from proof-of-work to proof-of-stake, triggered by a designated Total Difficulty limit, known as the Terminal Total Difficulty (TTD).

On June 2, 2022, at slot 24000, the Bellatrix upgrade will ready the Ropsten Beacon Chain for The Merge. At that moment, CL clients will begin monitoring for a TTD threshold to be attained on the proof-of-work chain.

Due to the highly fluctuating hash rate of proof-of-work testnets, the TTD will initially be set at a remarkably high figure, 100000000000000000000000. With Ropsten’s current hash rate, it would require approximately 250 years to reach that.

Once the Bellatrix upgrade has been executed on the Beacon Chain, a new TTD figure, which is anticipated to be achieved within a few days thereafter, will be established and publicized. Users will then need to adjust their node with this updated value. Guidance for doing this with each client is available here.

When this new TTD is reached or surpassed on Ropsten, the execution layer aspect of the transition, codenamed Paris, will commence. Again, note that the hash rate on Ropsten is notoriously inconsistent, so the actual timing of the Terminal Total Difficulty event may vary.

Once the execution layer has surpassed the TTD, the subsequent block will be produced solely by a Beacon Chain validator. We regard The Merge as completed once the Beacon Chain has finalized this block. Given typical network circumstances, this should occur 2 epochs, or roughly 13 minutes, after the inaugural post-TTD block is achieved!

A new JSON-RPC block tag, finalized, provides the latest finalized block or an error if no such block exists post-merge. This tag can assist applications in verifying if The Merge has been actualized. Similarly, smart contracts can check the DIFFICULTY opcode (0x44), rebranded to PREVRANDAO post-merge, to ascertain if The Merge has occurred. We recommend that infrastructure providers track overall network stability in addition to finalization.status.

Client Releases

The subsequent client releases facilitate The Merge on the Ropsten test network. Node operators are required to operate both an execution and consensus layer client to stay connected to the network during and after The Merge.

As stated earlier, the upcoming releases have a fixed Terminal Total Difficulty value of 100000000000000000000000, which will need to be manually modified after the Bellatrix upgrade becomes active on the Beacon Chain.

When selecting which client to operate, validators should particularly consider the hazards of running a majority client on both the EL and CL. An explanation of these hazards and their repercussions can be found here. An approximation of the current EL and CL client distribution and resources for transitioning from one client to another are located here.

Note: if you had earlier acquired a client release with a Ropsten TTD of 43531756765713534, you are required to either update your release or manually override the TTD to 100000000000000000000000 as indicated here.

Consensus Layer

Lodestar Note: the recent Lodestar release, v0.37.0, possesses an outdated Ropsten TTD value of 43531756765713534. To ensure compatibility with the Ropsten Merge, which currently employs a TTD of 100000000000000000000000, Lodestar users must manually set this value. Guidelines on how to do this are available on the team’s release announcement page.

Execution Layer

Geth Note: the most recent go-ethereum (geth) release, Sharblu (v1.10.18), has an outdated Ropsten TTD value of 43531756765713534. To achieve compatibility with the Ropsten Merge, which now utilizes a TTD of 100000000000000000000000, geth users need to either:

• Compile from source on the latest master branch
• Utilize the latest Docker image
• Manually override the TTD, via running the following command when initiating the“`html
  –override.terminaltotaldifficulty 100000000000000000000000.

Upgrade Specifications

Crucial consensus alterations for The Merge are outlined in two locations:

• The consensus layer alterations, located under the bellatrix directory of the consensus-specs repository
• The execution layer alterations, found under the Paris spec in the execution-specs repository

Besides these, two additional specifications address how the consensus and execution layer clients engage:

• The Engine API, defined in the execution-apis repository, facilitates communication between the consensus and execution layers
• Optimistic Sync, detailed in the sync folder of the consensus-specs repository, is utilized by the consensus layer to incorporate blocks while the execution layer client is syncing and to provide a partial perspective of the head of the chain from the former to the latter

FAQ

As a node operator, what actions should I take?

Following the merge, an Ethereum full node will integrate a consensus layer client, responsible for operating the proof-of-stake Beacon Chain, along with an execution layer client that oversees the user state and processes the computations linked to transactions. These layers communicate through an authenticated port using a new array of JSON RPC methods labeled the Engine API. The EL and CL clients authenticate one another using a JWT secret. Node operators should consult their clients’ documentation for guidelines on generating and configuring these.

In simpler terms, if you were previously operating a node on the Beacon Chain, you must now also run an execution layer client. Likewise, if you operated a node on the current proof-of-work network, you will need to deploy a consensus layer client. For secure communication, a JWT token needs to be transferred to each client.

It is critical to note that while both are incorporated into consensus layer client releases, operating a Beacon Node is separate from managing a Validator Client. Stakers must operate both, but node operators need only the former. This post clarifies the distinction between both components further.

Also, be aware that each layer will sustain a distinct set of peers and present its own APIs. The Beacon and JSON RPC APIs will continue functioning as anticipated.

Finally, remember to return on June 3rd for a notification on this blog regarding the final Ropsten TTD value.

As a staker, what actions do I need to perform?

As previously mentioned, validators on the Beacon Chain must run an execution layer client subsequent to The Merge, in addition to their consensus layer clients. Before the merge, while this was highly suggested, validators could have delegated these functions to external providers. This was feasible because the execution layer only required data updates to the deposit contract.

Post-merge, validators must ensure that transactions in blocks they produce and endorse are accurate. To accomplish this, every beacon node has to be paired with an execution layer client. Remember, multiple validators can still associate with a single beacon node & execution layer client combination. While this expands the validators’ duties, it further entitles a validator proposing a block to receive the associated transaction priority fees (currently awarded to miners).

While validator rewards accumulate on the Beacon Chain and will necessitate a subsequent network upgrade for withdrawal, transaction fees will persist in being paid, burned, and allocated on the execution layer. Validators can designate any Ethereum address as a recipient for transaction fees.

After updating your consensus client, ensure to configure the fee recipient within your validator client settings, to guarantee transaction fees are directed to an address under your control.

If you have staked through a third-party provider, it is the responsibility of your chosen provider to clarify how these fees are distributed.

Testnet upgrades are the last opportunity for validators to verify their configurations operate as intended and to rectify any issues. Information regarding running a validator on the Ropsten Beacon Chain in preparation for The Merge can be accessed on the Ropsten staking launchpad.

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

As an application or tooling developer, what actions should I take?

With The Merge being implemented on Ropsten, it’s vital to ensure that your product functions as anticipated throughout the proof-of-stake transition and in a post-merge environment. As described in a prior post, The Merge will have a minimal influence on a segment of contracts deployed on Ethereum, none of which should encounter disruptions. Moreover, the majority of user API endpoints
“`remain consistent (unless you utilize proof-of-work specific techniques such as eth_getWork).

That being said, the majority of applications on Ethereum encompass significantly more than solely on-chain contracts. Now is the moment to verify that your front-end code, tools, deployment pipeline, and other off-chain elements function as expected. We highly suggest that developers conduct a comprehensive testing & deployment cycle on Ropsten (or Kiln) and report any concerns regarding tools or dependencies to the maintainers of those projects. If you are uncertain about where to report an issue, please utilize this repository.

As an Ethereum user or Ether holder, is there anything I should do?

No. The Ethereum mainnet remains unaffected by this testnet. Future announcements will be made on this blog prior to the mainnet’s transition.

As a miner, is there any action I must take?

No. If you are mining on the Ethereum mainnet or Ropsten, you should be aware that each network will function entirely on proof-of-stake following The Merge. At that point, mining will no longer be feasible on the network.

This is anticipated around June 8, 2022 on Ropsten and later in the year for the Ethereum mainnet.

As a validator, can I withdraw my stake?

No. The Merge is the most intricate upgrade to Ethereum to date. To reduce the risks of network interruptions, a minimalistic approach has been adopted which excludes any non-transition alterations from this upgrade.

Withdrawals from the Beacon Chain are expected to be introduced in the first upgrade following The Merge. Specifications for both the consensus and execution layers are currently ongoing.

I have additional questions; where can I inquire?

A Merge Community Call is planned for June 3, 14:00 UTC. Client developers and researchers will be present to address inquiries from node operators, stakers, infrastructure & tooling providers, and community members.

When is the merge?

At the time of this post’s publication, the date for the Ethereum mainnet proof-of-stake transition has not been established. Any sources claiming otherwise are likely deceptive. Updates will be shared on this blog. Please remain cautious!

Assuming no issues arise with Ropsten, once client testing concludes, Ethereum’s other testnets will proceed with The Merge. Once Goerli and Sepolia have successfully transitioned and stabilized, a specific slot height will be determined for the Bellatrix upgrade on the Beacon Chain, and a difficulty value will be established for the mainnet transition. Clients will then release updates that enable The Merge on mainnet. These announcements will occur on this blog and in various community publications.

This scenario assumes no issues are discovered. Nevertheless, if problems are identified at any stage of the process or if testing coverage is deemed inadequate, these matters will be resolved before advancing with the deployment procedures.

Only then will it be feasible to approximate the precise date for The Merge.

In other terms, 🔜.