<\/p>\n
<\/p>\n
<\/p>\n
After years of diligent effort, Ethereum’s proof-of-stake upgrade is finally upon us! The successful transition of all public testnets is now accomplished, and The Merge has been slated for the Ethereum mainnet.<\/p>\n
<\/p>\n
The Merge diverges from earlier network upgrades in two key aspects. Firstly, node operators must update both their consensus layer (CL) and execution layer (EL) clients simultaneously, instead of just one of them. Secondly, the upgrade unfolds in two stages: the first, known as Bellatrix, at an epoch height on the Beacon Chain, followed by the second, referred to as Paris, upon reaching a Total Difficulty<\/span><\/a> benchmark on the execution layer.<\/p>\n <\/p>\n <\/p>\n \n <\/p>\n <\/p>\n The Merge<\/em> is a two-phase procedure. The initial phase is a network upgrade, Bellatrix, on the consensus layer instigated by an epoch height. This is succeeded by the transition of the execution layer from proof-of-work to proof-of-stake, Paris, initiated by a specific Total Difficulty<\/span> limit known as the Terminal Total Difficulty<\/span> (TTD<\/span>).<\/p>\n <\/p>\n The Bellatrix upgrade is slated for epoch 144896<\/span><\/strong> on the Beacon Chain — 11:34:47am UTC on Sept 6, 2022<\/strong>.<\/p>\n <\/p>\n Paris, the execution layer’s segment of the transition, will be activated by the Terminal Total Difficulty (TTD)<\/span> of 58750000000000000000000<\/span><\/strong>, expected between Sept 10-20, 2022<\/span><\/strong>. The precise date on which TTD<\/span> is attained hinges on the proof-of-work hash rate. Estimates for the transition can be found at bordel.wtf<\/a> and 797.io\/themerge<\/a>.<\/p>\n <\/p>\n Upon the execution layer reaching or surpassing the TTD<\/span>, the following block will be generated by a Beacon Chain validator. The Merge transition is regarded as complete once the Beacon Chain finalizes this block. Under typical network circumstances, this will occur 2 epochs (or approximately 13 minutes) after the first post-TTD block is minted!<\/p>\n <\/p>\n A new JSON-RPC block tag, finalized<\/span>, returns the latest finalized block or an error if no such post-merge block exists. Applications can utilize this tag to verify if The Merge has been finalized. In a similar vein, smart contracts can query the DIFFICULTY<\/span> opcode (0x44<\/span>)<\/a> (renamed to PREVRANDAO<\/span> post-merge) to ascertain if The Merge has taken place. We advise infrastructure providers to keep an eye on general network stability along with finalization status.<\/p>\n <\/p>\n <\/p>\n The following client releases facilitate The Merge on the Ethereum mainnet. Node operators are required to run both<\/strong> an execution and consensus layer client to maintain their presence on the network during and after The Merge.<\/p>\n <\/p>\n When selecting which client to operate, validators should be particularly cautious 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 located here<\/a>. An overview of the current EL and CL client distribution alongside guides for switching from one client to another can be found here<\/a>.<\/p>\n <\/p>\n Warning<\/em><\/strong>: Nimbus version v22.9.0 is a critical upgrade that addresses a significant pre-TTD block production problem affecting users who restarted their node post-Bellatrix. It also enhances compatibility with Besu, Prysm, and slower block builders while providing a performance boost in block processing, particularly for those utilizing Raspberry Pi and similar hardware.<\/p>\n <\/p>\n Warning<\/em><\/strong>: Lighthouse version v3.1.0 is a high-priority release containing a vital fix to ensure that Lighthouse does not attempt to generate invalid blocks. The –strict-fee-recipient flag for the Lighthouse Validator Client has also been determined to prevent block proposals during the period between the Bellatrix upgrade (Sept 6th) and the TTD date (anticipated Sept 15th). Presently, we are within that timeframe, and as such, all stakers using that flag are impacted. We strongly recommend that anyone utilizing the –strict-fee-recipient flag remove it and restart the Validator Client as soon as possible. This does not impact the –suggested-fee-recipient flag.<\/strong><\/p>\n <\/p>\n Alert<\/em><\/strong>: Prysm v3.1.1 is an essential update as it encompasses numerous vital corrections and functionalities for the merge.<\/p>\n <\/p>\n Alert<\/em><\/strong>: Teku version 22.9.0 is a mandatory update.<\/p>\n <\/p>\n Alert<\/em><\/strong>: Besu 22.7.2 is a suggested release for Merge and Mainnet users. 22.7.1 remains compatible for the Merge. This version offers additional stability before the Merge with various fixes and enhancements in synchronization, peer connections, and logging.<\/p>\n <\/p>\n Alert<\/em><\/strong>: Erigon version v2022.09.01-alpha addresses invalid block generation due to inadequate validation of digital signature components, block snapshot generation that occasionally takes place during the POS reversed header download, and numerous smaller bugs and security problems. All Erigon users are advised to upgrade to this or a later version prior to the Merge.<\/p>\n <\/p>\n Alert<\/em><\/strong>: Geth version v1.10.22 contains a severe database issue; refrain from using this version, and if you have already upgraded, please move to v1.10.23 at your earliest convenience.<\/p>\n <\/p>\n <\/p>\n Changes that are critical for consensus regarding The Merge are described in two locations:<\/p>\n <\/p>\n <\/p>\n Alongside these, two additional specifications explain the interaction between the consensus and execution layer clients:<\/p>\n <\/p>\n <\/p>\n <\/p>\n All bounties associated with Merge-related vulnerabilities have received a 4x multiplier from now until September 8th. Critical bugs are currently valued at up to $1 million USD<\/strong>.<\/p>\n <\/p>\n For further details, please refer to the bug bounty program<\/a>.<\/p>\n <\/p>\n <\/p>\n <\/p>\n After the merge, an Ethereum full node is composed of a consensus layer (CL) client that operates the proof-of-stake Beacon Chain and an execution layer (EL) client that oversees the user-state and handles the computations linked to transactions. The EL and CL clients interact over an authenticated port utilizing a new assortment of JSON RPC methods referred to as the Engine API<\/a>. The EL and CL clients validate one another using a JWT secret. Node operators should consult their clients’ documentation for guidance on how to create and configure this value.<\/strong><\/p>\n <\/p>\n In simpler terms, if you had been operating a node on the Beacon Chain, you now also must run an execution layer client. Similarly, if you were managing a node on the existing proof-of-work network, you will need to run a consensus layer client. For secure communication between them, a JWT token must be provided to each client. An update to the ‘Run a Node’ section<\/a> on ethereum.org elaborates on these processes in greater detail.<\/p>\n <\/p>\n It is essential to highlight that while both components are part of the consensus layer client releases, operating a Beacon Node is different from managing a Validator Client. Stakers must run both, but node operators only require the former. This article<\/a> provides further clarification on the distinctions between the two components.<\/p>\n <\/p>\n Additionally, note that each layer will sustain an independent set of peers and present its own APIs. The Beacon<\/a> and JSON RPC<\/a> APIs will both continue functioning as anticipated.<\/p>\n <\/p>\n <\/p>\n As stated previously, validators on the Beacon Chain will be required to operate an execution layer client following The Merge, in addition to their consensus layer clients.<\/strong> Before the merge, it was strongly advised, though some validators have delegated these functions to external providers. This was feasible because the execution layer only required updates to the deposit contract data.<\/p>\n <\/p>\n After the merge, validators must guarantee that user transactions and state transition blocks they create and attest to are valid. To achieve this, each beacon node must be connected to an execution layer client. Keep in mind that multiple validators may still be paired with a single beacon node & execution layer client combination. This broadens validators’ responsibilities while also allowing a validator proposing a block to claim its associated transaction priority fees (which currently go to miners).<\/p>\n <\/p>\n Although validator rewards continue to accumulate on the Beacon Chain and will necessitate a future network upgrade for withdrawal, transaction fees will be settled, incinerated, and allocated on the execution layer. Validators may designate any Ethereum address as the beneficiary for transaction fees.<\/p>\n <\/p>\n After updating your consensus client, ensure you configure the fee recipient<\/span> within your validator client settings to confirm transaction fees are directed to an address under your control.<\/strong> If you have staked through a third-party service, it is the responsibility of your chosen provider to determine how these fees are distributed.<\/p>\n <\/p>\n The Staking Launchpad features a Merge Readiness Checklist<\/a> that stakers can utilize to confirm they have completed each phase of the process. EthStaker has also conducted Validator Preparation Workshops<\/a>, with additional sessions on the horizon.<\/p>\n <\/p>\n Stakers intending to operate a validator on a testnet as preparation for the mainnet proof-of-stake transition can do so on Goerli (now merged with Prater), which also offers a Staking Launchpad instance<\/a>.<\/p>\n <\/p>\n <\/p>\n The additional difficulty per block is contingent upon the network hash rate, which is subject to fluctuations. If more hash rate contributes to the network, the TTD<\/span> will be achieved more rapidly. Conversely, if hash rate exits the network, the TTD<\/span> will be attained later. In the case of a significant decline in hash rate levels, a TTD Override<\/span> may be organized similar to what was done on Ropsten<\/a>.<\/p>\n <\/p>\n <\/p>\n As detailed in a previous article<\/a>, The Merge will exert only minor influence on a portion of contracts deployed on Ethereum, none of which should be non-functional. Furthermore, the majority of user API endpoints remain consistent (unless utilizing proof-of-work specific methods such as eth_getWork<\/span>).<\/p>\n <\/p>\n That being said, most applications on Ethereum involve significantly more than merely on-chain contracts. Now is the ideal time<\/strong> to guarantee your front-end code, tooling, deployment pipeline, and other off-chain components function as expected. We highly recommend that developers engage in a thorough testing & deployment cycle on Sepolia or Goerli and report any complications with tools or dependencies to the maintainers of those projects. If you are uncertain where to file an issue, please utilize this repository<\/a>.<\/p>\n <\/p>\n Furthermore, be aware that all testnets other than Sepolia and Goerli will be phased out following the merge. If you are utilizing Ropsten, Rinkeby, or Kiln, you should prepare to transition to Goerli or Sepolia. Further details regarding this can be found here<\/a>.<\/p>\n <\/p>\n <\/p>\n Whether you are engaging with Ethereum applications on-chain, holding Ether on an exchange, or in a self-custodied wallet, you are not required to take any action. If an application, exchange, or wallet you are utilizing provides additional guidance or recommendations, ensure these are actually coming from them. Remain vigilant against scams!<\/p>\n <\/p>\n <\/p>\n No. If you are mining on the Ethereum mainnet, please note that the network will transition entirely to proof-of-stake after The Merge. Subsequently, mining on the network will not be feasible.<\/p>\n <\/p>\n <\/p>\n If you are operating an Ethereum client that has not been updated to the most recent version (as listed above), your client will synchronize to the pre-fork blockchain once the upgrade takes place.<\/p>\n <\/p>\n You will find yourself stranded on an incompatible chain following the old protocols and will be unable to transmit Ether or function on the post-merge Ethereum network.<\/p>\n <\/p>\n <\/p>\n No. The Merge represents the most intricate upgrade to Ethereum thus far. To minimize the chances of network disruptions, a conservative strategy was adopted which excluded any non-transition alterations from this upgrade.<\/p>\n <\/p>\n Withdrawals from the Beacon Chain will likely be incorporated in the initial upgrade following The Merge. Specifications for both the consensus<\/a> and execution<\/a> layers are currently under development.<\/p>\n <\/p>\n <\/p>\n Join client team developers, ETHStaker members, researchers, and more in the upcoming Merge Community Call<\/a> on Friday, Sept 9 at 14:00 UTC!<\/p>\n <\/p>\n <\/p>\nUpgrade Information<\/h2>\n
Timing<\/h3>\n
Client Releases<\/h3>\n
Consensus Layer<\/h4>\n
\n<\/p>\nExecution Layer<\/h4>\n
\n<\/p>\nUpgrade Specifications<\/h3>\n
\n
\n
Merge Bug Bounty Bonus<\/h2>\n
FAQ<\/h2>\n
As a node operator, what should I perform?<\/h3>\n
As a staker, what actions should I take?<\/h3>\n
Why is the estimated date for the Terminal Total Difficulty<\/span> so wide-ranging?<\/h3>\n
As an application or tooling developer, what actions should I take?<\/h3>\n
As an Ethereum user or Ether holder, is there anything required of me?<\/h3>\n
As a miner, is there anything I should do?<\/h3>\n
What occurs if I am a miner or node operator and do not engage in the upgrade?<\/h3>\n
As a validator, am I permitted to withdraw my stake?<\/h3>\n
I possess additional inquiries; where can I direct them?<\/h3>\n
Thank You<\/h2>\n