Thread by @TimBeiko

We just wrapped up @ethereum #allcoredevs no. 130! Covered a lot of Merge ⛓ & Shanghai updates 🇨🇳

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

Recap below 👇🏻

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

@ethereum First on the call, @mkalinin2 presented an upgrade to the Engine API spec to address some issues we've seen on Kintsugi w.r.t. re-orgs. Full link here: github.com/ethereum/execu…

@ethereum @mkalinin2 In short, the PR makes it optional for EL clients to actually execute a payload when receiving an executePayload call (and hence renames that call to newPayload for clarity).

@ethereum @mkalinin2 The reason here is that when ELs receive payload which isn't on the canonical chain, they may choose to simply store/cache it rather than execute it immediately. This relaxes the constraints on the specification to allow this.

@ethereum @mkalinin2 That said, on the call, @mhswende suggested that we should only make this optional for non-canonical payloads, and that we should expect ELs to execute all payloads received on the main chain, see this comment:

@ethereum @mkalinin2 @mhswende It also addresses some CL <> EL communication issues when clients are syncing and receiving blocks on fork chains in parallel, see:

@ethereum @mkalinin2 @mhswende All EL teams on the call seemed to agree this was a good idea. We'll keep discussing this week and hopefully have it merged/agreed to by the CL call next week. Of course, we'll need to add test cases for the various edge cases implied by this change.

@ethereum @mkalinin2 @mhswende Next up, @mhswende presented his suggestion for an authentication mechanism between EL and CL nodes: github.com/ethereum/execu…

@ethereum @mkalinin2 @mhswende The goal of this mechanism is to act as a simple guard against people potentially exposing their Engine API to the open internet when running a node. While before, the worst that could happen with exposing a port was spam/DoS, post-merge, someone could mess with validator actions

@ethereum @mkalinin2 @mhswende The proposal is to use a JWT token for HTTP and websocket requests, which can be either user-supplied or, if not supplied, generated by clients on startup.

@ethereum @mkalinin2 @mhswende All EL teams seemed generally fine with this approach. Martin will open a PR, and we'll get feedback from CL teams before/on the CL call next week. Assuming all that is good, we'll proceed with implementing it 🛠

@ethereum @mkalinin2 @mhswende Next up on the call, Harry from @trufflesuite raised some potential issues around tooling due to the DIFFICULTY opcode being renamed and having its value changed to RANDOM post-merge.

@ethereum @mkalinin2 @mhswende @trufflesuite In short, this change will make it hard for tools which look at bytecode to, without context, know how to interpret this opcode. While this isn't great, there isn't an easy fix at the protocol level, and there are limited cases where the pre/post-merge context isn't available.

@ethereum @mkalinin2 @mhswende @trufflesuite We agreed to not change anything at the protocol level to address this, but will make sure to mention it in the next merge community call (cc: @trent_vanepps!)

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps Next up, we discussed how we should approach testnets beyond the merge. A few people had been asking in the discord where they should deploy things, and we hadn't explicitly thought through the options before.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps Recommend watching the livestream for the discussion, but, in short, we agreed it makes sense to always have at least one testnet with publicly open validator sets, and one with a closed one (for stability).

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps Similarly, we agreed that over time, testnets grow in size and there isn't a ton of value in that. So we should perhaps try and be more aggressive in deprecating old testnets and spawning new ones.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps We didn't come to a crystal clear conclusion, and will keep discussing this in the coming calls, but if you are looking for the safest bet for a testnet that will stay around long term post-merge, it's probably Goerli.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi also shared his thoughts:

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

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi Last on the call, we discussed a few potential EIPs for Shanghai. First was a question from @mhswende about EIP-4444. TL;DR, it's one thing to remove historical data, but we need to ensure it is available *somewhere*. How do we do that?

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi A bunch of folks are working on this, and will be sharing updates in coming calls as they make progress. See a recent thread by @0xRaino on the subject for more context:

https://twitter.com/0xRaino/status/1481657327283359749

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino Next up, @ralexstokes mentioned wanting to champion EIP-2537 and that he is looking for feedback from teams about blocks given that this EIP was close to inclusion in both Berlin and Shanghai.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino @ralexstokes We now have BLS libraries used in production on the beacon chain, so a lot of the issues around that are no longer as salient. Similarly, when planning London, there were concerns that perhaps EVM384 could make BLS less useful.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino @ralexstokes EVM384 seems less likely to happen now, and even if it did, there seems to be some desire to also have a precompile for BLS.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino @ralexstokes Lastly, @greg_colvin had shared his thoughts about a potential roadmap for the various EVM improvement EIPs, see: github.com/ethereum/pm/is…

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino @ralexstokes @greg_colvin We want to avoid repeating what happened with 2315, where it was included in an upgrade but removed at the last minute because it wasn't clear whether there were strong use cases for it.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino @ralexstokes @greg_colvin So it's valuable to think through the priority list now and solicit feedback from the community. We didn't get much time to discuss this on the call, but after the call there were some indications that 3540, 3670 and 3860 would make sense in Shanghai.

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino @ralexstokes @greg_colvin If you have strong opinions about the EVM or any of these proposals, now is the time to share them! The "discussions-to" link of each of these EIPs is the best place to do so:

* eips.ethereum.org/EIPS/eip-3540
* eips.ethereum.org/EIPS/eip-3670
* eips.ethereum.org/EIPS/eip-3860

@ethereum @mkalinin2 @mhswende @trufflesuite @trent_vanepps @peter_szilagyi @0xRaino @ralexstokes @greg_colvin And that was it! Expect a next version of the merge spec next week with the changes discussed above. Next CL call is Jan 27 14:00 UTC, and next ACD is Feb 4th 14:00 UTC. See you then 👋🏻