Title: Ethereum_is_turning_into_a_labyrinth_of_unnecessar
Category: EIPs

Author: pcaversaccio
Date: 2025-03-13T14:11:38.752Z

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.

Author: shemnon
Date: 2025-03-13T14:41:16.607Z

I’ll spend the time to give a more detailed response later this week, but I would like to point out that all of these questions were already asked and answered as a part of ACD 192 9 months ago.  I do not see any new concerns raised here.




All Core Devs - Execution (ACDE) #192, July 18 2024 Protocol Calls & happenings


Agenda
Execution Layer Meeting 192 · Issue #1098 · ethereum/pm · GitHub 
Moderator: @timbeiko
Summary


Recording


Additional info

Notes: Ethereum All Core Developers Execution Call #192 Writeup | Galaxy by @Christine_dkim
EOF: Why I am against EOF in Pectra – MariusVanDerWijden by @MariusVanDerWijden
RIP7212: Brief History and Current Situation of RIP-7212 by @ulerdogan

Author: xrchz
Date: 2025-03-13T15:02:27.670Z

Perhaps as a meta point there seems to be disagreement about whether major EVM changes are desirable in general (including in the notes from the call you mentioned). I would argue that a stable VM, on which people can invest in building up excellent tooling and apps with confidence, is much more valuable than the ability to evolve the VM to compete with other VMs, since this has the cost of scaring away investment in something that’s gonna potentially change in the future. (I’m speaking in part here as someone who becomes much more hesitant about my investments in the EVM, both as user and dev, when I see that stability of the VM isn’t being prioritised.)

Author: mitche50
Date: 2025-03-13T15:23:58.298Z

I just want to echo this sentiment - As someone who has been building on the EVM for a long time now, all of these changes adding in unnecessary complexity and changing assumptions is a huge turn off for developers building on the supposed “world computer”.

Author: bbjubjub
Date: 2025-03-13T16:17:59.703Z

pcaversaccio:

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.



IMHO tracking deployment height and applying different semantics to a contract on that basis has drawbacks. It means that if you have deployment transactions, they might produce different results if you cross the hardfork boundary. Although this is technically true already with gas schedule changes, this seems much more likely to cause issues. This is also true if you work in an Osaka environment and then switch networks. And we haven’t addressed contracts creating contracts which could also be messy. By contrast, versioning seems more elegant and allows explicit opt-in.
That does not mean that all of EOFv1 belongs as a bundle together. In fact it would be possible to introduce versioning on its own and nothing else, but there would be no incentive to upgrade. If we want a carrot, a good choice would be stack validation + relative jumps, which enable optimizations that could enable a gas discount. This pulls in roughly half of the EOF EIPs, which constitute a more minimal set and exclude some of the more problematic changes like gas inobservability. This may be inaccurate because I haven’t been following EOF closely, but the message is: versioning per se uniquely unlocks a more efficient EVM afaict.

Author: xrchz
Date: 2025-03-13T17:45:31.641Z

If something has to be included, I think I could get behind adding relative jumps (although not yet convinced they are really worth it).
I don’t believe stack validation needs changed semantics. It can be done already via analysis of status-quo EVM code. Is there reason to think otherwise?
I take this opportunity to call out another pattern I have observed in discussion of EOF so far: that proponents seem keen to equivocate between “EOF enables X” and “X requires EOF”, when these are not in fact logically equivalent statements. I hope readers of these discussions take heed that demonstrating “Y enables X” is much easier than proving that “X requires Y”, but it’s the latter that we need proven before biting the bullet on adopting Y (assuming X is highly desired).
Thanks for your point about versioning. On that point my previous comment about stability still feels relevant: I would rather not make plans (like versioning) that make major EVM upgrades easier, because I would rather not have major EVM upgrades and for the benefits of this to be appreciated.

Author: duncancmt
Date: 2025-03-14T09:23:28.328Z

As I stated over here EOF creates new problems for application-layer developers like me. Seeing as it also doesn’t really solve any of the existing problems that I have, I would not adopt EOF. Also seeing as legacy EVM will need support for the foreseeable future, I’m not enthusiastic about EOF.
My 3 major gripes are:

TXCREATE’s functionality (or lack thereof) not supporting CREATE3-like patterns.
The insistance around lack of inspectability of bytecode (and how you can’t completely hide the bytecode if you have anything resembling CREATE2)
Gas rules (not allowing capped-gas *CALL, the 2300 gas rule, 63/64ths rule)

Author: bbjubjub
Date: 2025-03-14T11:27:49.734Z

xrchz:

I don’t believe stack validation needs changed semantics. It can be done already via analysis of status-quo EVM code. Is there reason to think otherwise?


After thinking about it, I personally believe that it would be possible to do stack validation without pulling in EOF. It would involve analyzing “legacy” bytecode using a similar algorithm as EIP-5450. Specific sequences involving the PC opcode would be recognized as static relative jumps, (a bit like aiupc in RISC-V) and PUSH-JUMP as absolute. Then if validation fails, the contract would be marked as non-compliant, but still remain usable with backwards compatible semantics as before. If it is compliant, it would be marked as such and potentially benefit from gas discounts and a higher size limit. This would still require a hardfork, but would be much more transparent to the application layer.
There would need to be an EIP to flesh this out and give it a chance. I am willing to help write it if there is interest.

Author: Arvolear
Date: 2025-03-16T07:18:15.685Z

The question I always ask is who would use EOF if L2s dominate the market share?
With such a huge EVM update it’s not enough for Ethereum to just be a “North Star”. Existing L2 stacks have to upgrade as well or an official stack need to be provided and maintained by EF.
Honestly, there are three things that scare me the most:

Instantly added complexity to EVM.
Even wider divergence of L2s from L1.
Short term concentration on the app layer “fixes”, while not addressing scalability issues and not bringing new ideas to L1.

Also with the current rollup-centric roadmap Ethereum may well become a pure DA layer. So all these EVM shenanigans may not really worth the effort.

Author: chfast
Date: 2025-03-16T08:27:32.107Z

pcaversaccio:

We could just remove JUMPDESTs.


Are you going to properly propose this in form of EIP / spec update?

Author: ajsutton
Date: 2025-03-16T16:01:57.454Z

Arvolear:

Existing L2 stacks have to upgrade as well or an official stack need to be provided and maintained by EF.


Every L1 hard fork needs to be adopted by L2s, which they consistently do. What makes you think L2s wouldn’t adopt this given the exceptionally strong demand for full Ethereum equivalence?
At least for OP Stack EOF support would be inherited from the L1 client implementations quite easily and I don’t see any reason it wouldn’t be supported.

Author: Arvolear
Date: 2025-03-16T17:33:40.178Z

Because this upgrade is so complex and consists of numerous new opcodes, it must be coordinated with the L2 teams.

For opstack, it is not as simple as “merging upstream changes”.
For ZK rollups, constraints generation spec, tracers, zkECs, etc, need to be updated.

For example, Linea still doesn’t support a simple push0 opcode.
zkstack has its own Solidity compiler that will need to be updated as well.



I really want to believe that L2s would wish to implement EOF, but given their reluctance to ship much smaller changes, I have doubts about that.

Author: pdobacz
Date: 2025-03-17T08:59:55.939Z

duncancmt:

TXCREATE’s functionality (or lack thereof) not supporting CREATE3-like patterns.


Can you elaborate on this one please? TXCREATE as specced out in EIP-7873 is designed to allow anyone to deploy a CREATE3-like EOF factory to a deterministic address on different chains. By CREATE3-like I’m assuming you mean one which doesn’t include the initcode hash in the address.
If EIP-7873 misses any deployment pattern, please let us know.

Author: duncancmt
Date: 2025-03-17T18:00:33.150Z

Ahh, I wrote that original comment before the changes to 7873 that removed the inithash from the address calculation. I did not re-read the EIP to pick up the changes. I think that as it exists right now, 7873 supports every usecase that I can think of

Author: bbjubjub
Date: 2025-03-18T15:04:49.420Z

xrchz:

If something has to be included, I think I could get behind adding relative jumps (although not yet convinced they are really worth it).


IMHO static jumps on their own are not really worth it because they can be done with combos of PC PUSH ADD/SUB and JUMP(I).



 xrchz:

I don’t believe stack validation needs changed semantics. It can be done already via analysis of status-quo EVM code. Is there reason to think otherwise?


As far as I can tell this type of analysis can be done. Since we wouldn’t have dedicated jump and call instructions, we would have to “bless” certain opcode sequences as the official ways to do a relative jump or a subroutine call and statically track the stack that way. Then you would be able to add protocol-level flags to the contract accounts that pass validation, which is something that EOF wanted to avoid. Someone could also explicitly trigger validation of an existing contract, which isn’t possible with EOF.
It seems as though if we already specced stack validation for EOFv1, we can port it back to legacy EVM. Plus, it seems compilers most likely generate compliant bytecode already. I would love if compiler people and client devs could check me on this though.



 xrchz:

Thanks for your point about versioning. On that point my previous comment about stability still feels relevant: I would rather not make plans (like versioning) that make major EVM upgrades easier, because I would rather not have major EVM upgrades and for the benefits of this to be appreciated.


That is a very fair concern for sure. It also made me think that if Ethereum is aiming to eventually ossify, at some point there would be an ultimate EOF version and we would stop changing semantics. However, we would be left with a lot of overhead due to all the previous versions. If we can avoid than and still get most of the benefits that would be nice.

Author: shemnon
Date: 2025-03-18T21:26:57.613Z

A lot of these questions have been asked and answered in other forums.  But it’s great to get a centralized list.



 pcaversaccio:

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.)



