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
prysmaticlabs/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.

[MariusVanDerWijden]

I'd love to take a minute to talk about ethereum/EIPs#5793 EIP-5793 proposes a new eth protocol version eth/68 which adds tx type and tx size to the tx announcement message. It's kinda required for making danksharding safer and its a change that we can roll out right now

[karalabe]

The code for EIP-5793 is very very simple, https://github.com/ethereum/go-ethereum/pull/25980/files, we just need an ack from ACD before we merge it into Geth since we can't unrelease it once it's out.

EDIT: Also, even though it was primarily conceived as a DoS prevention mechanism for 4844, it is still useful standalone as it would allow us to bump the max allowed normal tx sizes without risking a network bandwidth blowup (that needs more work on scheduling tx fetches, but the point is that currently we fetch blind, so it's an infinite improvement).

[timbeiko]

Lots to cover 😅 ! I just updated the agenda to include everything proposed. @ineffectualproperty, @gcolvin, my plan was to use the next ACD to have open discussions about EIPs and have this one focused on client teams sharing their updates and views of what priorities should be. I've added both your EIPs to the end of the agenda, but realistically, with the long list of other topics to cover, I doubt we'll have time to get to them tomorrow. Letting you know so you don't waste 2h of your time in case you'd rather just come to the next call!

[gcolvin]

Unfortunate but understood, @timbeiko. The Ipsilon team has been doing very good work, and I'd ask that on the next ACD call we give it some serious attention.

For what it's worth, given the overall balance of technical tradeoffs I will likely be withdrawing EIP-2315 in favor of EIP-4750 and related Ipsilon EIPs. If they haven't already ask that people take a look.

[chfast]

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

The basic EOF (two current CFI EIPs) with Functions (EIP-4750) and Static relative jumps (EIP-4200) provide new control flow primitives which replace current dynamic jumps (they can be rejected from EOF code). No more jumpdest analysis. If we want a significant EOF feature set this is it.

[gcolvin]

If we want a significant EOF feature set this is it.

Yes. And Stack Validation then reduces runtime checks to a minimum. Underflow and correct numbers of arguments and return values can be checked at initialization time. I think only stack overflow and gas will need runtime checks. That gives us what I've been trying to get since EIP-615.

[bobsummerwill]

Just to put on record that the ETC Cooperative would like to do whatever we can to support the EOF "full package", and that can include:

• Besu and Geth implementation work (@meowsbits, @diega, @ziogaschr)
• Maybe Erigon too? (we have an experimental fork)
• Funding SOLC, Vyper or Hyperledger Solang work, if required, to support static jumps, subroutines, etc so we have proven end-to-end workflow.
• Testing, metrics gathering, spec revision, etc.

Whatever we can do to help.

[holiman]

I will likely be withdrawing EIP-2315 in favor of EIP-4750 and related Ipsilon EIPs. If they haven't already ask that people take a look.

I think that is a a good step, @gcolvin , and fwiw I support the EOF eips. Won't be able to make the call today unfortunately.

[bobsummerwill]

See "EOF Devnets Breakout Room", happening on Nov 4th:
#653

[timbeiko]

Closed in favour of #652