# Single vs. Dual Merge Releases Pros and cons of bundling Bellatrix and the true TTD in a single release, vs. first deploying Bellatrix with a placeholder TTD and then having a second release which contains the true TTD. ## Single Release ### Cons * Risk of TTD being hit before Bellatrix is activated. This effectively "breaks" The Merge, as the EL will stall upon reaching TTD until the CL activates Bellatrix. This would cause a liveness failure. Also, the "flow" of ELs waiting until Bellatrix to merge, especially on the order of days, hasn't been tested extensively. * For this to happen, the hashrate on the Ethereum mainnet would have to change significantly (read: >2x). If this happened, it would be visible days/weeks in advance. * If this were to be noticed, a `TTD override` could be coordinated. * The closer we are to Bellatrix, the more hashrate is needed to bring TTD forward. For example, if client releases are put out with Bellatrix hitting 2 weeks later and TTD scheduled 2 weeks after that, an attacker would need to 2x the hashrate to have TTD happen before Bellatrix if they started mining on the announcement. One week in, with Bellatrix 1 week away and TTD 3 weeks out, they'd need to >3x the hashrate. 2 days before, with TTD 16 days out, they'd need >8x, and so on. * Two possible mitigations are (1) have Bellatrix happen closer to the epoch being chosen/announced, although realistically 2 weeks is probably the minimum and (2) have a larger delay between Bellatrix and TTD, although >2 weeks probably makes it simpler to have separate releases. ### Pros * Simpler UX for node operators: only have to update the EL/CL combo once rather than twice. * There is a non-trivial risk of operator error in updating nodes twice, because both the EL and CL need to be updated to versions which have the correct TTD. * Can deploy slightly quicker: not needing two releases/announcements probably saves 1-2 weeks in the process ## Dual Releases ### Cons * Increased coordination costs * Need to announce both releases, explain the more complicated process, have clients release two versions, etc. * Can mitigate partially by clearly stating in the first announcement that a second release will be announced after Bellatrix, which has a fixed time. * Increased risk of operator error * Having to update both the EL and CL twice means there are 4 potential updates where things can go wrong vs. 2. * 1-2 week increase in deployment process * While with a single release you can choose the Bellatrix epoch & TTD and have The Merge happen 3-4 weeks afterwards, with two releases, you would likely need 4-5 weeks for the entire process, as sufficient notice needs to be given to users to update their nodes twice. * In the past few years, the quickest we've ever had users update their software is ~1 week, with [Muir Glacier](https://blog.ethereum.org/2019/12/23/ethereum-muir-glacier-upgrade-announcement/). If we warn users ahead of time they will need to update twice, it could be possible to provide a similar window. That said, too short of a window also opens the door to an attacker making the merge happen quicker than expected (though with much lesser negative impacts) ### Pros * Certainty that Bellatrix occurs before TTD is hit * Because we explicitly wait for Bellatrix to be activated prior to TTD being chosen, there is no scenario where a liveness failure is caused. ## Single Release & TTD Override Have a single client release with an arbitrarily high TTD, and then, once Bellatrix is activated, tell users to do a TTD override, like we did for Ropsten: [release](https://blog.ethereum.org/2022/05/30/ropsten-merge-announcement/), [override](https://blog.ethereum.org/2022/06/03/ropsten-merge-ttd/). ### Cons * Users need to run through two different flows (downloading a release, and applying a TTD override) * Increased risk of operator error * Risks of override not being applied correctly / challenge to check whether it has been applied * Can "build a tool" but unclear it would work across all setups, especially more complex ones which are likely used by larger validators ### Pros * Impossible to hit TTD before Bellatrix is activated * Might be quicker than dual (and single?) release strategies because: * Don't need to wait on second set of releases (just apply the override) * Can share the commands to run (with a placeholder instead of TTD) in advance so people know what they are * If warning users in advance, can perhaps have the override happen quicker to Bellatrix than in even single releases, because we are estimating it from much "closer", so less drift