Thread by @TimBeiko

Last @ethereum #AllCoreDevs of the year tomorrow ‼

It's going to be a big one, where teams hopefully agree about the scope of the next network upgrade.

You can view the agenda here: github.com/ethereum/pm/is…
And follow along live on the stream: 📺

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

@ethereum And we wrapped up the call earlier today! The vast majority of the conversation was around Shanghai planning. Recommend watching the livestream to anyone interested in that side of things 📺 github.com/ethereum/pm/is…

@ethereum Before we got into that, though, there were a few important topics we wanted to be sure to cover. First, @trent_vanepps gave an update on the KZG Ceremony, which is a requirement for EIP-4844 to go live.

@ethereum @trent_vanepps There was a recent Twitter Spaces going into the details (

https://twitter.com/christine_dkim/status/1598080566293069825

) and an FAQ is also available on Github: github.com/ethereum/kzg-c…

@ethereum @trent_vanepps TL;DR: the KZG Ceremony is used to generate a randomness source to enable us to verify the validity of data stored in blobs with (proto)danksharding. For it to be secure, only a single participant is required to be honest.

@ethereum @trent_vanepps The Ceremony will go live 🔜 for the everyone, and we expect to have ~10k participants (>2x the largest previous ceremony). If you want to help scale Ethereum, participating is a very easy thing you can do :-) Follow @trent_vanepps for updates 🕯️

@ethereum @trent_vanepps Second, @mkalinin2 shared a proposal about adapting the Engine API specs to a post-merge world: github.com/ethereum/execu…

In short, it proposes ways to deal with the overall layout of the spec (by feature vs. by fork), as well as a lifecycle strategy for API updates across forks.

@ethereum @trent_vanepps @mkalinin2 Third, we discussed the state of the current withdrawal implementations. Barnabas from the EF devops team shared the status of devnets. They are currently running two: one starting pre-merge, and one starting post-merge, based on what configurations client support.

@ethereum @trent_vanepps @mkalinin2 On the pre-merge genesis one, Geth, Prysm, Nethermind, Teku, EthereumJS and Lighthouse were all interoperating. Similarly, on the post-merge genesis one, we have Lodestar running with Geth/Nethermind/Besu.

@ethereum @trent_vanepps @mkalinin2 Withdrawals were working smoothly on both those cases, and there were still some issues to fix with the withdrawal credential upgrades from BLS to ETH addresses.

@ethereum @trent_vanepps @mkalinin2 A quick note on that last point! Today, validators can deposit and use either a BLS (0x00) or ETH address (0x01) withdrawal credential. To enable withdrawals, validators will need to have a 0x01 credential (to indicate where the ETH should be sent).

@ethereum @trent_vanepps @mkalinin2 For validators with a 0x00 credential, this means a message will need to be signed to update the credential to a 0x01-type one, i.e. an ETH address. github.com/wealdtech/ethdo currently supports signing these messages, but other tooling should as well 🔜

@ethereum @trent_vanepps @mkalinin2 In terms of next steps, Prysm and Lighthouse are working on enabling support for post-merge genesis networks. Besu is working on its time-based forking implementation (more on that later) and Erigon + Nimbus haven't joined the devnets yet. They are expecting to soon!

@ethereum @trent_vanepps @mkalinin2 On the testing side, @elbuenmayini shared his WIP list with the various test cases: notes.ethereum.org/@marioevz/With…

Once these are finalized, more EL/CL mocking will be added to Hive as well.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini So, with a good view on where things are at for withdrawals, we spent the rest of the call discussing how to approach Shanghai and the various CFI'd EIPs: github.com/ethereum/execu…

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini I started by stating what I thought was the main thing everyone agreed on: that withdrawals should be prioritized and be delivered relatively quickly. That seemed to be the emergent consensus over the past ACD and CL call last week.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi disagreed 😄 his view was that we should try and get 4844 out alongside withdrawals, even if it meant a delay. His fear is that not doing this would lead to 4844 not happening before the fall.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi While there was pretty broad support for seeing 4844 come sooner than that, the consensus landed on a decoupled withdrawal & 4844 spec, like was discussed on last week's CL call (brief notes from @benjaminion_xyz: hackmd.io/@benjaminion/S…).

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz On the CL side, EIP-4844 is specified right "after" the withdrawals/Capella fork (see: github.com/ethereum/conse…). This isn't really a concept we have (yet!) on the CL side, but there was agreement to follow the same approach.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz So, we agreed that while EIP-4844 wouldn't be in Shanghai, it would be the main thing around which we centre the next EL upgrade as well, matching what is specified on the CL, and that we should get this upgrade out relatively quickly after Shanghai.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz At this point, the two main things agreed on were (1) seeing Shanghai happen quickly, ideally around March and (2) following this with a fork centered around EIP-4844. The big question to answer was where everything else on the Considered for Inclusion list should land.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz The Geth and Besu teams felt that EOF - the set of EIPs introducing a new EVM contract format, code/data separations, new opcodes, etc. - should be the main thing included alongside withdrawals. Nethermind and Erigon felt like "one other feature" could work, with less preference.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz One concern about EOF on the call was whether the spec was stable enough and whether, given its size, it could actually be implemented in time. To help others understand this, @alexberegszaszi and @lightclients have put together a unified spec for all EOF: notes.ethereum.org/@ipsilon/eof1-…

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients EOF was originally split into 5 EIPs to help client teams reason about each specific change more clearly, but when considering it as a whole, it helps to have it all in one place.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients With regards to whether the EIP could be implemented without delaying withdrawals, Geth, Besu and Nethermind felt confident it could, with Erigon saying the delay would be at most a few weeks.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients There was some pushback on the call about this, with attendees wanting to be sure that delays would not compound from here. Similarly, there was concern about whether once we start implementing EOF, we can easily remove it if it's not done in time.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients All client teams agreed that this was a fairly easy EIP to remove from Shanghai if needed. On the timeline front, we discussed this for a bit and eventually landed on the following milestones we'd want to hit for EOF to remain in Shanghai:

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients 1. By the next AllCoreDevs (Jan 5, 2023), we want to have all clients with a complete EOF implementation and passing test suites.
2. By the ACD after that (Jan 19, 2023), we want to have seen EL clients interop on a devnet.

