Source: Ethereum Foundation official blog
Ethereum is moving to Proof of Stake (PoS)! This transition is called The Merge and must first be activated via a Bellatrix upgrade on the Beacon Chain . Later, 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 on September 6, 2022 at 11:34:47 UTC time in the epoch of the beacon chain
144896.The total difficulty value of the terminal that triggers the merger is
58750000000000000000000, expected to be between September 10 and 20, 2022 .Note: As previously announced, the Kiln testnet is being deprecated and the operator will shut down on September 6, 2022.
background
After years of hard work, Ethereum’s PoS upgrade is finally coming! All public testnets have now been successfully upgraded, and the merged upgrade of the Ethereum mainnet has also been scheduled.
The merger 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 , not just one of them. Second, this upgrade is activated in two stages: the first stage is called Bellatrix , which will be completed at a certain epoch height on the beacon chain; the second stage is called Paris , which will be when the execution layer reaches the predetermined total difficulty value Finish.
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 that is triggered by a specific total difficulty value called Total Terminal Difficulty (TTD).
The Bellatrix upgrade is scheduled to take place on September 6, 2022 at 11:34:47 AM UTC when the beacon chain height reaches 144896.
The execution layer upgrade Paris will 58750000000000000000000 be triggered when the total difficulty value of TTD is reached, which is expected to be between September 10 and September 20, 2022 . The exact date to reach TTD depends on the computing power of the proof of work. You can find the estimated 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 validators 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 finalizedthat returns the latest final block, or an error if no such merged block exists. Applications can use this tag to check whether the merge has completed. Likewise, the smart contract can query the DIFFICULTY opcode (0x44) [3] (renamed after the merge PREVRANDAO) to determine whether the merge occurred. We recommend that infrastructure providers monitor overall network stability in addition to the final state.
client version
The following client versions support merge upgrades to the Ethereum mainnet. Note that node operators must run both 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 of clients on EL and CL. You can find an explanation of these risks and their consequences here[4]. You can also find an estimate of execution and consensus layer client distribution 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: Eragon
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: The geth v1.10.22 client 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
The merged consensus key changes are specified in two places:
The consensus layer changes based on the Bellatrix catalog[6] of the consensus specification repository.
The execution layer changes based on the Paris specification [7] in the execution specification repository.
Beyond this, two other specifications cover how consensus and execution layer clients interact:
The Engine API specified in the execution-apis[8] repository is used for communication between the consensus layer and the execution layer.
Optimistic Sync, specified in the sync[9] folder of the consensus specification repository, is used by the consensus layer when performing layer client synchronization to import blocks and provide a partial view of the chain header from the former to the latter.
Incorporate bug bounty programs
All merge-related bug bounties between now and September 8th will have a 4x multiplier. Serious bug bounties can be up to $1 million.
For more details, see the Bug Bounty Program:
https://bounty.ethereum.org/
FAQ
1. As a node operator, what should I do?
After the merger, an Ethereum full node is a combination of a consensus layer (CL) client, which runs the proof-of-stake beacon chain, and an execution layer (EL) client, which manages user state and runs transaction-related calculations. Execution layer (EL) and consensus layer (CL) clients communicate over authenticated ports using a new set of JSON RPC methods called the Engine API [10]. Execution layer (EL) and consensus layer (CL) clients authenticate each other using JWT keys. Node operators should refer to their client's documentation for instructions on how to generate and configure this value.
In other words, if you already run a node on the beacon chain, you now also need to run an execution layer client. Likewise, if you run a node on the current Proof-of-Work (PoW) network, you will 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 [11] of the ethereum.org website has been updated with more details on these steps.
It’s worth emphasizing that running a beacon chain node is different from running a validator client, although they are both part of the consensus layer client version. Stakers must run both, while node operators only need to run the former. This article [12] explains the difference between these two components in more detail.
Additionally, please note that each layer will maintain an independent set of peer nodes and expose its own API. Both the Beacon API [13] and the JSON RPC API [14] will continue to work as expected.
2. As a staker, what do I need to do?
As mentioned above, in addition to running the consensus layer client, validators on the beacon chain also need to run the execution layer client after the merge. Stakers are strongly encouraged to do this before merging, but some validators have outsourced these functions to third-party providers. This is possible because the only data required by the execution layer are updates to the deposit contract.
After merging, validators must ensure that the blocks of user transactions and state transitions they create and certify 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 responsibilities of validators, but also gives the validators who propose blocks the rights to associated transaction priority fees (which currently belong to miners).
While validator rewards are still generated on the beacon chain and require subsequent network upgrades to be withdrawn, transaction fees will be paid, burned, and distributed on the execution layer. Validators can designate any Ethereum address as the recipient of transaction fees.
After updating your consensus client, be sure to fee recipient set this as part of your validator client configuration to ensure transaction fees are sent to addresses you control. If you use a third-party provider for staking, it is up to the provider you choose to specify how these fees are allocated.
Staking Launchpad has a merge preparation checklist[15] that stakers can use to ensure they complete each step of the process. EthStaker also hosts validator preparation workshops, with more planned.
Stakers who wish to run a validator on the testnet in preparation for the mainnet PoS transition can do so on the Goerli testnet (now merged), which also has a Staking Launchpad instance.
3. Why is the estimated date range for Total Terminal Difficulty (TTD) so wide?
The increased difficulty of each block depends on the unstable network computing power. If more computing power joins the network, the TTD will be reached faster. Likewise, if computing power leaves the network, the arrival time of TTD will be delayed. In the event that hashrate levels drop significantly, a TTD coverage value could be coordinated as done on the Ropsten testnet.
4. As an application or tool developer, what should I do?
As mentioned in a previous article, the merge will have a minimal impact on the subset of contracts deployed on Ethereum and all contracts should not be broken. Additionally, most user API endpoints will remain stable (unless you use proof-of-work specific methods, for example eth_getWork).
That said, most applications on Ethereum involve much more than on-chain contracts. Now is the time to make sure your front-end code, tooling, deployment pipelines, and other off-chain components work as expected. We strongly recommend that developers run a full test and deployment cycle on Sepolia or Goerli and report any tooling or dependency issues to the maintainers of these projects. If you are not sure where to open an issue, please 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 use an Ethereum application on the chain, hold ETH on an exchange, or in a wallet you keep, you don’t have to do anything. If you are using an app, exchange or wallet that provides additional instructions or advice, you should verify that it comes from them. Please 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 on the Proof-of-Stake (PoS) algorithm, and at that 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 you are using an Ethereum client that has not been updated to the latest version (listed above), your client will sync to the pre-fork blockchain once the network completes the upgrade.
You will be stuck on an incompatible chain following the old rules, unable to send ether or operate on the merged Ethereum network.
8. As a validator, can I withdraw my staked ETH equity?
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-transitional changes in this upgrade.
Withdrawals from the beacon chain may be introduced in the first upgrade after the merger. Specifications for 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 on September 9th at 14:00 UTC, where you can join client developers, ETHStaker members, researchers, and more!
Acknowledgments
Ethereum’s transition to Proof-of-Stake (PoS) has been in the works for a long time. 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 build this cathedral without all of you.
When will it be merged? It will be very fast.
Original link:
https://blog.ethereum.org/2022/08/24/mainnet-merge-announcement/
Links mentioned above:
[1]: https://bordel.wtf/
[2]: https://797.io/themerge/
[3]:https://eips.ethereum.org/EIPS/eip-4399#using-264-threshold-to-determine-pos-blocks
[4]:https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html
[5]:https://clientdiversity.org/
[6]:https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix
[7]:https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md
[8]:https://github.com/ethereum/execution-apis/tree/main/src/engine
[9]:https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md
[10]:https://github.com/ethereum/execution-apis/tree/main/src/engine
[11]:https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/
[12]:https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-client-architecture/
[13]:https://github.com/ethereum/beacon-apis
[14]:https://github.com/ethereum/execution-apis
[15]:https://launchpad.ethereum.org/en/merge-readiness
[16]:https://blog.ethereum.org/2022/06/21/testnet-deprecation/
-END-
[The purpose of publishing articles is to disseminate more valuable information. The copyright of the article belongs to the original author. Its content and opinions do not represent the position of Unitimes. The pictures appearing on this WeChat platform are all collected from the Internet, and the copyright belongs to the copyright owner. If the copyright owner believes that his work is not suitable for everyone to browse or should not be used for free, please add WeChat uniforms2018 to contact us, and this platform will make corrections immediately. 】
Just click " Like " when you come.
