The case for EOF in Fusaka

Answering the question of why EOF is Scheduled For Inclusion in Fusaka. Many have given great arguments in depth already, which I'll link below. This is a higher-level summary of the best arguments I have seen.

Why EOF at all?

• EOF represents an acceptance that the EVM is not ready for ossification and should instead become a good base for innovations to happen on Ethereum
• "The EVM is like a 1950s computer and EOF makes it like a 1990s computer" - Tim Beiko
• To pay down the tech debt created by a hastily built EVM now that we have the benefit of years of usage and feedback
• "It simplifies the surface of contact with the EVM while also providing the necessary prerequisites to make future extensions easier to implement." - Solidity
• It is the culmination of ~10 years of research and development, iterating towards the current solution

EOF Unlocks

• Versioning allows backwards-incompatible changes without the need to analyse all existing contracts, for example removing opcodes
• Better auditing of smart contracts therefore improved ecosystem security, due to static analysis
• More ZK friendly, potentially cheaper and faster too
• Improved compilers, tooling and a better environment for new EVM languages could bring and keep more developers in Ethereum
• Static analysis enables more code inlining opportunities and gas optimisations therefore ultimately cheaper transactions
• More efficient execution by avoiding runtime code validation

Banning Gas Introspection

• In legacy EVM, repricing gas can break existing contracts and requires extensive analysis, similar to removing an opcode
• Banning gas introspection in EOF makes this easy
• Gas repricing is something we know we want to do in the short/medium term; it is necessary for scaling Ethereum safely

Banning Code Introspection

• The most controversial one since smart contracts already rely on code introspection features and may go against the 'immutable contract' concept.
• Opens up the possibility of forced conversion of legacy contracts, see https://ethereum-magicians.org/t/eof-proposal-ban-code-introspection-of-eof-accounts/12113
• EOF could exclude this change, but banning introspection now leaves open the option to add it back in later if it was a mistake: it is a reversible decision.
• Not banning introspection in EOF instead means we must introduce another breaking change if we want to ban it later.

Addressing arguments against EOF

There are many valid concerns that were well expressed.

• EOF is complex upgrade, but so are other upgrades we do
• Mitigate complexity with lots of testing, EOF has ~30K tests, the most of any Ethereum feature
• Doing EOF-like incremental upgrades without the EOF container could potentially add the same complexity whilst increasing (instead of reducing) the tech debt burden at both a design and implementation level
• Even if we never get rid of legacy EVM support in the clients, for the ecosystem above the clients, EOF is an improvement across the board. Universal adoption will make the legacy EVM irrelevant there. - Solidity

Why in Fusaka?

• In short, the majority of teams/core devs agreed and it is close enough to ready to ship this year.
• It doesn't interact with the consensus layer, so won't impact priority one, PeerDAS.
• All major clients have a working implementation on devnets
• Huge amount of tests (~30K) and fuzzing have been done and are ongoing (more so than any other Ethereum feature)
• Objections were raised and considered but this was not enough to change the consensus view on inclusion
  • Only Geth had split support, all other EL clients were in support; also solidity strongly in support
• One big breaking change instead of many across multiple forks

Resources

Thanks to Besu team for various discussions and Luis Pinto for reviewing this document

https://github.com/ethereum/pm/issues/1374 - ACD 208 in which EOF was SFI'd
https://notes.ethereum.org/@ipsilon/eof_fusaka_options
https://evmobjectformat.org/
https://github.com/ethereum/pm/issues/1098 - Long discussion on Youtube recording from last year

Arguments in favour

• https://soliditylang.org/blog/2025/03/27/the-case-for-eof/
• https://youtu.be/WpjcPPrrN2E?si=xtrOtRNYZ9zDqrt_&t=3330 - Tim's Bankless ep
• https://x.com/SuccinctLabs/status/1853525841537552833?t=MWZALOPiR1s-jCOVfa3Uyg
• https://blog.succinct.xyz/eofbenefits/
• https://x.com/urozmej/status/1902333108289953950
• https://evmobjectformat.org/#first

Arguments Against

• https://ethereum-magicians.org/t/ethereum-is-turning-into-a-labyrinth-of-unnecessary-complexity-with-eof-lets-reconsider-eof/
• https://hackmd.io/@pcaversaccio/eof-when-complexity-outweighs-necessity
• https://mariusvanderwijden.github.io/blog/2024/07/12/EOF/
• https://github.com/ethereum/EIPs/pull/9501 - Alternative proposal solving a subset of issues without EOF