Compilers indeed can solve the famous “stack too deep” problem with register allocation but they cannot guarantee optimal solution. But even if they could, stack/register spilling is very cost ineffective without reliable access to cheap memory. The EVM’s non-linear gas cost for memory makes access to larger variable pools more expensive and fragile than a paged memory model like one in typical silicon processors.
With this in mind, solving this problem on the compiler level is just a trade-off, rather than a direct improvement. Efficient and safe upgrade to EVM’s stack management is important, EIP-663 achieves that and in order to do so safely, requires immediate arguments (see other points).



 pcaversaccio:

Improving bytecode size due to JUMPDEST removal:

We could just remove JUMPDESTs.



Removing JUMPDESTs will have very negative downstream impact. JUMPDEST addressed an inherent defect in dynamic jumps. Without JUMPDEST compilation via Intermediate Representations (IR) (e.g. LLVM) was infeasible.
There are also security implications related to preventing execution of data carried in the contract. Details should be better explained in a stand alone article.



 pcaversaccio:

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.



This describes an approach that was tried and rejected in 2019 (EIP-1702).  You need to know which rule set to follow not only when validating, but also when executing a contract, so information about the version must be stored alongside the code. EIP-7702 also greatly complicates account versioning for contract validation. This is why EOF opts for storing it inside bytecode container.
Secondly, to allow for validation we also would need to allow for data segments. We would need to mark code as being EOF, then mark where the code ends and the data starts. This is the essence of the EOF container, and falls naturally from first principles once the need for validation is established.
Finally, EOF aims for changing the version as little as possible, ideally never. New rule set at every fork would mean a lot of versions co-existing together in the state, which greatly complicates reasoning about overall execution rules, any future (EVM- or adjacent) upgrade must take into account all possible versions it affects, and EVM implementations must maintain multiple rule sets in parallel. These are the points that EOF is already being criticized for, while introducing only one additional version. Piecemeal changes would have a net grater complexity if not aggregated in an upgrade like EOF.



 pcaversaccio:

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.



EOF forbids deploying undefined opcodes, which allows to introduce new opcodes in the future without changing EOF version. The system where new opcodes require new validation rules at every fork would be more complicated (see previous point).



 pcaversaccio:

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).



This is exactly how EOF removes gas introspection.



 pcaversaccio:

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.



This is exactly how EOF removes code introspection.
Devising and shipping an intermediate container format which just enables code introspection removal and then iterating on it to achieve other benefits of the structuring means more EVM versions co-existing together in the state (see previous point). At the same time, achieving just code non-introspection by itself would not warrant the effort or complexity required for the containerization.



 pcaversaccio:

Remove dynamic jumps:

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



This proposal has zero benefit for static analysis, because this pattern exists today and static analysis tools already recognize it. Dynamic jumps are not banned and this is what the tooling struggles to analyze.
Furthermore, detecting this carveout would slow down VM implementations as they would need to take processor time to detect the pattern at every jump. Gas charged will go down but so will gas per second and transactions per second.



 pcaversaccio:

Subroutines:

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



If this refers to EIP-2315, that one was rejected by ACD after arguments were made it would not be adopted. The argument was that there wasn’t enough benefit and enough gas saving provided by it. EOF’s approach to subroutines (functions) have strong support from at least one compiler team.



 pcaversaccio:

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.



Important consideration here is that we want to prevent breaking of already deployed contracts if/when an ASE proposal is introduced. There are operational contracts that depend on the trimming of the address argument. This is what derailed previous attempts at address space extension.



 pcaversaccio:

Remove codesize limits:

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



EIP-3860 addressed a JUMPDEST analysis exploit that was best executed at initcode time, however there is no metering to loading contracts from state. JUMPDEST analysis still needs to be performed or cached. And this needs to be loaded from the cache or performed every time the contract is executed. Piecemeal changes to existing analysis rules would also require cached validations to be updated.
EOF code validation is performed only when the code is first introduced to the blockchain via the initcode transaction.  Hence any other interactions with EOF code (reading the contract from state, executing other contracts, factory contracts creating new contracts, etc) are performed without needing any further validation. Validation is asserted for the life of the bytecode.



 pcaversaccio:

ZK-friendliness

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



We do not claim it is a hard requirement. But ZK-friendliness is an argument in favor of EOF. Initial implementations have shown a 2.5 to 3x speed improvement in the cost of ZK proving a contract transaction. Driving down the prices of ZK transaction is needed to achieve the “nickle” goal of Ethereum scaling.



 pcaversaccio:

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


Piecemeal improvements have a greater cost over the longer term of their implementation.  Multiple backwards incompatible changes will cause the clients to have to support multiple incompatible versions of the EVM. This is why EOF is batching proposed backwards incompatible changes in to as few steps as possible, ideally one.
Piecemeal changes also have a tendency to complicate each other when not properly coordinated. One previously considered alternative was to add contract versioning (EIP-1702). The new EIP-7702 contract delegate feature in Pectra breaks any safety guarantees that this EIP would have provided, as the actual code the account contains could easily be updated, and now two different accounts need to be considered in the logic, increasing the number of ways a client optimizing this interaction could introduce unexpected bugs.
Packaging the changes in aggregate allows the net impact of all of the changes to be smaller and less invasive than if each change were to be introduced slowly. It also removes the need for intermediate states between each piecemeal change, where novel attacks could be launched.
Piecemeal would mean we need to maintain multiple non-compatible EVMs. Also the piecemeal approach has been proposed before and rejected by ACD/the community as not useful enough and problematic (EIP-2315, EIP-1702, EIP-615, for example).
It is much more rational for EOF to ship all breaking changes in only one backwards-incompatible step.



 pcaversaccio:

Meanwhile, the complexities of EOF cannot be ignored:

Legacy EVM needs to be maintained, probably indefinitely.



EOF is at its core a container format for the EVM, and is designed to be run within the same VM code. The same operation dispatch, contract calling code, storage access, memory handling, arithmetic, etc. et. al. is all handled by the same client code whether the contract is in an EOF container or is a legacy contract. EOF shares more with the legacy EVM than what differentiates it.
By “legacy EVM” in this context we should clarify that we are talking about 16 removed opcodes, making up for roughly 10% of current opcode count. Some of these opcodes share large portions of logic with their legacy counterparts (e.g. EXT*CALL, EOFCREATE), bringing that figure further down.
Also, the potential for a legacy → EOF bytecode migration still has not been definitely ruled out, albeit it is a daunting task best approached once EOF is in production.



 pcaversaccio:

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


This is true for all changes to the EVM. Coordination is done via the bi-weekly EOF implementers call everyone is welcome to. Besides the EOF implementers and EIP authors, there are members of testing, compiler and tooling teams participating. Some teams have already shipped devnet-0 support in their tools.



 pcaversaccio:

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.


Solidity’s current plan is to deprecate send() and transfer() for EOF contracts. Other means to prevent reentrancy are encouraged (TSTORE/TLOAD), especially so since relying on gas to block reentrancy is subject to break unexpectedly on gas repricings, which is also one of the reasons gas introspection is removed in EOF in general.
Other developments like the PAY opcode may impact that decision, but given the subtleties between the implementations Solidity may choose to expose it via a new API (such as pay()) while providing compiler warnings when mapping send and transfer to the PAY opcode, but this is a decision for the Solidity team.
Answering the notion that the issue remained unnoticed for nearly 4 years: the first PR with initial EOF Solidity support was pushed on July 23rd 2024. This is a problem which is related to language implementation and how it deals with reentrancy issue. It was actually noticed by the Solidity team soon after that PR opened and before the official release with experimental support for EOF.



 pcaversaccio:

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.


Specifications being updated prior to activation is the norm in Ethereum, not the exception. For instance, EIP-7702 which had a change merged one month before Holesky activation. EIP-2537’s spec was updated after the testnet hard fork.  This EIP is even older than the main EOF specifications.
The changes to spec are driven mostly by feedback from ACD and the community, or they are immaterial clarifications and renamings. For context and point of reference: we are still months away from EOF going to testnet and intend to freeze breaking changes with devnet-1, months from the public testnet rather than weeks we have seen in other major features.
You can review planned EOF devnet-1 changes, and also review the EOF Testnet plan.



 pcaversaccio:

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


Solidity has already updated their compiler to the current devnet-0 spec and end users will not need to update the source code of their contracts unless they are depending on deprecated features, such as the current incarnation of SELFDESTRUCT.



 pcaversaccio:

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


With EOF, contracts get much simpler thanks to separating data and code reliably, as well as replacing dynamic jumps with static ones and function calls. Contract size cannot be seen as a metric to compare complication (or complexity).
In all but the simplest contracts the number of bytes used in the header is offset before the function dispatch code or first function is complete.



 pcaversaccio:

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


From experiments with a preliminary PoC that was largely unoptimized we did not see any bytecode regressions for widely used contracts. The tested contracts all demonstrated a reduction in bytecode size.
Small subroutines indeed may be inlined by compiler optimizations, which is already the case when targeting legacy EVM.
The current Solidity EOF implementation still have almost all optimizations steps disabled for EOF in assembly level. This means that this version’s 10% reduction in code size when using EOF should not be used to measure the final impact. We have experimental version with most important optimizations enabled which confirm code size and gas cost reduction for EOF. It’s going to be pushed to solidity repo soon. Also CPU time benchmarks confirm gains in execution speed of EOF compiled contracts.

Author: shemnon
Date: 2025-03-18T21:27:37.184Z

xrchz:

Perhaps as a meta point there seems to be disagreement about whether major EVM changes are desirable in general (including in the notes from the call you mentioned). I would argue that a stable VM, on which people can invest in building up excellent tooling and apps with confidence, is much more valuable than the ability to evolve the VM to compete with other VMs, since this has the cost of scaring away investment in something that’s gonna potentially change in the future. (I’m speaking in part here as someone who becomes much more hesitant about my investments in the EVM, both as user and dev, when I see that stability of the VM isn’t being prioritised.)


This is a fully general argument that could be applied to any change in the protocol, not only EVM. Any change for the sake of scalability, security, usability, goes against “stability” of ossified protocol.
Ossifying the protocol at the wrong time presents more risk to the future of Ethereum than not ossifying at all.

Author: shemnon
Date: 2025-03-18T21:28:44.836Z

bbjubjub:

That does not mean that all of EOFv1 belongs as a bundle together. In fact it would be possible to introduce versioning on its own and nothing else, but there would be no incentive to upgrade. If we want a carrot, a good choice would be stack validation + relative jumps, which enable optimizations that could enable a gas discount. This pulls in roughly half of the EOF EIPs, which constitute a more minimal set and exclude some of the more problematic changes like gas inobservability. This may be inaccurate because I haven’t been following EOF closely, but the message is: versioning per se uniquely unlocks a more efficient EVM afaict.


This is a more nuanced take on the “one step” argument than the prior arguments and it deserves consideration in a less adversarial environment (such as delaying no code introspection and no gas intospection to a hypothetical ‘EOFv2’).  However, we have seen problems in getting any EVM change adopted of any size, so there is no guarantee that breaking EOF into multiple parts would lead to the latter pieces being adopted.

Author: shemnon
Date: 2025-03-18T21:29:40.511Z

bbjubjub:




 xrchz:

I don’t believe stack validation needs changed semantics. It can be done already via analysis of status-quo EVM code. Is there reason to think otherwise?


After thinking about it, I personally believe that it would be possible to do stack validation without pulling in EOF. It would involve analyzing “legacy” bytecode using a similar algorithm as EIP-5450. Specific sequences involving the PC opcode would be recognized as static relative jumps, (a bit like aiupc in RISC-V) and PUSH-JUMP as absolute. Then if validation fails, the contract would be marked as non-compliant, but still remain usable with backwards compatible semantics as before. If it is compliant, it would be marked as such and potentially benefit from gas discounts and a higher size limit. This would still require a hardfork, but would be much more transparent to the application layer.
There would need to be an EIP to flesh this out and give it a chance. I am willing to help write it if there is interest.


The space that needs to be carved out is to ensure that no “compiler bombs” are allowed.  While most contracts are well behaved the presence of a malicious contract can remove all the gains seen by compliant contracts.  The sad truth of Ethereum security is we always optimize for the worst case, because these will be posted to the network (such as the Shanghai attacks in 2016).
Also, the time spent to separate compliant from non-compliant contracts could be more than the time saved by applying the compiler optimizations.

Author: shemnon
Date: 2025-03-18T21:30:50.020Z

duncancmt:

TXCREATE’s functionality (or lack thereof) not supporting CREATE3-like patterns.


TXCREATE as specced out in EIP-7873  is designed to allow anyone to deploy a CREATE3-like EOF factory to a deterministic address on different chains.  This is a core feature of the EOF devnet-1 plans and has been part of the mega spec for two years.  It was removed from Prague as a concession to the size of the fork and was always intended to ship at some point.  The current plan is to ship it with the Osaka specced EOF version.



 duncancmt:

The insistance around lack of inspectability of bytecode (and how you can’t completely hide the bytecode if you have anything resembling CREATE2)


Vitalik makes the best arguments for banning code introspection.  It separates the representation of the contract from the consensus about its execution and outcome at the protocol level, allowing code to be transpiled to other formats, such as RISC-V.  Allowing the code to enter or leave system memory locks in one particular representation of the contract as part of consensus.



 duncancmt:

Gas rules (not allowing capped-gas *CALL, the 2300 gas rule, 63/64ths rule)


Relying on a fixed gas schedule has been a problem for a long time and best practices are to not rely on it.  EOF formalizes this recommendation in a way that allows future EVM repricings to have minimal impact on user code. There is a working group working on dramatic changes, including things like multi-dimensional pricing and code merkelization, which will have dramatic effects on the gas schedule as a whole.

Author: chfast
Date: 2025-03-18T22:18:56.272Z

Arvolear:

Because this upgrade is so complex and consists of numerous new opcodes, it must be coordinated with the L2 teams.

For opstack , it is not as simple as “merging upstream changes”.
For ZK rollups, constraints generation spec, tracers, zkECs, etc, need to be updated.

For example, Linea  still doesn’t support a simple push0 opcode.
zkstack  has its own  Solidity compiler that will need to be updated as well.



I really want to believe that L2s would wish to implement EOF, but given their reluctance to ship much smaller changes, I have doubts about that.


These are general criticisms of the rollup centric roadmap, not EOF in particular. If EOF were not proposed these would still be problems, in the same way they are stated.
Note that one engineer from Optimism said that if EOF ships on mainnet it will appear on the op-stack. This is because of OP’s architecture that relies on lightly modified L1 clients, they will get the bulk of the work for free. The parts of the EVM that EOF would modify are fairly separated from the pieces that are changed to accomodate the other parts of the OP stack such as the sequencer.

Author: TimDaub
Date: 2025-03-18T23:20:01.894Z

What are the benefits of EOF to Ethereum users, app devs and to dapp consumers?

Author: 0xTraub
Date: 2025-03-19T01:18:59.676Z

An important consideration though is the potential increase in version management for L2s, as the ability to deploy multi-chain gets easier. In the current system smart contract devs can opt out of using new features that are not enabled on every chain they deploy to. For example, simply setting your foundry EVM-version config to the oldest one supported by all the chains you want to deploy on to ensure bytecode uniformity. Shipping on l1 first makes managing different bytecode versions mandatory for all devs, which can be a real headache before we even discuss having to maintain two different versions of the codebase if you plan on working in low-level assembly where opcode changes are impactful. We’ve seen this directly with transient storage not being implemented at scale because of chains that still haven’t implemented it.

Author: duncancmt
Date: 2025-03-19T07:51:41.994Z

shemnon:




 duncancmt:

TXCREATE’s functionality (or lack thereof) not supporting CREATE3-like patterns.


TXCREATE as specced out in EIP-7873  is designed to allow anyone to deploy a CREATE3-like EOF factory… The current plan is to ship it with the Osaka specced EOF version.


Awesome! As @pdobacz pointed out up-thread and I replied, I had written the originally-linked thread before that was possible and had not checked up on the changes 



 shemnon:




 duncancmt:

The insistance around lack of inspectability of bytecode (and how you can’t completely hide the bytecode if you have anything resembling CREATE2)


Vitalik makes the best arguments for banning code introspection. … Allowing the code to enter or leave system memory locks in one particular representation of the contract as part of consensus.


I’m not denying that there are reasons for having this behavior. My point here is that there are interesting (and arguably valuable) use cases for being able to know things about the code deployed to other addresses. By removing this functionality, it creates new problems for application developers. As a consequence of creating those problems, there is a very explicit disincentive for developers (like myself) to adopt EOF.



 shemnon:




 duncancmt:

Gas rules (not allowing capped-gas *CALL, the 2300 gas rule, 63/64ths rule)


Relying on a fixed gas schedule has been a problem for a long time and best practices are to not rely on it. EOF formalizes this recommendation in a way that allows future EVM repricings to have minimal impact on user code. There is a working group working on dramatic changes, including things like multi-dimensional pricing and code merkelization, which will have dramatic effects on the gas schedule as a whole.


This is not the only reason to want to pass something less than all-but-one-64th of the available gas to a sub-context when performing a call. Particularly if the called contract is only somewhat trusted by the calling contract. Again, there are valuable design patterns enabled by the ability to pass less gas when performing a call, and the removal of that capability makes my life harder.
Additionally, designing contracts around opcode repricing has been a thing for ages already. A contract that is designed in such a way that it is brittle to opcode gas costs is already a badly-designed contract.

Overall, while I appreciate the detailed responses, @shemnon, that you’ve given to the criticism in this thread, but I think that taken in totality they’re clearly missing the point here that EOF is being sold as “a VM improvement that will benefit smart contract developers”, when in fact it is actually being driven by the needs/agenda of the execution layer to the detriment of smart contract developers. It’s this discrepancy that causes me to bristle and which I think will ultimately stand in between EOF and adoption. That’s not to say that I don’t see and appreciate the reasons why EOF may be a net improvement to Ethereum, but when I look shortsightedly at the path of least resistance, that path is “ignore EOF if adopted and oppose it before it is because, it makes my life harder”.
And I also endorse the general thesis of the OP: this is additional complexity that is patently unnecessary from the perspective of the smart contract developer.

Author: pdobacz
Date: 2025-03-19T09:28:59.539Z

duncancmt:

My point here is that there are interesting (and arguably valuable) use cases for being able to know things about the code deployed to other addresses. By removing this functionality, it creates new problems for application developers.


Can you name the use cases specifically? As noted above, we’re gathering feedback and acting on it (examples: TXCREATE, HASCODE, EXTCODEADDRESS, metadata section… not always it’s feasible to include in EOFv1/Osaka, but one needs to know the use cases to even start discussing them).



 duncancmt:

This is not the only reason to want to pass something less than all-but-one-64th of the available gas to a sub-context when performing a call. Particularly if the called contract is only somewhat trusted by the calling contract. Again, there are valuable design patterns enabled by the ability to pass less gas when performing a call, and the removal of that capability makes my life harder.
Additionally, designing contracts around opcode repricing has been a thing for ages already. A contract that is designed in such a way that it is brittle to opcode gas costs is already a badly-designed contract.


Again - please be more specific and name the use cases, ones which don’t fall into the latter category of brittle.



 duncancmt:

missing the point here that EOF is being sold as “a VM improvement that will benefit smart contract developers”,


I feel like OP listed many benefits in the first half of the post, and @shemnon laid out why EOF is currently the optimal known path forward, if we want to have these benefits. They’re not short-term nor direct benefits, but rather enablers and quirk-removers. They are aimed to benefit sc developers via better and more maintainable compilers, SA, stability against gas repricings, lax contract size limits, EVMMAX etc.
And please, elaborate on the above 2 points or anything else that shortsightedly makes life harder, maybe as with TXCREATE it isn’t so bad.

Author: benaadams
Date: 2025-03-19T10:21:54.545Z

TimDaub:

What are the benefits of EOF to Ethereum users, app devs and to dapp consumers?





 duncancmt:

this is additional complexity that is patently unnecessary from the perspective of the smart contract developer.


One thing is it opens the door to larger smart contracts EIP-7830: Contract size limit increase for EOF to 64kB
In practice developers deploy multiple smart contracts and use strange contrivances like ERC-2535: Diamonds, Multi-Facet Proxy to get around the contract limit.
However this adds complexity and opens door to hacks from improper permissions for smart contract comms or initialization gaps.

Author: TimDaub
Date: 2025-03-19T11:06:47.769Z

What were the actual hacks when contract size limitations lead to user funds being stolen/inaccessible? Knowing a dollar value would be interesting. Thanks
To me the argument that greater contract size equals more correct contract code is unclear. I can only anecdotally speak for myself and when I develop smart contracts, the smaller they are the more likely they are to be correct and safe. That said, maybe the Diamond pattern is at fault for producing issues, not the contract size limitation. Can your problem be fixed by reforming the Diamond contract pattern? I‘m worried that we‘re adding smth here that is super complex but has no direct benefit to consumers. Idk if you‘ve looked at the price and sentiment recently… it‘s not good xD so it‘d be wise to prioritize, even if that means orphaning some branches

Author: charles-cooper
Date: 2025-03-19T11:25:57.613Z

benaadams:

One thing is it opens the door to larger smart contracts EIP-7830: Contract size limit increase for EOF to 64kB


I don’t think EOF actually does open the door to larger smart contracts. EIP-170 was quite clear that VM bytecode preprocessing was only one of several DoS vectors that grow linearly in the size (and these are well documented in the discussions around it).
The correct solution here is removing contract size limits and replacing with gas metering on loading code, as I recently proposed in EIPs 7903 and 7907 (there is predecessor work here too, for instance EIP-5027)



EIP: Remove Contract Size Limit


    discussions-to for Add EIP: Remove Contract Code Size Limit by charles-cooper · Pull Request #9483 · ethereum/EIPs · GitHub






EIP-7903: Remove Initcode Size Limit EIPs core


    discussion topic for Add EIP: Remove Initcode Size Limit by charles-cooper · Pull Request #9452 · ethereum/EIPs · GitHub






EIP-5027: Unlimit contract code size EIPs


eip: 5027 
title: Unlimit contract code size 
author: Qi Zhou @qizhou 
discussions-to: TBD 
status: Draft 
type: Standards 
Track category: Core 
created: 2022-04-21 
requires: EIP-170

Abstract
Unlimit the contract code size so that users can deploy a large-code contract without worrying about splitting the contract into several sub-contracts.

Author: pcaversaccio
Date: 2025-03-19T12:05:46.381Z

shemnon:

A lot of these questions have been asked and answered in other forums. But it’s great to get a centralized list.


The sheer length and depth of this response already serves as proof of the unnecessary complexity that EOF introduces. Yet, despite all this effort, the core issue I raised—the full extent of complexity we’re facing—remains unaddressed. If it takes this much explanation just to justify EOF, isn’t that a sign we’re heading in the wrong direction? Ethereum should prioritise simplicity, not more labyrinthine abstractions.
@MariusVanDerWijden has written an excellent section on the complexity here:

The biggest issue I see is that EOF is extremely complex. It introduces RJUMP, RJUMPI, RJUMPV, CALLF, RETF, JUMPF, EOFCREATE, RETURNCONTRACT, DATALOAD, DATALOADN, DATASIZE, DATACOPY, DUPN, SWAPN, EXCHANGE, RETURNDATALOAD, EXTCALL, EXTDELEGATECALL and EXTSTATICCALL.
All-in-all EOF introduces 19 new opcodes. Additionally it removes 16 opcodes present in the existing EVM from EOF and changes the behavior of multiple opcodes in both versions. These changes have already resulted in two consensus issues in Besu and evmone (used by erigon) even before EOF made it to mainnet. Luckily these issues were found by Martin Holst Swende before they made it into a release.
All these new opcodes must be tested, especially because some of these (like EOFCREATE and RETURNCONTRACT) interact with each other.
Additionally EOF introduces the code and stack validation. This means that the code is verified before it’s being deployed. Therefore the code validity now becomes part of consensus which means that bugs in the code or stack validation will result in consensus bugs. Even worse, if the code and stack validation spec has a bug, a faulty contract could be deployed which would result in undefined behavior if called.

But you keep ignoring these concerns. You can go ahead and gamble with Ethereum’s core machinery, but I won’t stand by and watch. I care about not messing up the foundation—because if we screw up the core, there won’t be a core anymore.

Author: TimDaub
Date: 2025-03-19T12:36:15.039Z

Btw why is the discussion here centered around the quality of the improvement? This seems to me unnecessarily pure in regard to what we want to achieve. A quick reminder, we aren’t in academia. We have a token price to increase.
It must be pretty clear to everyone who is locked into Ethereum prices that there are fundamental things wrong with it since the blobs upgrade. Clearly we have to fix a bunch of things in the short term, and we have to serve application developers so that they can onboard more users, to make the blob-addition logic make sense finally. We’re not going to be able to increase the total fee accrual by just ignoring the issue, kicking the can down the road, or by increasing prices. So inevitably we’re going to have to onboard more users. I’m pretty sure there is a maximum capacity of things the core devs can do within a time frame. Why are we asking them to do a bunch of refactors for a goal that doesn’t align to fix short term issues?
But if the only argument here is that contract sizes can be increased, then I’m not sure why we’re even discussing how high quality the EIP is. Clearly increasing contract sizes is not going to fix the obvious short coming of the current Ethereum configuration. Clearly whether the EIP is high quality doesn’t matter as to how to prioritize the proposal within the set of tasks that are needed to be done to fix the current protocol’s short comings.

Author: middlemarch
Date: 2025-03-19T13:16:42.470Z

I’ve been thinking through some practical implications of EOF’s removal of capped-gas calls, and it seems problematic for common patterns that rely on “push” Ether transfers.
Consider a common auction pattern:
function bid(uint256 id) external payable {
    Auction storage auction = auctions[id];

    address previousBidder = auction.latestBidder;
    uint256 previousValue  = auction.latestBid;
    address bidder         = msg.sender;
    uint256 value          = msg.value;

    if (value < _currentBidPrice(auction)) revert MinimumBidNotMet();
    if (block.timestamp > auction.endTimestamp) revert AuctionNotActive();

    auction.latestBid    = uint112(value);
    auction.latestBidder = bidder;

    (bool success,) = payable(previousBidder).call{value: previousValue, gas: 60_000}("");

    if (!success) {
       balances[previousBidder] += previousValue;
    }

    emit Bid(id, value, bidder);
}

In this snippet, the call to previousBidder uses a fixed gas limit (gas: 60_000) to ensure the bidder can run minimal logic without significantly impacting the rest of our transaction. This pattern is widely used today to prevent the recipient from consuming too much gas and breaking subsequent logic in the calling contract.
This pattern isn’t possible under EOF as explicit gas limits are removed, giving the callee nearly all available gas.
How does EOF intend to handle scenarios like this? One possible answer is that push-based withdrawals would no longer be safe or recommended—after all, even today, contracts must implement fallback logic in case transfers fail. Still, it’s useful and practical for contracts to be able to reliably react in minimal, controlled ways when receiving Ether.
Is it truly feasible or desirable to eliminate this capability protocol-wide?

Author: shemnon
Date: 2025-03-19T14:50:37.013Z

pcaversaccio:

The sheer length and depth of this response already serves as proof of the unnecessary complexity that EOF introduces. Yet, despite all this effort, the core issue I raised—the full extent of complexity we’re facing—remains unaddressed. If it takes this much explanation just to justify EOF, isn’t that a sign we’re heading in the wrong direction? Ethereum should prioritise simplicity, not more labyrinthine abstractions.


You provide a long list of questions and assertions and are now upset they were answered in turn?  If we replied with one liners would you have then complained that we didn’t think deeply enough about the issues?



 pcaversaccio:

@MariusVanDerWijden has written an excellent section on the complexity here :


