Ethereum consensus shifts on EVM upgrade

This is a segment from the 0xResearch newsletter. To read full editions, subscribe . Ethereum core developers have reached a pivotal decision on the future of the Ethereum Virtual Machine (EVM): the EVM Object Format (EOF) will be removed from the upcoming Fusaka fork. After years of work, EOF faced a new round of attacks ahead of the Fusaka scoping deadline. A final decision was deferred to today’s Interop Testing call , with broad implications for scalability and developer experience. Developers will continue work on Fusaka focused on PeerDAS and other scaling improvements, but the future of EOF is once again uncertain. It was the first time the Interop Testing call attracted over 100 participants, project coordinator Tim Beiko said, thus laying out the stakes. “When we ship something, we cannot revert that, and so we should have a really, really high bar to doing that,” Beiko reminded the group at the start of the call. Despite strong technical support for EOF in certain quarters, the lack of consensus ultimately meant it could not be bundled into Fusaka. EOF is an upgrade to the EVM that aims to clean up longstanding technical debt. It would let developers give new contracts a clear, verifiable layout, remove unpredictable code execution paths, and reduce the risk of bugs and security vulnerabilities by making contract behavior easier to analyze and validate. Geth developer Marius van der Wijden, initially an EOF skeptic, reviewed the evolution of his own thinking in an X thread . “Someone said ‘if we were to design the EVM from scratch, it would probably look like [EOF]’ and that swayed me to work on it,” van der Wijden wrote. Proponents argue it would make contracts easier to eventually migrate to new architectures like RISC-V. “Without EOF, it’s much harder to ever get there cleanly,” Danno Ferrin, one of EOF’s primary advocates, wrote ahead of the Interop call. The Cons Opposition grew louder in recent weeks, particularly among application devs and members of the Vyper compiler team. On Monday’s call, Charles Cooper, a core contributor to Vyper, reiterated his view that it shouldn’t even be called an “upgrade.” “If you’re going to break backwards compatibility, you shouldn’t say that it’s an improvement to the EVM,” Cooper said on the call. “It’s just like a new VM, and it should be sold to users that way, instead of telling them that it’s an improvement to the EVM, but it breaks all applications.” Michael Egorov, whose Curve protocol uses Vyper, has similarly questioned the premises behind EOF. “It really looks like the Solidity compiler trying to solve technical debt by doing something on the EVM level,” Egorov told Blockworks. He warned that the added complexity could waste valuable resources and potentially slow scalability, as EOFs’ benefits could be addressed through compiler improvements alone. Tensions also surfaced over the compatibility of major Solidity libraries, like OpenZeppelin and Uniswap. Research from the Ipsilon team confirmed many libraries would require adjustments to compile under EOF. While backward compatibility remains possible, adoption could be uneven. Ferrin presented a quick review of the top four Ethereum contracts. He showed that EOF would require only minimal changes, if developers opted for “ Option D ,” a less contentious version that restores code and gas introspection while keeping the core structure improvements. “If we remove EIP-7069 [the gas introspection ban], most of the problems above here are no longer problems,” Ferrin explained. This compromise would have delayed Fusaka’s Devnet 2 plan by just a couple of weeks, he said. However, it was ultimately not enough to secure consensus for inclusion. Others on the call noted that as part of any transition, many contracts would likely require fresh audits to ensure full security when revised under the new format. That costs money and time. Community voices had offered sharply different takes in recent days. Elias Tazartes pushed back on fears that layer-2 solutions would struggle with EOF adoption. “The promise of L2s was L1 equivalence, and early benchmarks show EVM with EOF to be easier to prove than without,” he said. In his view, EOF could even enhance rollup efficiency. The Solidity team weighed in forcefully ahead of the meeting, defending EOF against common criticisms. They pointed out that EOF has been under active development for over four years, and delaying it further would not significantly improve its “readiness.” Responding to concerns about potential disruption, they emphasized that legacy contracts will continue working, and that users can adopt EOF gradually. “EOF is not taking time away from scaling,” they argued, highlighting that most client work is already complete and that dropping EOF now would squander past investments. Regarding the larger execution layer roadmap criticism, they emphasized that migration to RISC-V in the future would not make EOF obsolete — instead, it would make such a transition smoother. The “Nays” have it Ethereum core development operates by rough consensus, and the bottom line is, when it comes to EOF, consensus is lacking. As van der Wijden noted: “We don’t agree, and we’re not coming to an agreement about EOF anymore, and so it has to go out,” he said. “I’m still torn, and I think a lot of people on this call are torn between the two options — and they don’t really know what the right decision would be — [but] in the past, in these cases, we always defaulted to not changing something, because that’s the safe option.” Beneath the technical debate runs a deeper philosophical tension about priorities. Developers debated whether Ethereum’s governance model — modeled after the IETF’s (Internet Engineering Task Force) — had failed to catch key issues early enough. Ethereum’s governance intentionally differs from, for instance, W3C’s “priority of constituencies,” where users are ranked above developers. Even if developer experience sometimes takes precedence in Ethereum governance, it strives for pragmatic decisions. That’s because core devs are not the ultimate arbiters; each Ethereum node operator ultimately decides what code to run, or not run. As van der Wijden observed, “There is a bit of pain with throwing good code away, but that shouldn’t influence our decision about what’s best for Ethereum.” Justin Florentine from the Besu client team was passionate about holding off on a final decision. “The idea that we would do an about-face, after a pretty hard-fought decision was reached to go with option A about a month ago , I find a little shocking,” Florentine said. “I don’t know that a vocal minority should be listened to.” He argued the recent objections of app developers should be taken with a grain of salt. “We are stewards of the protocol and have to be responsible for the tech debt that we are accruing and paying it off,” Florentine said. “We need to stop thinking like product developers and more like platform stewards.” Beiko acknowledged these governance challenges during the call, in calling for EOF to be reconsidered. “The cost of shipping the wrong thing is much higher than the cost of delaying,” he said. “If we do want to overhaul the EVM in such a way, the thing we should do is to do this in conjunction with smart contract developers and the tooling community more broadly.” Ultimately, while core dev teams like Geth, Nethermind, Erigon, and Besu expressed varying degrees of support for including a scaled-back EOF (while the Reth team was opposed), the lack of overwhelming consensus on a precise way forward was insurmountable. Beiko suggested that if EOF is to be revived, it would need to go through a fresh planning process for the subsequent hard fork, code named Glamsterdam. “I think the rest of the community should expect that EOF developers may not be so enthusiastic to keep working on this if it gets removed and as it has been in the past,” Beiko said, concluding that it was nevertheless a necessary risk to take. So Fusaka will move ahead without EOF, with a narrowed focus on PeerDAS and critical scalability improvements. Ethereum’s future EVM upgrades remain undecided, but the process questions raised today are likely to shape development for years to come. Get the news in your inbox. Explore Blockworks newsletters: Blockworks Daily : Unpacking crypto and the markets. Empire : Crypto news and analysis to start your day. Forward Guidance : The intersection of crypto, macro and policy. 0xResearch : Alpha directly in your inbox. Lightspeed : All things Solana. The Drop : Apps, games, memes and more. Supply Shock : Bitcoin, bitcoin, bitcoin.

Source: Blockworks