EVM Basics: How the Ethereum Virtual Machine Executes Code

Imagine a computer that doesn't sit on your desk. Instead, it runs simultaneously on thousands of servers around the world, all agreeing on exactly what calculation to perform next. That is the Ethereum Virtual Machine in action. It is the engine behind every decentralized application, ensuring that code behaves predictably even when no single entity controls the infrastructure.

If you are building or interacting with smart contracts, understanding how this machine works is not just nice-to-have-it is essential. You need to know why your code costs money to run, how data is stored, and why certain operations fail silently. This guide breaks down the mechanics of the EVM without the academic fluff.

The Core Concept: A Deterministic State Machine

At its heart, the Ethereum Virtual Machine (EVM) is a state machine. In computing terms, a state machine transitions from one condition to another based on specific inputs. For Ethereum, the "state" includes account balances, token ownership records, and contract storage. Every time a transaction occurs, the EVM takes the current state, processes the instructions, and outputs a new, valid state.

The critical feature here is determinism. If Node A in New York and Node B in Tokyo execute the same transaction with the same initial state, they must produce the exact same result. There is no room for ambiguity. This consistency allows the network to reach consensus without a central authority verifying the math. Without this deterministic nature, the entire trustless model of blockchain would collapse.

Think of it like a robotic chef following a recipe. The ingredients (inputs) and the steps (code) are fixed. No matter which kitchen the robot is in, if it follows the instructions precisely, the dish (output) will be identical. This reliability is what enables complex financial systems to operate autonomously.

Stack-Based Architecture vs. Register Machines

Most modern computers use a register-based architecture, where data is stored in small, fast memory locations called registers before being processed by the CPU. The EVM, however, uses a stack-based design. This distinction matters because it changes how developers think about data manipulation.

In the EVM, all in-memory values are pushed onto a stack-a last-in, first-out (LIFO) structure. When an operation needs two numbers, it pops them off the top of the stack, performs the calculation, and pushes the result back. This simplifies the instruction set significantly. The EVM operates with a word size of 256 bits. This specific size was chosen to align with cryptographic standards like Keccak-256 hashing and secp256k1 signatures, making security operations native and efficient.

The stack has a maximum depth of 1024 items. If your code tries to push more than that, the transaction fails immediately. This limit prevents memory exhaustion attacks and keeps the computational model bounded. For developers coming from languages like C++ or Java, this shift from explicit variable addressing to stack manipulation requires a mental adjustment but results in cleaner, more modular bytecode.

Data Storage: Memory, Storage, and Calldata

Understanding where data lives during execution is crucial for optimizing costs. The EVM distinguishes between three types of data storage:

• Memory: This is volatile, temporary storage. It is initialized to zero at the start of each transaction and cleared afterward. Data here is cheap to access but disappears once the transaction ends. Think of it as scratch paper.
• Storage: This is permanent, part of the blockchain state. Changes here persist across transactions and blocks. Writing to storage is expensive because it alters the global state of the network. This is where your contract’s core data-like user balances-lives.
• Calldata: This contains the input data sent with a transaction. It is read-only and immutable during execution. It is the cheapest source of data because it does not change the state and is provided by the caller.

A common mistake beginners make is storing data in memory when they should use calldata, or vice versa. Misusing these can lead to unnecessary gas consumption or unexpected behavior. Always ask yourself: does this data need to survive after the transaction? If yes, it goes to storage. If it’s just for intermediate calculation, keep it in memory.

From Solidity to Bytecode: The Compilation Process

You don’t write directly in EVM bytecode. Most developers use high-level languages like Solidity or Vyper. These languages abstract away the low-level complexity, allowing you to write readable code. However, the EVM cannot understand Solidity. It only understands bytecode.

When you compile your contract, the compiler translates your human-readable code into a sequence of opcodes-binary instructions that the EVM executes. Each opcode corresponds to a specific action, such as adding two numbers, pushing a value onto the stack, or calling another contract. This compilation step is where many bugs hide. A slight misinterpretation by the compiler can lead to vulnerabilities.

Once deployed, this bytecode is stored permanently on the blockchain. It is public and immutable. Anyone can inspect the bytecode to reverse-engineer the logic, which is why open-source practices are standard in the ecosystem. The deployment process itself is a transaction that creates a new account for the contract, assigning it an address derived from the sender’s address and nonce.

Gas: The Cost of Computation

The EVM is Turing complete, meaning it can theoretically compute anything given enough resources. But infinite computation would break the network. To prevent denial-of-service attacks and infinite loops, the EVM uses a resource accounting system called gas.

Every operation consumes a specific amount of gas. Simple arithmetic might cost 3 gas units, while reading from storage could cost 21,000. Users must specify a gas limit-the maximum amount of gas they are willing to consume-and a gas price-the amount of Ether they pay per unit of gas. If the transaction runs out of gas mid-execution, it reverts, and all state changes are undone, but the gas is still paid to the validator.

This economic incentive forces developers to write efficient code. Bloated contracts cost more to run, discouraging waste. It also protects the network from malicious actors trying to freeze it with endless loops. As network demand fluctuates, gas prices adjust dynamically, creating a market-driven mechanism for prioritizing transactions.

EVM Equivalence vs. Compatibility

As the Ethereum ecosystem expands, other blockchains have emerged that interact with the EVM. Not all are created equal. Understanding the difference between EVM equivalent and EVM compatible chains is vital for cross-chain development.

An EVM equivalent chain adheres strictly to the Ethereum specification. It uses the same opcodes, state-transition logic, and virtual machine rules. You can deploy a contract written for Ethereum mainnet to an EVM equivalent chain without changing a single line of code. Optimism and Arbitrum fall into this category. They prioritize seamless interoperability, making them ideal for scaling solutions where users expect familiar behavior.

In contrast, EVM compatible chains may modify the core architecture for performance or privacy reasons. While they can execute smart contracts written in Solidity, there might be subtle differences in how certain operations behave. Polygon zkEVM and zkSync Era are examples here. Developers often need to adjust their code or use specialized libraries to ensure compatibility. This trade-off offers benefits like lower fees or faster finality but introduces complexity in deployment.

Execution Flow: Step-by-Step

Let’s trace what happens when you click “Send” on a dApp interface:

1. Transaction Submission: Your wallet signs a transaction containing the recipient address, value, and calldata. This is broadcast to the mempool.
2. Inclusion: A validator picks up the transaction, bundles it into a block, and proposes it to the network.
3. Initialization: The EVM loads the contract’s bytecode into its ROM (Read-Only Memory). It initializes memory and storage to zero.
4. Opcode Execution: The EVM reads opcodes sequentially from the program counter. It manipulates the stack, accesses memory/storage, and performs calculations.
5. State Update: Upon successful completion, the new state is committed to the blockchain. Gas is deducted from the sender’s balance.
6. Reversion: If an error occurs (e.g., insufficient funds, assertion failure), the execution halts, state changes are rolled back, and gas is consumed.

This flow ensures that every participant in the network can verify the outcome independently. The transparency of this process is what makes decentralized applications trustworthy.