EVM Control Flow — Foundational Concepts & Context

EIPs EIPs core
1

Discussion topic for EIP-8173
Currently unmerged at https://github.com/ethereum/EIPs/pull/11353

Update Log

  • 2026-03-27: initial draft

External Reviews

None as of 2026-03-27.

Outstanding Issues

None as of 2026-03-27.

1 Like
2

Thank you for elaborating on this topic. There’s a few more points that I think should be addressed by this document.

  1. As far as I can tell it is possible to compile (JIT or AOT) EVM bytecode to machine code, only that JUMP instructions may have to be compiled to dynamic dispatch, and stack over/underflow checks at basic block boundaries can’t in general be removed. What is not obvious to me is whether this negates the potential wins of compilation to machine code.
  2. Do the benefits of static jumps materialize even if the VM continues to support dynamic jumps?
3

Hello @frangio. EIP-8173 isn’t merged yet, so I won’t try to give a full response until it is.

  1. In your example, you can’t resolve and optimize the dynamic JUMP, so you have to directly translate it to a dynamic jump in the target code – if the target has one. If it doesn’t you have to generate some sort of if/else chain over every JUMPDEST in the source code. So it’s a nasty attack surface. Most CPUs have some sort of dynamic jump, but not all possible targets will.
  2. The full benefits of static control flow are only available to MAGIC code where all JUMPs have been validated at CREATE time to take a static argument. The reason to support them outside of MAGIC code is of course backwards compatibility.
4

One of the difficulties is while you can certainly compile the code; you can’t really optimize or analyse it beyond a certain point.

This is due to a single smart contract acting like a single function of 28kB with random jumps into every other control flow structure; which is a structurally very hard thing to reason about.

5

Right. There are any number of ways that the lack of structure hurts.