Skip to content

Everything about the EVM Object Format (EOF).md

Latest commit

 

History

History
75 lines (51 loc) · 5.87 KB

Everything about the EVM Object Format (EOF).md

File metadata and controls

75 lines (51 loc) · 5.87 KB

Everything about the EVM Object Format (EOF)

The aim of this document is to serve as an explainer and collection of links about EVM Object Format. This is a living document, so updates and changes are expected.

Please leave comments on the Ethereum Magicians forum or the discussions URLs for the specific EIPs.

[toc]

Motivation

On-chain deployed EVM bytecode contains no pre-defined structure today. Code is typically validated in clients to the extent of JUMPDEST analysis at runtime, every single time prior to execution. This poses not only an overhead, but also a challenge for introducing new or deprecating old features.

Validating code during the contract creation process allows code versioning without an additional version field in the account. Versioning is a useful tool for introducing or deprecating features, especially for larger changes (such as significant changes to control flow, or features like account abstraction).

Two hard forks

In order to have strong guarantees that code looking like EOF1 is actually valid EOF1 code, we must a) introduce deploy time validation of all submitted contracts, and b) ensure that no such (malicious) contract is deployed before this feature is enabled on mainnet.

A solution to this is to first reject a specific starting byte for new contracts, then select the shortest prefix (starting with this byte) which does not exists in any already deployed contract, and finally use this as the prefix of the EOF format. This way it is not possible to encounter existing code "masquerading" as EOF1.

Timeline

London

EIP-3541 is rolled out, which rejects any new contracts starting with the 0xEF byte. After the forkblock, we'll inspect all existing code on chain to select the prefix.

Shanghai

The format described in EIP-3540 introduces a simple and extensible container with a minimal set of changes required to both clients and languages, and introduces the concept of validation.

The first tangible feature it provides is separation of executable code and non-executable data. This separation is especially beneficial for on-chain code validators (like those utilised by layer-2 scaling tools, such as Optimism), because they can distinguish code and data (this includes deployment code and constructor arguments too). Code and data separation can result in ease of use and significant gas savings for such use cases. Additionally, various (static) analysis tools can also benefit, though off-chain tools can already deal with existing code, so the impact is smaller.

Time permitting, we also would like to include EIP-3670 in Shanghai. That EIP extends EOF with deploy time validation of the code section, such that code using unassigned instructions or truncated PUSHes are rejected.

Cancun and later

We aim to provide a new extension, EOF2, which overhauls control flow. The currently considered ideas include:

  • Including a JUMPDEST-table (to avoid analysis at execution time) or removing JUMPDESTs entirely.
  • Introducing static jumps (with relative addresses) and jump tables, and disallowing dynamic jumps at the same time.
  • Representing functions as individual code sections instead of subroutines.

Note that some of these are mutually exclusive, and all of them need to be investigated for both technical complexity, benefits to Ethereum clients, benefits to users.

Potential other features for the future could include:

  • Requiring code section(s) to be terminated by STOP. (Assumptions like this can provide significant speed improvements in interpreters, such as a speed up of ~7% seen in evmone.)
  • Any feature needing multi-byte opcodes (without any workarounds).
  • Introducing a specific section for the EIP-2938 Account Abstraction “top-level AA execution frame”, simplifying the proposal.

Core Specifications/Explainers

Various Potential Use Cases

Additional Links

Implementations