If these bars aren't met, then EOF will be removed.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients These deadlines mean that we'd be moving to mainnet shadow forks late Jan, and then likely moving to testnets in February for both EOF and Withdrawals, assuming no unexpected issues are found.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients Another thing I wanted to make explicit was whether having EOF in Shanghai meant other proposals, such as EIP-1153, 2573, etc. would have to wait. There was some back and forth here, but client teams landed on making a push for EOF as the exclusive addition to Shanghai.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients Champions for other EIPs were understandably disappointed by this, especially in cases where implementations were quite advanced the the EIP was not very large.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients Both @vdWijden and @yperbasis made the point that even if an EIP is relatively small/well tested/etc., there are only a limited number of them client teams can work with within a single update, and every incremental one does have overhead with reviews, testing, etc.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis So, that's where we landed for Shanghai: Withdrawals, EOF & a few already implemented EIPs (PUSH0, Warm COINBASE, Limit/Meter initcode) are what we will go for. If by January, we don't meet the EOF milestones mentioned above, we'll remove it from Shanghai so withdrawals ship ASAP

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis In addition, we agreed to have EIP-4844 as the cornerstone of the next upgrade. I've opened a PR against the EL specs to update this: github.com/ethereum/execu…

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis We were already out of time, but there were two other small things to discuss about Shanghai: the timestamp forking and Engine API changes.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis For context, in order to have EL & CL upgrades happen at the same time (literally!), we need to move the EL to upgrade based on timestamps rather than block numbers. The reason for this is that offline proposers can create slot:block gaps!

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis For example, if we fork at slot N & block X, but there are missed slots between setting N & X and actually hitting X, you could end up in a spot where a feature is activated on the EL but not the CL, or vice-versa.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis In practice, this could look like a withdrawal being sent by the CL and the EL not ready to process, or a blob being sent in an EL transaction and the CL not ready to store it. To fix this, we can use timestamps ⏰

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis Because the CL's epoch/slots are time-based, we can simply use a timestamp on the EL instead of a block number to activate the upgrade, and ensure they happen at the same time on both layers. While this is conceptually simple, it does require some changes in clients.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis Teams have already started to work on this, and with the geth implementation basically done, @vdWijden will write an EIP describing the change to serve as a reference.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis And, lastly, we briefly discussed two Engine API changes we'd like to include as part of Shanghai: the introduction of getPayloadBodiesByRangeV1 (github.com/ethereum/execu…) and engine_getPayloadV2 (github.com/ethereum/execu…), which adds the locally built block value to the payload.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis Client teams agreed that both those changes should be included as part of Shanghai, but, again, that if they turned out to have unexpected issues that could delay withdrawals going live, we should consider removing them!

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis And that was it! Last ACD of 2022 🫡 There will be a CL call next week, then two weeks off, and we'll be back on Jan 5, 2023, to kick off the new year!

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis If you want to learn more about the KZG Ceremony, there's a discord session about it scheduled next Monday 🕯️

https://twitter.com/AtHeartEngineer/status/1600938924104245248

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis Good question re: withdrawal credentials! There is no date by which you need to make the 0x00 -> 0x01 switch, but until you do, neither partial nor full withdrawals will be processed for your validator.

https://twitter.com/GrayKoenig/status/1600939738491674625

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis If you have 0x01 credentials, withdrawals happen automatically on a periodic basis. Excess balances will be withdrawn if you are still active, and the full balance will be withdrawn if the validator is out of the exit queue.

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis Correction by @BarnabasBusa about the latest state of withdrawal devnets ✨

https://twitter.com/BarnabasBusa/status/1600988230039793665

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis @BarnabasBusa One more addition: @christine_dkim's excellent summary of yesterday's call. Strongly recommended if you want a better structured recap instead of my braindump tweets 😄

https://twitter.com/christine_dkim/status/1601202710421725184