How the EVM Executes Smart Contracts: Complete Guide

The Ethereum Virtual Machine is the engine that powers every smart contract on Ethereum and EVM-compatible blockchains. Understanding how it executes code matters for developers, security auditors, and anyone evaluating blockchain platforms. The execution model determines gas costs, contract security, and getting it wrong has cost projects millions.

What Is the Ethereum Virtual Machine

The EVM is a stack-based virtual machine that executes smart contract bytecode. It operates as a deterministic state machine: given an input state and a transaction, it produces a new output state. This determinism is what makes Ethereum reproducible and verifiable across all nodes in the network.

Unlike a traditional computer processor, the EVM doesn’t run on bare metal. It runs on top of Ethereum nodes as software. Each full node maintains its own EVM instance, and when a transaction is submitted, every node executes that same transaction to reach consensus on the resulting state change.

The EVM was designed with specific constraints in mind. It must be sandboxed, so contracts cannot access the host system directly. It must be Turing-complete, meaning it can theoretically compute any algorithm given enough resources. And it must charge for computation through the gas mechanism to prevent infinite loops and denial-of-service attacks.

One thing worth noting: the EVM isn’t a single implementation. Multiple teams maintain different EVM implementations—geth (Go), erigon (Go), revm (Rust), and others—yet they all produce identical results because they follow the same formal specification in the Ethereum Yellow Paper.

The EVM Architecture

The EVM has three primary storage areas, each with different characteristics and costs.

Stack is the primary workspace. It’s a last-in-first-out data structure that holds 256-bit words—the EVM’s native word size. The stack has a maximum depth of 1024 items. Most operations pop values from the stack, compute something, and push the result back.

Memory is a byte array that contracts use for temporary data during execution. It’s volatile, cleared after each transaction. Memory is word-aligned, meaning reads and writes operate on 32-byte chunks. Accessing memory scales quadratically in cost past a certain point, which is why efficient contracts minimize memory operations.

Storage is persistent and lives on the blockchain state trie. Each contract has its own storage namespace—a key-value mapping of 256-bit keys to 256-bit values. Storage operations are expensive because they modify the blockchain’s world state and must be recorded in the state trie.

The EVM also maintains execution context for each message call. This includes the calldata (input provided by the caller), the returndata (space for the contract to write output), the sender address, the contract address being called, and the gas available for execution.

Bytecode and Opcodes

Smart contracts are written in high-level languages like Solidity or Vyper, then compiled into EVM bytecode. This bytecode is a sequence of bytes, where each byte represents an operation or its parameter.

Opcodes are the human-readable representation of these operations. For example, the opcode PUSH1 followed by 60 00 in bytecode means “push the value 0 onto the stack.” The EVM has approximately 140 opcodes, though not all are actively used.

Here’s a simple Solidity contract and what its bytecode might look like after compilation:

// Solidity source
contract Storage {
    uint256 public value;
    function set(uint256 _value) public {
        value = _value;
    }
}

The compiled bytecode includes initialization code that runs once during contract creation (the constructor), followed by the runtime code that lives onchain. The runtime code for the set function would include opcodes like CALLER (get the message sender), SSTORE (store to persistent storage), and GAS (get remaining gas).

Understanding opcodes matters for optimization and security. Gas costs are tied to specific opcodes. SSTORE costs 20,000 gas when setting a storage slot from zero to non-zero, but only 5,000 when modifying an existing slot. This pricing structure incentivizes efficient storage patterns and has significant implications for contract design.

Step-by-Step Smart Contract Execution

The execution flow begins when a transaction targets a smart contract. Here’s how it works:

Transaction Reception: A user signs a transaction that calls a function on a smart contract. This transaction includes the target contract address, the function selector (the first 4 bytes of the keccak256 hash of the function signature), any arguments encoded according to the ABI specification, and the gas limit they’re willing to pay.

Message Call Creation: When the EVM processes the transaction, it creates a message call context. This includes the sender, the contract being called, the available gas (minus some upfront costs), and the calldata. If the transaction creates a new contract, the EVM uses the CREATE opcode instead, which executes the constructor and deploys the resulting bytecode.

Bytecode Execution: The EVM starts at the program counter position zero and begins reading opcodes sequentially. For each opcode, it pops required operands from the stack, performs the operation, pushes results back to the stack, and advances the program counter.

