Ethereum Core Devs Meeting 151 Agenda

[timbeiko]

Meeting Info

• December 8, 2022, 14:00-15:30 UTC
  • Note: there won't be a call on December 22(happy holidays🎄!) - next ACD will be on Jan 5, 2023
• Youtube Stream: https://youtu.be/y8jZ11_CQGo
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• KZG Ceremony update
• Engine API spec improvement proposal execution-apis#321
• Withdrawals devnet/testing updates
• Shanghai Planning #450 (comment)
  • Included EIPs Candidates
    • Shanghai CFI'd EIPs
    • EIP-663
    • EIP-6046: Replace SELFDESTRUCT with DEACTIVATE
  • Commitments for following fork
  • Timestamp fork spec
  • Add engine_getPayloadV2 with locally built block value execution-apis#314
  • Devnet plans
• Other topics
  • Define eth_account execution-apis#329
  • Engine API: add getPayloadBodiesByRangeV1 to #146 execution-apis#218
  • Add EIP-5988: Add Poseidon hash function precompile EIPs#5988

[lightclient]

We'd like to propose a new JSON-RPC endpoint eth_getAccount: ethereum/execution-apis#329

[tvanepps]

I'd like to mention the KZG Ceremony briefly just to build awareness as we wrap up the second audit and move towards the public contribution period

[holgerd77]

Some EthereumJS takes on Shanghai HF planning:

0. Scope: We generally perceive a HF including Withdrawals, 4844, Extended-EOF together with the already included EIPs as too big/complex and would prefer to have this separated into (at least) two different HFs.

Regarding a potential Shanghai HF in March:

1. While the EOF/Ipsilon team has made impressive progress we feel that there is still a lot late movement in the specs and it would be good to have some more dedicated time for local inter-client functionality testing and edge case refinement and we therefore receive a March production date as pretty early, also regarding the fact that all 3-4 additional EOF EIPs are still WIP for many clients.
2. For Sharding/4844 we are a bit less certain. Judging from the scope of our own implementation, our (incomplete) picture on overall readiness and the fact that KZG commitments are a very new type of underlying base technology we have a stronger tendency though to see March also as a date being very much early for production readiness.
3. We feel comfortable having withdrawals included in Shanghai (in March), nevertheless also see withdrawals as a - somewhat - complex EIP bringing in a new type of state transition mechanism which deserves a descent amount of dedicated attention. We also acknowledge the fact that withdrawals have been promised to be delivered to the community "as soon as possible".

Potential HF timing and scope ideas:

4. "On the other hand" we also acknowledge the fact that there is a somewhat urgent need from the L2 side for Sharding/4844 and generally a stronger push for both 4844 and EOF to be included (as) early (as possible). One compromise might be to directly schedule and (more or less) determine the scope for two closely following HFs, with a Shanghai HF in March with the currently included EIPs and a 4844/EOF "Cancun" HF in May/June (both eventually open for 1-2 smallish EIP additions). This would guarantee a somewhat earlyish inclusion and at least give some planning security to the EOF/sharding-involved teams.
5. Also possible/ok-ish would be an "All-Included + Sharding" HF in April/May (with EOF just loosely scheduled for a not-yet-planned following HF) or (a bit less preferred, see 0.) an "All-Included + Sharding + EOF" HF in May/June.

These are just some ideas. We are likely ok with other options as well. 🙂

[ralexstokes]

if we do settle on pushing EOF and/or 4844 to a future fork after Shanghai then I would ask client devs to consider EIP-2537 to go along w/ withdrawals

[protolambda]

If we can do a minimal upgrade with Withdrawals, with a fast timeline for ~March, I think it can benefit all of ethereum:

• We commit to 4844 + EOF following into the next HF shortly after, ideally in May.
• We can keep parallelizing development work as much as possible.
• We get time to better de-risk both upgrades.
• We have a clear roadmap with commitment for the next half year.
• Withdrawals get included with fastest timeline.

To do this, I think it's important to NOT feature-creep the hardforks as much as possible, and just do Withdrawals first, and then 4844+EOF.

• EIP-1153 (transient storage) is the only EIP I can think of that is CFI, is very widely tested, and could go into the Withdrawals HF with the existing support.
• I don't believe EIP-2537 (BLS in EVM) is as far along, although I would support it if there is commitment from each team that it does not add delays.

[mkalinin]

A couple of other Engine API things to raise if there is a time:

• Add engine_getPayloadV2 with locally built block value execution-apis#314
• Engine API: add getPayloadBodiesByRangeV1 to #146 execution-apis#218

[leonardoalt]

EIP-1153 (transient storage) is the only EIP I can think of that is CFI, is very widely tested, and could go into the Withdrawals HF with the existing support.

Not saying it shouldn't go in, but I disagree that it's widely tested. Afaik (happy to be shown otherwise) the only usable implementation for it is in ethereum-js / hardhat right now.

