ACDE #210: Call Minutes
The call where developers debated EOF yet again
Good evening,
Yesterday, Ethereum developers debated the merits of the Ethereum Virtual Machine Object Format (EOF) in the Fusaka upgrade yet again. At this point, I have lost count of how many times developers have reconsidered EOF for Fusaka.
For background on EOF and why it was initially included in Fusaka, read this post:
Below are the full call minutes for All Core Developers Execution Call (ACDE) #210.
Yours Truly,
Christine D. Kim
Programming note: The ACD After Hours newsletter will be going on break starting next week and resume again in June.
Date and time: April 24, 2025, 10:00-11:30 ET/14:00-15:30 UTC
Duration: 90 minutes
Ethereum Magicians Discussion Link
Key Decisions & Announcements
Pectra
The Ethereum Foundation (EF) published a blog post announcing the Pectra mainnet upgrade.
Fusaka
Developers agreed to a format and naming convention for configuring EIP 7892 (Blob parameter only hard forks) on the execution layer (EL) of Ethereum. The format is specified in the EIP document.
Developers said they will re-discuss what version of EOF to include in the Fusaka upgrade on Monday’s Pectra testing call.
Developers have tentatively agreed to prioritize EIP 7935 in Fusaka. The new scheduled for inclusion (SFI’d) EIP seeks to determine a new and higher block gas limit for Ethereum.
EF Researcher Piper Merriam said the deadline for activating history expiry on the Sepolia testnet is May 1, 2025. Developers said they would discuss this timeline and next steps for history expiry asynchronously from the call on Discord.
Notable Discussions
Pectra preparations
EF Developer Operations Engineer Barnabas Busa said he has been testing the MEV workflow with the Pectra upgrade for the past few weeks. (For background on MEV, read this Galaxy Research report.)
Busa said:
“There has been quite some bugs and fixes coming to the relay, MEV-Boost, and rbuilder as well. So far, it has gained a bunch of improvements in the past couple of weeks and we have solid block production now through MEV-Boost.”
EF Developer Operations Engineer Parithosh Jayanthi added that his team is wrapping up testing for all final client releases for Pectra. Jayanthi said his team will launch a shadow fork of the Ethereum mainnet sometime early next week.
Fun fact: Shadow forks are special test networks created by forking live networks. Developers use them to test how an upgrade would behave in similar conditions to the forked network.
EOF debate
Tim Beiko, EF Protocol Support and Chair of the ACDE calls, prefaced the discussion on EOF by noting two concerns related to the code changes.
1. Smart contract developer experience
The first concern was raised by Nethermind client developer Ben Adams. He argued that the smart contract developer community is not ready to support a new version of the Ethereum Virtual Machine (EVM) as defined in the current EOF specifications for Fusaka. He recommended revising the scope of EOF to make it more compatible with existing smart contracts. The proposed revisions to EOF scope are defined as "Option D" in this document.
Reth client developer Dan Cline was in favor of revising EOF scope to Option D as suggested by Adams.
EF Researcher Ansgar Dietrichs said he had no strong opinions about the scope revision but noted that rediscussing EOF scope at all on the ACD call felt like a violation of the governance process. He wrote in the Zoom chat:
"Didn't we make a final decision on EOF scope already? ... I think we should only reconsider EOF scope for either of: client implementation issues, security concerns, major strategic reconsiderations."
In response to Dietrich's comments, Beiko said that in his view, developers did not fully understand the implications of their decision to scope out EOF in its most ambitious version and so, re-evaluating this decision is fine.
Danno Ferrin, an independent Ethereum developer leading EOF efforts, said about Option D for EOF:
"Going with this option does result in less scope and less work that needs to be done."
Cline and Paradigm CTO Georgios Konstantopoulos both emphasized that the main priority in Fusaka is PeerDAS, and all changes to the EOF scope should be considered in light of the PeerDAS timeline. For background on PeerDAS, read my “Figuring Out Fusaka” post.
There was no clear consensus on revising EOF scope in Fusaka. Konstantopoulos recommended that developers take time to review the options and be prepared to make a final decision on this in the next few days. Beiko recommended using next Monday's Pectra testing call on April 28 to decide.
2. RISC-V Research
The second concern related to EOF was raised by Geth client developer who uses the pseudonym "Lightclient." Lightclient argued that, in light of Vitalik Buterin's recent proposal to replace EVM bytecode with RISC-V instructions, developers should reconsider whether it is wise to expend time and resources to upgrade the EVM to EOF in Fusaka.
For background about Vitalik's proposal to replace the EVM and the RISC-V instruction set architecture (ISA), read this post:
About removing EOF from Fusaka in light of RISC-V research, Geth client developer and outspoken critic of EOF Guillaume Ballet said:
"There's this new shiny thing on the horizon and we would give up on doing something that we could do now so that we potentially get something in the future. But there are so many moving parameters that we don't know which future we will get to. So, once again, I'm not a big EOF fan but I don't think this is why we should not have EOF."
Lightclient responded:
"I think, unlike many protocol changes, when you change the user space, you put a massive burden on the entire user base and community, and we need to hold those types of changes to a higher standard than changing a database or changing the way the consensus protocol works."
Ethereum co-founder Vitalik Buterin clarified in the Zoom chat that his proposal to replace the EVM was suggested with a two-to-five-year timeline in mind. On the topic of how his proposal impacts EOF, Buterin said:
"If the end game for Ethereum that we think makes sense ends up being let's switch from the EVM entirely to something much simpler like RISC-V or prover-oriented VM, then that's a different end game and we should re-evaluate how we try to extract some of the [developer experience] and efficiency benefits that we want to get out of EOF in the short-term."
Throughout the discussion, Dietrichs and other developers in the Zoom chat asked about the governance process for formally reversing the decision to include EOF in Fusaka.
Dietrichs suggested a four-week period to research Buterin's proposal in earnest before deciding on the status of EOF in Fusaka.
Beiko pushed back on this suggestion, saying that four weeks is likely insufficient time for impactful research into alternate virtual machines (VMs) and may delay the Fusaka fork. Beiko recommended deciding on all matters related to EOF by Monday's testing call.
Lightclient said developers are not ready to make a decision on EOF.
Besu client developer Justin Florentine wrote in the Zoom chat:
"I'm really not sure how to compare something that is a pure research idea to an already engineered and being tested alternative."
Due to limited time on the call, Beiko suggested moving on to other agenda items like EIP 7935 and history expiry. Refer to the section above for a summary of the key decisions and announcements made about these other items on ACDE #210.
That’s all for my summary on ACDE #210. If you made it this far into today’s post, well done! You are now officially caught up on the state of Ethereum protocol development and governance.
Stay tuned for my insights on ACDE #210 coming out tomorrow.
Below are links for further reading and listening on the topics discussed on ACDE #210:
EIP 7935: Gas Limit Testing (Github pull request)
EIP 7927: History Expiry (EIP document)
EOF Fusaka Options (Blog post)
To EOF or Not? ETH Devs Can’t Decide (Podcast)
R55: An Experimental Integration of Ethereum with RISC-V (Github repo)
Thank you for reading today’s ACD After Hours post! What did you think of this one? Leave a comment and tell me what you liked (or didn’t). I read every message. :)
If you like what you read, consider sharing it with a friend who might also enjoy the content.
Also, subscribe, if you haven’t already, to receive my updates on Ethereum protocol development and governance directly in your inbox!
Finally, I am actively sourcing feedback on the ACD After Hours newsletter. Make your voice heard on the evolution of this series by responding to the poll below:
Newsletter Credits:
Special thanks to Shinhye Kim for the graphics in this newsletter.