EOF: The Biggest Upgrade in the EVM's History
EOF: The Biggest Upgrade in the EVM's History
The EVM's First Facelift
The upcoming EOF upgrade changes how the EVM works while establishing a foundation for a host of upgrades to follow. It is a set of 5 core EIPs (Ethereum Improvement Proposals). Today’s write-up explains each, what EOF is, and the significance of the changes. Enjoy.
*If you haven’t read last week’s write-up on how the EVM works, I highly recommend reading that first. Here’s the link.
*Thank you to Andy for proofreading.
EIP-3540: Structures Low-Level Code
The first upgrade in EOF, or EVM Object Format, changes how instructions to the EVM are structured. Specifically, it establishes a structure where one didn’t really exist before. It splits bytecode into two strings of characters, one containing code and the other containing data. Currently, both code and data exist in the same single string, so analyzing code requires also analyzing data, which becomes expensive. This added efficiency becomes most beneficial for Rollups who often need to analyze code only.
EIP-3540: Makes Future Upgrades Easier
EIP-3540 also makes it easier to upgrade the EVM over time. It creates a system to distinguish new contracts and to determine what features each is using. By being able to distinguish which contracts were deployed with the EVM as we know it today, and those that are deployed in the future with EOF, the EVM can react as necessary. When it comes time to upgrade the EVM again in the future, we can also create a distinguisher for them within this system. The EVM executes each program based on the “version” of the EVM it was released in, and new upgrades can be delivered more easily.
EIP-3670: Verifying Code When it’s Deployed
The second EIP in EOF, EIP-3670, introduces the concept of code validation, specifically when a smart contract is deployed. Today, a contract gets deployed, and people may interact with it and discover it’s faulty. This is because contracts aren’t validated by the Ethereum network before they’re deployed, they get validated as they’re executed by people.
EIP-3670: Rejecting Faulty Contracts
Moving forward, EIP-3670 proposes validating contracts when they get deployed. This saves significantly on execution costs, as programs are validated once on deployment, and any necessary data for operation is made available in the data section of the bytecode. Contracts that have unresolved data are rejected before they get pushed to the Ethereum network, saving gas on faulty deployments and saving space on the blockchain.
EIP-4200: What are Stack Machines?
The third EIP, EIP-4200 introduces two special opcodes to Ethereum. To understand them, we should quickly review what a stack machine is (not to be confused with state machines). Stack machines can be imagined as glass containers, tall and thin. They execute instructions and store data in these glass containers. The first piece of data is placed at the bottom, and everything afterwards gets placed on top, in a “stack.”
EIP-4200: Improving Ethereum’s Stack Machine
Stack machines have pointers that can move between pieces of data to read them. Ethereum’s stack machine currently requires a lot of resources to shift a pointer in a stack from one location to another, or to “jump.” That’s because the only current instructions, or opcodes (JUMP and JUMPDEST), used for this purpose are inefficient. They must always be used together; performing a “JUMP” requires a destination, or a “JUMPDEST.”
EIP-4200: Looking Through the Stack More Easily
EIP-4200’s new opcodes enable the Ethereum stack machine to shift its pointer far more efficiently. RJUMP can be used alone to shift the pointer to a desired location. RJUMP1 can be used to shift the pointer based on a condition. Finally, RJUMPV can also be used to shift the pointer based on instructions, but between pieces of data held in a specific table. This results in cheaper gas fees both for deploying a contract as well as for interacting with one. It also makes on-chain analysis easier.
EIP-4750: Introducing Functions to Ethereum’s Stack
Next, EIP-4750 introduces functions, or subroutines, that the stack itself can perform. Functions are instructions that need to be performed more than once in a program. Writing such instructions once as a function makes programs more efficient, leading to cost savings on Ethereum.
EIP-4750: Functions Instead of Frequent Jumps
Currently, functions don’t exist at the bytecode level (that the stack machine executes) on Ethereum. To repeat instructions, the “JUMP” and “JUMPDEST” opcodes are instead used to shift the pointer to where an instruction is when it needs to be executed. Functions allow the EVM to execute more elaborate instructions more efficiently, again leading to gas savings across the board.
EIP-5450: Preventing Stack Overflows and Underflows
Finally, EIP-5450 also focuses on validating contracts when they’re deployed, but by looking for errors the stack machine might encounter, called stack overflows or underflows. A stack overflow happens when data needs to be added to a stack, but the stack’s used up all its space already and is full. Stack underflows happen when a stack machine is instructed to retrieve data while the stack itself is empty.
EIP-5450: No More Stack Machine Errors
Despite stack overflows and underflows being basic errors, they can occur on Ethereum today. The checks necessary to prevent them are introduced with EIP-5450. Contracts that result in these errors are rejected when they get deployed, again leading to fewer faulty contracts.
To Conclude
EOF is a suite of EIPs, together making EVM execution more efficient, more consistent, and more easily upgradeable. EOF itself is first upgrade the EVM will receive, and can be expected in the Shanghai Hard Fork in March, 2023. There’s much to look forward to.
Thank You & Additional Reading!
Thank you for signing up and reading! Here are some more resources if you'd like to dive deeper.
Share a Summary
Thanks again, please consider sharing this newsletter below!
Stay kind. Stay curious.
Rami, I enjoy the newsletter. If I could provide some feedback, however, I would suggest using fewer, or even no photos in your write-ups. Stock photos don't add much value in the first place - some say they even "cheapen" the feel of the page. Having so many of them also makes it cumbersome to load the newsletter (esp. on slower connections around the world). Lastly, they distract from the content and require far more scrolling than is necessary. I personally would rather read a straight-to-the-point newsletter that is a concise block of text with just the right descriptive headings and/or bullet points, and no images at all.