Partnered With:

Goerli/Prater merger is imminent, these things need attention

Read this article in 19 Minutes

The Goerli/Prater merger is expected to take place between August 6-12 this year.

Original title: "Goerli/Prater Merger Announcement"

Original source: Ethereum Foundation Blog

Original author: Protocol Support Team

Original compilation: ETH Chinese

As the last testnet to transition to Proof of Stake, Goerli will merge with Prater. The combined Goerli/Prater network will retain the Goerli name.

Prater testnet Bellatrix upgrade in preparation for the merger will be activated at epoch 112260 , Estimated time is 12:24PM UTC on August 4, 2022

Bellatrix upgrade activation, The Goerli/Prater merger will occur when Goerli hits a total difficulty value of 10790000 , estimated between August 6-12, 2022 .

After the merger, Goerli's validator set will be maintained for individual stakers running testnet validators open. Staking carts looking to launch a Goerli/Prater validator can head to the Prater Launchpad.

Background

< /p>

After several years of hard work bringing Proof of Stake to Ethereum, we have now entered the final testing phase: testnet deployment!

After going through several dev testnets, shadow forks and deprecated testnets After that, Sepolia recently transitioned to Proof of Stake. Now, there is only one testnet left: Goerli and its companion beacon chain, Prater.

The merger differs from previous Ethereum upgrades in two ways. First, node operators need to upgrade their Consensus Layer (CL) and Execution Layer (EL) clients, not just one of the two. The upgrade is then activated in two phases: the first is the Bellatrix upgrade, activated at a public epoch height on the beacon chain, and the second is the Paris upgrade, which reaches a Total Difficulty (total difficulty) value is activated.

Upgrade Information

Time

Merge in two steps Walk. It starts with an upgrade of the Bellatrix network on the consensus layer, triggered by an epoch height. Next is the upgrade of the execution layer from proof-of-work to proof-of-stake Paris, triggered by a specific Total Difficulty threshold, called Terminal Total Difficulty (TTD).

The Bellatrix upgrade plan is activated on epoch 112260 of the Prater beacon chain, Estimated at 12:24PM UTC on August 4, 2022 (12:24PM UTC on August 4, 2022). Part of Paris on the executive layer will be triggered when the Terminal Total Difficulty (TTD) of the Goerli testnet reaches 10790000 , which is expected to be on August 6-12, 2022.

Once the execution layer exceeds TTD, the next block will be completely controlled by the beacon chain The verifier is generated. Once the beacon chain has finalized the block, we consider the merge complete. Assuming normal network conditions, this should be done 2 epochs after the first block after the TTD trigger, which is about 13 minutes later!

There is a new JSON-RPC block tag finalized which returns the is the latest finalized block, or returns an error if no such merged block exists. This tag can be used by applications to check whether the merge has completed. Likewise, a smart contract can query the DIFFICULTY opcode (0x44), which is renamed PREVRANDAO after a merge, to determine whether a merge has occurred. We recommend that infrastructure providers monitor overall network stability in addition to finalization status.

Client Version

The following client versions support the merger of Goerli and Prater testnets. Node operators must run an Execution Layer (EL) client and Consensus Layer (CL) client to remain on the network during and after the merge.

When selecting clients to run, validators should pay special attention to running EL and CL Risk for most clients. See this explainer for these risks and their consequences. See this article for an estimate of the current distribution of EL and CL clients and guidelines for switching from one to the other.

Consensus Layer

Lighthouse Geardude Clockberg (v2.4.0)

Lodestar v0.41.0

Prysm v2.1.4-rc.0

Nimbus v22.7.0

Teku 22.7.0

Execution Layer

Besu 22.7.0-RC3

Erigon 2022.07.03-alpha

go-ethereum (geth) v1.10.21

Nethermind 1.13.5

Upgrade specification< /h4>

The merged consensus key changes are specified in two places:

Consensus layer changes, in the bellatrix directory of the consensus specification warehouse

Execution layer changes, in the Paris spec of the execution specification warehouse

< /p>
Additionally, two other specifications cover how the consensus layer and execution layer clients interact:

Engine API is described in the execution-apis repository, it is used for communication between the consensus layer and the execution layer

Optimistic Sync is explained in the sync folder of the consensus specification warehouse. It is used by the consensus layer to import blocks when the execution layer is synchronized, and provides the execution layer with a partial view of the chain header of the consensus layer.

FAQ

< /p>

1. What should I do as a node runner?

After the merger, an Ethereum full node will combine a consensus layer client (running the PoS letter token chain) and an execution layer client (managing user state and running transaction-related calculations). They communicate over an authenticated port (using a new set of JSON RPC methods called the Engine API). The execution layer client and the consensus layer client use an encrypted JWT to authenticate each other. Node operators need to refer to their client documentation on how to generate and configure this information.

In other words, if you already have a node running on the beacon chain, you now An execution layer client also needs to be running. Likewise, if you are running a node on the current PoW network, then you will need to run a consensus layer client. In order for them to communicate securely, each client must be passed a JWT token. Brief instructions for running a node on the Goerli/Prater network can be found here.

