All Core Devs - Execution (ACDE) #210, April 24

Protocol Calls & happenings
,
3

Next Steps

  1. EOF Next Steps Decision on Monday’s interop call

EL teams, please share your views about the next steps for EOF based on today’s conversation on the interop call agenda: Interop Testing #34 | April 28 2025 · Issue #1499 · ethereum/pm · GitHub. We’ll make a decision on Monday about any potential scope adjustments for EOF then. If you’re not sure what I’m referring to, please make sure to watch the recording of today’s ACD.

  1. SFI’ing the Gas Limit Defaults Informational EIP

On the last ACDE, we agreed to make increasing the gas limit one of the key “features” of Fusaka. To align on client defaults and keep this as a priority, we’ve drafted an EIP. It’s a bit unconventional, but not unprecedented (see EIP-7840). We plan to get it merged early next week and formally SFI it on the next ACD.
PR: Add gas limit increase EIP by Sophia-Gold · Pull Request #9678 · ethereum/EIPs · GitHub

As we find bottlenecks that prevent raising the gas limit, we should expect minor EIPs to patch them, such as: Add EIP: RLP Execution Block Size Limit by Giulio2002 · Pull Request #9658 · ethereum/EIPs · GitHub

  1. History Expiry Next Steps

It’s still unclear exactly where different teams stand with respect to dropping history in May. Let’s use #history-expiry to coordinate next steps.

Call Summary

Pectra

  • Mainnet announcement is out :tada:
  • PandaOps has been testing the block builder workflow, as well as using the latest client releases for feature tests. A mainnet shadow fork using the latest releases is planned for next week.

Fusaka

BPO Config Format

  • EL teams agreed to use the format as specified in the EIP, with a minor change to the naming scheme: each BPO fork should use the name BPO1, BPO2, etc. instead of a timestamp.

EOF

A lot was discussed about EOF. These notes are a brief summary. Please watch the full recording for complete context.

EOF updates

  • devnet-1 supports all container changes as well as TXCREATE. An EEST release is out for this.
    • Besu and Geth are passing all tests, as well as EVMone. EELS support is expected soon.
  • Planning to fuzz the implementations. ETA for devnet launch is the week of May 5.

Contract compilation issues

  • The current EOF version bans code introspection, which means existing contracts cannot trivially recompile to EOF, especially if they use assembly along with Solidity.
  • This implies that many popular libraries (e.g., OpenZeppelin contracts) cannot be imported as-is in EOF contracts, requiring a rewrite (and audits) to provide the same developer experience post-EOF.
  • This led some client teams to reconsider whether we should ban code introspection, or instead pursue a different variant of EOF (“Option D”) or potentially drop EOF in favor of simpler EVM changes (e.g., EIP-7907 and/or this proposal).
  • Concerns were raised both about the impact on the decision-making process of removing EOF so late and about the risks of shipping EOF with code introspection and then being unable to remove that functionality later (versus reintroducing it if EOF goes live with the ban).
  • Teams agreed to review the different options and make a final decision about scope on Monday’s interop call.

RISC-V

  • Another set of EOF-related concerns came from the recent proposal to replace the EVM with RISC-V. If the ecosystem adopts EOF over the next few years, and Ethereum later moves away from it, is that work wasted?
  • There was a lot of back and forth (again, see the livestream for full context). Ultimately, the uncertainty around RISC-V felt too high for this to directly affect the Fusaka EOF decision.
  • Still, there was some recognition that EOF may not be the long-term execution environment. Whether that future is RISC-V or another VM, this should be part of our reasoning about whether to move forward with EOF.

Gas Limit Default Configs

  • On ACDE #209, we agreed to prioritize raising the L1 gas limit in parallel with Fusaka work. While the gas limit is ultimately set by validators, we agreed that having an EIP to coordinate client defaults would help keep this a priority and ensure all clients update their defaults by the time Fusaka goes live.
  • An EIP was drafted for this purpose. We expect to merge it next week and formally SFI it on the next ACDE.
  • As we continue this work, we expect to identify changes that need to be made in-protocol to support a higher gas limit. This implies adding more EIPs to Fusaka, even though the fork scope is “final.” Example: EIP-9658

History Expiry

  • Clients are expected to drop history on Sepolia in the coming weeks. Team statuses were unclear on the call, so please update the Ethereum Magicians thread accordingly.
5 Likes