Execution Layer Meeting 181

[timbeiko]

Meeting Info

• Feb 15, 2024, 14:00-15:30 UTC
• Youtube Stream: https://youtube.com/live/UTgnbE6jTuE
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Dencun Updates
  • Client releases
• "Retroactive" EIPs
  • EIP-7610
  • EIP-7523
• Prague/Electra EL Proposals
  • EIP-5806 overview
  • EIP-7557 overview
  • EIP-2935
  • EIP-5920
  • EIP-7609
  • Inclusion List Breakout Room #954
  • Client team preferences
    • EIP-2537: CFI -> Included?

[yoavw]

It would be great if @Amxx could present EIP-5806 on this call, as a safe solution for delegation and batching.

[holiman]

Me and @rjl493456442 have posted an EIP, 7610. The short version is to retroactively add a contract deployment condition:

This EIP amends EIP-684 with one extra condition, requiring empty storage for contract deployment.

This resolves some ugly edgecases from testing, and makes it possible for clients to simplify some internal logic (re how contract creation is rolled back in case a deployment-over-existing-storage is reverted).

This does not require a hard-fork. In practice, we just need "general agreement" really, so nobody is surprised/angry if tests are changed and start failing.

Discussion here: https://ethereum-magicians.org/t/eip-7610-revert-creation-in-case-of-non-empty-storage/18452 . Besu, Reth and Geth seems to be on board.

[holgerd77]

@holiman The EIP is stating that it does require a hard fork, you are starting in the comment that it does not. What is correct (and why)?

[holiman]

I guess that's a philosophical question.

• It is a change in spec, therefore hardfork
• However, due to circumstances, it can be applied retroactively, thus not really a hardfork - it can be implemented at any time
• And also, in practice it's of no consequence (only in theory, and maybe on weird testnets with storage set in genesis), so it's not a hardfork
• But still it is a change in spec...

I don't really know what denomination to use...

[yoavw]

Would be great to discuss and get feedback on EIP-7557 - block level warming.

Warming of cold accounts and storage slots is priced unfairly: the validator incurs the DB access cost just once per block, but users pay for it multiple times across the block.

This proposal fixes it by sharing the cost across transactions that include the account/slot in their access-list. Refund happens at the end of the block, similarly to CL withdrawals, so the change is not visible to EVM and doesn't affect block execution.

[jrudolf]

Would like to throw EIP-2935 on the agenda if time. Relevant to Verkle / stateless clients. @gballet can give a quick update on the latest 2935 implementation. Note: alternative suggestion by @shemnon here: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565/28

[timbeiko]

@jrudolf is this something that would have to go in Prague or Osaka? If it's for Osaka, I can add it at the end of the call but I suspect we'll be overflowing so it may get bumped to the next one.

[michaelneuder]

hey all – would love a chance to share some recent updates on inclusion lists (eip-7547) in tomorrow's call.

two recent docs

• unconditional property / high-level design
• spec overview for EELS, CL spec, and engine api

the goal of this agenda item is

• share the scope (esp. w.r.t the execution layer) of the EIP with a broader audience
• answer any questions
• facilitate further consideration for inclusion (pun intended heh) in electra

also its worth calling out that there will be an IL specific breakout room this friday! see #954 for more details

[jrudolf]

@jrudolf is this something that would have to go in Prague or Osaka? If it's for Osaka, I can add it at the end of the call but I suspect we'll be overflowing so it may get bumped to the next one.

@timbeiko it would be a "very-nice-to-have" for Prague, but not a "must-have".

[garyschulte]

*EIP-2935

[charles-cooper]

i'd like to add https://eips.ethereum.org/EIPS/eip-5920 and transient storage reduction (ethereum/EIPs#8158) to the agenda which were pushed back last week: #943 (comment)

[timbeiko]

added @charles-cooper

[timbeiko]

Closed in favor of #961