[leonardoalt]

As a Solidity rep I'd also like to ask EIP-663 to be considered for inclusion with EOF.

tl;dr: it's a very small change that would bring immediate huge benefits for every high level EVM language, and it has support from Solidity, Vyper and Huff. The main argument against it so far has been the need for immediate arguments, which becomes trivial with EOF. I can talk more about it if needed.

[timbeiko]

@holgerd77 @protolambda - thanks for your thoughts re: the multi-fork planning. Will make sure we cover this, first by discussing what we should have in a fork centered around withdrawals (@ralexstokes we'll bring up BLS as part of the Shanghai CFI'd EIPs), and then what commitments we can make for the following fork.

@mkalinin I've added the Engine API issues for after this during the call.

@leonardoalt I've added an agenda item about EIP-663 as well. As a heads up, though, we try and avoid CFI'ing an EIP on the first call it is brought up so people generally have at least two weeks to review them more deeply and aren't surprised that something "snuck in" CFI.

[leonardoalt]

Sure, that makes sense. What I wanted to bring up was mostly that it was actually agreed for Constantinople already in the past, but needed immediate arguments which wasn't available then. If EOF goes in, and considering the above, I think it makes sense to include 663 too.

[axic]

@timbeiko to be fair EIP-663 was brought up last call too, but it didn't fit the call time. And it was actually "EFI" back in 2019 (meetings #74 to #79) 😅

[axic]

Not sure if the selfdestruct topic will be discussed, but a proposal from 2 weeks ago now has an EIP merged: EIP-6046: Replace SELFDESTRUCT with DEACTIVATE.

[timbeiko]

Thanks for the context, @axic! Added 6046 as well.

[moodysalem]

Afaik (happy to be shown otherwise) the only usable implementation for it is in ethereum-js / hardhat right now.

Please see the thread or shanghai planning for the status. As of today it is merged in 3/5 clients and PRs out on Besu (waiting for clarity before reviewing cc @shemnon) and Erigon

And those implementations are well tested, there was even a CTF deployed on a testnet

[protolambda]

My view of the targeted timeline, please correct me if it's off (NOT a promise of dates):

Dec 8th: today. Remaining EOF work ASAP. Maybe do withdrawals-only testing till holidays to derisk optionality of EOF.
Dec ~20th holidays
Jan 5th ACD - check if EOF implementations are ready, all functionality tested.
Jan 12th CL call - note: shadowforking should start!
Jan 19th ACD call - EOF cross-client interop must have been smooth for EOF to continue.
21-29 workshop (incl travel time) - goal: stable EOF/withdrawals mainnet shadowfrok, and 4844 clients all on testnet.
Feb 30+ continue shadow-forking, and public testnets: Sepolia, Goerli, ??. Likely ~1-2 weeks apart each.
Mid March: Shanghai hardfork
End March: Any 4844 interop corrections
Mid April: 4844 mainnet shadowforking
End April: margin
Mid May: 4844 on public testnets
End May (or if delayed, June): 4844 mainnet?

So TLDR:

• EOF in shanghai, but ONLY if withdrawals are not delayed.
• 4844 center of next HF, with commitment to parallel work where possible. Aiming for May/June.

Also, 1153 IMO is stable and well tested, was a bit unclear during ACD, and should be included in Shanghai IMO, but with the current minimalist mindset it will probably have to go into the next HF along with 4844 (and maybe EOF if that's not ready by start January).

[protolambda]

Cross-posting discord R&D message:

Note that we aim for a fast turn-around with Cancun, ideally in May/June, 4844 is a critical improvement for ethereum and so far we were aiming/building towards Shanghai already. So we should continue the already ongoing 4844 testnet efforts, and need client support insofar it does not delay Withdrawals. I believe Cancun should be open for additional proposals, but IMO by start of February every proposal should meet the same support/testing as 4844 to go into Cancun. E.g. EIP-1153 would be a good candidate, or EOF if it slips in January.

[jochem-brouwer]

Could we add a brief discussion/note on tests? Currently, the EOF EIPs are changing rather fast (weekly, if not faster). There are test PRs open in ethereum/tests. However, these are "useless": it is unknown on whatever spec of the EIP these tests were generated, thus it is unknown if another client fails the tests if these are really faulty, or, if tests pass, if they are actually valid. If tests are published, an explicit mention/definition to whatever spec of the EIP which is implemented should be noted in these tests.

This would help the ecosystem a lot. There are many clients currently which have (internal) tests regarding these EIPs. I find myself writing tests on my own to test against the spec. But this is essentially doing work multiple times: if I want to implement EIP X at version y, and if a client already has tests for that specific EIP and that specific version, then I should be able to just "copy" those tests and test against it.

[timbeiko]

@jochem-brouwer will paste your comment in the next call's agenda: #700