EOF moves forward despite dev friction
Ethereum core developers debated a major overhaul of the EVM, weighing complexity and benefits
Skorzewiak/Shutterstock and Adobe modified by Blockworks
This is a segment from the 0xResearch newsletter. To read full editions, subscribe.
On Thursday’s ACD call, Ethereum core developers reaffirmed their intent to ship Full EOF (EVM object format) with the Fusaka fork alongside the PeerDAS main driver. (Ipsilon wrote up a thorough review of the options, with Full EOF referred to as “Option A.”)
EOF is a major overhaul of the EVM that aims for long-term optimization, safety and modularity of Ethereum’s execution engine.
Its scope has stirred controversy. Felix (from the Geth team) backed the more moderate Option D, putting him slightly at odds with fellow Geth college Lightclients.
From outside the client teams, Pascal Caversaccio voiced strong opposition, following up on his published critique: “EOF: When Complexity Outweighs Necessity.” His main claim: No application developers are asking for EOF, and its rollout risks alienating the broader dev community.
Despite this, EF staff — including Piper Merriam and Ansgar Dietrichs, as well as client teams like Besu and Erigon — stood behind Full EOF. Their reasoning: It’s a clean structural reset, demanded by compiler authors, and backward-compatible for developers preferring the legacy EVM.
Tim Beiko acknowledged the complexity, but noted it emerged from years of iterative work. “We can’t decide not to do something just because it’s complex,” he told participants on the call.
“Long live Full EOF,” cheered Merriam.
So EOF is coming. For developers, the negotiation phase seems over, and the upgrade’s next chapter will focus on implementation and testing.
Get the news in your inbox. Explore Blockworks newsletters:
- The Breakdown: Decoding crypto and the markets. Daily.
- 0xResearch: Alpha in your inbox. Think like an analyst.
