# Ethereum is turning into a labyrinth of unnecessary complexity with EOF

Source: https://ethereum-magicians.org/t/ethereum-is-turning-into-a-labyrinth-of-unnecessary-complexity-with-eof-lets-reconsider-eof/23136?u=timdaub
Kiwi News: https://news.kiwistand.com/stories/Ethereum-is-turning-into-a-labyrinth-of-unnecessary-complexity-with-EOF?index=0x67da7f0cca75ac4c72d55587ef981a140f9618308b63bba2ac21362fb37844c2de3c40c6
Submitted by tim on 2025-03-19 UTC, 2 upvotes, 0 comments

## Summary

Ethereum's EOF upgrade is unnecessarily complex, and its benefits could be delivered through less invasive changes to the existing EVM. The article says EOF introduces two new contract creation semantics (EOFCREATE and TXCREATE) and removes and adds over a dozen opcodes. It argues that goals such as reducing compiler complexity, removing gas and code introspection, and removing codesize limits can each be met by validation rules or updated pricing in the current EVM. It also lists costs including the need to maintain the legacy EVM, tooling coordination, and a reentrancy issue with send() and transfer() noticed only a month before Osaka's scheduled finalisation.

## Article

Ethereum is turning into a labyrinth of unnecessary complexity with EOF - Let's reconsider EOF

EOF is extremely complex. It introduces two new contract creation semantics (EOFCREATE and TXCREATE), removes and adds over a dozen opcodes. Furthermore, the purported benefits don’t require EOF, they could be implemented in the current EVM in much less invasive ways. Let’s explore these:

Reducing compiler complexity:

EIP-663 opcodes allow access deeper in the data stack. This is useful, but not a requirement for modern compilers – all modern compilers know how to implement stack/register spilling. This is a shortcoming of solc, not of the underlying VM. (As an example, Vyper does not have stack-too-deep as a result of compiler and language design.)

Improving bytecode size due to JUMPDEST removal:

We could just remove JUMPDESTs.

Makes it easier to upgrade the EVM, e.g. adding or removing opcodes:

We can add validation rules to the existing EVM. Bytecodes of contracts can be analysed at creation, and we can disallow deploying contracts with specific opcodes - or change semantics thereof - if they are deployed after a given fork_blocknum.

Allows for opcodes with immediates:

Again, we don’t need to change semantics of existing contracts. Rather, validate and apply updated semantics to newly created contracts.

Remove gas introspection:

You can just add the EIP-7069 (CALL2, etc) opcodes, which don’t access gas.

Validate that code does not include the GAS opcode.

Because of the 63/64ths rule, contract behaviour depends on gasleft anyways (subcalls can OOG without the outer contract OOG).

Remove code introspection:

You can add validation rules to legacy EVM to remove the relevant opcodes. New creation opcodes would need to be introduced, but it wouldn’t need to be shipped at the same time as all these other changes.

Remove dynamic jumps:

This can also be addressed simply by updating pricing and providing a carveout for PUSH2 JUMP(I) in the gas schedule.

Subroutines:

There are existing, less invasive proposals to the EVM which include subroutines and give preference to static jumps.

Address space expansion:

Can change semantics of existing opcodes (like BALANCE) to not zero the top 12 bytes of the address, again via contract versioning.

Remove codesize limits:

We can just do that, since initcode is metered via EIP-3860.

ZK-friendliness

EOF is purportedly more ZK-friendly. However, we have not seen arguments for why this is a hard requirement.

In other words, all the benefits of EOF can be introduced in more piecemeal, less invasive updates to the EVM.

Meanwhile, the complexities of EOF cannot be ignored:

Legacy EVM needs to be maintained, probably indefinitely.

Tooling needs to support EOF. This requires coordination and effort across many different teams.

Risk of vulnerabilities due to complexity. For instance, send() and transfer() now allow reentrancy. This was not noticed until a month before Osaka was scheduled to be finalised, even though EOF has been in development for nearly 4 years.

Related to that, EOF has been a moving target: EOF is looking to get shipped even though parts of the spec keep changing, making it difficult for compiler and app devs to review the entire package.

Work to target the new format for compilers and app devs.

EVM contracts get much more complicated due to headers. An empty contract is now at least 15 bytes.

Bytecode size tradeoffs. For instance, subroutines cost several bytes just to declare, which penalises contracts with many, small subroutines.

Update: I have co-authored a new and longer EOF deep-dive: EOF: When Complexity Outweighs Necessity. We break down its supposed benefits and argue they’re more “nice-to-haves” than essential upgrades. Instead of adding complexity, we highlight cleaner, less disruptive solutions that achieve the same goals. EOF’s objectives are solid—but there’s a smarter way to get there.

Please give it a read and let us know your thoughts in this thread.