Go listen to ACD192 where we spent most of the meeting discussing it.  It includes the opinion of the lead of Solidity where he endorses EOF as what he wants “by orders of magnitude”.  And at the end of the meeting Marius agreed to disagree and commit.  My interpretation of his concerns was that there were many unanswered questions in his mind, but they all did have answers and had been thoguht through, as we discussed on that call.
And I do not view this gambling ethereum’s core.  Solidity’s comment indicates to me we are shoring up a sandy foundation rather than applying more duct tape and balling wire to an insufficient solution.  While some of these problems can be fixed in the compiler we need to reflect on the question of whether or not that is the right place to fix it.  A fix in the wrong layer can cause more damage.
There are fixes that need to be done to the VM that take it up to more modern standards, rater than the 1950’s “stream of bytes” standard we have had.  The benefits in a container and other features like stack validation will enable compilers to provide even better utility than they do now, much more so than the compiler working alone with an outdated model. I respect that we have differing opinions on this but I stand with Daniel’s assertion in ACD 192 that this is the correct solution for the compiler and the layers below it.

Author: duncancmt
Date: 2025-03-19T15:06:15.127Z

I feel like my underlying point (the forest) is being missed for the specific technical details of my concerns (the trees). My point is that there is complexity and burden being foisted on the chain and on smart contract developers without immediate benefit. To crib a cynical phrase from American politics, all of these future benefits are nice, “but what have you done for me lately?”. That there are any opcodes that are removed/broken, and consequently that there are some design patterns that are no longer possible is a VERY big stick. Where is the corresponding carrot?
Regardless, I will respond point-by-point:



 pdobacz:




 duncancmt:

EXTCODE*


Can you name the use cases specifically?


In the absence of a technique (like CREATE2) to verify that the code at an address was derived from trusted initcode, we want to know whether the *CALL that we’re about to make is executing the code we expect. We can’t do what Solana does and directly read the state of foreign contracts, so we have to resort to trusting the code in that address to report directly on its state.
To give a concrete example: Curve V2 Tricrypto NG factory pools are CREATE’d (not CREATE2) by a factory. If we want to know if an arbitrary pool is a pool, we need to check its bytecode. I acknowledge that there are probably other ways to skin this cat, but checking the code is an expedient solution.

Alternatively, maybe we want to do what Vyper does and store some arbitrary data in another address, load it into memory and treat it as initcode (or other arbitrary data) to work around the contract size limit.



 pdobacz:




 duncancmt:

all-but-one-64th


Again - please be more specific and name the use cases, ones which don’t fall into the latter category of brittle.


https://etherscan.io/address/0x0000000000001ff3684f28c67538d4d072c22734#code#F7#L26
In general, the pattern that is not not supported is performing a call that you expect to revert, but to have “enough” gas to still perform some useful computation. You might say “well, just assert that the revert reason/returndata is non-null”, but sometimes you don’t have that degree of flexibility when interoperating with contracts that were written by a 3rd party.

Another application of this pattern is calling some 3rd-party contract in order to see what it does, then reverting with some machine-readable summary of that behavior. This achieves a kind of pseudo-STATICCALL and is completely dependent on the ability to discover whether a call reverted due to out-of-gas or some other reason.
Similarly, you may wish to call some 3rd-party contract that represents the agent of some entity to gracefully wind down a position, forwarding a “reasonable” amount of gas (e.g. a proportion of the block gas limit). Then if that fails to gracefully wind down the position, you forcibly liquidate. If we can only forward 63/64 of the gas, there’s no way to ensure that the “liquidation” portion of the operation has enough gas if the “wind down” portion refuses to participate. (I regret that I cannot give you a specific address where this code lives; the protocol that I’m referencing never launched.)



 pdobacz:




 duncancmt:

missing the point here that EOF is being sold as “a VM improvement that will benefit smart contract developers”,


I feel like OP listed many benefits in the first half of the post, and @shemnon laid out why EOF is currently the optimal known path forward, if we want to have these benefits. They’re not short-term nor direct benefits, but rather enablers and quirk-removers. They are aimed to benefit sc developers via better and more maintainable compilers, SA, stability against gas repricings, lax contract size limits, EVMMAX etc.


