Thread by @lightclients

Ethereum has recently seen substantial changes, such as the move to PoS & EIP-1559. However, the EVM looks mostly the same.

This may finally change with the Ethereum Object Format (EOF), which is likely going into Shanghai. It will be the EVM's biggest change since genesis.

EOF is comprised of several EIPs. Although they aren't "all or nothing", we're considering them as an entire set. The EIPs are:

EIP-3540: EOF v1
EIP-3670: Code validation
EIP-4200: Static relative jumps
EIP-4750: Functions
EIP-5450: Stack validation

EIP-3540: EOF v1

This EIP introduces the EOF container. This includes an EOF header and several EOF sections (code, data, types). This sets up the scene to allow for EVM interpreters to interpret EOF contracts differently than legacy contracts.

EIP-3670: Code validation

This is the first EIP that uses the EOF container. It constricts code by validating certain properties such as (some come from later EOF EIPs):

* no deprecated/undefined op
* code ends in "terminating" op
* jumps are valid
* function calls are valid

EIP-4200: Static relative jumps

New control flow operations are added, RJUMP + RJUMPI. These ops take an operand (like PUSH) which points to a code location relative to the op to jump to. It costs less than its JUMP counterpart, because validation only needs to happen once.

EIP-4750: Functions

More control flow operations are added, CALLF and RETF. This introduces the concept of EVM functions aka subroutines. With this + 4200, we can fully remove dynamic jumps (JUMP/JUMPI).

It also introduces type sections which essentially define the function signature. Since there is only 1 type in the EVM (uint256), the signature is just a tuple of inputs and outputs.

A big win from this EIP is better static analysis + no more JUMPDEST analysis (expensive).

EIP-5450: Stack validation

The last EIP of EOF introduces a static validation requirement for the stack. Currently, each loop of the interpreter must determine if the op it is about to execute will underflow/overflow.

With 5450, the code will be analyzed at deployment to determine the "maximum stack size" (MSS) for each code section and determine if any underflows occur. The contract deployment would fail if an underflow is encountered.

The MSS for each function is later used to extricate the interpreter of checking overflows at each op. Instead, the potential for overflow is only checked when changing code sections with CALLF. This will marginally improve the speed of the interpreter loop.

Generally speaking- the stricter requirements of validation are expected to improve the performance of interpreter-based EVMs and make the EVM more amenable to JIT compilation of bytecode.

The EOF suite of EIPs is result of many years of work by @teamipsilon (e.g. @alexberegszaszi, @gumb00, @chfast, etc).

Not only will it bring substantial improvements to the EVM on introduction; it also finally adds versioning to EVM code.

Although it is just the beginning of EOF, I am excited to see what an "upgradable" EVM will allow us to do. I can already imagine that it can improve the experience of working with L2s that aren't perfectly EVM-compatible.

There could be some reserved "L2 versions" of EOF where L2s can experiment - but at the same time provide an L1 EVM version with identical semantics.

If you are able to, please review the EOF EIPs and share any feedback on their respective eth magicians threads. The exact set of EIPs in Shanghai is still being determined, but community support of EOF can go a long way.

There is an EOF breakout room with core developers tomorrow where we'll discuss a few open questions: github.com/ethereum/pm/is…

In the next few weeks, we'll have a devnet with EOF. I'll share more details when the time comes. In the meantime, here are some other relevant links:
* github.com/ipsilon/eof
* notes.ethereum.org/@ipsilon/eof1-…
* github.com/ethereum/go-et…