Linked with GitHub
# 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
* 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.
* 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
* 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)
* 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/).
* 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
* 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