Execution Layer Meeting 183

[timbeiko]

Meeting Info

• Mar 14, 2024, 14:00-15:30 UTC
  • Note that DST will have started in parts of the world: double check your local time!
• Youtube Stream: https://youtube.com/live/US8T0ZoGF8s
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Dencun Retrospective
  • Move EIPs to Final
    • Update EIP-4844: Update blob base fee to base fee per blob gas EIPs#8316
  • Goerli Shutdown
• Prague/Electra EL Proposals
  • EIP-2537 (context)
  • EIP-3074 user perspective
  • Inclusion Lists (context)
  • EIP-7623 (impact analysis, rationale)
  • EIP-7645: Alias ORIGIN to SENDER
• Interop/Testing Calls continuation
• Next ACDE:
  • State Growth Research
  • EIP-5920, EIP-7609
  • "Retroactive" EIPs
    • EIP-7610
    • EIP-7523

[ralexstokes]

I'd like to discuss the latest with EIP-2537, now that it has been scheduled for Pectra.

We will be doing gas costs updates and make a pass on testing/test vectors in the coming months.

After talking with various users of this precompile and sourcing use cases, including zero-knowledge cryptography and zk-rollups, we have the following open questions. I'd like to raise them for awareness and discuss with core devs to get a temperature check on what to include to finalize EIP-2537.

EIP-2537 open questions

• Precompiles for point decompression: can be better for computation in data-constrained environments (e.g. L2s)

• Precompiles for operations in G_t: BLS12_GT{ADD, MUL, MULTIEXP}

• Update BLS12_PAIRING to BLS12_PAIRING_VERIFY (which works as currently specified) and add another precompile BLS12_PAIRING which returns the result of the pairing operation.

And note, I'm working on sourcing a "hash to field" implementation in Solidity, which should be cheap enough to not need a precompile. There are also some cryptographers reviewing the text for editorial changes and relevant security call outs (e.g. cofactor clearing). I'll also be having a similar conversation with rollups on the next RollCall I can attend.

[cyrusadkisson]

Could we discuss EIP-7645 (alias ORIGIN to SENDER)? Or, if that change is too steep for Pectra, the precursor step of banning all new use of ORIGIN (contract deployment txs containing ORIGIN are invalid)?

[gakonst]

Think agenda might be busy given priorities, but we published our research on state growth recently which may be relevant to people working on EIP-4444 and Verkle, so would be keen to have @sslivkoff present either on the next ACDE.

https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1

[shemnon]

Could we discuss EIP-7645 (alias ORIGIN to SENDER)? Or, if that change is too steep for Pectra, the precursor step of banning all new use of ORIGIN (contract deployment txs containing ORIGIN are invalid)?

Banning opcodes from new deployments doesn't work for legacy EVM. What if ORIGIN shows up in solidity's signature data?

[cyrusadkisson]

Could we discuss EIP-7645 (alias ORIGIN to SENDER)? Or, if that change is too steep for Pectra, the precursor step of banning all new use of ORIGIN (contract deployment txs containing ORIGIN are invalid)?

Banning opcodes from new deployments doesn't work for legacy EVM. What if ORIGIN shows up in solidity's signature data?

Not sure if this is the right venue to have this discussion, but in the ban-only-for-now scenario, ORIGIN code would still exist within old contracts, would still be an accessible variable within transactions and still be treated the same way it's always been treated. The only change is it won't be able to appear in new smart contract code. The idea is to start aligning ORIGIN and SENDER, tease out misuse cases and give us more information about the implications of aliasing of ORIGIN to SENDER.

I might be missing something in your question, though. Maybe we table this until tomorrow or until there's an EIP for the ban-only proposal?

[shemnon]

We can discuss tomorrow, but I don't see how we can ban an opcode without code/data separation. For that we need a container format, which is EOF. Code validation has no context with our stream-of-bytes model, apart from jumpdest analysis, which is only a runtime impact not a tx validation/CREATE time impact.

[timbeiko]

@ralexstokes thanks for flagging, have added it to the Pectra discussion! @gakonst agreed this is valuable to bring up. I've put it after all the "in progress" EIPs, and think we should have time for at least a brief overview. @cyrusadkisson I'll put yours at the end, but if other topics take too long we may have to push this to another call.

[michaelneuder]

hey! for the pectra discussion i think it would be great to discuss the EIP-7547 (inclusion lists) spec PoC we are prototyping: https://notes.ethereum.org/@mikeneuder/il-poc-spec. lots of people have been involved. also would like to discuss the friday breakout room

[danfinlay]

Hi all, I'd like to join and am happy to comment on the benefits of EIP-3074 for our existing wallet users.

[nerolation]

If there's time, I'd like to quickly share some updates on EIP-7623.

I did some impact analysis and published the results in the following:

• Table showing the individual methods and if they'd be impacted
• Quick post with many more details on the EIP

[charles-cooper]

if there's time, i'd like to get more feedback on including EIP-5920 and EIP-7069 in prague/electra

[timbeiko]

@danfinlay thanks for coming on! adding you to the top of the Pectra section. @nerolation @charles-cooper I've added your proposals to the agenda too... let's see how far we get!

[charles-cooper]

@timbeiko whoops, typo on my end -- i meant https://eips.ethereum.org/EIPS/eip-7609

[g11tech]

would like to discuss a small cleanup to 4844 EIP references:

• Update EIP-4844: Update blob base fee to base fee per blob gas EIPs#8316