As you acknowledged, none of these are benefits realized immediately after the proposed Osaka hardfork. And some of these benefits accrue to smart contract/application developers only indirectly. Enablers and quirk-removers don’t make the lives of smart contract developers easier. Improving the tooling and developer experience is certainly a boon, but EOF is not the only way of achieving this (going back to @xrchz 's point about being sure to distinguish between “requires” vs “enables”).
To be abundantly clear here: I’m not saying that I don’t see or that I disagree with the value of EOF. Clearly improving/versioning the EVM is something that is needed for Ethereum to achieve its mission. But as a smart contract developer, because EOF causes problems for me with no corresponding benefit, I will not adopt it at launch.

Author: jflo
Date: 2025-03-19T21:10:00.692Z

duncancmt:

To crib a cynical phrase from American politics, all of these future benefits are nice, “but what have you done for me lately?”.


The purpose of EOF is inherently long-termist. If you fundamentally disagree with that approach, I suppose that is fine but it is hard to have technical arguments around that.
The forced conversion problem this solves is an extremely powerful unlock.
Nor is moving the token price something that can be considered, aided, or even addressed by an EIP.

Author: charles-cooper
Date: 2025-03-19T23:38:53.370Z

shemnon:

If this refers to EIP-2315 , that one was rejected by ACD after arguments were made it would not be adopted. The argument was that there wasn’t enough benefit and enough gas saving provided by it. EOF’s approach to subroutines (functions) have strong support from at least one compiler team.


By the way I checked the old threads and I think the examples that were given at the time to argue against the gas savings of EIP 2315 may have actually been inaccurately based on an old draft of the EIP. The latest gas values in the EIP are 5 gas for JUMPSUB and 3 gas for RETURNSUB – exactly the same as CALLF and RETF. So I don’t think it makes sense to use the arguments based on “gas benefit” or “compiler benefit” against EIP-2315, since they apply equally if not more to EOF. EOF not only has the same gas costs, it is also structurally more restrictive, blocking optimizations that are conversely available via EIP-2315, and requiring substantially more complexity on the compiler side.
For reference, our POC for EOF in Vyper took nearly 1k lines of code to be EOF-compliant. And I’m not that familiar with the Solidity codebase, but it looks like the EOF POC was 14,000 lines (Implementation of EOF in Solidity [DO NOT MERGE] by rodiazet · Pull Request #15294 · ethereum/solidity · GitHub). Whereas for EIP-2315, I can’t speak for Solidity but at least on the Vyper side, EIP-2315 is a 10-20 line change.

Author: daniellehrner
Date: 2025-03-20T10:22:54.050Z

duncancmt:

As you acknowledged, none of these are benefits realized immediately after the proposed Osaka hardfork.


Solidity has a EOF version that can you used today. So immediately after the hardfork SC devs won´t be plagued by stack too deep errors anymore.
EOF brings immediate cost reductions. For example for Uniswap v3 deployment costs decrease by 14% and costs for calls by 9% [1] All of that without any changes to the Solidity code.
Screenshot 2025-03-20 at 11.20.111418×1392 127 KB
How are those not immediate benefits?
[1] EOF Explained: What Developers Need to Know | by BuildBear Team | BuildBear Labs | Medium

Author: TimDaub
Date: 2025-03-20T10:27:31.964Z

daniellehrner:

EOF brings immediate cost reductions. For example for Uniswap v3 deployment costs decrease by 14% and costs for calls by 9% [1] All of that without any changes to the Solidity code.


Dapp dev here: Contract deployment costs are completely irrelevant nowadays. They are basically free on L2s and on Mainnet they’re also basically free because gas has been averaging 1gwei for the entire February.
As a contract developer you can often wait for a period when gas is cheaper to deploy a contract too. Also going from 14% to 9% really does not matter in my day to day. The core costs to producing production-ready Solidity smart contracts are the cost of the audit, the cost of the Solidity dev (have you seen their salary?), how long it takes to find one, etc. Deployment cost is completely irrelevant

Author: duncancmt
Date: 2025-03-20T10:45:36.260Z

daniellehrner:

SC devs won´t be plagued by stack too deep errors anymore.


This is not what’s standing in between me and shipping products that users desire. Also EOF is a solution to this problem, but not the solution to this problem. A smarter compiler (looking at you, Vyper) also solves this problem.



 daniellehrner:

Uniswap v3 deployment costs decrease by 14% and costs for calls by 9%


Like @TimDaub said, deployment costs basically don’t matter. But 9% decrease in runtime gas is pretty neat! I recant my earlier statement that there is no benefit to smart contract developers immediately on the hardfork. I think that’s still probably not enough benefit to counteract the additional pain/burden caused by the opcode changes, but I appreciate that things are moving in a beneficial direction. 
My application is more sensitive to gas consumption than most, so “gas lower” is a better reason for me to adopt EOF than it is for most projects. But I reiterate my first point: this is not what’s standing in between dApp developers and shipping products that users deesire.

Author: rodiazet
Date: 2025-03-20T10:53:02.563Z

charles-cooper:

For reference, our POC for EOF in Vyper took nearly 1k lines of code to be EOF-compliant. And I’m not that familiar with the Solidity codebase, but it looks like the EOF POC was 14,000 lines (Implementation of EOF in Solidity [DO NOT MERGE] by rodiazet · Pull Request #15294 · ethereum/solidity · GitHub). Whereas for EIP-2315, I can’t speak for Solidity but at least on the Vyper side, EIP-2315 is a 10-20 line change.


Re the 14K line diff - did you stop to fact check what that is? It’s 2x Uniswap files which are in not-merged PR just for code size and gas price impact check. They are not in main repo. Moreover most of the changes/additions are in test directory. Solidity has a lot of semantic, syntax a many other tests which were updated. I’m leaving your homework for you to calculate how big was the change. I’m not going to do this. Sorry.
image656×121 8.52 KB

Author: charles-cooper
Date: 2025-03-20T14:48:35.218Z

I started that sentence by saying that I’m not that familiar with the Solidity codebase. Anybody can see that it is unmerged, it’s in the text of the link. I just found the PR which looked indicative of the effort. If you want to provide updated numbers that you think are more accurate on the Solidity side, I’m happy for you to do so. I brought it up in an effort to provide more diverse sources than just Vyper, although from your reaction, it sounds like maybe I should have just skipped that step altogether.
On the other hand though, I am familiar with the Vyper codebase, and my numbers there do stand. I don’t really think going through and adding up all the EOF-related commits in solc is going to change my point that EOF is substantially more complex for compilers to implement than EIP-2315. Again, I’m happy to be corrected here, though. If it turns out that EOF only takes 10 lines to implement in solc, that would be a very interesting data point.

Author: pdobacz
Date: 2025-03-20T18:13:05.280Z

duncancmt:

I feel like my underlying point (the forest) is being missed for the specific technical details of my concerns (the trees).


Underlying point is understood. Still, I find the specific technical details useful to discuss. I am trying to understand and try propose solutions for the problems you are facing (c.f. the TXCREATE case).
So if that’s not a problem, I have only two quick follow-ups for now:



 duncancmt:

completely dependent on the ability to discover whether a call reverted due to out-of-gas or some other reason.


In EIP-7069 EXT*CALL discriminates between revert and oog of the callee (or any other failure consuming all callee gas) via the returned status code - 1 vs 2. Does that help? Would other status codes help?



 duncancmt:

If we can only forward 63/64 of the gas, there’s no way to ensure that the “liquidation” portion of the operation has enough gas if the “wind down” portion refuses to participate


What if EXT*CALL allowed to customize the gas forwarding rule to a relative amount, i.e. forward “x/64th”? This is an draft idea which floated recently, not fully sure if viable yet.

Author: moodysalem
Date: 2025-03-20T18:59:54.031Z

daniellehrner:

calls by 9% [1] All of that without any changes to the Solidity code.


I wrote a lot of Uniswap V3 so let me comment on this. O(10%) is not a good ROI for the amount of mental overhead EOF introduces for me as a dapp developer. Bytecode size is irrelevant as long as it’s under 24kB, especially with newer singleton designs as in in Ekubo Protocol, Balancer V3, Uniswap V4. The singleton design of these contracts saves much more than 9% in contract calls and storage reads/writes. Simply introducing a usable account abstraction removes approval transactions, and that probably scales the blockspace by more than 10%. You could save even more by building swaps into the account to remove approvals. I often find major improvements in gas costs simply by dropping down into assembly, so the solidity optimizer is far from optimal. All that to say, 10% usually comes at a cost of far, far less complexity.
I also don’t see the scaling benefits of EOF as significant. IMO you can do way better than a 15% speedup on execution if you focus on parallelization, e.g. introduce a new TX type that has mandatory access lists + incentivize it with gas refunds for accuracy.
I don’t argue with the benefits of EOF, I take issue with the immeasurable complexity cost of those improvements. If your EIPs need 30k tests to be safely deployed and only save 10% gas on execution, maybe it’s not worth it. For context, Ekubo Protocol has about 350 unit/fuzz tests, Uniswap V3 had about 1k unit tests, and transient storage has what looks like a few dozen.
Edit: can’t find where I saw the 30k tests number, so striking it out

Author: jflo
Date: 2025-03-20T19:27:54.045Z

Well, it’s not completely irrelevant, it actually relates directly to gas price, per your example. Gas price may have been 1gwei for all of Feb, but gas prices fluctuate, and that low price is not eternal. People definitely complain about deployment cost when gas was high, especially for more dynamic use cases such as we expect with account abstraction.

Author: shemnon
Date: 2025-03-20T19:59:38.760Z

It’s quite interesting to see a team being criticized for writing too many tests. And your estimate of 30K is off by about an order of magnitude.
Ethereum testing has evolved quite a bit since TSTORE was added.  Compared to the old JSON based testing EEST makes writing lots of tests easy because it has a very expressive parameter system based around python. It makes it easier to fire off 90 tests rather than find the 5 most representative failures, so it takes a bit of restraint to not quickly carpet-bomb the testing area because pytest makes it very easy to do so.  Judging complexity by test load is not very insightful because it’s actually fun to write EEST tests, as opposed to the monotony of other testing systems.
And the comparison to a narrowly focused DeFi swapper for complexity is not an apt comparison.  Ekubo does one thing well, and a VM need to do, well, basically everything.
If we hyper focus on the smallest possible change we will never be able to correct the mistakes that were made in the first draft of the EVM: dynamic jumps, no container system, no subroutines, etc.  If there was a serious VM person in the pre-olympic days I bet we would at least have a container, and that alone would solve lots of problems.
For example, if we had a container we would have a place to store metadata about what storage slots are touched based on the input and we could more intelligently decide what transactions need to be examined for conflicts, and parallelize the rest.  Instead without it we would have to enumerate those conflicts and incentivize correctness, rather than make it an easily computable part of the program.
The perception of the complexity is we are adjusting some fundamental assumptions that are holding the EVM back, and as devs we understand where all the touch points are.

Author: moodysalem
Date: 2025-03-20T21:26:50.421Z

shemnon:

And your estimate of 30K is off by about an order of magnitude.


Sorry, can’t find where I first saw that number, so striking it out.



 shemnon:

Ethereum testing has evolved quite a bit since TSTORE was added. Compared to the old JSON based testing EEST makes writing lots of tests easy because it has a very expressive parameter system based around python.


For reference, I was counting from here: execution-spec-tests/tests/cancun/eip1153_tstore at v3.0.0 · ethereum/execution-spec-tests · GitHub



 shemnon:

If we hyper focus on the smallest possible change we will never be able to correct the mistakes that were made in the first draft of the EVM





Pectra Network Upgrade Meta Thread

As an EVM developer, I am opposed to EOF. I am not convinced of the value in creating a new version of the EVM while still forever maintaining past versions. Even if it’s an order of magnitude more efficient, unless there is a plan to disable, remove, or (impossibly?) migrate older code, my main concern is the developer overhead for working with multiple versions of the EVM as well as the increased risk of client bugs.





Pectra Network Upgrade Meta Thread

EOF is not a new version EVM. It is a container format around the existing EVM model and a number opcodes to fix several issues related to technical debt: static jumps, code validation, subroutines, removing code introspection, and removing gas introspection. The core model of the EVM remains the same, and Legacy EVM and EOF can freeley call each other with the exact same semantics. Your traces will look mostly the same (new opcodes aside) and the same techniques you use to develop will be the same. To most smart contract developers it will be nothing more than toggling a switch in solidity or vyper, and your code will also be a little smaller once you do.


This point has surely been made a few times by others, but you can’t actually correct the mistakes because the existing contracts will never go away. If you could migrate or otherwise get rid of old contracts, I wouldn’t have any issue and might even be excited about EOF. It might be on your roadmap, but I see no practical way to migrate existing contracts, and at least it’s a huge effort for what amounts to O(10%) cost reduction.
Your reply about it looking the same to EVM developers does not sound right to me. I regularly drop down to assembly blocks and I basically have evm.codes open all day long. It’s critical to understand exactly how the EVM works and what solidity is doing under the hood when gas or safety matters, and I also need to know how EOF contracts interact with non-EOF contracts and vice versa.



 shemnon:

For example, if we had a container we would have a place to store metadata about what storage slots are touched based on the input and we could more intelligently decide what transactions need to be examined for conflicts, and parallelize the rest. Instead without it we would have to enumerate those conflicts and incentivize correctness, rather than make it an easily computable part of the program.


I don’t think it’s even desirable to have that metadata on-chain. You can just simulate the transaction off chain, and/or the dapp will contain the logic for determining the slots that are touched. If you priced the theoretical mandatory access lists TX correctly, then the dapps would be incentivized to be as precise/accurate as possible.

Author: wminshew
Date: 2025-03-20T21:47:07.880Z

Your reply about it looking the same to EVM developers does not sound right to me. I regularly drop down to assembly blocks and I basically have evm.codes open all day long. It’s critical to understand exactly how the EVM works and what solidity is doing under the hood when gas or safety matters, and I also need to know how EOF contracts interact with non-EOF contracts and vice versa.

strong++ to this

Author: Arvolear
Date: 2025-03-21T05:30:44.180Z

So adoption of EOF now relies on the words of some random engineer at OP?
This is very very sad.
To be clear, I am not saying that EOF is a bad idea. Bytecode versioning is great. But it is something that EVM should have been initially designed with. Now we would just add a ton of technical debt instead of addressing it.
Once again, EOF would only see light if most of the EVM chains adopt it. Otherwise, EOF would become another weird kido like push0 or transient storage.
Why can’t we see some coordination efforts from EF? Why there is no official L2 rollup stack that would support all the latest Ethereum changes? Why are we focusing on EOF instead of scaling the L1?

Author: TimDaub
Date: 2025-03-21T08:12:51.527Z

jflo:

Gas price may have been 1gwei for all of Feb, but gas prices fluctuate, and that low price is not eternal


I know where you’re coming from and I agree of course. But at the moment whether contract deployments are 5% more or less really doesn’t matter. My main concern is wasting time and Ethereum going to shit because it’s core mechanics are unfixed in production for over a year now. I don’t think we can take for granted that gas prices will come back to prior levels with the system so fucked up. I imagine EOF can also be done at a time when things aren’t on the edge collapsing?



 jflo:

People definitely complain about deployment cost when gas was high, especially for more dynamic use cases such as we expect with account abstraction.


As a consumer product builder IMO “people complaining” is usually not a proxy for “I need to optimize something” but it is a proxy for “wow we have created something so valuable that when we bar people from it they start to complain/bargain with us.” Everyone says the iPhone is too expensive…
Anyways, just to be clear about my intent. I complain here bc I don’t see how EOF is addressing the most pressing issues that the Ethereum software currently has and therefore, for now, I’m against doing this effort.

Author: daniellehrner
Date: 2025-03-21T08:58:31.070Z

TimDaub:

Anyways, just to be clear about my intent. I complain here bc I don’t see how EOF is addressing the most pressing issues that the Ethereum software currently has and therefore, for now, I’m against doing this effort.


But what do you think are the most pressing issues of Ethereum then? Because making the lifes of SC devs easier is quite high in my priority list. Among other things, EOF should enable better tooling and make developing on Ethereum easier. Doesn’t this address your concerns about SC development being too expensive for example?

Author: daniellehrner
Date: 2025-03-21T09:04:44.555Z

moodysalem:

Your reply about it looking the same to EVM developers does not sound right to me. I regularly drop down to assembly blocks and I basically have evm.codes open all day long. It’s critical to understand exactly how the EVM works and what solidity is doing under the hood when gas or safety matters, and I also need to know how EOF contracts interact with non-EOF contracts and vice versa.


This is the strongest point yet that something is fundamentally broken with the EVM in general or at least Solidity. We can’t expect all the devs to know how to write assembly in order to be productive.
According to Electric Capital’s 2023 only around 0.085% of all software developers work in web3 full time. Meaning that if blockchains become as important as we all think the vast majority of devs is yet to join and start working on smart contracts. We need to make their entry as easy as possible. Solidity thinks that EOF helps write compilers so that’s a good start for me. I don’t know which other steps are needed, but needing assembly so often seems to be a bug that needs to be addressed.

Author: TimDaub
Date: 2025-03-21T10:04:58.049Z

daniellehrner:

But what do you think are the most pressing issues of Ethereum then?


Screenshot 2025-03-21 at 11.00.153098×988 272 KB (source: Ethereum financial statement | Token Terminal)
Ethereum has stopped making money for its holders. Check the fee accrual row. Ethereum was mechanically worth a lot of money as a business because if you owned it you’d get access to between 9B to 2B USD in annual fee accrual. Plus you’d also get all the fees from Flashbots. Because of a (frankly) half-assed update fee accrual is now 10x less for 2025 with no direct path to going up again. Why should ETH price not follow this decrease in cashflows and go 10x down?
(btw I’m far from the only person who sees ETH evaluation like this: Ethereum Must Choose: Asset or Platform, Says EY’s Paul Brody - "The Defiant")

“Bitcoin is the asset. Ethereum is a platform,” he said. “Ethereum doesn’t need to be highly valuable, but fundamentally, the valuation of Ethereum is based on a discounted cash flow model. It generates transaction fees. You stake it, you get yield. It’s actually really simple.”

(I disagree with ETH “not needing to be highly valuable” as economic security is important for the chain. Anyways I’m quoting this to confirm that other’s value ETH based on discounted cashflows too).
What? “More users are going to surely come soon?” That feels way too optimistic to me. Just because we’ve built it doesn’t mean they’ll come. Solana has also built it and their fee accrual is more than ours for this year already.
So this is the starting point and every one of us has to do everything we can to fix this in one way or another. Sorry, I’m sure the EOF work was done in good faith ofc, but embarking on a big “refactor” for some minor optimizations seems to me like a very foolish idea considering that it is taking away overall capacity from the core dev team to addressing the core issue. If everyone’s busy with EOF they may not spend time fixing the main issue more directly

Author: daniellehrner
Date: 2025-03-21T10:47:11.484Z

Okay, but that is completely off topic, I thought you meant changes to the EVM. I do not think that a post about EOF is the right place to discuss ETH value accrual.

Author: TimDaub
Date: 2025-03-21T10:50:07.497Z

Why would that be off topic? This is literally the single most important thing in all of Ethereum. Neither of our fault that it was broken but it is now an existential issue. But we have to deal with it anyways. If that doesn’t work we also don’t have to discuss a refactor of the code base because the code base won’t matter anymore

Author: pcaversaccio
Date: 2025-03-21T15:55:52.344Z

Guys, 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.

Author: moodysalem
Date: 2025-03-21T16:31:12.500Z

daniellehrner:

This is the strongest point yet that something is fundamentally broken with the EVM in general or at least Solidity. We can’t expect all the devs to know how to write assembly in order to be productive.


Actually it is usually entirely solidity’s fault, just take a look at all the simple functions in the solady library that are cheaper by avoiding solidity’s bytecode generation. Hence my suggestion that the energy be shifted towards the language and compiler for a much higher ROI.
Here’s an example: Writing a struct that fits in a single slot incurs additional SLOADs in Solidity 0.8.29. The assembly-only version costs 125 less gas, even though the result is identical.
pragma solidity =0.8.29;

import {Test} from "forge-std/Test.sol";

contract Target {
    struct MyStruct {
        uint64 a;
        uint64 b;
        uint128 c;
    }

    MyStruct public state;

    constructor() {
        state = MyStruct(3, 2, 1);
    }

    function solidityOnly() external {
        state = MyStruct(1, 2, 3);
    }

    function assemblyOnly() external {
        assembly ("memory-safe") {
            sstore(0, or(or(1, shl(64, 2)), shl(128, 3)))
        }
    }
}

contract TestWasteTest is Test {
    Target t;

    function setUp() public {
        t = new Target();
    }

    function test_solidityOnly() public {
        t.solidityOnly();
        vm.snapshotGasLastCall("solidity only");

        (uint64 a, uint64 b, uint128 c) = t.state();
        assertEq(a, 1);
        assertEq(b, 2);
        assertEq(c, 3);
    }

    function test_assemblyOnly() public {
        t.assemblyOnly();
        vm.snapshotGasLastCall("assembly only");

        (uint64 a, uint64 b, uint128 c) = t.state();
        assertEq(a, 1);
        assertEq(b, 2);
        assertEq(c, 3);
    }
}

And I disagree with the premise anyway. If you are writing contracts that will handle billions of dollars, sorry but you’re going to need to have a deep understanding the platform you’re building on. EOF is going to make that a much bigger hurdle.

Author: gcolvin
Date: 2025-03-21T23:01:44.577Z

Stack validation can be done, but in the presence of dynamic jumps it cannot be done in linear time – every possible path out of every jump must be traced, taking quadratic time.  The same problem afflicts anything that involves tracing the control flow of a program, including compilers of EVM bytecode to machine code.
The EVM has no subroutine instruction.  Instead, they are implemented with dynamic jumps.  We have been arguing about whether and how to remove dynamic jumps and add a subroutine instruction to the EVM for ten years now.

Author: duncancmt
Date: 2025-03-23T08:57:04.372Z

This sub-topic appears to be diverging from the main discussion, perhaps we ought to take it to another thread. Regardless, here’s some more discourse around the specific technical points raised before:




 pdobacz:




 duncancmt:

discover whether a call reverted due to out-of-gas


In EIP-7069 EXT*CALL discriminates between revert and oog of the callee (or any other failure consuming all callee gas) via the returned status code - 1 vs 2. Does that help? Would other status codes help?


Ahh, so THAT’s what that does. That doesn’t all the way solve the problem. As you can see in the first contract that I linked and in this conceptually-similar block in another contract for the same protocol https://etherscan.io/address/0x00000000000000cf9e3c5a26621af382fa17f24f#code#F1#L103 , finding out whether the next-childward context reverted exceptionally isn’t sufficient because we may need to find out whether a contract some number of contexts away from us reverted exceptionally. An example of this would be protocols with nested proxies, but the specific use case that this contract is designed for is DEX routing wherein a DEX may be a proxy (i.e. the context stack may be MultiCall → router (generic) → router (specialized) → DEX (upgradeable proxy) → DEX (minimal proxy) → DEX (implementation) → oracle (proxy) → oracle (implementation) [yes, this is a real context stack that I’ve encountered in production] and we want to make sure that the oracle got enough gas). In the example, we’d just set contextdepth = 7.
I’m not sure if there’s a good way of retrofitting this into the existing EIP in a way that isn’t intrusive, but I would appreciate a suggestion for how to support this use case. I think that @pcaversaccio hit the nail on the head on HackMD:



 pcaversaccio:

Due to the 63/64ths rule, simply “sending more gas as part of the transaction” doesn’t fully resolve the issue, as execution remains gas-dependent . The 63/64ths rule means a subcall’s success or failure depends on the gas provided to the current call context, affecting the current context’s outcome.






 pdobacz:




 duncancmt:

If we can only forward 63/64 of the gas, there’s no way to ensure that the “liquidation” portion of the operation has enough gas if the “wind down” portion refuses to participate


What if EXT*CALL allowed to customize the gas forwarding rule to a relative amount, i.e. forward “x/64th”? This is an draft idea which floated recently, not fully sure if viable yet.


I think that solves the problem in the case that you know the relative gas consumption of the pre- context in terms of the post- context, but that may not be sufficient in general. Perhaps a more elegant solution would be to forward gas (up to) some proportion of the block gas limit?

Author: benaadams
Date: 2025-03-23T12:19:17.091Z

middlemarch:

it seems problematic for common patterns that rely on “push” Ether transfers.


This is resolved by the PAY opcode slated for EOF devnet-2

Author: msoos
Date: 2025-03-25T13:26:15.795Z

Hi,
I work on hevm, a symbolic execution framework for EVM with over 5k commits. What I can say is that EOF will significantly lower the burden of doing formal verification of contracts. And there’s some really good reasons why that’s important. Hacks are an issue. But so are bugs (e.g. funds accidentally locked in). All serious crypto systems do formal verification of their code, be that AAVE, Uniswap, etc. These are not small players, and I’m pretty sure some people on this very thread trust these systems with some serious money. If you want these, and similar systems to thrive, you need to make sure they can be formally verified. EOF helps with that in a big way. I don’t think I need to go into details of what’s wrong with no separation of code and data, and basically impossible-to-disentangle control flow graphs. But I will anyway. It’s hard. Sometimes very hard, and sometimes impossible without human help (which can not only be costly, and delay verification work, but can introduce errors). Now, of course, if you are willing to spend a few million USD, Certora will disentangle that for you, no worries. But… innovation in the application space will suffer for it due to the delay, uncertainty, and monetary barrier it introduces. Furthermore, it unnecessarily raises the barrier of entry for tools that perform formal verification of contracts – and it’s already a pretty high bar.
I can’t comment on many of the things that are said here, and I don’t want to – they are outside the scope of my expertise. What I am an expert in is formal verification (wrote a SAT solver, and a model counter that are quite widely used), and I worked a lot in the IT security space (at one point having written code that broke >60% of all car anti-theft systems on the road). Based on these experiences, my opinion is that (1) we need formal verification or bugs will slip through and (2) without EOF, formal verification of contracts is gonna keep on being harder than it needs to be.
Just my 2 cents,
Mate
PS: I am also in favour of (1) mature and  (2) well-thought-through proposals that (3) solve the CFG & data/code separation issues that (4) have a serious chance of being accepted and implemented. As they say: “Scientists are treacherous allies on committees, for they are apt to change their minds in response to arguments”.

Author: cameel
Date: 2025-03-27T12:21:31.968Z

Here’s Solidity’s perspective: The Case for EOF | Solidity Programming Language

Author: sbacha
Date: 2025-03-28T03:49:54.570Z

ngl I just found out about this website: https://evmobjectformat.org/

Author: sbacha
Date: 2025-03-28T03:54:28.761Z

charles-cooper:

I am familiar with the Vyper codebase,


what an argument, we would hope so

Author: gcolvin
Date: 2025-03-28T20:25:01.804Z

I have been hearing similar observations and complaints from formalists and auditors for ten years now.  Currently the worst case time for tracing the control flow of an EVM program is quadratic in the size of the program.  That is impossibly slow at initialization time, and a huge obstacle offline.  EOF fixes this.

Author: kladkogex
Date: 2025-04-01T00:19:05.421Z

Well, the EVM today is an ecosystem of many projects, most of which lack the resources or motivation to implement this. It’s unclear what the purpose is, since most people are satisfied with the current state of things.
Blockchains are meant to be immutable, with as few changes as possible—just look at Bitcoin.
The guiding principle should be making small changes with high impact. This, on the other hand, is a major change with minimal benefit.
I imagine what would Linux Torvalds say if Linux would make kernel API changes like this

Author: 0xTraub
Date: 2025-04-01T16:04:51.269Z

I respectfully disagree with your definition of immutability. The principal of immutability applies to the ability to retroactively modifiy transaction history or contract bytecode, but not the rules of execution themselves. If a consensus can be reached about modifying EVM behavior without requiring that the existing state and chain history be modified then it should be implemented.
I further agree with the solidity team’s argument that it is too soon to seriously consider protocol ossification of the execution layer. While there is a debate to be had, it cannot be unanimously declared that Bitcoin’s decision to do such has been perfect to justify the same on Ethereum just yet.

Author: kladkogex
Date: 2025-04-20T13:29:56.476Z

0xTraub:

it cannot be unanimously declared that Bitcoin’s decision to do such has been perfect to justify the same on Ethereum just yet.


Hey Traub
I agree with you that Ethereum is not Bitcoin—because it needs to innovate. But there has to be a balance.
Bitcoin is a store of value because people can reasonably save for retirement, knowing that Bitcoin won’t change. Every time Ethereum changes, it undermines that same store-of-value narrative. Too much change over the past few years has significantly damaged ETH’s value relative to Bitcoin.
Moreover, changes come at a high cost to the Ethereum ecosystem, especially for smaller projects that are EVM-compatible. Most of these projects are stuck on much older versions of the EVM and Solidity.
Changes should originate from users. They should be voted on and implemented slowly and minimally. I’m not aware of any users who have asked for drastic changes to the EVM format.
If such requests do exist, they need to be quantified and documented. There must be a clear process for expressing different points of view and voting on them.

Author: 0xTraub
Date: 2025-04-25T15:33:10.742Z

While I don’t believe this forum is the correct place to discuss narratives about value capture, I disagree with the notion that change is solely a negative, especially when in many cases it can enhance the utility of Ethereum. It would not make sense to argue that EIP-1559 or the merge undermined the value of ETH.


Yes, concern about impacting smaller projects that are EVM-compatible is warranted, but the versioning schemes implemented by EOF do aid in resolving that by ensuring that future EVM upgrades are backwards compatible. I think the debate over SELFDESTRUCT illustrates this well enough.


If by users you mean validators then they can “vote” on this by choosing not to upgrade their nodes to latest versions. End-users who submit transactions don’t necessarily care about the format of the EVM itself. The majority don’t know what the EVM is, but they do care about new features for their transactions, and security, both of which EOF would have a positive second and third order effect on. If we’re going by what end-users specifically have asked for then most of the ETH roadmap would go away and we’d be spending all our time arguing about how to pump the price rather than making Ethereum better.

Author: kladkogex
Date: 2025-04-25T16:15:02.335Z

0xTraub:

While I don’t believe this forum is the correct place to discuss narratives about value capture


Hey Traub,
At the end of the day, users want Ethereum to be truly useful.
Would you agree that for most users, Ethereum is first and foremost a cryptocurrency and a store of value? They want it to have decentralized governance and a sound economic model — core principles that have always defined Ethereum’s appeal.
Are you suggesting that we should censor people on this message board simply for expressing these widely held views? If so, we would end up silencing 99% of Ethereum users — which hardly seems aligned with the spirit of decentralization and open dialogue.



 0xTraub:

The majority don’t know what the EVM is, but they do care about new features for their transactions, and security, both of which EOF would have a positive second and third order effect on.


Which specific new features are you referring to?
Let’s discuss them and figure out the minimum set of changes needed to implement this.



 0xTraub:

If by users you mean validators then they can “vote” on this by choosing not to upgrade their nodes to latest versions.


In most cases, when we speak of “users,” we mean paying customers. In the context of Ethereum, those paying customers are the people who send transactions. Would you agree? These users, in my understanding, want Ethereum to be fast, decentralized, and secure.
Stakers, on the other hand, deploy capital and are best thought of as investors. Their goals are different: they seek to see the value of the Ethereum token appreciate, and they expect staking rewards — which are derived from a combination of inflation and transaction fees.
Ultimately, the moral responsibility of Ethereum is to serve these two groups: users and stakers. The people employed by the Ethereum Foundation, as well as developers, researchers, validators, and others, are, in essence, paid to ensure that users and stakers are happy.
In nearly every corporate structure — for example, Microsoft — owning even a single share gives you the right to vote. The overwhelming majority of decentralized projects similarly have formal voting mechanisms. In fact, Ethereum is the only major project I am aware of that has no such formal governance system. In corporations like Microsoft, shareholder interests are protected by corporate law. In the decentralized world, where formal legal structures don’t exist, we rely instead on moral principles. And by those principles, if someone owns a portion of Ethereum, it seems reasonable — even necessary — that they should have a voice in its governance. Would you agree?
Vitalik Buterin himself has written extensively about quadratic voting, DAOs, and new forms of decentralized governance. Yet, when the community asks the Ethereum Foundation about governance, the response has been an uncomfortable and persistent silence — stretching over years.
This highlights another unfortunate reality: not only is it impossible to vote, but it’s also nearly impossible to even get a response to basic questions.
For example, if I buy a single share of Microsoft, I can attend a shareholder meeting and ask a question. In contrast, there’s no real mechanism for engaging with the Ethereum Foundation. Devcon sessions don’t allow for open Q&A. When submissions to Devcon are rejected, the submitters receive no feedback — not even a single line.
There’s also no straightforward way to report a security vulnerability to the Ethereum protocol, no structured incentivized testnets, and I’m not even talking about actually getting a bounty paid.

Author: 0xTraub
Date: 2025-04-25T16:25:20.909Z

Is it a store of value first and foremost? I would argue that Eth’s primarily value is derived from its utility in accessing decentralized computation, and if that is the case then EOF stands to enhance that by enabling the acceleration of ethereum’s base-layer development. I think that it is possible to have a sound economic model and still innovate, especially as EOF is a technical not economic upgrade.
If users want Ethereum to be useful, then we need to add new features, and the lack of things like versioning schemes or bytecode structure makes it more difficult to add those new features. I go back to selfdestruct because figuring out how to solve that issue is critical to implementation of the verge, which users do benefit from (more decentralization and security, lower validator requirements, etc).
I believe EIP’s such as EVMMAX are in the discussion as well as being a benefit of EOF which would enable new applications not currently feasible in the EVM (although I may be wrong about that my knowledge of the subject is limited).
I’m not suggesting that we censor anyone, you’re free to post whatever you want, I’m merely pointing out that this thread was intended for discussions of the technical aspects of EOF and politely ask that we stay on topic.