Thread by @TimBeiko

We wrapped up @ethereum #AllCoreDevs 124 this morning, and, as promised, we've had several merge updates since the last call!

Agenda: github.com/ethereum/pm/is…
Stream:

Recap below 👇🏻

https://twitter.com/TimBeiko/status/1443992801486598147

@ethereum First on the call, we recap'ed the #amphora🏺 interop from last week. Rather than rehashing the recap, here's the blog post covering the event 😁:

https://twitter.com/TimBeiko/status/1449004495745138689

@ethereum A couple updates from the call that aren't in the blog post: Pithos, the new devnet which was launched yesterday, is now running with 3 consensus clients + geth. Besu + Nethermind will be added soon. Explorer: pithos-explorer.ethdevops.io

Build instructions: github.com/parithosh/cons…

@ethereum Second, @vdWijden is working on a fuzzer for the Engine API, which can be found here: github.com/MariusVanDerWi…

@ethereum @vdWijden Third, @peter_szilagyi is still working on the post-merge sync and expects a spec refresh 🔜

@ethereum @vdWijden @peter_szilagyi Lastly, @protolambda made the comment that one thing which helped #amphora be successful was having a clear set of milestones to aim towards, and that we should keep this approach for the upcoming devnets as we approach The Merge 💪🏻

@ethereum @vdWijden @peter_szilagyi @protolambda Then, we spent the bulk of the call discussing the difficulty bomb pushback: the bomb will go off in December, which means we need to push it back, but it was unclear by how much 😅

@ethereum @vdWijden @peter_szilagyi @protolambda I suggest people watch the livestream for the nuanced conversation, which wasn't too technical and gives a good glimpse into how we get to "rough consensus"! At a high level, there are a few things we needed to consider:

@ethereum @vdWijden @peter_szilagyi @protolambda 1. We need all client teams to be ready for the merge & different teams may be comfortable with different timelines;
2. Pushing back the bomb twice if we're too aggressive may disrupt merge progress, but having it too far can make it lose its forcing function utility;

@ethereum @vdWijden @peter_szilagyi @protolambda 3. The merge will be a more complicated upgrade than past ones, so we probably want some extra buffer relative to our regular upgrade schedules;
4. This means there are two blocks of time we need to consider: the time to implement things (variable) and the heads up (fixed);

@ethereum @vdWijden @peter_szilagyi @protolambda 5. A lot of the work will be towards planning for "disaster recovery" cases, which is quite hard to estimate;
6. The way we will set the merge, using the PoW difficulty, means users will need to update their nodes likely >1 time in the process;

@ethereum @vdWijden @peter_szilagyi @protolambda 7. The difficulty bomb is based on the current network hashrate, and if the hashrate falls rapidly prior to the merge (as miners want to sell their GPUs), that could accelerate the advent of the bomb.

@ethereum @vdWijden @peter_szilagyi @protolambda So, TL;DR, there are a lot of different things to weight, and people have differing opinions about them. We debated these things for most of the call and came to the following conclusions:

@ethereum @vdWijden @peter_szilagyi @protolambda 1. We wanted the bomb to not be too aggressive, but still want to maintain momentum towards the merge;
2. We want to be mindful that the bomb may show up weeks earlier if the hashrate drops;
3. Ideally, we'd like this to be the last we push the bomb back, but...

@ethereum @vdWijden @peter_szilagyi @protolambda ... everyone agrees having a safe, well tested merge is the most important thing, by far, and we're OK pushing the bomb back twice if that is required.

@ethereum @vdWijden @peter_szilagyi @protolambda 4. We think ~4 months is a generous timeframe from having the code done to seeing the merge on mainnet.
5. We think there's a chance this can happy by February (obviously, still a lot of unknowns!), so we decided to set the bomb based on that.

@ethereum @vdWijden @peter_szilagyi @protolambda All that being said, we're going to push the bomb back to June 2022, which is 4 months after February 💣 To be clear, if the merge was ready before, we could do it prior to that. Also, we can push the bomb back again if we're not ready. We'll need to make a call around Feb!

@ethereum @vdWijden @peter_szilagyi @protolambda This strikes a balance between keeping the momentum going, ideally not pushing back the bomb twice, and having some buffer room for a longer than usual rollout and/or large hashrate changes on the network. Again, lots of uncertainty, but that's what we agreed to 😁

@ethereum @vdWijden @peter_szilagyi @protolambda Here's the EIP for it: eips.ethereum.org/EIPS/eip-4345

Also, again, shout out to @tjayrush for sanity-checking all the numbers 🙏

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush Then, we had to decide when to actually have the network upgrade. I had proposed a set of blocks, and dates by which we'd need client releases:

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush No one had a super strong opinion on this, so we went with the second row, block 13773000 (etherscan.io/block/countdow…), which is set for December 8th. This gives client teams 3 weeks to implement the EIP, write a test for it, and put out a release.

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush So, to summarize:

🧊🏹 Arrow Glacier, block: 13773000 (~Dec 8th) 🏹🧊
One EIP included, 4345, which pushes back the difficulty bomb to around June 💣, again, assuming no major drops in hashrate ⛏

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush And that was the bulk of the call! There were two other small issues. First, we moved EIP-3607, which has now been implemented across all clients, to Final: github.com/ethereum/pm/is…

It was a simple security fix to an unlikely hash collision attack, which was never exploited.

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush Second, there was a question about whether @OpenEthereumOrg would be supporting the Arrow Glacier upgrade. The client has now been officially deprecated, and doesn't have a dedicated team maintaining it, but is still used by several folks.

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush @OpenEthereumOrg Given that the Arrow Glacier change is very small (literally a one line change), it's very likely someone in the community will add support for it in OE. That being said, the client _is_ deprecated, and if you haven't moved to an alternative, you absolutely should.

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush @OpenEthereumOrg To make this more explicit: devnets for the merge are already starting to go up, and OE doesn't support that, so if you do want to start preparing for The Merge before the last minute, you already kind of need to use another client.

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush @OpenEthereumOrg And that was it! Next call is scheduled for Oct 29, 14:00 UTC. See you then 🎃

@ethereum @vdWijden @peter_szilagyi @protolambda @tjayrush @OpenEthereumOrg

https://twitter.com/TimBeiko/status/1449054820480917507