This continues until either the program counter reaches the end of the code, an explicit STOP or RETURN opcode executes, or the gas runs out.

State Modifications: As the contract executes, it may read from or write to storage using SLOAD and SSTORE opcodes. These modifications happen in the EVM’s temporary state during execution. Only after successful completion are these changes committed to the actual blockchain state. If execution fails (due to running out of gas or an explicit REVERT), all state changes are discarded.

Return Data: When a contract finishes executing, it can return data using the RETURN opcode. This typically contains the function’s return values encoded as ABI. The calling contract can access this through the RETURNDATASIZE and RETURNDATACOPY opcodes.

Gas and Execution Costs

Gas is the metering mechanism that makes Ethereum economically sustainable and secure. Every EVM operation costs a specific amount of gas, and the total gas consumed multiplied by the gas price determines the transaction fee.

The gas schedule reflects the real computational cost of each operation. Simple arithmetic like ADD or MUL costs 3 gas. Memory operations cost more as the memory grows: it’s 3 gas per word for the first 224 words, then the cost increases. Storage operations are the most expensive because they require every node to permanently record the change.

When a transaction runs out of gas mid-execution, the EVM triggers an out-of-gas exception. All state changes are reverted, but the sender still pays for the gas consumed. This prevents attackers from creating computationally expensive transactions that drain node resources without consequence.

The gas mechanism enables interesting patterns. Contracts can use CALL with a limited gas stipend to interact with other contracts, and they can check the gas remaining using the GAS opcode to implement conditional logic based on available resources.

A genuine limitation: gas estimation is notoriously difficult in practice. Dynamic gas costs mean that actual consumption depends on runtime conditions—storage values, contract state, and execution paths all affect the final total. Tools like Tenderly and Hardhat provide simulation capabilities, but they can’t account for every possible execution scenario.

Execution Context and Sub-Calls

The EVM supports nested execution through message calls. A contract can call another contract using the CALL, DELEGATECALL, STATICCALL, or CREATE opcodes. Each creates a new execution context with its own stack, memory, and program counter.

CALL is the standard inter-contract communication. The calling contract can send gas to the callee (up to 63/64 of the remaining gas, minus some overhead). The callee executes its code and can itself make further calls, creating a call depth that can go up to 1024 levels.

DELEGATECALL is particularly important for proxy patterns. It executes code in the context of the caller, meaning storage writes go to the caller’s storage and msg.sender remains the original external caller. This enables upgradeable contract architectures where a proxy contract delegates execution to implementation logic.

STATICCALL prevents state modifications in the called contract. It’s used for view and pure functions that shouldn’t mutate state. If the called contract attempts an SSTORE operation, the EVM reverts the entire call.

Common Questions About EVM Execution

What happens when a smart contract is called?

When you call a smart contract function, your transaction creates a message call in the EVM. The EVM loads the contract’s bytecode, executes the function’s logic by processing opcodes sequentially, may read from or modify the contract’s storage, and returns encoded results. If execution succeeds, the state changes are committed to the blockchain. If it fails, all changes are rolled back.

How does the EVM ensure determinism?

The EVM operates on a closed system with no access to external data sources during execution. It cannot make HTTP requests, read files, or access the system clock. All inputs come from the transaction itself, from storage, or from block context information that’s identical across all nodes. This determinism is fundamental to achieving consensus.

Can EVM execution be interrupted?

Only by running out of gas or encountering an explicit REVERT opcode. Unlike traditional programs, you cannot gracefully interrupt EVM execution from outside. The entire transaction either completes successfully or fails atomically. This design choice simplifies the execution model but creates challenges for long-running operations.

Looking Forward

The EVM execution model has remained remarkably stable since Ethereum’s launch, but it’s not static. EIP proposals regularly introduce new opcodes or modify gas costs to address emerging patterns. Recent discussions around EOF (EVM Object Format) aim to improve bytecode organization and enable new categories of smart contracts.

Understanding the EVM matters for serious blockchain development. The execution model determines what’s possible, what’s expensive, and what’s secure. As layer-2 networks and alternative EVM-compatible chains proliferate, this foundational knowledge becomes valuable across the entire ecosystem. Projects building on Arbitrum, Optimism, Base, or Avalanch all need developers who understand how their code actually runs.