EOF Explained: What Developers Need to Know

Ethereum has undergone numerous upgrades recently, with the Ethereum Virtual Machine remaining fundamental to its architecture. In the upcoming Pectra upgrade, the core development team of Ethereum has announced the agreement on the inclusion of EVM Object Format (EOF) — An Improvement on EVM to innovate and improve user experience, developer experience, and performance across both Layer 1 and Layer 2.

In this article, we will learn about :

1. What is EVM Object Format (EOF)?

2. Why do we need EOF? (larger eco-system play)

3. EIPs and EOF Implementations.

4. How will it create a better Developer and User Experience

What is EVM Object Format (EOF)?

Firstly let us understand the basics of EVM and EVM bytecode. Ethereum uses EVM as a core component of the network; smart contract code written in high-level languages (eg Solidity) needs to be compiled into EVM bytecode to be able to run on the EVM.

Currently, on-chain deployed EVM bytecode contains no predefined structure. That means the data and the code are in the same instruction. For instance, in contracts like Uniswap, essential constants such as fees are embedded as data within the bytecode alongside the executable code. This requires runtime validation for each contract interaction, resulting in repeated overhead during execution, making transactions slower and more expensive.

To summarise, here are the challenges in the Current EVM:

• Runtime Overhead

• Flexibility and Upgradability

• Limited Static Analysis and Formal Verification

What is EOF and Why do we need it?

The EVM Object Format (EOF) is a structured format for Ethereum bytecode that separates executable code from data, enhancing efficiency and reducing overhead.

EOF solves the above mentioned challenges by introducing a well-structured format for EVM bytecode. It separates code from data, enabling Ethereum clients (like Geth or Besu) to perform one-time validation during deployment rather than repeating validation during every execution. This process, particularly JUMPDEST analysis (used to ensure valid jump destinations in the bytecode), consumes both time and gas, leading to slower transactions and increased costs.

Now let us look into EOF v1 and its EIPs.

EIP-3540 introduced EOF Version 1. The EOF container consists of a header and body with the header containing the version of EOF and metadata about the contract, while the body contains the actual contract bytecode. With these components, the Ethereum client can more efficiently organize and execute the contract without needing repeated validations.

Here is the sample structured format of the EOF container:

container := header, body
header := 
    magic, version, 
    kind_type, type_size, 
    kind_code, num_code_sections, code_size+,
    [kind_container, num_container_sections, container_size+,]
    kind_data, data_size,
    terminator
body := types_section, code_section+, container_section*, data_section
types_section := (inputs, outputs, max_stack_height)+

Key Features of EOFv1:

1. Structured Bytecode: EOF divides bytecode into defined sections, including headers, code, and data — which makes it easier to manage and read.

2. Versioning: Supports version control, ensuring compatibility with future upgrades and deprecations.

3. One-time Validation: Bytecode validation occurs during deployment, reducing runtime overhead and improving contract execution efficiency.

Related EIPs and Implementations

Several EIPs complementing EOF’s implementation in the coming Ethereum Pectra upgrade are included in the EIP-7692 such as:

• EIP-3540: Introduces EOF Version 1, establishing the initial structure for structured bytecode.

• EIP-3670, EIP-4200, EIP-4750, EIP-5450, EIP-6206, EIP-7480, EIP-663, EIP-7069, EIP-7620, EIP-7698: Enhance EOF functionalities, improving security, efficiency, and usability across Ethereum’s ecosystem.

Major Clients Supporting EOF

1. evmone: C++ implementation of the EVM has fully integrated EOF supporting structured bytecode and code-data separation. Here is an example demonstrating several key features of EOF by evmone.

2. revm: Rust implementation of EVM has supports EOF primitives, defining structures like headers and body sections for efficient bytecode handling. Refer to the revm documentation for more details on this.

3. besu: An enterprise-grade Ethereum client fully integrated EOF for EOF-compliant deployments and optimization.

4. Nethermind: The client provides full support of EOF to improve performance and compatibility for smart contract developers targeting Ethereum’s future upgrades. Here are the commits related to EOF.

5. Solidity POC: Partially implemented EIPs related to EOF Support contact creation for experimental solidity but lack certain functionalities related to specific proposals.

Benefits for dApps

1. Enhanced Security: With one-time validation and the removal of JUMPDEST-analysis, EOF strengthens contract security.

2. Faster Transactions: Reduced runtime overhead makes smart contract execution faster, providing a better overall user experience.

3. Improved Efficiency: Separating code and data streamlines gas usage and improves contract execution speed, reducing the gas cost for users.

4. Future-Proof Upgrades: Versioning ensures compatibility with evolving Ethereum and facilitates seamless upgrades.

Example with measurable benefits of EOF

Let us quickly analyze EOF implementation based on tests (on Legacy and EOF) to measure benefits in terms of bytecode size, gas usage, and execution time for popular smart contracts UniswapV3.

EOF clearly offers measurable improvements in terms of gas costs, execution speed, and bytecode size for developers and significantly enhances user experience. To discover more about the test, visit the full test results here.

NOTE*: [Solidity](https://github.com/ethereum/solidity/tree/eof1) compilers will soon completely support EOF, henceforth frameworks like Hardhat and Foundry are expected to follow by integrating EOF container generation. Developers won’t need to make code changes but should stay updated to take advantage of these improvements.*

Conclusion

The Ethereum Virtual Machine Object Format (EOF) is an advancement in EVM. With its structured bytecode and versioning capabilities, EOF promises increased security, efficiency, and flexibility in the Ethereum ecosystem. As Ethereum continues to evolve, EOF sets a strong foundation for future upgrades and innovations on the network.

About BuildBear:

BuildBear is a platform tailored for DApp development and testing. Developers gain the freedom to construct a personalized Private Testnet sandbox across a variety of blockchain networks. The liberty to mint unlimited Native and ERC20 tokens, coupled with rapid transaction times on BuildBear (under 3 seconds!), enhances the DApp development lifecycle manifold. The platform comes equipped with tools and plugins designed for real-time testing and debugging, ensuring developers can keep tabs on intricate blockchain transactions with unparalleled ease.

Connect with us on Twitter | LinkedIn | Telegram | GitHub

Contributors: Emmanuel Antony, Dipesh Sukhani & Sana M Ummer