Prague Headliner Feature - EOF

EVM Object Framework

Who is working on EOF?

Team Ipsilon� EF funded team focusing on EVM improvements

Execution Clients� Geth, Besu, Nethermind, and evmone have various implementations

Compiler Teams� Solidity and Vyper have had significant input

Smart Contract Community� SSTORE2 teams have been advocating for their use cases

What is EOF?

EOF is a container format for EVM code

EOF requires code and data separation

EOF requires all code be valid

EOF’s structure fixes a number of EVM evolution problems

Allows new opcodes with immediate arguments

Prohibits problematic behavior

How does it interact with the existing EVM?

EOF will operate in parallel to legacy EVM smart contracts

EOF and Legacy EVM differ in packaging and feature set

EOF and legacy EVM code share almost all the same semantics� Opcodes and Stacks� Storage and Accounts� Message Frames� Memory and Transient Memory

What are the major features of EOF

The EOF container itself

Static (not dynamic) jumps

Subroutines

Code and data separation

Remove code introspection capabilities

Remove gas observability capabilities

Code and Stack validation

Maybe prepare for address space expansion?

EIP-3540: EOF - EVM Object Format v1

Defines a container format for EVM bytecode

Header Section

Types Section (Stack validation data)

Code Sections

Subcontainer Sections (CREATE3 support)

Data Section

EIP-4200: EOF - Static relative jumps

Ban Dynamic Jump Opcodes (JUMP, JUMPI), as well as PC opcode

Introduce Opcodes with immediate mode targets (RJUMP, RJUMPI)

Add a vector jump operation (RJUMPV)

EIP-4750: EOF - Functions (aka code sections)

Subroutine support

Leverages the container format

3 Opcodes - CALLF, RETF and JUMPF (tail recursion support)

Stack height restrictions are enforced with opcodes

EIP-663: Unlimited DUP and SWAP

Intent of the original EIP was to allow full stack access

EIP has been reformulated to support immediate instructions

Adds DUPN - depth of dup comes from immediate argument

Adds EXCHANGE - Allows swap of any 2 stack positions

Old DUP and SWAP instructions remain

​

EIP-7480: EOF - Data section access instructions

Read half of the “Remove code introspection capabilities” goal

Contract Code is never written to EVM memory or account storage

Bans CODESIZE, CODECOPY, � EXTCODESIZE, EXTCODECOPY, EXTCODEHASH

Adds DATALOAD, DATALOADN, DATASIZE, DATACOPY

Legacy EVM will not be able to EXTCODE* into EOF contracts

EIP-pending: EOF CREATE3 and CREATE4

Write half of the “Remove code introspection capabilities” goal

Contract code is never created from EVM memory or account storage

Bans CREATE and CREATE2

Adds CREATE3, CREATE4, RETURNCONTRACT

CREATE3 gets code from the EOF container

CREATE4 gets code from new field in a new transaction type

RETURNCONTRACT opcode to permit adding data to the data section

EIP-7069: Revamped CALL instructions

Handles the “Remove gas observability capabilities” goal

Ban GAS, CALL, STATICCALL, DELEGATECALL and CALLCODE

Add CALL2, STATICCALL2, DELEGATECALL2� Remove gas stack operand� Remove output location stack operands� Also available to Legacy EVM!�

This makes increasing the gas limit in the top level transaction the answer to all EOF gas schedule changes.

EIP-3670: EOF Code Validation

Bans dead code, all code must valid opcodes or immediate data

Bans dead code sections, all code must be executable

Requires opcode immediates to refer to valid values� Jump destinations� Code Sections� Containers

​

​

This code validation simplifies adding future opcodes to EOF

EIP-5450: EOF Stack Validation

Code is analyzed to ensure stacks cannot grow out of bounds

Special interactions with code sections (CALLF/JUMPF)

Validation values are added to the container

​

Good for ZK and transpiling EOF code to other targets

Miscellaneous Notes

EOF and Legacy EVM can freely call each other� Except EOF cannot DELEGATECALL legacy

SELFDESTRUCT is banned

EOF and Legacy EVM cannot cross CREATE� EOF factories can only create EOF contracts, same with Legacy EVM

EOF Opcode Changes Summary

Replaced Removed Added

* Starred instructions can also be exposed in Legacy EVM

Testing

Explicit Reference Test Generation

Client teams can help out testing team with test cases

Differential EVM testing

Martin’s, Marius’ & Guido’s differential EVM fuzzers are amazing

Martin had a container fuzzer for Big EOF (Shanghai)

No complex CL/EL interop needed

EVM execution is self contained, no network or multithreaded protocols

Wen EOF?

Proposal:

Headliner for Prague

3-6 months after Cancun

BACKUP SLIDES

Evolution modes for the EVM and EOF

Compatible changes (non-breaking)

​

Add new functionality or features without removing or altering other functionality or features

​

Make invalid byte sequences valid

​

Must execute all prior contracts the same

�Doesn’t require an contract version bump

Incompatible changes (breaking)

​

Can remove or alter functionality

​

May not have an equivalent feature set

​

May make valid semantics invalid

​

May not execute prior contracts the same

​

May requires an contract version bump

Why Immediates? A validation story.

0xE0 - RJUMP

​

“Immediate” bytes

forms an int16

(Like PUSH2)

​

E00080 - Jump forward� 128 bytes��E0FF80 - Jump backward� 128 bytes

​

61018065 - PC=0x100� Legacy forward�

608065 - PC=0x100� Legacy backward

​

Why Immediates? A validation story.

​

JUMPDEST instructions cannot be in “immediate data”

​

i.e. the contents of PUSH instructions

C9

2A

61

61

01

00

EF

E0

5B

FF

EVM Code

Opcodes

Immediate Data

“Invalid Code”

Why Immediates? A validation story.

​

Adding opcodes with new immediate data changes the interpretation of existing code

C9

2A

61

61

01

00

EF

E0

5B

FF

EVM Code

Opcodes

Immediate Data

“Invalid Code”

Features on the “Bubble”

EXTDATACOPY

Copy data from EOF and legacy

contracts.

CALLFI, JUMPFI

Conditional section branching

RETURNDATALOAD

Improves new calling opcodes

​

Address space expansion (ASE)

All opcodes handling addresses

would not trim to 160 bits/20 bytes

Each of these features is not essential for a fully functional EOF, but address size and UX regressions.

​

Most have workarounds (compiler or contract design) that increase contract size or that make UX worse.

​

​

ASE is a breaking change under consideration to “create space” for other features.