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.