Ethereum Core Devs Meeting 148 Agenda

[timbeiko]

Meeting Info

• October 27, 2022, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/oQfEW8LdE88
• Zoom: shared on #allcoredevs Discord server shortly before the call

Agenda

• Shanghai Planning #450 (comment)
  • Client team updates/priorities
  • Currently CFId EIPs
    • Withdrawals update
  • Fork activation
  • Shandong
• Other topics
  • Engine API block value response
  • eth/68: Add transaction type to tx announcement
  • Goerli Supply Issues
  • Executable Specs
• [If time permits] Shanghai Candidate EIPs discussions
  • EIP-2537
  • EIP-2315

[ineffectualproperty]

Hey @timbeiko - It would be great to get 5 minutes to discuss EIP-2537 (BLS precompiles) during the Shanghai planning. I've posted on Ethereum Magicians as well but let me know if you have any questions.

[timbeiko]

Thanks, @ineffectualproperty! I posted about this on EthMagicians yesterday, but in short I think it's important we restart the calls with client teams sharing where they are at, what they see as priorities, etc. before opening the floor up to the various EIP champions. This way, we can have these discussions with a bit more context.

I'm not sure we'll have time at the end of this call to actually get into in, but I'd expect the call after to be mostly dedicated to this. If you, or other EIP champions, want to attend and possibly discuss the EIP at the end of the call, happy to add it to the agenda. If you'd rather be "sure" it gets discussed, then I think scheduling it for the call after is probably best.

[gcolvin]

I'm involved in a L2 startup that needs EIP-2315 if we are to use the EVM, so I'd like to gauge the sentiment on that sooner rather than later.

[terencechain]

If time permits, it may be worth bringing up progress of adding block value to the engine API response as one of the more promising censorship resistance combat paths:
ethereum/execution-apis#307

Some client progresses using a similar mechanism:
ethereum/go-ethereum#25998
OffchainLabs/prysm#11557

[holiman]

I'm involved in a L2 startup that needs EIP-2315 if we are to use the EVM, so I'd like to gauge the sentiment on that sooner rather than later.

@gcolvin is it possible for you to elaborate on what makes it a "need" instead of a "want"?

[gcolvin]

is it possible for you to elaborate on what makes it a "need" instead of a "want"?
Gladly, @holiman

What I'm really wanting to know is

Do we intend to deprecate dynamic jumps in favor of some form of static jumps and subroutines in Shanghai?

@axic and the other Ipsilon folks probably want to know as well.

The venture I'm involved with needs to do secure off-chain execution of EVM code, and our design involves rewriting EVM code to an expanded form which embeds Merkel hashes and digital signatures in the control flow. So we will need to traverse and represent the control-flow graph in time and space near-linear in the size of the original code. If we succeed at that we will soon-enough need to compile the resulting expanded EVM code to machine code in one pass.

Dynamic jumps defeat all of these requirements -- in their presence the control-flow graph can take quadratic time and space to traverse and represent. There are proposals to be rid of them, most of them tagged as Shanghai candidates.

EIP-2315: : Simple Subroutines for the EVM, together with EIP-4200: Static relative jumps, deprecates JUMP and JUMPI and provides for subroutines and static jumps to replace them.

EIP-4750: EOF - Functions together with EIP-4200 and the other Ipsilon EIPs would also do the job.

As currently specified EIP-4750 inhibits inter-procedural optimization of the EVM code because it allows for only one function per code section. So I've proposed an extension to EIP-4750 that expands code sections from Functions to Modules, but we haven't discussed it much yet. I think we have yet to converge on the best design. I have my preferences, but after so many years of effort am open to any design that does the job.

[holiman]

Well, remember that there exists no suggestion to fully remove dynamic jumps. Old code is old code. So you'll have to deal with that regardless. I personally am in favor of EOF and possibly some simple validation for Shanghai. But not the more advanced ones such as static jumps, not yet.

[gcolvin]

For our purposes we aren't concerned with old code. But of course, yes, pre-EOF code cannot take advantage of post-EOF features.

For six or seven years now we've been saying "not yet". How many more years?

Subroutines go back to Turing's ACE machine in 1945 and have been provided in some form by most all of the machines that I know of, real and virtual, ever since (see https://people.computing.clemson.edu/~mark/subroutines.html for a quick review). They have been proposed and implemented in the EVM more than once and in more than one EVM client. They are not a big ask.

[holgerd77]

If time allows I would love to give a 4-5 minute overview and update on the new Shandong ephemeral Pre-Shanghai testnet we started within the JavaScript team.

[q9f]

I want one minute to preset the new testnet workgroup, which requires a future commitment by client teams and infrastructure providers.

• Discussion: https://ethereum-magicians.org/t/testnet-workgroup-paths-out-of-the-goerli-supply-mess/11453
• Call: [Comms] Goerli Testnet Community Call #6 eth-clients/goerli#129

[ralexstokes]

I'd like to mention this doc to track withdrawals progress and call out a few (minor) changes to EIP-4895 since the last call (and I assume we can get a status update from each client team about EIP-4895 progress)

https://notes.ethereum.org/LqHDfmQdS96KWgs3UzGeyA?view

and also, assuming there is time, I want to get a quick temperature check from the CL teams on the call about the cappella specs, if anyone is present

[holgerd77]

Not sure if we get a minute on Shandong or if the call is already too packed, so just to mention here: we have just restarted the testnet with new genesis and fixed some EIP-3540 EVM Object Format (EOF) consensus issues and the testnet should now be ready to be joined by other clients.