.@ethereum #ACDE wrapped up earlier today. Most of the call discussed potential EIPs for the next fork, Pectra, with some conversation about Dencun releases, shadow forks, and retroactively applied EIPs.

Agenda:
Stream: github.com/ethereum/pm/is…
youtube.com/live/UTgnbE6jT…

Execution Layer Meeting 181 [2024-02-15]https://github.com/ethereum/pm/issues/952https://youtube.com/live/UTgnbE6jTuE

Execution Layer Meeting 181 · Issue #952 · ethereum/pmMeeting 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...https://github.com/ethereum/pm/issues/952

First, @christine_dkim front-ran me for the recap. Here's her summary of the call as well as my discord TL;DR

To kick things off, we discussed Dencun readiness. The EF Devops team is getting ready for our final mainnet shadow fork by syncing nodes for each client and setting up every pair for testing 💪 

Geth, Besu & Reth all have Dencun mainnet releases out. Everyone else should have theirs 🔜, with a deadline of next Thursday. Once all releases our out, the shadow fork will be scheduled. ETA is next Thursday/Friday. 

Assuming there aren't any unexpected issues found on the MSF, expect a proper announcement early in the week of Feb 26th, for a fork date of March 13 📆 

@CarlBeek also shared that this week's RollCall confirmed L2s should generally be ready to adopt 4844 either right as it ships, or soon after: the blobs are coming .oO! 

Next up, we discussed two EIPs intended to clarify specification edge cases and retroactively add constraints to the protocol. The first was EIP-7610 by the Geth team:

EIP-7610: Revert creation in case of non-empty storageEIP: Add EIP: Revert creation in case of non-empty storage by rjl493456442 · Pull Request #8161 · ethereum/EIPs · GitHubhttps://ethereum-magicians.org/t/eip-7610-revert-creation-in-case-of-non-empty-storage/18452

Currently, the spec states that a contract deploy transaction will revert if the destination address has a non-zero nonce or code length. This EIP adds a third check for storage, given it is impossible to actually deploy a contract to an address with existing storage. 

Having this EIP would allow client teams to simplify their codebases, as well as the consensus test suites. Because this has never happened on chain, the EIP could be "retroactively activated" from Genesis. 

Two other EIPs have previously been retroactively activated this way: 2681 and 3607 (see: ). At n=3, it might be time to think about a cleaner way to document this...

That said, there were some potential concerns by @gballet about if/how this could interact with a verkleized (?) state. We'll continue the discussion async and come back to this on the next ACDE. 

Then, we discussed EIP-7523 (), which similarly proposes to ban empty accounts, which are no longer possible. Empty accounts were created en-masse during the Shanghai DoS attacks and subsequently (mostly) cleaned in the Spurious Dragon hard fork.

EIP-7523: Empty accounts deprecationProhibit empty accounts on post-merge networkshttps://eips.ethereum.org/EIPS/eip-7523

A few years ago, @ultratwo found that Spurious Dragon had missed some empty accounts and wrote a script to clear the remaining ones. Now that we are sure they are gone, and can't be created, we could formalize the rule for post-merge networks. 

Again, this would allow client teams to simplify parts of their codebases. We had general agreement to move forward with this, with the caveat that we'd want to independently verify that Peter actually go all the empty accounts out of the state  

After these, we discussed various Pectra candidate EIPs. There were a lot to go through on the call, and even more proposed on the @EthMagicians thread, but we got through them all!

Prague/Electra Network Upgrade Meta ThreadFeb 5, 2024 Update Prague/Electra Meta EIP PR EIPs 6110, 7002 and 7549 Included EIP-2537 CFI’d Verkle Tries included in post-Prague EL fork, Osaka EIP-4444 work to continue in parallel to network …https://ethereum-magicians.org/t/prague-electra-network-upgrade-meta-thread/16809

First up we had @Amxx present EIP-5806 (), an alternative to EIP-3074. In short, it allows multicall, removes the need for invoker contracts, and allows for the cancellation of transactions.

EIP-5806 Delegate transactionhttps://ethereum-magicians.org/t/eip-5806-delegate-transaction/11409

There was some contention by 3074 author @lightclients and other about whether this is in fact a better approach, as it doesn't permit social recovery or multi-user txn bundling, but generally a positive sentiment towards it as it could meaningfully improve UX. 

Jumping ahead here: account abstraction & evolving EOAs is something that will require a deeper conversation, so we'll be organizing a breakout room on the topic in the next week or so. Info here:

Future EOA/AA Breakout Room · Issue #962 · ethereum/pmMeeting Info Date: TBA (see #future-eoas Discord channel for options) Youtube Stream & Zoom: TBA Ethereum Protocol Calls Calendar subscription Agenda Prague AA/EOA-augmentation candidates TBAhttps://github.com/ethereum/pm/issues/962

Afterwards, @yoavw presented EIP-7557 () which proposes to move the WARM/COLD state access pricing from a transaction-level scope to a block-level one. Doing so would mean something called multiple times in a block would only pay the (higher) COLD cost once

EIP-7557: Block-level WarmingA mechanism for a fair distribution of the gas costs associated with access to addresses and storage slots among multiple transactions with shared items in their accessList.https://ethereum-magicians.org/t/eip-7557-block-level-warming/16642

There were many questions about the best way to actually track this and handle refunds, whether it could potentially affect EVM parallelization efforts, interactions with Verkle, and gas estimation complexities. 

@yperbasis felt that other EIPs would likely move the needle more in terms of UX and should be our focus over this. 

Moving on, @gballet presented EIP-2935 for which Verkle brings a renewed interest. Here is his PR reviving the EIP:

Update EIP-2935: Move to Draft by gballet · Pull Request #8166 · ethereum/EIPsThis heretofore stagnant eip is now necessary for stateless clients to be able to execute the BLOCKHASH opcode. This PR: moves the eip from a stagnant status to a draft status change how the PR is...https://github.com/ethereum/EIPs/pull/8166

The ability to verify historical block hashes is important to reduce trust assumptions for stateless clients. The PR above changes the EIP to take into account the latest fork activation schemes & verkle roadmap:

@dannyryan first commented to support generally moving towards all inputs to the EL state transition function being either part of the current block or state, rather than looking at previous blocks, as the CL does. 

There was general support for this, but the conversation took a different turn once people voiced their desire to see 2935 adopt a similar architecture to 4788, which uses a ring buffer to store (and overwrite) the historical data. 

There were some concerns that using a regular contract could lead to exploits by mining contract with large amounts of data whose address has a common prefix with the precompile. 

Verkle's hashing being compute intensive than our current MPT hashing means such an attacker could create an increased computational load on the network each block. That said, a version of this attack could also be done on any popular contract who gets called most blocks. 

So, this felt like a more fundamental Verkle concern than one about the precompile. The Verkle team will be looking into both the potential attack and precompile design further. 

Next up, @CharlesCooper__ came to discuss EIPs 5920 (PAY opcode) and 7609 (reducing the price of transient storage). 

PAY would allow ETH transfers without the calling context which would reduce some potential smart contract re-entrancy risks. There was some support for this as an easy dev UX win. 

7609 argues that the current prices for TSTORE & TLOAD are too high. There was a bit of back and forth on the call about the numbers, and whether it's worth focusing on this over more significant scaling updates. 

No strong conclusions there, but some vocal support by @adietrichs and @peter_szilagyi towards making small gas schedule changes that are useful to users & devs. 

Last on the list, @mikeneuder highlighted that tomorrow at 14 UTC there will be a full breakout room dedicated to Inclusion Lists. More info here:

Inclusion List Breakout Room · Issue #954 · ethereum/pmMeeting Info Feb 16, 2024, 14:00-15:00 UTC Zoom: https://ethereumfoundation.zoom.us/j/83722574563?pwd=Zmw6YKhEBqYi3pgibBw0PCNxXJeQo6.1 Ethereum Protocol Calls Calendar subscription Agenda Inclusion...https://github.com/ethereum/pm/issues/954

At this point, we had <5 minutes left. We agreed to move EIP-2537, which had previously been CFI'd for Pectra, to Included (see ), and make more Pectra decisions in two weeks, after teams had time to review everything.

Update EIP-7600: Move to Review by timbeiko · Pull Request #8226 · ethereum/EIPsWe agreed to move 2537 from CFI to Included on ACDE#181https://github.com/ethereum/EIPs/pull/8226

Before we left, @potuz1 stressed the importance of agreeing on a timeline for Pectra as we debate the scope, to make sure that teams' plans assume the same ship date target. At this point, it seems like teams want to have Pectra go live before EOY! 

And that was it! Over the next two weeks we'll have the EOA & IL breakouts, and then continue the Pectra conversations on the next ACDE, scheduled for Feb 29, 14 UTC 🫡 

... and now, let's try and convert this thread to a Farcaster frame...