Unveiling the Sepolia Merge: A New Chapter for Ethereum

• Note: on July 5, 2022, the advised releases for go-ethereum and Erigon were updated. Refer to “Client Releases” for further information.
• Sepolia is set to be the second of three public testnets to undergo The Merge.
• The network will shift to proof-of-stake once the overall difficulty on the proof-of-work chain exceeds 17,000,000,000,000,000, which is anticipated to take place in the upcoming days.
• After the merge, Sepolia will have a controlled validator set, similar to current proof-of-authority testnets. Goerli/Prater, which will merge at a later stage, will retain an open validator set to enable stakers to trial the shift.

Background

Following years of efforts to implement proof-of-stake in Ethereum, we are now deeply engaged in the final testing phase: testnet deployments!

With Ropsten already migrated to proof-of-stake and shadow forks occurring regularly, Sepolia is now primed for The Merge. After Sepolia, only Goerli/Prater requires merging before advancing to mainnet. Other testnets will be regarded as obsolete post-merge, as articulated in a recent update.

The Merge distinguishes itself from earlier Ethereum upgrades in two significant ways. Firstly, node operators must simultaneously update both their consensus layer (CL) and execution layer (EL) clients, instead of just one. Secondly, the upgrade unfolds in two stages: the first occurs at an epoch height on the Beacon Chain and the second upon reaching a Total Difficulty milestone on the execution layer.

Sepolia has already experienced the Bellatrix upgrade on the Beacon Chain. We are now disclosing the specifics of the second phase of the transition: achieving the Terminal Total Difficulty.

Upgrade Information

Timing

The Merge constitutes a two-part process. It begins with a network upgrade on the consensus layer, initiated by an epoch height. This is succeeded by the execution layer’s transition from proof-of-work to proof-of-stake, activated by reaching a certain Total Difficulty limit, referred to as the Terminal Total Difficulty (TTD).

On June 20, 2022, at epoch 100, the Bellatrix upgrade prepared the Sepolia Beacon Chain for The Merge. At that moment, CL clients began monitoring for a TTD value to be achieved on the proof-of-work chain.

Given that the hash rate of proof-of-work testnets is quite unpredictable, the TTD value was initially established at an exceedingly high figure, 100000000000000000000000. Based on Sepolia’s current hash rate, it would take centuries to reach this figure.

With Bellatrix now operational, a revised TTD value of 17000000000000000 has been established for the transition. It is anticipated to be reached within the upcoming days. When this new TTD is hit or surpassed, the execution layer aspect of the transition, codenamed Paris, will commence. Again, please note that the hash rate on Sepolia is notoriously erratic, so the actual moment when the Terminal Total Difficulty occurs may vary.

Once the execution layer surpasses the TTD, the subsequent block will be produced exclusively by a Beacon Chain validator. We consider The Merge to be complete when the Beacon Chain finalizes this block. Assuming standard network conditions, this should occur 2 epochs, or roughly 13 minutes, after the initial post-TTD block is reached!

A new JSON-RPC block tag, finalized, returns the latest finalized block or an error if no post-merge block exists. This tag can be utilized by applications to verify if The Merge has been accomplished. In a similar vein, smart contracts can query the DIFFICULTY opcode (0x44), renamed to PREVRANDAO post-merge, to check if The Merge has transpired. We encourage infrastructure providers to monitor overall network stability alongside finalization status.

Client Releases

The subsequent client releases endorse The Merge on the Sepolia testnet. Node operators must operate both an execution and consensus layer client to stay connected to the network during and after The Merge.

When selecting which client to deploy, validators should particularly be aware of the risks associated with running a dominant client on both the EL and CL. An explanation of these risks and their implications can be found here. An overview of current EL and CL client distribution alongside guides for transitioning from one client to another can be located here.

Consensus Layer

Execution Layer

Besu Note: for compatibility with the Sepolia merge, Besu users will be required to execute a manual Terminal Total Difficulty override. For this, users must run the latest Besu release, 22.4.3 at the time of this post’s release, and proceed with the following steps:

• When using TOML configuration files, insert the following line: override-genesis-config=[“terminalTotalDifficulty=17000000000000000”]
• When initiating the node via the CLI, include the following flag: –override-genesis-config=”terminalTotalDifficulty=17000000000000000″

Further details about overriding the TTD can be located in the Ropsten TTD Announcement.

Geth Note: a regression introduced in go-ethereum v1.10.20 renders it unsuitable for utilization as part of the Sepolia merge. Geth users should instead operate the master branch until a new release is available. Instructions for doing so can be found here.

Upgrade Specifications

Consensus-critical alterations for The Merge are outlined in two locations:

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

Besides these, two additional specifications describe the interaction between the consensus and execution layer clients:

• The Engine API, detailed in the execution-apis repository, facilitates communication between the consensus and execution layers
• Optimistic Sync, described in the sync folder of the consensus-specs repository, allows the consensus layer to import blocks while the execution layer client is syncing and to provide a partial view 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, which operates the proof-of-stake Beacon Chain, and an execution layer client, which handles the user-state and executes computations related to transactions. These components communicate over an authenticated port utilizing a new set of JSON RPC methods known as the Engine API. The EL and CL client authenticate one another using a JWT secret. Node operators should consult their clients’ documentation for guidance on how to create and configure these settings.

