We wrapped up an eventful @Ethereum #AllCoreDevs earlier today! Covered testnets, and everything being considered for Shanghai.. along with what "considered" even means Agenda: github.com/ethereum/pm/is… Stream: youtu.be/HX_Zr_gVeOE Recap below!

First on the call, after pushing it back a few times, we had Afri (@Q. on gh/ethmag) give us an update on the latest discussions around testnet sustainability.

At a high level, it's hard to offer guarantees around long-term testnet maintenance. State grows, supply gets hard to obtain, etc. Afri therefore has a proposal for more explicit commitments around testnet lifeschedules: ethereum-magicians.org/t/proposal-pre…

While testnets shutting down isn't great, if that's the default path (because they get too hard to maintain), then we should at least provide more predictability around it so users can plan migrations well ahead of time.

Also worth noting that there are many different uses for testnets: testing EIPs in production before mainnet, stakers testing their setup and, of course, apps and users deploying and testing contracts. There's a world where the solution for each of these looks very different!

Goerli is currently the only testnet available for stakers to use, but it's been really hard to get GoETH. Sepolia doesn't have this problem (can mint it), but has a restricted validator set and has less contracts on it than Goerli

Thinking about the best solutions for client teams, stakers, developers, users is important. @Mario Havel also shared a proposal for ephemeral staker testnets that would allow people to test their setup quickly on a network where 32ETH is easily available: github.com/taxmeifyoucan/…

Lastly, we discussed shutting down of Ropsten We had already committed to doing it down post-merge, and it has mostly been deprecated by infra providers and abandoned by validators already. Expect a full shut down around the holidays, and a proper announcement !

And, for the rest of the call, we discussed the status of the various Shanghai proposals, along with when we'd want the upgrade to happen. There was a lot of nuance shared here, so I'd strongly recommend watching the livestream

First, we discussed which of the EIPs we've been discussing should be moved to "Considered for Inclusion" status. A few years ago, we added the CFI status to highlight EIPs that client teams liked and wanted to potentially implement, without committing them to a specific fork

You can see that here: github.com/ethereum/execu…

Over the past few upgrades, though, almost everything that's been CFI'd has been included in forks, raising questions about whether CFI is actually useful/valuable, and whether it's a waste of time to even try and articulate what's CFI vs. just include things.

I don't think it is Obviously, for folks who spend all of their time thinking about network upgrades, the context/distinction is quite clear, but it makes it very hard for the community to have a read around what's being considered.

So, we took a decent chunk of the call to go over what should be CFI'd There was a lot more back and forth, but for brevity's sake, here's where we landed on things.

First, we discussed the EVM Object Format (EOF) EIPs. If you don't know what EOF is, @ً had a great thread about it last week: twitter.com/lightclients/s…

EOF previously had two EIPs (3540/3670) CFI'd, but since then the consensus has moved to wanting to do the full suite of EOF EIPs together, to minimize any extra EOF version (which then needs to be maintained forever by clients).

While not everyone agreed about if/when/how we should do EOF, there is definitely strong support, and the EIPs are already being implemented in devnets, which historically has happened _after_ EIPs are CFI'd. So, the 3 other EOF EIPs have been CFI'd: 4200, 4750 and 5450

Next up, we discussed EIP-4844. @liam.eth had a great thread yesterday summarizing the current state of things there: twitter.com/liamihorne/sta…

For similar reasons to EOF (4844 also has been prototyped and launched on devnets across multiple clients), we agreed to move it to CFI

After that, we had an interlude discussing exactly what CFI should signify/if it has value/etc. I won't recap this part, but if you care about that stuff, I recommend watching the stream That's something we'll have to think about more, but it's unlikely to happen pre-Shanghai!

