Ethereum Foundation: Ethereum Mainnet Merge Announcement

Source: Ethereum Foundation official blog

• Ethereum is moving to Proof of Stake (PoS)! This transition is called The Merge and must first be activated on the Beacon Chain via the Bellatrix upgrade . After that, the Ethereum Proof of Work (PoW) chain will migrate to Proof of Stake (PoS) when a specific total difficulty value is reached .

• According to the plan, the Bellatrix upgrade will be carried out at 11:34:47 UTC on September 6, 2022 at the 144896 epoch of the beacon chain .

• The terminal total difficulty value that triggers the merge is 58750000000000000000000 , which is expected to be between September 10 and 20, 2022 .

• NOTE: As previously announced, the Kiln testnet is being deprecated and operators will shut down on September 6, 2022.

background

After years of hard work, Ethereum’s PoS upgrade is finally here! All public testnets have now successfully completed the upgrade, and the merge upgrade to the Ethereum mainnet has been scheduled.

The merge differs from previous network upgrades in two ways. First, node operators need to update both their consensus layer (CL) clients and their execution layer (EL) clients , not just one or the other. Second, the upgrade is activated in two phases: the first phase, called Bellatrix , will be completed at a certain epoch height on the beacon chain; the second phase, called Paris , will be completed when the execution layer reaches a predetermined total difficulty value.

Upgrade information

time

The merger is divided into two steps. The first step is the Bellatrix network upgrade triggered at the consensus layer at a certain epoch height . Subsequently, the execution layer transitions from proof of work (PoW) to proof of stake (PoS), a step called Paris , which is triggered by a specific total difficulty value called terminal total difficulty (TTD).

The Bellatrix upgrade is scheduled to take place on September 6, 2022 at 11:34:47 AM UTC when the beacon chain reaches block 144896.

The execution layer upgrade, Paris, will be triggered when the total difficulty of TTD reaches 58750000000000000000000 , which is expected to be between September 10 and September 20, 2022. The exact date of reaching TTD depends on the computing power of the proof of work. You can find estimates of the transition time at bordel.wtf[1] and 797.io/themerge[2] .

Once the execution layer reaches or exceeds the predetermined TTD value, the beacon chain validator will be responsible for generating subsequent blocks. Once the beacon chain finalizes the block, the merge upgrade is considered complete. Under normal network conditions, the first block generated after the TDD difficulty value is reached will be finalized in 2 epochs (about 13 minutes).

A new JSON-RPC block tag, finalized , returns the latest finalized block, or an error if no such merged block exists. Applications can use this tag to check whether a merge has completed. Similarly, smart contracts can query the DIFFICULTY opcode‌ (0x44) [3] (renamed to PREVRANDAO after the merge) to determine whether a merge has occurred. We recommend that infrastructure providers monitor overall network stability in addition to monitoring finalization.

Client version

The following client versions support merge upgrades to the Ethereum mainnet. Note that node operators must run both the execution layer and consensus layer clients to remain on the network during and after the merge.

When choosing which client to run, validators should pay special attention to the risks of running a majority client on EL and CL. You can find an explanation of these risks and their consequences here‌ [ 4]. You can also find estimates of the distribution of execution and consensus layer clients here‌ [ 5], as well as guidance on switching from one client to another.

1) Consensus layer client

Client: Lighthouse

Version: v3.0.0

Download Link:

https://github.com/sigp/lighthouse/releases/tag/v3.0.0

Client: Lodestar

Version: v1.0.0

Download Link:

https://github.com/ChainSafe/lodestar/releases/tag/v1.0.0

Client: Nimbus

Version: v22.8.0

Download Link:

https://github.com/status-im/nimbus-eth2/releases/tag/v22.8.0

Client: Prysm

Version: v3.0.0

Download Link:

https://github.com/prysmaticlabs/prysm/releases/tag/v3.0.0

Client: Teku

Version: 22.8.1

Download Link:

https://github.com/ConsenSys/teku/releases/tag/22.8.1

2) Execution layer client

Client: Besu

Version: 22.7.1

Download Link:

https://github.com/hyperledger/besu/releases/tag/22.7.1

Client: Erigon

Version: v2022.08.02-alpha

Download Link:

https://github.com/ledgerwatch/erigon/releases/tag/v2022.08.02

Client: go-ethereum (geth)

Version: v1.10.23

Download Link:

https://github.com/ethereum/go-ethereum/releases/tag/v1.10.23

Client: Nethermind

Version: v1.14.0

Download Link:

https://github.com/NethermindEth/nethermind/releases/tag/1.14.0

Warning: geth v1.10.22 contains serious database issues. Please do not use this version. If you are using this version of the client, please upgrade to v1.10.23 as soon as possible.

Upgrade Specifications

Consensus-critical changes that are merged are specified in two places:

1. The consensus layer changes according to the Bellatrix catalog of the consensus specification repository [ 6].

2. The execution layer changes according to the Paris specification [ 7] in the execution specification repository .

In addition to this, two other specifications cover how consensus and execution layer clients interact:

1. The Engine API specified in the execution-apis [ 8] repository is used for communication between the consensus layer and the execution layer.

2. Optimistic Sync, specified in the sync ‌ [ 9] folder of the consensus specification repository, is used by the consensus layer to import blocks when syncing with the execution layer client and provide a partial view of the chain head from the former to the latter.

