# "Additive EOF" -- Fusaka Proposal

*See also [EOF Fusaka Options](https://notes.ethereum.org/@ipsilon/eof_fusaka_options).*

This proposal aims to improve the EVM by **adding valuable functionality** while **minimizing breakage**. It recognizes the most likely outcome that EOF will indefinitely coexist with Legacy EVM, and as a result **does not attempt to remove abilities** that EOF contracts would nonetheless be able to work around.

### General Arguments for EOF

- Structured containers are a better foundation for tooling than unstructured bytecode and unreliable heuristics.
- Structured control flow is significantly better for static analysis.
- Stack and code validation at deploy time reduce EVM runtime overhead.
- Higher level constructs (functions, subcontainers, data), relative jumps, and expanded stack access make compilers simpler and easier to implement.
- Instructions with immediates can provide rich functionality efficiently. *(Some disagree that immediates require EOF.)*
- Non-introspectable contract code grants more flexibility for VM upgrades.

### Selection Criteria for this Proposal

- The upgrade should contribute to the benefits listed above.
- Developers should be incentivized to migrate to EOF by improved tooling as a result of the upgrade.
- Use and maintenance of Legacy code must remain viable. Existing libraries and tools should be able to support both Legacy and EOF in the medium term without too high a maintenance burden.
- Compilers for high level languages (Solidity, Vyper) should be able to implement an EOF target in addition to the current Legacy target.
- Contract code written for Legacy may require minimal changes to be compiled for EOF.
- It should be possible to write contract libraries that (with a single codebase) can be compiled for both targets with equivalent semantics.
- Legacy instructions/abilities may be made unavailable to EOF contracts only if they are not recoverable by dispatching to Legacy code, so that the effort has a real payoff.

### Specification

#### Included

- EIP-3540: EOF - EVM Object Format v1
- EIP-3670: EOF - Code Validation
- Only banned instructions: `JUMP`, `JUMPI`, `PC`, `CODESIZE`, `CODECOPY`
- EIP-4200: EOF - Static relative jumps
- EIP-4750: EOF - Functions
- EIP-5450: EOF - Stack Validation
- EIP-6206: EOF - `JUMPF` and non-returning functions
- EIP-7480: EOF - Data section access instructions
- EIP-663: `SWAPN`, `DUPN` and `EXCHANGE` instructions
- `EXCHANGE` could be excluded
- EIP-7620: EOF - Contract Creation
- EIP-7834: Separate Metadata Section for EOF
- Nice to have but could be excluded
- EIP-7873: EOF - TXCREATE and InitcodeTransaction type

#### Excluded

- Since gas introspection (`GAS` and `CALL` instructions) remain available:
- EIP-7069: Revamped `CALL` instructions
- EIP-5920: `PAY` opcode
- Since `EXTCODECOPY/HASH` remain available:
- EIP-7761: `EXTCODETYPE` instruction
- EIP-7880: EOF - `EXTCODEADDRESS` instruction
- EIP-7698: EOF - Creation transaction