EIP-7979: Call and Return Opcodes for the EVM

EIP-7979: Call and Return Opcodes for the EVM

Abstract

This is the smallest possible change to the EVM to support calls and returns.

This proposal introduces two new control-flow opcodes

  • JUMPSUB — jump to the PC on top of the stack
  • RETURNSUB — return to the PC after the most recent JUMPSUB

and restricts valid control flow to static uses of JUMP, JUMPI, and JUMPSUB.

Valid code will not execute invalid instructions, jump to invalid locations, underflow stack, or use unbounded stack in the absence of recursion.

3 Likes

This EIP is great! Puts an important part which EVM is missing that can have immediate benefits, reducing gas costs with backwards compatibility. This is awesome.

The main question right now (and the reason it’s still a draft PR) is whether we need an ENTERSUB code. You can find them all in one pass by marking the destinations of JUMPSUB, but that’s the hard way.

ENTERSUB means a little bit more development time, but it’s a worthwhile addition. It won’t add any new runtime behaviour, it just makes the structure explicit.

Bottom line, it’s a minimal addition with a lot of benefit.

Yes – it amounts to a form of JUMPDEST. It’s also not clear that a validation algorithm can be made to work efficiently without it. Unfortunately Max – the compiler expert who was working with me on that algorithm – died a few weeks ago.

Damn that’s terrible news, I’m sorry to hear about Max.

ENTERSUB makes even more sense now, if the validation algorithm becomes harder with it, then its an almsot obvious decision.

I’m not a compiler expert but I’d like to help however I can. Let me know if there’s a way I can move this forward.

Thanks.

What some people seem not to understand (and I don’t blame them) is the basics of control flow graphs, why they can be an essential tool for static analysis, how to extract them from machine code, why dynamic jumps can make extracting them go quadratic, and why – unlike most applications – we need to extract them in linear time. And of course – given that static analysis is anything you can do to code without actually executing it – how many important things are forms of static analysis, including symbolic execution, translating EVM stack code to register code for faster interpretation and compiling to machine code, proofs of EVM code correctness and more. There is an entire academic literature devoted to working around the problems caused by dynamic jumps.

All this amounts to two or three university courses, some of which I never took – I finished school in 1982 and learned most of what I do know on the job. So I’m not the best person to explain all of this, let alone briefly enough to fit in an EIP.

Honsetly this gave me a much clearer view of what it can do. I didn’t study control flow graphs formally either, but the way you framed it makes a good case for structured control flow and ENTERSUB.

I’d love to help maybe I can write a short draft that explains the CFG/static analysis angle in layman’s terms as supporting context for people(like me haha) so it’s easier to understand. Let me know if that’s useful happy to contribute however I can