All Core Devs - Execution (ACDE) #209

[timbeiko]

All Core Devs - Execution (ACDE) #209

• April 10, 2025, 14:00-15:30 UTC
• 90 minutes
• Stream: https://youtube.com/live/_j4XPNQxDPc

Agenda

• Pectra
  • EIP-7702 receipts
    • Add authorization status to EIP7702 authorizations in transaction receipt execution-apis#640
    • https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code/19923/382
• Fusaka
  • Scope finalization
    • PFI vs. CFI vs. SFI
    • Client Team preferences
      • Besu
      • Reth
      • Erigon
      • Nethermind
      • Geth
    • Synchronous vs. async presentations
      • EIP-7819
      • EIP-7918
• Reconfiguring AllCoreDevs

---

Facilitator email: tim@ethereum.org

[github-actions]

Note: Meeting already exists for this call series. Skipping event creation.

Discourse Topic

• Discourse topic created : https://ethereum-magicians.org/t/all-core-devs-execution-acde-209/23373/2

⚠️ Failed to create Zoom meeting. Please check credentials.

Calendar Event

• Meeting already on Ethereum Calendar

RSS Feed Updated

Telegram Notification

• Sent message to Ethereum Protocol Updates channel

[anderselowsson]

I would like to highlight EIP-7918, which is PFI for Fusaka.

[charles-cooper]

Perhaps this is one ACDE session too late, but I would like to state Vyper's formal position on EOF, which is that, as Vyper's lead developer, I oppose it. There are multiple reasons for this, which I can go into.

The first reason is that Vyper doesn't actually need any features of EOF. For example, Vyper does not suffer from stack-too-deep, and therefore doesn't need EIP-663. This was originally because Vyper allocates variables in memory, but in recent releases in our experimental Venom pipeline, we lift a substantial number of variables to stack. There is theoretically a limit to the number of variables you can lift to stack, but we don't hit it in practice. Also, since Vyper's memory model is safe, we can spill to memory, it's not a language-defining limit.

As for the other features that EOF adds, the story is more or less the same - they are at best nice-to-have, but not a requirement.

Therefore, EOF creates a huge amount of forced work for us, with practically no benefit. (There are obviously benefits from improved gas pricing, but those exist for any proposal which improves gas pricing -- we are proponents of EIPs 7609, 5920 and 7923, for example). Since EOF is a container format with additional constraints on control flow and stack validation, support for it is substantially more complex than previous opcode additions, which are supported by simple opcode selection and only require a few lines.