It is worth emphasizing that although the beacon chain nodes and validator clients are consensus layers part of the client, but running a beacon chain node is not the same as running a validator client. Validators must run both, while node runners only need to run beacon chain nodes. This article explains the difference between these two components in more detail: https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-client-architecture/

Also, note that both the consensus layer and the enforcement layer maintain a separate set of peers and expose their own API . Both Beacon and JSON RPC APIs will continue to work as expected.

2. As a staker, what do I need to do?

The Goerli/Prater merge is the last thing everyone wants to make sure validators are properly configured before mainnet transition Chance. We strongly recommend participating in this merger to avoid any unexpected issues on mainnet.

As mentioned above, after the merger, validators on the beacon chain run their consensus In addition to the client layer, an execution layer client needs to be running. We strongly encourage everyone to do this before merging, but validators can outsource these functions to third-party providers. This is possible because the only data the execution layer needs are updates to the deposit contract.

After the merge, validators need to ensure that the transactions in the block they created and proved are valid of. In order to do this, each beacon node must be paired with an executive layer client.

Note that multiple validators can still be paired with a beacon node and executive layer client combination. While this increases the liability of validators, it also entitles validators proposing blocks to receive priority fees for their associated transactions (currently collected by miners).

While validator rewards are accumulated on the beacon chain and will not be claimed until subsequent network upgrades, transaction fees will continue to be paid at the execution layer , destruction and allocation. Validators can designate any Ethereum address as a recipient of transaction fees.

After updating your consensus layer client, make sure Set the fee recipient (fee recipient) when setting up the validator client to ensure that the transaction fee can be sent to the address you control. If a third-party provider is selected for staking, it is up to the provider you choose to specify how these fees are distributed.

Prater Staking Launchpad has a merge readiness checklist that validators can use to make sure they are done every step of the process. The EthStaker team will also be hosting a merge validator preparation workshop on July 29th.

3. Why is the estimated time span for Terminal Total Difficulty so large?

Increased difficulty fluctuations per block make TTD estimates higher than block or epoch heights Harder, and thus a wider range of expectations. Users should be aware that this will also occur during the transition period of the mainnet due to changes in the proof-of-work hash rate.

4. What should I do as an application or tool developer?

Goerli testnet is ready for merger, now is your last chance to secure your product Going through the PoS transition smoothly and functioning as expected in the merged environment. As mentioned in a previous blog post, the merge will only have a very weak effect on a subset of contracts deployed on Ethereum and should not break any contracts. Additionally, API endpoints for most users will remain stable (unless proof-of-work specific methods like eth_getWork are used).

Nevertheless, most applications on Ethereum involve much more than on-chain contracts. Now you want to make sure your front-end code, tools, deployment pipeline, and other off-chain components work as expected. We strongly recommend that developers perform a full test and deploy cycle on Ropsten (or Kiln) and report any issues with the tools or dependencies to the maintainers of those projects. If you're not sure where to open an issue, use this repository.

Also, you need to note that all testnets except Sepolia and Goerli will Shut down after the merger. If you are a user of the Ropsten, Rinkeby or Kiln testnets, you should plan to migrate to the Goerli or Sepolia testnets. For more detailed information, please read the article "Ropsten, Rinkeby and Kiln Testnet Deprecation Announcement".

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

No need. The Ethereum mainnet is not affected by this testnet. We will make a follow-up announcement on this blog before the mainnet transition.

6. As a miner, what do I need to do?

No need. If you are mining on the Ethereum mainnet or the Sepolia testnet, you need to know that after the merger each network will operate entirely under the PoS consensus. At that time, mining will no longer be possible on the network.

7. As a validator, can I stake my stake?

No. The merger is ethereum's most complex upgrade to date. In order to minimize the risk of network disruption, we have taken the minimum feasible approach, which means that in this upgrade, we set aside all changes that are not related to the PoW->PoS transition.

The ability to withdraw funds from the beacon chain may be upgraded for the first time after the merger Introduced in. The normative promotion of the consensus layer and the execution layer is in progress.

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

The EthStaker community has set up a discord channel to answer staker and node operator questions. You can join their discord and ask for help at #goerli-prater As mentioned above, EthStaker will also be hosting a merge validator preparation workshop on July 29th.

Additionally, a merged community meeting is scheduled for August 12 at 14:00 UTC. Client developers and researchers will answer questions from node runners, stakers, infrastructure & tools providers, and community members. Note that this community call is expected to take place following the Goerli/Prater merger.

9. When to merge?

As of the publication of this article, no date has been set for the Ethereum mainnet merger. Any talk of a merger date is likely to be a hoax. Updates will be posted on the Ethereum Foundation blog, don't be fooled!

Assuming the Goerli/Prater merger finds nothing wrong, when the client releases a fully functional version, We will choose the slot height to activate the Bellatrix upgrade on the mainnet beacon chain, and set the overall difficulty value used to trigger the mainnet transition. Clients will release versions for mainnet mergers. We'll be announcing it on this blog, as well as on other community platforms.

The above are based on the premise that no problems have been found. If at any point during this process issues are discovered, or the testing coverage is determined to be insufficient, we will address them before moving forward with the deployment process.

Only until then, It is only possible to estimate the exact date of the merger.