In essence, if you were previously running a node on the Beacon Chain, you will now also need to operate an execution layer client. Likewise, if you were managing a node on the existing proof-of-work network, you will have to run a consensus layer client. To ensure secure communication, a JWT token must be delivered to each client.

It is important to highlight that while both are included in consensus layer client releases, executing a Beacon Node is distinct from operating a Validator Client. Stakers must run both, but node operators only require the former. This post elaborates on the differences between the two components in greater detail.

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

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

The validator set for Sepolia is permissioned, so unless you have already been added as a Sepolia validator, no steps are necessary.

–>

The transition of Goerli/Prater to proof-of-stake, set to be revealed later, will be accessible to all validators. Below are some notes to assist in preparation for this. Once more, no action is necessary at this time.

As previously mentioned, validators on the Beacon Chain must operate an execution layer client following The Merge, in addition to their consensus layer clients. Prior to the merge, this was highly recommended, but validators could have outsourced these duties to external providers. This was feasible since the only information needed on the execution layer was updates to the deposit contract.

After the merge, validators must verify that the transactions within the blocks they generate and attest to are legitimate. To achieve this, each beacon node must be linked with an execution layer client. It’s important to note that multiple validators can still connect to one beacon node & execution layer client pairing. While this broadens validators’ duties, it also grants a validator proposing a block the entitlement to its correlating transaction priority fees (which currently are awarded to miners).

Although validator rewards accumulate on the Beacon Chain and will need a future network upgrade for withdrawal, transaction fees will persist in being paid, incinerated, and distributed on the execution layer. Validators can designate any Ethereum address as the beneficiary of transaction fees.

After upgrading your consensus client, make sure to configure the fee recipient within your validator client settings to guarantee that transaction fees are directed to an address you possess.

Should you have staked using a third-party service, it is your chosen provider’s responsibility to determine how these fees are distributed.

If you wish to experiment with running a validator on Ethereum post-merge, instructions can be found on the Ropsten staking launchpad.

As a developer of applications or tools, what actions should I take?

With The Merge commencing on Sepolia, now is the ideal moment to verify that your product functions as anticipated during the proof-of-stake shift and within a post-merge framework. As detailed in a previous entry, The Merge will have minimal effects on a limited range of contracts deployed on Ethereum, none of which should experience disruptions. Furthermore, the majority of user API endpoints will remain constant (unless you utilize proof-of-work specific methods such as eth_getWork).

That being said, most applications on Ethereum encompass much more than just on-chain contracts. Now is the moment to ascertain that your front-end code, tools, deployment pipeline, and other off-chain components operate as expected. We highly advise that developers complete a thorough testing & deployment cycle on Ropsten (or Kiln) and notify any issues regarding tools or dependencies to the maintainers of those projects. If uncertain about where to raise an issue, please refer to this repository.

Additionally, you should be aware that all testnets except for Sepolia and Goerli will be phased out after the merge. If you utilize Ropsten, Rinkeby, or Kiln, you should plan to transition to Goerli or Sepolia. More details about this can be found here.

As an Ethereum user or Ether holder, is there any action I must take?

No. The Ethereum mainnet is not influenced by this testnet. Further announcements will be made on this blog prior to the mainnet transition.

As a miner, is there any action I need to take?

No. If you are mining on the Ethereum mainnet or Sepolia, please note that each network will function purely under proof-of-stake following The Merge. At that stage, mining on the network will cease to be an option.

This is anticipated to happen in the coming days for Sepolia and later in the year for the Ethereum mainnet.

As a validator, may I withdraw my stake?

No. The Merge represents the most intricate upgrade to Ethereum so far. To mitigate risks of network disruptions, a minimalistic strategy was adopted, which excluded any non-transition modifications from this upgrade.

Withdrawals from the Beacon Chain will likely be enabled in the first upgrade following The Merge. Specifications for both the consensus and execution layers are under development.

I have further inquiries, where can I pose them?

A Merge Community Call is set for July 15, 14:00 UTC. Client developers and researchers will be present to answer questions from node operators, stakers, infrastructure & tooling providers, and community members.

When will the merge happen?

As of the release of this post, the date for the transition of the Ethereum mainnet to proof-of-stake has not been determined. Any source asserting otherwise is likely to be fraudulent. Updates will be provided on this blog. Stay vigilant!

Assuming no complications arise with Sepolia, after completing client testing, Ethereum’s other EL testnet, Goerli, will undergo The Merge alongside the Prater CL testnet. After Goerli/Prater have transitioned successfully and stabilized, an epoch will be selected for the Bellatrix upgrade on the mainnet Beacon Chain, and a difficulty value will be assigned for the mainnet transition. Clients will then deliver releases enabling The Merge on the mainnet. These updates will be disclosed on this blog and in various community channels.

This is based on the assumption that no issues are found. If complications arise at any stage during the process or if test coverage is deemed inadequate, these matters will be rectified before proceeding with the deployment process.

Only after this will it be feasible to approximate the exact date for The Merge.

In other words, 🔜.

---

Acknowledgments to Justin Chrn for the cover image.