Additionally, this is not a one-time burden, but an ongoing maintenance burden. On the previous ACDE call, a geth maintainer said that it's "only" 1000 additional lines of code for geth. That may be fine for clients, but clients don't need to maintain a compiler. Solidity claims in their article (https://soliditylang.org/blog/2025/03/27/the-case-for-eof/) that

Ultimately, this is the cost of bad design choices in a system that demands strong backwards-compatibility. The question is if the cost is justified. For the ecosystem above the clients, EOF is an improvement across the board. Universal adoption will make the legacy EVM irrelevant there.

The question is indeed if the cost is justified. As I stated before, Vyper does not derive substantial benefits from EOF. And how long will it take for chains to upgrade to EOF? This means that we will need to maintain code paths for non-EOF contracts, potentially for years. Since EOF is an entirely new format for bytecode, maintaining the additional code path is not simply a few lines to select opcode based on EVM target -- we need a whole new machinery for managing the bytecode output. And depending on the code generation pipeline chosen, we actually need to change existing code paths for the calling convention, breaking compatibility for consumers of our existing IR outputs.

The attitude by EOF proponents towards non-EOF contracts has been somewhat flippant, as if we "just don't need to think about it anymore". Since EOF removes gas and code introspection and wholesale replaces existing creation modes, user code necessarily needs to be ported to be EOF-compliant in many cases. There is even discussion of not adding PAY to non-EOF EVM (https://ethereum-magicians.org/t/eof-implementors-call-70-april-2-2025/23212/3). This means that users will write code which targets EOF which is therefore not deployable on EVMs without EOF, or worse, the compiler hides the changed semantics depending on compilation mode, which is dangerous in an even more insidious way. "The user can just supply a flag specifying EOF" is a fiction which is directly contradicted by EOF proponents' attitudes towards non-EOF EVM.

EOF breaks so many app developer assumptions that features are continually being proposed and added to it to fix these problems -- PAY, HASCODE and TXCREATE to name a few, and now CALL_GAS_SPLIT. Rather than stepping back and wondering whether this indicates a problem with the overall approach, the response from the designers has been to double down and add as many features as needed to EOF to achieve feature parity with the features it removed in the first place.

The all-or-nothing approach of EOF (and the attitude of EOF proponents that future upgrades to the EVM will only apply to EOF) gives us pressure to ship EOF as a full package alongside the next hard fork, instead of being able to add the features incrementally, as it makes sense to implement them.

Finally, shipping EOF contains a hidden cost in that it takes attention and energy away from other improvements which the EVM badly needs, such as fixing memory and transient storage pricing (and with it, lowering the barrier to protecting against reentrancy), fixing the 63/64ths rule, code size limit improvements and PAY opcode. For instance, fixing memory pricing is at least as impactful as all of EOF in terms of the impact to compilers, since it allows us to implement proper call stack / heap separation. It also has an immediate and tangible impact on developers, who can start to use more memory for memory heavy use cases, whereas EOF has no tangible impact for developers -- if anything, it worsens devex, since they need to manage two mental models of the EVM, instead of just one.

I don't disagree that adding static jumps and subroutines to the EVM would be useful. This only requires EIPs 4200, 2315 and BEGINDATA (or some variant of it which can actually encode data sections). These are much more preferable for us, provide the same codesize and gas performance improvements (in fact, strictly better performance improvements, since there is no header overhead, and there is no ban on global jumps, which are useful for compilers), and have a simple implementation in the compiler via opcode selection, rather than needing to conform to an entirely new container format and validation rules.

In my opinion, moving forward with EOF would be a serious mistake for Ethereum and hurt its competitiveness. It demonstrates to app and tooling/compiler developers that we do not care about the stability of the VM, and permanently (or at least for multiple years) increases the maintenance burden of apps and compilers across EOF and non-EOF ecosystems. The question is not about ossification, but whether we are willing to rug users who are building on the EVM at the drop of a hat.

I have been hesitant to take a firm stance in opposition of EOF since I personally know many of the proponents and designers of EOF. I know there is a feeling that there is a need for it and that many people have spent a lot of time on it. However, I think this issue is too existentially important for Ethereum for me to stay silent on.

There is a conception that "compiler authors want EOF" as was stated on the last ACDE call. It's not true -- at least for Vyper, we do not want it.

[shemnon]

Charles, thank you for articulating Vyper’s stance on EOF with such detail—it’s a valuable perspective, and I appreciate the depth of thought here. Navigating ecosystem-wide changes like EOF is tough when stakeholders like Vyper and Solidity have divergent needs, and I recognize that this puts us in a position of making hard calls.

I want to clarify a key point: EOF is an opt-in container format, and legacy EVM remains fully functional for non-EOF code. Beyond basic interoperability (e.g., reading EOF contracts), Vyper’s existing pipeline doesn’t need to change, and there’s no mandate to adopt EOF. That said, I hear your concern about the practical pressures—like maintaining dual code paths or supporting users across EOF and non-EOF chains. We’re committed to minimizing disruption as chains adopt EOF over time.

On the flip side, teams like Solidity, hEVM, and Succinct see EOF as a major step forward—unlocking more efficient gas pricing, enhanced tooling, and a foundation for formally proven contracts. These gains aim to strengthen the ecosystem as a whole, even if they don’t directly address Vyper’s current needs.

I also take your point about opportunity costs: changes like memory pricing and transient storage costs are critical. The EVM Resource Pricing Working Group’s ongoing work is driving these changes independent of the EOF efforts (last meeting notes here). They are also addressing larger issues like whether we should adopt a multi-dimensional gas model. Design decisions like banning gas introspection are intended to give them room to innovate.

The tension here is real — EOF’s bold design decisions do push the ecosystem toward a new standard, and that shift won’t be painless. But I believe the long-term payoff justifies the transition.

I am strongly of the opinion that a container format with strong validation is essential for the future competitiveness of the EVM.

I look forward to Vyper's continued collaboration in the EVM. Even though EOF has not been able to accommodate every request, Vyper has a history of providing valuable feedback and I would like to see that continue.

[charles-cooper]

I want to clarify a key point: EOF is an opt-in container format, and legacy EVM remains fully functional for non-EOF code. Beyond basic interoperability (e.g., reading EOF contracts), Vyper’s existing pipeline doesn’t need to change, and there’s no mandate to adopt EOF. That said, I hear your concern about the practical pressures—like maintaining dual code paths or supporting users across EOF and non-EOF chains. We’re committed to minimizing disruption as chains adopt EOF over time.

In practice, we do need to adopt the new pipeline to be competitive. This is because the pricing and opcode inclusion is anti-competitive against non-EOF EVM. The attitude I have heard expressed on ACDE and EOF calls is very much that, going forward, ACD will not ship any more improvements to non-EOF EVM. So in practice, non-EOF EVM will be a no-go as a compilation target for mainnet. But the catch-22 for those of us who have to maintain tooling is that, since EOF won't immediately see universal rollout, we still need to maintain those non-EOF code paths, potentially indefinitely!

On the flip side, teams like Solidity, hEVM, and Succinct see EOF as a major step forward

Besides Solidity, which has more complex needs, I'm pretty sure hevm and Succinct see the most benefit solely from adding static jumps to the EVM. As I mentioned, static jumps would be useful, but can be implemented with just the three EIPs mentioned. These three EIPs are roughly 2 orders of magnitude(!) -- 10-50loc vs ~1k loc -- simpler for us to implement than the EOF container format.

Also, how much of the improvements cited by hevm and Succinct can be achieved with algorithmic/heuristic improvements or more control-flow graph information provided by the compiler? Can these improvements be achieved in any other way?

[shemnon]

The attitude I have heard expressed on ACDE and EOF calls is very much that, going forward, ACD will not ship any more improvements to non-EOF EVM. So in practice, non-EOF EVM will be a no-go as a compilation target for mainnet.

There hasn't been a formal policy for that yet. The best argument for only adding new opcodes inside the EOF container is the claim that nobody will use them outside an EOF container. If Vyper has a commitment to use them outside of EOF (such as the PAY opcode) that is a compelling reason to extend the opcode outside the container and extend testing to cover those scenarios.

For PAY the best way would be for you to state in the PAY opcode eth-magicians discussion that you would like it outside of EOF containers. That should be a small lift for client devs, more of the impact will be in ensuring testing coverage is adequate.

As I mentioned, static jumps would be useful, but can be implemented with just the three EIPs mentioned

All of these also were proposed in the past (also see EIP-615) and rejected. EOF was written with those reasons for rejection in mind.

EIP-2315 does not prevent the natural flow of code from entering or exiting a subroutine context. While there is disagreement as to wether or not it is a good thing or a bad thing it was one of the technical arguments that people opposing it (including @lightclient ) found persuasive. EIP-4200 requires immediate data, which breaks the current jumpdest model, and would require a separae validation regime. BEGINDATA is the beginning of a container format, but builds it in a way that is not forward-looking in design.

I agree it is a simpler design, but for the problems they solve they are too simple and will inhibit good solutions to other issues the EVM faces.

[xrchz]

Since hevm's claim that they benefit from EOF is being used to justify the stronger claim that EOF is better for formal verification, I would like to state clearly that from the perspective of the comprehensive formal verification plans being executed in the Verifereum project -- and I would expect this to be the case for other ITP-based verification approaches -- EOF is a substantial cost with essentially zero benefit. The reasons echo some of those articulated by Charles: in our formal model of the EVM we will need to support both "legacy" EVM (already implemented) and EOF (waiting for a stable spec before we can implement it), which increases spec-writing, auxiliary proving, and proof-maintenance burdens for the forseeable future. This is not merely an additive change, it will most likely complicate the structure of the formal spec with the overhead of branching on whether we're dealing with EOF or not, plus the need to account for the interactions between EOF and non-EOF code. Looking ahead, it is also very worrying that the community is so willing to make major changes to the EVM that disrupt ongoing efforts to build up formal verification infrastructure (and all other kinds of tooling around the EVM beyond clients) and discourage long-term investments into building such infrastructure.

[yongqjn]

If possible, id like to propose a change to transaction receipt specifically for 7702 transactions

execution-apis - ethereum/execution-apis#640
ethereum-magicians discussion - https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code/19923/380

[charles-cooper]

I'd like to bring up a memory pricing change for discussion: https://ethereum-magicians.org/t/eip-7923-linear-page-based-memory-costing/23290

[AFDudley]

Sorry to butt in.

There hasn't been a formal policy for that yet. The best argument for only adding new opcodes inside the EOF container is the claim that nobody will use them outside an EOF container.

Wouldn't all the L2 and countless other chains that rely on the EVM and make up The Ethereum Ecosystem use these new opcodes? isn't the benefit of EOF that it makes interoperability for those chains easier in the long term? Don't they need a long term (5+ years) migration path? It's been a long time since I've been on an ACD call, but I imagine these folks are under represented on these calls?

I do agree that EOF opens the door to the EVM being feature frozen but support for win16 API in windows wasn't removed until 64-bit hardware failed to support the underlying processor features, or put another way all 32-bit Windows OSes supported the 16-bit API in its entirety. It's unclear when patches stopped being applied to win16. The EVM is no where near as mature as win16 was when win32 was released.

The community has the funds and the need to continue fully supporting both EOF and EVM until such time that a majority of mainnet traffic has shifted to EOF. This transition shouldn't be forced by kneecapping the EVM but because stakeholders realize true benefits from EOF and migrate naturally.

[msooseth]

Hi,

I can't talk for ITP-based approaches. My understanding is that most serious, industry-leading systems are all verified with non-ITP-based approaches such as Certora (Certora Prover), Runtime Verification (K-framework), and the like. These approaches would greatly benefit from EOF, as explained before.

[pipermerriam]

I recognize that EOF will be extra work for compiler teams to implement, but I don't see these as hidden work. In your post you mention other efforts such as resource repricing as being higher priority. EOF is the path towards us having the ability to do clean resource repricing as it removes gas observability which is one of the things that currently makes repricing difficult in the current EVM model.

I don't find the reasons outlined in this position against EOF to be compelling. I'm remain in favor of EOF.