Thread by @TimBeiko

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:

Recap below!

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

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

@ethereum @Q9F 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…

@ethereum @Q9F 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.

@ethereum @Q9F 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!

@ethereum @Q9F 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

@ethereum @Q9F Thinking about the best solutions for client teams, stakers, developers, users is important. @TMIYChao 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/… 🚰

@ethereum @Q9F @TMIYChao 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 🔜!

@ethereum @Q9F @TMIYChao 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 😄

@ethereum @Q9F @TMIYChao 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

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

@ethereum @Q9F @TMIYChao 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.

@ethereum @Q9F @TMIYChao 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.

@ethereum @Q9F @TMIYChao 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.

@ethereum @Q9F @TMIYChao First, we discussed the EVM Object Format (EOF) EIPs. If you don't know what EOF is, @lightclients had a great thread about it last week:

https://twitter.com/lightclients/status/1593270266909450241?s=46&t=i9fwm8kNpb-iHI-OhZIAgw

@ethereum @Q9F @TMIYChao @lightclients 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).

@ethereum @Q9F @TMIYChao @lightclients 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 ✅

@ethereum @Q9F @TMIYChao @lightclients Next up, we discussed EIP-4844. @liamihorne had a great thread yesterday summarizing the current state of things there:

https://twitter.com/liamihorne/status/1595592154650288129

@ethereum @Q9F @TMIYChao @lightclients @liamihorne For similar reasons to EOF (4844 also has been prototyped and launched on devnets across multiple clients), we agreed to move it to CFI ✅

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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!

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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?

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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.

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

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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!

https://twitter.com/vdWijden/status/1595792080651124737

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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 😅

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne cc: everyone who thinks withdrawals are cancelled or delayed :-)

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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 📺

@ethereum @Q9F @TMIYChao @lightclients @liamihorne 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"!

@ethereum @Q9F @TMIYChao @lightclients @liamihorne So, to start, I asked the various client teams what they thought should be the priority and scope for Shanghai 👀

@ethereum @Q9F @TMIYChao @lightclients @liamihorne .@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

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum .@ErigonEth also wants a small fork, but feels like EOF & 4844 are both quite big, so would rather include smaller things alongside withdrawals.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth .@nethermindeth +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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth .@HyperledgerBesu is in a similar spot with withdrawals, but would rather have EOF come alongside it than 4844.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu There were also several CL team representatives on the call. @terencechain from Prysm shared the same view as here:

https://twitter.com/terencechain/status/1595822292805861377

Withdrawals Priority #1, and 4844 alongside it if it doesn't cause delays (while keeping the code decoupled).

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner from Lighthouse and @benjaminion_xyz from Teku both +1'd this view. @jcksie agreed on withdrawals, but was skeptical that 4844 could be done without introducing significant delays.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie That said, there was some pushback on the idea that we should try and "bundle what fits" with withdrawals. @protolambda 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda 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 😄

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda 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

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda 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.

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda 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 😄

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda And, lastly, @vdWijden gave an update on withdrawal progress: as he had shared earlier this week, we've launched a devnet with 5 clients running 🙌

https://twitter.com/vdWijden/status/1595386746786779137

@ethereum @Q9F @TMIYChao @lightclients @liamihorne @go_ethereum @ErigonEth @nethermindeth @HyperledgerBesu @terencechain @paulhauner @benjaminion_xyz @jcksie @protolambda @vdWijden 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 👋