The Merge client release strategies

Proposed Mainnet Merge Client release strategies, Single client release, Dual Client Release, Difference between Single and Dual Release, Single Release & TTD Override

The Merge client release strategies

Ethereum public testnets are currently being merged as part of #TestingtheMerge, only Goerli remains to be merged and this will happen very soon. Therefore, Tim Beiko from the Ethereum Foundation, who facilitates the core developer calls, briefed three client release merge deployment strategy. The Ethereum mainnet merge is scheduled to occur after theGoerli testnet merge.

  1. Bundling Bellatrix and the true TTD in a single release
  2. Dual release - first release huge TTD and when Bellatrix is live then true TTD release
  3. Single Release & TTD Override like in Ropsten

The Ethereum Developers came to the approximate conclusion at last Thursday's Consensus Layer call that a _ Single Release _ would be the ideal method for activating the Ethereum mainnet merge, which is scheduled to occur in the week of September 19 following the results from the Goerli testnet merge.

This release decision was made in light of the most recent Ropsten and Sepolia testnet merges. The node operators on these testnets had to download a new client software initially, and then subsequently either download a second client release or submit a terminal total difficulty (TTD) override command to the first client release. Both of these were not single client releases, and there were a few minor config issues during the merge that are extremely unlikely to, but still have a possibility of happening during the mainnet merge.

With this in mind, the single release will be tested by merging the Prater chain and the Goerli testnet in order to identify any potential problems and take appropriate action prior to the mainnet merge. If everything goes according to plan, the Goerli/Prater merge should take place by July 11 and the Ethereum mainnet merge will be in the week of September 19, exact date is yet to be declared.

Table

Proposed Mainnet Merge Client release strategies

Single client release

Pros

  • Because both the EL (Execution Layer) and CL (Consensus Layer) need to be updated to versions that have the right TTD just once, there is a non-trivial risk of operator error which is prevalent when updating the nodes twice. Consequently, the UX for node operators is simpler.
  • Can deploy a little bit faster: not requiring two releases or announcements likely saves the 1-2 weeks in the process.

Cons

  • Possibility of TTD being reached before Bellatrix is turned on. As a result, The Merge is effectively "broken," as the EL will halt once it reaches TTD until the CL activates Bellatrix. The liveness failing would result from this. Additionally, there hasn't been much testing done on the "flow" of ELs waiting for Bellatrix to combine, especially on the time scale of days.
  • The Ethereum mainnet's hashrate would need to increase noticeably (i.e., by more than two times) for this to take place. If this were to occur, it would be visible days or weeks in advance.
  • Two potential mitigations include (1) moving Bellatrix closer to the epoch being chosen or announced, but in reality 2 weeks is probably the minimum, and (2) delay between Bellatrix and TTD for a longer period of time, though >2 weeks probably makes it easier to have distinct releases.

Dual Client Release

Pros

  • Bellatrix happens before TTD is hit, without a doubt
  • There is no scenario where a liveness failure could be brought about because we expressly wait for Bellatrix to be enabled before TTD is selected.

Cons

  • More extensive coordinating
  • Both releases must be publicized, the more difficult process must be explained, clients must release two versions, etc.
  • Can partially reduce by making it explicit in the initial announcement that a second release will be made following Bellatrix, which has a set period.
  • Greater likelihood of operator error
  • Since both the EL and CL must be updated twice, there are four possible updates where anything could go wrong as opposed to two in a single release.
  • Increase of 1-2 weeks in the deployment process

Difference between Single and Dual Release

With a single release, you can select the Bellatrix epoch and TTD and have The Merge occur 3–4 weeks later; but, with two releases, the complete procedure would probably take 4-5 weeks because users would need to be given enough time to upgrade their nodes twice.

Single Release & TTD Override

Pros

  • To hit TTD before Bellatrix activates is impossible.
  • possibly faster than dual release tactics, or perhaps single release strategies as well
  • There is no need to wait for the following releases (just apply the override)
  • Can communicate the orders to execute (with a placeholder rather than TTD) beforehand so that individuals are aware of what they are

Cons

  • Users must go through two distinct flows (downloading a release, and applying a TTD override)
  • Risk of operator error increasing (override may not be done appropriately or it may be difficult to confirm whether it has been applied).

Summary

Currently, Ethereum has 4 EL clients ( Geth, Open Ethereum, Erigon and Nethermind) and 5 CL clients (Teku, Nimbus, Lighthouse, Lodestar, Prysm) spec ready for the Merge.

Following the debate over the consensus layer call, the conclusion appears to be that (a) making user experience simpler is crucial and (b) the risk of hitting the TTD too early does not alter the security model under PoW (that an attacker has 50% of hash power). Therefore, the first choice—a single client release—seems like a decent idea. To reduce the execution risks of Ethereum's switch to proof-of-stake, the decision was made to streamline the Merge activation process by removing the requirement that node operators upgrade both their EL and CL nodes twice (PoS). The user experience for operators during the Merge is enhanced and the danger of potential operator errors and mishaps is decreased.

Highlights of Ethereum Consensus Layer meeting 91

Read more

Read more about Ethereum in previous Bulletins -Ethereum Bulletin

Related articles

_________________________________________________________________________

Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.

To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Support us at Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.


Share Tweet Send
0 Comments
Loading...
You've successfully subscribed to EtherWorld.co
Great! Next, complete checkout for full access to EtherWorld.co
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.