At a high-level, though, the questions are: - Should CFI even be a thing? - If so, should it be a signal that we want the EIP in _this_ fork (currently, no) or in _a fork soon_ (closer to people's understanding, in my view) - How "strong" should the CFI commitment be?

Continuing on our list, the next proposal was EIP-4758, which proposes to deactivate SELFDESTRUCT, replacing by a SENDALL opcode which transfers the funds but leaves the contract as is.

One issue with this proposal is that it breaks the use cases where a contract can be deployed with CREATE2, then SELFDESTRUCTed and then re-instantiated at the same address. A smart contract author which uses this pattern came on the call to explain how it would affect them.

You can read more about this specific issue here: ethereum-magicians.org/t/eip-4758-dea…

The consensus here was to wait to CFI the EIP until we have a proposal to address this edge case. That said, it's more and more likely that SELFDESTRUCT deprecation is a question of *when* and not *if*. Prepare for this! twitter.com/vdWijden/statu…

Lastly, we moved EIP-2537, which introduces a BLS precompile, to CFI as well.. mostly on the grounds that it's been CFI'd since the Berlin upgrade

So, in short, Shanghai currently is guaranteed to include the following EIPs: EIP-3651: Warm COINBASE EIP-3855: PUSH0 instruction EIP-3860: Limit and meter initcode EIP-4895: Beacon chain push withdrawals as operations

And the list of CFI'd EIPs is: EOF (3540, 3670, 4200, 4750, 5450) EIP-1153 (transient storage) EIP-2537 (BLS precompile) EIP-4844 (protodanksharding) The SELFDESTRUCT EIP may also be CFI'd, pending spec changes to deal with existing contracts breaking.

cc: everyone who thinks withdrawals are cancelled or delayed :-)

Then, we spent the rest of the call discussing how to prioritize things for Shanghai. Again, there was a lot of back and forth here, so I'll summarize the highlights and recommend the livestream for the nuance

And I'll emphasize by saying this was a relatively non-technical conversation much more focused on "what are the important things we should do", so please don't be intimidated if your idea of ACD's is "discussing the technical implementation details of EIPs"!

So, to start, I asked the various client teams what they thought should be the priority and scope for Shanghai

.@Go Ethereum went first, saying that they'd like to have a relatively "lean" Shanghai which prioritizes withdrawals, ideally includes EOF, and goes live around March

.@erigon.eth also wants a small fork, but feels like EOF & 4844 are both quite big, so would rather include smaller things alongside withdrawals.

.@Nethermind +1'd withdrawals, and thinks they have the bandwidth to include one other significant thing, whether it's EOF or 4844. They have a preference for 4844.

.@Hyperledger Besu is in a similar spot with withdrawals, but would rather have EOF come alongside it than 4844.

There were also several CL team representatives on the call. @terence.eth from Prysm shared the same view as here: twitter.com/terencechain/s… Withdrawals Priority #1, and 4844 alongside it if it doesn't cause delays (while keeping the code decoupled).

@Paul Hauner from Lighthouse and @Ben Edgington from Teku both +1'd this view. @Jacek Sieka agreed on withdrawals, but was skeptical that 4844 could be done without introducing significant delays.

So, the broadest commitment across teams is that withdrawals happening quickly, ideally around March, should be the priority. There are other things they are working on in parallel, and if these can make it at the same time, we should include them, but withdrawals guide the fork.

That said, there was some pushback on the idea that we should try and "bundle what fits" with withdrawals. @proto.eth argued this isn't a good way to encompass the community's preferences in the process, who aren't really represented as part of ACD.

If you assume that 4844 _is_ the second most important thing, but then bundle several other things with withdrawals, then there's a risk this ends up delaying 4844 while not providing as much value in the meantime.

There wasn't a clear "outcome" here - on one hand, it's obviously true, but OTOH, teams shared that they were generally able to work on these streams pretty independently.

Based on that, and only having 5 mins left to the call, I asked teams when they would need a clear commitment on the scope of Shanghai given that at some point you do need to merge these things into a single upgrade

While Geth was in a fortunate position with most things implemented, it wasn't the case with all EL clients, and for others, getting clarity ASAP would help.

On the CL side, the code is structured so 4844 is activated after withdrawals no matter what (it could be a delay of 1 epoch / 12 minutes, not necessarily "months apart!), and there aren't as many other competing proposals, so "merging things together" isn't really an issue

So, now 5 minutes overtime, we agreed to have a discussion about the added complexity of 4844 along with Withdrawals on the CL call next week. We're then aiming to make a decision about which EL EIPs to include in Shanghai on the ACD after that.

It's worth noting that the next ACD (Dec 8!) will be the last one of 2022, so it'd be great to wrap up the year with the final specs for Shanghai

And, lastly, @MariusVanDerWijden gave an update on withdrawal progress: as he had shared earlier this week, we've launched a devnet with 5 clients running twitter.com/vdWijden/statu…

We agreed to start the next call with a proper status update on withdrawals, to make sure we aren't in the same situation of discussing everything else and not having time for it! See you then, on Dec 8th, 14:00 UTC