Thread by @TimBeiko

We wrapped up another @ethereum #AllCoreDevs this AM 🛠

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

Recap below 👇🏻

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

@ethereum First up, @nethermindeth had an announcement urging people to upgrade to v1.11.2 to mitigate a potential PoW vulnerability. More details here:

https://twitter.com/nethermindeth/status/1437815831015079938

Upgrade your nodes 🚨

@ethereum @nethermindeth Then, we discussed several things related to The Merge ⛓

@ethereum @nethermindeth 1. @mkalinin2 is working on specs for the first interop devnet between execution and consensus clients. You can expect them early next week 👀

@ethereum @nethermindeth @mkalinin2 2. To simplify the initial implementations of the merge, we agreed to have synchronous message ordering on the consensus layer. This means that the beacon chain will wait until it hears back from the execution layer before sending more messages.

@ethereum @nethermindeth @mkalinin2 As we implement devnets and get a better feel for the bottlenecks and possible optimizations, we'll move some of the messages to be asynchronous.

@ethereum @nethermindeth @mkalinin2 3. After some back and forth, it seems like we'll be hardcoding the terminal total difficulty (the point at which execution clients start listening to the beacon chain instead of PoW) rather than computing it dynamically.

@ethereum @nethermindeth @mkalinin2 We discussed the tradeoffs of this on the call, so I encourage you to watch the livestream for nuance. The Github PR has a good description of the rationale: github.com/ethereum/conse…

@ethereum @nethermindeth @mkalinin2 TL;DR: there are two issues, one subtle one where clients may reach different TTDs (see: github.com/ethereum/conse…), and another where, if the TTD isn't hardcoded, users who do nothing or incorrectly set up their node for the merge may not realize they haven't moved to PoS.

@ethereum @nethermindeth @mkalinin2 The way the merge is set to work is that first, the beacon chain will upgrade to support sending/receiving messages to/from the execution layer, then, once the execution layer hits the TTD, it will stop broadcasting blocks + listening to PoW, and instead listen to the PoS layer.

@ethereum @nethermindeth @mkalinin2 What we want to avoid with a hardcoded TTD is a case where we hit the TTD _before_ the beacon chain upgrades. Another potential issue, though less severe, is if hashrate drops a lot pre-merge and we set the TTD to early, we might be waiting for the merge for longer than we'd like

@ethereum @nethermindeth @mkalinin2 We discussed a few options, but didn't come to a decision for exactly how to handle the rollout. There was general consensus for using a fixed TTD, and it's likely more conversations happen on the PRs/issues linked.

@ethereum @nethermindeth @mkalinin2 4. @protolambda brought up an issue about transaction type representations differing between the execution and consensus layer, details here: github.com/ethereum/conse…. We didn't discuss on the call much, but folks are starting to chime in on the issue with their preferred approach

@ethereum @nethermindeth @mkalinin2 @protolambda Lastly, we asked the various client teams for their progress on implementing the APIs and sync protocols for the merge. Still a WIP for everyone, and a new version of the sync spec should be shared next week.

@ethereum @nethermindeth @mkalinin2 @protolambda FYI: on the sync note, post-merge sync will require large refactors in clients, which will result in Geth dropping support for fast sync.

https://twitter.com/peter_szilagyi/status/1438503255126929408

@ethereum @nethermindeth @mkalinin2 @protolambda Then, we went on to discuss EIP-3756, which proposes to cap the gas limit (but let miners lower it as needed).

@ethereum @nethermindeth @mkalinin2 @protolambda While it seems like most teams are generally in favor (w/ the exception of Erigon being against, but OK with whatever the majority decides), the EIP opens several thorny questions: what gas limit _should_ we set? when should it be increased?

@ethereum @nethermindeth @mkalinin2 @protolambda One major reason for the EIP is the misaligned incentives between miners/validators (who want to optimize for their revenue and can get bribed to increase the gas limit) and the short + long term health of the network with DoS risks and state growth.

@ethereum @nethermindeth @mkalinin2 @protolambda Everyone seemed to agree that if miners/validators were to raise the gas limit to dangerous levels, it would make sense to deploy this. Again, defining a "dangerous level" is hard to do in advance and more a case of "you know it when you see it" 😅

@ethereum @nethermindeth @mkalinin2 @protolambda Relatedly, we discussed whether *if* we accepted this, we should do it before, alongside, or after the Merge.

@ethereum @nethermindeth @mkalinin2 @protolambda On one hand, there is never a good time for these changes, and if we want to do it, sooner is best. OTOH, we currently did not plan to introduce any changes which needed to be deployed to testnets prior to the merge, and doing this would add some overhead.

@ethereum @nethermindeth @mkalinin2 @protolambda Similarly, two other EIPs were introduced on the call: EIP-3855, by @alexberegszaszi, which adds a PUSH0 opcode. This would, as it states, PUSH0 onto the stack, and save on gas costs by developers.

@ethereum @nethermindeth @mkalinin2 @protolambda @alexberegszaszi The other was EIP-3860 (eips.ethereum.org/EIPS/eip-3860), which limits the size of initcode.

@ethereum @nethermindeth @mkalinin2 @protolambda @alexberegszaszi EIP-3855 was weakly supported by everyone, but it wasn't clear that it was an important enough change to get done before the merge.

@ethereum @nethermindeth @mkalinin2 @protolambda @alexberegszaszi EIP-3860 fixes a potential DoS vector and would also provide better guarantees to the consensus layer about the payload size from the execution layer post-merge. We discussed whether we should consider this one for before the merge.

@ethereum @nethermindeth @mkalinin2 @protolambda @alexberegszaszi We were already close to the time limit, so couldn't discuss in depth, but _if_ we were to do 3860 before the merge, then it would also be trivial to add 3855 and 3756.

@ethereum @nethermindeth @mkalinin2 @protolambda @alexberegszaszi Because of the difficulty bomb, though, we need to make this decision _fast_! The bomb is expected to go off early December, which means we'd need to have forked the testnets in November and, well, have releases for this in October... which is soon!

@ethereum @nethermindeth @mkalinin2 @protolambda @alexberegszaszi So, we'll keep discussing this async and I'll spend time over the next two weeks thinking through the various options and timelines. One way or another, expect a final decision on the next ACD, which is scheduled for October 1st, 14:00 UTC. See you then 👋🏻

@ethereum @nethermindeth @mkalinin2 @protolambda @alexberegszaszi Oh, and one more thing: the @go_ethereum team shared a post-mortem about the minority split we saw a few weeks ago: github.com/ethereum/go-et…