EIP-7960: EOF - Extended types section

Extend EOF container's types section with an extra type parameter.

Metadata

Status: DraftStandards Track: CoreCreated: 2025-05-28

Authors

Wei Tang (@sorpaas)

Requires

EIP-3540

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This EIP extends the definition of types_section in EOF format (EIP-3540) with an additional type parameter.

Motivation

An additional type parameter allows the EOF EVM interpreter to identify the "type" of a code section. This allows the interpreter to "interpret" each code section differently, allowing EOF function calls to, for example, invoke pure EVM64 code or even later support RISC-V.

Specification

types_section, as defined in EIP-3540, is changed to be of the following format (type, reserved, inputs, outputs, max_stack_increase). type is uint8, reserved is 24 bits, and inputs, outputs, max_stack_increase are defined as uint8, uint8, uint16 respectively, the same as before. The only valid type defined in this EIP is 0x01. Additional EIPs may be defined for other code section types.

version, as defined in EIP-3540, is changed to 0x02, to avoid the backward compatibility issue if a third-party chain already deployed EOF in production.

In EOF container, the following validation rules are added:

If a type in types_section is not of an known type, then the validation fails.
reserved in types_section must be all zeros.

Rationale

The new type parameter allows a contract to "dispatch" to different variants of the interpreter to better suit its need.

The portion of the code where it mainly interacts with Ethereum addresses, balances, storages may run "normal" EVM.
The portion of the code that is computationally heavy may run faster EVM64, but loses the ability to directly interact with Ethereum addresses and balances.

Allowing this type to be defined for each code section ensures that a contract remains conscise -- it can quickly switch between its computational needs and system/runtime needs.

reserved is added to types_section to maintain the proper padding. Each item in types_section is now 64 bits in total.

Backwards Compatibility

As we know, EOF, including EIP-3540, was extremely close to being deployed before it was decided to withdraw from Fusaka. To avoid the issue that some third-party chains have already deployed EOF in production (given the state of EOF we can consider this to be likely), we bump version of EOF to 0x02. 0x01 is now invalid.

No other backward compatibility issues found.

Test Cases

To be added.

Reference Implementation