Thread by @TimBeiko

This week's off-schedule @ethereum #AllCoreDevs call just wrapped up (early, for the first time in months!) 😁

Agenda: github.com/ethereum/pm/is…
Stream:
Summary below 🧵

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

First up, I gave a summary of my conversation with the various client teams over the past week. I had pasted a text version in the agenda as well:

TL;DR: client teams prefer a tighter-scoped London upgrade, London in July would be best, and if we keep London small + the Merge work goes according to plan, we should be able to do another feature fork this fall without delaying the merge.

There were four specific EIPs we were considering alongside the already included ones (1559, 3198, 3238) for London: EIP-2537, EIP-2677, EIP-3403, and EIP-3074.

EIP-2677 was the simplest: small change, but no one strongly in favor and, given it would add testing overhead, we're not adding it to London ❎

Then, we discussed EIP-3403. The EIP proposes to remove refunds from SSTORE and SELFDESTRUCT, except in a handful of cases. Because refunds can increase block gas consumption, and 1559 does too, limiting them in London was brought up as a security concern previously.

The challenge with 3403 lies in the "except in a handful of cases": adding such logic to clients increases code complexity and is prone to bugs. OTOH, completely disabling refunds would be a very large breaking change, and was already rejected (EIP-3298).

So, @VitalikButerin and @mhswende have been working on a new proposal, which would lower gas refunds from SSTORE from 15k to 4.8k gas, remove SELFDESTRUCT refunds and lower the maximum extra execution from refunds from 1/2 to 1/5th of the block.

This proposal would achieve the goal of reducing block elasticity, disincentivizing things like gas token, and reduce implementation complexity relative to 3403. The EIP was discussed in more detail on the call, but should be formally created early next week.

Everyone on the call seemed favorable to the idea, but given there is no actual EIP to look at yet, clients will review it over the next week and we will make a decision about this on next Friday's call ✅

Next up, we discussed EIP-2537, the BLS precompile. The champion asked what clients would like to see to include it in London, and there were two potential concerns: first, the desire to move to a new library, which would require more testing, and second, some gas price changes.

While neither of these are very large changes, they would require more work, and this could potentially delay London.

The question, though, is if this doesn't make it into London, when would we see it on mainnet? The same question applies for EIP-3074.

We then spent a large part of the call discussing how we could balance having a "lean London", keeping The Merge a top priority, and shipping features that the community clearly wants, such as 3074 and 2537.

There was a lot of back and forth about this, and I encourage you to watch the livestream for the nuance, but this is what we agreed to 👇🏻

1️⃣ Keep London lean, and aim for a mid-July mainnet deployement. Only 1559, 3198, 3238 and the to-be-created refund EIP.

2️⃣ Keep working on the Merge in parallel to London and aim to ship it ASAP.

3️⃣ When London is done, start working on another small feature fork, Shanghai.

Shanghai should really be "only the things that we wanted in London but couldn't make it". If it is ready before the Merge, we ship it first. If the Merge is ready before, everyone is OK delaying Shanghai (and doing the extra technical work to adapt it) to after the merge.

Client teams were all confident that doing this would keep the most momentum: they are already focused on London and The Merge in parallel and good progress is happening on both. When London is out the door, then we can focus on Shanghai.

It's worth noting this is how we are operating for London: most of the work got started as Berlin was rolling out, and this is how we're able to have the fork happen only a few months (vs. 1+ year) after the previous one.

As for London timelines, this is roughly what we are going for. We didn't want to set blocks on this call given that code is still not merged in clients and we are still waiting on an EIP, but the dates should be pretty fixed, and blocks should come during the next call.

So, to summarize, we're looking at mid-July for London, and the fork will contain EIPs 1559, 3198 (BASEFEE opcode), 3238 (Ice Age pushback), and very likely a to-be-created EIP addressing the refunds issue which we'll discuss next call.

As for the Ice Age pushback, the current EIP was scheduled to push it back to Q2 2022. Given that we want to either ship Shanghai and/or the Merge this year, we agreed we should make the bomb go off sooner as a forcing function. Everyone on the call agreed on aiming for December.

Then, @lightclients proposed a new EIP, 3521 (github.com/ethereum/EIPs/…), which would improve the way EIP-2930 access lists are generated. People were generally positive, but there are some quirks to figure out.

We aren't including it into London, but it may be a good, small change to include in Shanghai 👀

Lastly, we discussed a few process-related things. The first was to have the "Considered for Inclusion" status for EIPs reset between each network upgrade. In short, this status is to signal that core devs like an EIP, but that there is still technical work to be done on it.

Given that people propose EIPs for specific upgrades and that they tend to "go stale" if they are not accepted in an upgrade, I proposed that we reset the status each time. If someone wants to get their EIP re-CFI, they simply have to propose it for a new fork.

No objections, we're going forward with that ✅ More conversation about this here: github.com/ethereum/pm/is…

Then, we spend a bunch of time discussing the value of these off-schedule calls, whether we should make decisions on them, and whether we should move AllCoreDevs to a weekly cadence instead of bi-weekly.

Again, lots of back and forth, and an interesting part of the stream to watch if you are interested in the cat herding of all this! We agreed to _not_ have the calls go weekly, and a few people highlighted that it was useful that I reached out to client teams between the calls.

So, I agreed to take more meetings for myself instead of everyone on the call, and whenever it feels like there are complex topics we need to get clients' thoughts on, I'll make sure to chat with all the teams and summarize their opinions prior to the calls 😁

Obviously, these calls being public is very important, so even though I will do the meetings myself and share a summary, I'll always make sure to leave room on the call for people to voice opinions on these topics. Let's see how this goes!

And that was it: it was the first time in a while we finished early! Next call is one week from now, April 30th, 14:00 UTC 👋🏻