Merging Bug Bounty Programs

All merge-related bug bounties will have a 4x multiplier between now and September 8. Serious bug bounties can go up to $1 million.

For more details, see the Bug Bounty Program:

https://bounty.ethereum.org/

FAQ

1. What should I do as a node operator?

After the merger, an Ethereum full node is a combination of a consensus layer (CL) client that runs the proof-of-stake beacon chain and an execution layer (EL) client that manages user state and runs transaction-related computations. EL and CL clients communicate over authenticated ports using a new set of JSON RPC methods called the Engine API ‌ [ 10]. EL and CL clients authenticate each other using a JWT key. Node operators should refer to their client's documentation for instructions on how to generate and configure this value.

In other words, if you’re already running a node on the beacon chain, you now also need to run an execution layer client. Similarly, if you’re running a node on the current proof-of-work (PoW) network, you also need to run a consensus layer client. In order for them to communicate securely, a JWT token must be passed to each client. The “Run a Node” section of the ethereum.org website [11] has been updated to describe these steps in more detail.

It is worth emphasizing that while they are both part of the consensus layer client version, running a beacon chain node is different from running a validator client. Stakers must run both, while node operators only need to run the former. This article [12] explains the difference between the two components in more detail.

Additionally, please note that each tier will maintain an independent set of peers and expose its own API. Both the Beacon API [13] and the JSON RPC API [14] will continue to work as expected.

2. What do I need to do as a staker?

As mentioned above, validators on the beacon chain will need to run an execution layer client after the merge in addition to the consensus layer client. It is highly recommended that stakers do this before the merge, but some validators have outsourced 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 must ensure that the blocks of user transactions and state transitions they create and attest are valid. To do this, each beacon chain node must be paired with an execution layer client. Note that multiple validators can still be paired with a single beacon chain node and execution layer client combination. This expands the responsibility of validators, but also gives the validator who proposed the block the right to the transaction priority fees associated with it (currently belongs to miners).

While validator rewards are still generated on the beacon chain and require a subsequent network upgrade to be withdrawn, transaction fees will 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 fee recipient as part of your validator client configuration to ensure that transaction fees are sent to addresses you control. If you use a third-party provider for staking, your chosen provider specifies how these fees are distributed.

Staking Launchpad has a merge readiness checklist [ 15] that stakers can use to ensure they complete each step of the process. EthStaker also hosts validator readiness workshops and plans to host more.

Stakers who wish to run validators on a testnet in preparation for the mainnet PoS transition can do so on the (now merged) Goerli testnet, which also has a Staking Launchpad instance.

3. Why is the estimated date range for Terminal Total Difficulty (TTD) so wide?

The difficulty added per block depends on the unstable network hashrate, if more hashrate joins the network then TTD will be reached sooner. Likewise, if hashrate leaves the network, TTD will be reached later. In the event of a significant drop in hashrate levels, a TTD override value can be coordinated as was done on the Ropsten testnet.

4. As an application or tool developer, what should I do?

As mentioned in the previous article, the merge will have minimal impact on a subset of contracts deployed on Ethereum, and no contracts should be broken. Additionally, most user API endpoints will remain 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 ensure that your front-end code, tooling, deployment pipelines, and other off-chain components work as expected. We strongly encourage developers to run a full test and deployment cycle on Sepolia or Goerli, and report any tooling or dependency issues to the maintainers of those projects. If you're not sure where to open an issue, use this repository.

Additionally, please note that all testnets except Sepolia and Goerli will be deprecated after the merge. If you are a user of Ropsten, Rinkeby, or Kiln, you should plan to migrate to Goerli or Sepolia. For more information on this, see this link [16]‌.

5. As an Ethereum user or ETH holder, what do I need to do?

Whether you are using an Ethereum app on-chain, holding ETH on an exchange, or in a wallet you hold in your own custody, you do not need to do anything. If the app, exchange, or wallet you are using provides additional instructions or suggestions, you should verify that these instructions or suggestions are from them. Beware of scams!

6. Is there anything else I can do as an Ethereum miner?

No, if you are mining on the Ethereum mainnet, you should know that after the merger, the network will run entirely under the Proof of Stake (PoS) algorithm, and at that time, POW mining will no longer be possible.

7. What happens if I am a miner or node operator and do not participate in the upgrade?

If you are using an Ethereum client that is not updated to the latest version (listed above), your client will sync to the pre-fork blockchain once the network is upgraded.

You will be stuck on an incompatible chain that follows the old rules, unable to send ether or operate on the merged Ethereum network.

8. As a validator, can I withdraw my staked ETH?

No , the merge is the most complex upgrade to Ethereum to date, and to minimize the risk of network disruption we have taken a minimalist approach that excludes any non-transitional changes in this upgrade.

Withdrawals from the beacon chain may be introduced in the first upgrade after the merger. The specifications of the consensus layer and execution layer are being developed.

9. I have more questions, where can I ask them?

There will be a community call about the merge at 14:00 UTC on September 9th, and you can join in with client developers, ETHStaker members, researchers, and more!

Acknowledgements

Ethereum’s transition to Proof of Stake has been a long time in the making. Thanks to everyone who contributed to researching, developing, analyzing, testing, breaking, fixing, or explaining everything about The Merge.

There are too many contributors over the years to list here, but you know who you are. We could not have built this cathedral without all of you.

When will it merge? Very soon.