Ethereum Foundation: Ethereum Mainnet Merge Announcement
The Ethereum mainnet merge countdown has begun.Original Title: 《ethereum foundation blog: Mainnet Merge Announcement》
Original Author: Protocol Support Team
Original Compilation: Unitimes, ODAILY
Ethereum is transitioning to Proof of Stake (PoS)! This transition is called The Merge, which must first be activated through the Bellatrix upgrade on the Beacon Chain. 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 take place on September 6, 2022 at 11:34:47 UTC during the 144896th epoch on the Beacon Chain. *
The terminal total difficulty value that triggers the merge is 58750000000000000000000, expected to occur between September 10 and September 20, 2022. *
Note: As previously announced, the Kiln testnet will be deprecated, and operators will shut it down on September 6, 2022. *
Background
After years of effort, Ethereum's PoS upgrade is finally here! All public testnets have successfully completed the upgrade, and the merge upgrade for the Ethereum mainnet has also been scheduled.
The merge differs from previous network upgrades in two ways. First, node operators need to update both their Consensus Layer (CL) client and Execution Layer (EL) client simultaneously, rather than just one of them. Second, this upgrade is activated in two phases: the first phase is called Bellatrix, which will be completed at a certain epoch height on the Beacon Chain; the second phase is called Paris, which will be completed when the Execution Layer reaches the predetermined total difficulty value.
Upgrade Information
Timing
The merge consists of two steps, the first step is the Bellatrix network upgrade triggered at a certain epoch height on the Consensus Layer. Subsequently, the Execution Layer transitions from Proof of Work (PoW) to Proof of Stake (PoS), a step known as Paris, triggered by a specific total difficulty value called Terminal Total Difficulty (TTD).
The Bellatrix upgrade is scheduled to occur on September 6, 2022, at 11:34:47 UTC when the Beacon Chain reaches a height of 144896.
The Execution Layer upgrade Paris will be triggered when the TTD total difficulty value reaches 58750000000000000000000, expected to occur between September 10 and September 20, 2022. The exact date for reaching TTD depends on the hash power situation of the Proof of Work network; you can find estimates regarding the transition time at bordel.wtf and 797.io/themerge.
Once the Execution Layer reaches or exceeds the predetermined TTD value, Beacon Chain validators will be responsible for generating subsequent blocks. Once the Beacon Chain finalizes that block, the merge upgrade is considered complete. Under normal network conditions, the first block generated after reaching the TTD difficulty value will be finalized in 2 epochs (approximately 13 minutes).
A new JSON-RPC block tag finalized will return the latest finalized block, or if no such post-merge block exists, it will return an error. Applications can use this tag to check if the merge has been completed. Similarly, smart contracts can query the DIFFICULTY opcode (0x44) (renamed to PREVRANDAO after the merge) to determine if the merge has occurred. We recommend that infrastructure providers monitor not only the final state but also the overall stability of the network.
Client Versions
The following client versions support the Ethereum mainnet merge upgrade. Note that node operators must run both the Execution Layer and Consensus Layer clients simultaneously 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 both EL and CL. You can find explanations of these risks and their consequences here. You can also find estimates of the distribution of Execution Layer and Consensus Layer clients, as well as guides for switching from one client to another here.
1) Consensus Layer Clients
Client: Lighthouse
Version: v3.0.0
Client: Lodestar
Version: v1.0.0
Client: Nimbus
Version: v22.8.0
Client: Prysm
Version: v3.0.0
Client: Teku
Version: 22.8.1
2) Execution Layer Clients
Client: Besu
Version: 22.7.1
Client: Erigon
Version: v2022.08.02-alpha
Client: go-ethereum (geth)
Version: v1.10.23
Client: Nethermind
Version: v1.14.0
Warning: The geth v1.10.22 client contains serious database issues; 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
The key consensus changes for the merge are specified in two places:
Changes in the Consensus Layer are based on the Bellatrix directory of the consensus specification repository.
Changes in the Execution Layer are based on the Paris specification in the execution specification repository.
In addition, two other specifications cover how the Consensus Layer and Execution Layer clients interact:
The Engine API specified in the execution-apis repository is used for communication between the Consensus Layer and Execution Layer.
The Optimistic Sync specified in the sync folder of the consensus specification repository is used by the Consensus Layer to import blocks while synchronizing with the Execution Layer client, providing a partial view of the chain head from the former to the latter.
Merge Bug Bounty Program
From now until September 8, all merge-related bug bounties will have a 4x multiplier. Serious bug bounties can go up to $1 million.
For more details, please refer to the bug bounty program.
FAQ
1. What should I do as a node operator?
After the merge, an Ethereum full node is a combination of a Consensus Layer (CL) client and an Execution Layer (EL) client, with the former running the Proof of Stake Beacon Chain and the latter managing user state and executing transaction-related computations. The Execution Layer (EL) and Consensus Layer (CL) clients communicate using a new set of JSON RPC methods called Engine API over authenticated ports. The Execution Layer (EL) and Consensus Layer (CL) clients authenticate each other using JWT keys. Node operators should refer to their client documentation for instructions on how to generate and configure this value.
In other words, if you are already running a node on the Beacon Chain, you will now also need to run an Execution Layer client. Similarly, if you are running a node on the current Proof of Work (PoW) network, you will also need to run a Consensus Layer client. To enable secure communication between them, a JWT token must be passed to each client. The “Run a Node” section of the ethereum.org website has been updated to detail these steps.
It is important to emphasize that while they are both part of the Consensus Layer client versions, 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 explains the differences between these two components in more detail.
Additionally, please note that each layer will maintain a separate set of peer nodes and expose its own API. The Beacon API and JSON RPC API will continue to function as expected.
2. What do I need to do as a staker?
As mentioned above, validators on the Beacon Chain need to run an Execution Layer client in addition to the Consensus Layer client after the merge. It is strongly recommended that stakers do this before the merge, but some validators have outsourced this functionality to third-party providers. This is possible because the only data required by the Execution Layer is updates to the deposit contract.
After the merge, validators must ensure that the user transactions and state transition blocks they create and attest to are valid. To do this, each Beacon Chain node must be paired with an Execution Layer client. Note that multiple validators can still pair with a single Beacon Chain node and Execution Layer client combination. This expands the responsibilities of the validators but also grants the proposing validators the right to the associated transaction priority fees (currently belonging to miners).
While validator rewards will still be generated on the Beacon Chain and will require subsequent network upgrades to withdraw, 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 the consensus client, be sure to set the fee recipient as part of the validator client configuration to ensure that transaction fees are sent to an address you control. If you are staking with a third-party provider, it is up to the provider you choose to specify how these fees are allocated.
The Staking Launchpad has a merge readiness checklist that stakers can use to ensure they have completed every step of the process. EthStaker also hosts validator readiness workshops and plans to hold more workshops.
Stakers looking to run validators on the testnet in preparation for the mainnet PoS transition can operate on the Goerli testnet (which has already completed the merge), which also has a Staking Launchpad instance.
3. Why is the estimated date range for the Terminal Total Difficulty (TTD) so broad?
The difficulty added with each block depends on the unstable network hash power; if more hash power joins the network, the TTD will be reached faster. Similarly, if hash power leaves the network, the arrival time of TTD will be delayed. In cases of significant drops in hash power, a TTD coverage value can be coordinated, as was done on the Ropsten testnet.
4. What should I do as an application or tool developer?
As mentioned in the previous article, the merge has minimal impact on a subset of contracts deployed on Ethereum, and all contracts should remain intact. Additionally, most user API endpoints will remain stable (unless you are using Proof of Work-specific methods, such as eth_getWork).
That said, most applications on Ethereum involve much more than just on-chain contracts. Now is the time to ensure that front-end code, tools, deployment pipelines, and other off-chain components work as expected. We strongly recommend developers run a complete testing and deployment cycle on Sepolia or Goerli and report any tool or dependency issues to the maintainers of these projects. If you are unsure where to open issues, please use this repository.
Additionally, please note that all testnets other than 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.
5. What do I need to do as an Ethereum user or ETH holder?
Whether you are using Ethereum applications on-chain, holding ETH on an exchange, or in a self-custodied wallet, you do not need to do anything. If the applications, exchanges, or wallets you use provide additional instructions or recommendations, you should verify that these instructions or recommendations come from them. Beware of scams!
6. Is there anything I can do as an Ethereum miner?
No, if you are mining on the Ethereum mainnet, you should know that after the merge, the network will operate entirely under the Proof of Stake (PoS) algorithm, at which point 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 the Ethereum client you are using is not updated to the latest version (as listed above), once the network completes the upgrade, your client will sync to the pre-fork blockchain.
You will be stuck on an incompatible chain that follows the old rules, unable to send Ether or operate on the post-merge Ethereum network.
8. Can I withdraw my staked ETH as a validator?
No, the merge is the most complex upgrade to Ethereum to date, and to minimize the risk of network disruption, we have taken a minimal approach that excludes any non-transition changes in this upgrade.
Withdrawals from the Beacon Chain may be introduced in the first upgrade after the merge. Specifications for the Consensus Layer and Execution Layer are being developed.
9. I have more questions; where can I ask?
There will be a community call about the merge on September 9 at 14:00 UTC, where you can join client developers, ETHStaker members, researchers, and others!
Acknowledgments
The transition of Ethereum to Proof of Stake (PoS) has been in preparation for a long time. Thanks to everyone who contributed to the research, development, analysis, testing, breaking, fixing, or explaining of 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 the merge happen? Very soon.
