How the EVM Actually Executes Your Transaction, Opcode by Opcode

You know that Ethereum runs smart contracts. You've probably heard the term "Ethereum Virtual Machine." But most guides stop at the metaphor — "it's a world computer" — and skip the actual execution model. That gap matters: understanding how the EVM processes your function call explains why transactions fail, why gas estimates are wrong, and why certain contract patterns cost more than others.

This article covers what physically happens inside the EVM from the moment your signed transaction enters a block to the moment state changes commit.

You might picture the EVM as something like a virtual processor running Solidity. That's wrong twice. First, the EVM never sees Solidity — it executes bytecode, a sequence of single-byte instructions compiled from Solidity (or Vyper, or Huff, or hand-written assembly). Second, the EVM's architecture is a stack machine, meaning it doesn't use named registers like an x86 CPU. Every operation pulls inputs from and pushes outputs onto a last-in-first-out stack.

The stack holds 256-bit (32-byte) words, and it has a hard maximum depth of 1,024 items. Most operations consume one or two items from the top and push one result back. There are no floating-point numbers, no native string type. Everything is a 256-bit integer, and the bytecode is responsible for interpreting those integers as addresses, booleans, or whatever the contract logic needs.

This architecture is why Solidity has a "stack too deep" compilation error — the EVM can only directly access the top 16 stack slots via its DUP and SWAP opcodes. If a function has too many local variables, the compiler literally cannot reach them.

⚠ Common mistake: Assuming the EVM has memory like a normal computer. The EVM actually has three distinct data locations: the stack (fast, tiny, for computation), memory (byte-addressable, ephemeral, wiped after each call), and storage (persistent key-value store on-chain, expensive). Confusing these is the single most common source of gas misunderstanding.

When your transaction gets included in a block, the execution client (Geth, Nethermind, Besu, Erigon) initializes an EVM instance for it. The EVM receives the transaction's context: sender, value, gas limit, and the calldata (the raw bytes encoding which function you're calling and with what arguments).

The EVM loads the target contract's bytecode from state and sets the program counter (PC) to zero. It then enters a loop: read the opcode at the current PC, check if enough gas remains, execute the operation, advance the PC. This loop continues until the bytecode hits a STOP or RETURN opcode, runs out of gas, or encounters a REVERT.

The first thing most contracts execute is the function dispatcher — a sequence of opcodes that reads the first 4 bytes of calldata (the function selector), compares it against known selectors using EQ and JUMPI opcodes, and routes execution to the matching function body. If no selector matches, execution falls through to the fallback or receive function, or reverts. This dispatcher is why calling a contract with garbage calldata doesn't execute random code — it just fails the selector check.

⚠ Common mistake: Thinking "calling a function" on a smart contract is like calling a function in Python. There's no function table or object. The EVM receives raw bytes and the bytecode itself decides what to do with them. The 4-byte selector convention is an ABI standard, not an EVM feature.

Every opcode has a gas cost defined in the Ethereum Yellow Paper (and updated through EIPs). Simple stack operations like ADD, MUL, and PUSH cost 3 gas each — these are the Wvery low tier. Hashing with KECCAK256 costs 30 gas base plus 6 gas per 32-byte word of input. These are small numbers.

The expensive operations touch storage. SLOAD (reading a storage slot) costs 2,100 gas for a cold read (first access in the transaction) and 100 gas for a warm read (already accessed). SSTORE (writing to storage) ranges from 2,900 gas (modifying an already-dirty slot) up to 20,000 gas (writing a nonzero value to a slot that was zero). These numbers come from EIP-2929 and EIP-2200, which introduced the cold/warm access model in the Berlin and Istanbul upgrades.

This is why a simple ERC-20 transfer costs around ~65,000 gas — most of that is two SSTORE operations (decrementing sender balance, incrementing receiver balance) plus the associated SLOADs and event logging. The actual arithmetic is trivial by comparison.

• SSTORE (zero to nonzero): 20,000 gas
• SSTORE (nonzero to nonzero): 2,900 gas
• SLOAD (cold): 2,100 gas
• SLOAD (warm): 100 gas
• CREATE (deploying a contract): 32,000 gas base + 200 gas per deployed byte
• LOG with 2 topics: 375 + 375×2 + 8 per byte of data

⚠ Common mistake: Believing gas cost equals computational difficulty. SLOAD is computationally cheap — it's a database read. It's expensive because storage access is the bottleneck for node performance. Gas pricing is about network resource consumption, not CPU cycles.

Memory is a clean byte array initialized to zero at the start of each external call. It's cheap to use initially but gets progressively more expensive: memory cost scales quadratically with size. The formula is 3 gas per word plus a quadratic term (word² ÷ 512). For small memory usage (a few hundred bytes), this is negligible. For large memory allocations — say, returning a huge array — the quadratic blowup makes it prohibitively expensive. This is a deliberate design choice to prevent contracts from using unbounded memory.

Storage uses a key-value model where both key and value are 32 bytes. Each contract has its own storage space, totally isolated. The key detail many miss: storage layout is determined at compile time. Solidity assigns state variables to sequential slots starting from slot 0. Mappings and dynamic arrays use a keccak256 hash of the slot number and key to derive their actual storage position. This is why reading a mapping value on-chain requires knowing both the mapping's declared slot and the key.

The interaction between memory and storage explains a common pattern in gas-optimized contracts: loading a storage value into a local memory variable, doing all computation in memory, then writing the result back to storage once. Each SLOAD/SSTORE costs thousands of gas; stack and memory operations cost single digits.

⚠ Common mistake: Thinking storage is like a hard drive with sequential reads. Each SLOAD is an independent key-value lookup. Reading storage slots 0, 1, and 2 is three separate operations at full cost each (minus warm access discounts within the same transaction).

When your transaction's target contract calls another contract (via CALL, STATICCALL, or DELEGATECALL), the EVM creates a new message frame — a fresh stack, fresh memory, a new program counter set to zero, and its own gas allocation. The calling contract specifies how much of its remaining gas to forward (since EIP-150, this is capped at 63/64ths of remaining gas, preventing a caller from forwarding 100% and having nothing left for post-call cleanup).

STATICCALL is identical to CALL except the EVM enforces that no state modifications occur — any SSTORE, LOG, CREATE, or SELFDESTRUCT in the subcall causes an immediate revert. This is how view functions are enforced at the EVM level, not just at the Solidity level. DELEGATECALL executes the target's bytecode but in the context of the calling contract — meaning storage reads and writes affect the caller's storage, and msg.sender remains the original caller. This is the mechanism behind proxy contracts and upgradeable patterns like EIP-1967.

If a subcall reverts, the calling frame gets a 0 pushed onto its stack (failure signal) and all state changes from that subcall are rolled back. The calling contract can check this return value and decide whether to revert itself or handle the failure. Gas consumed by the failed subcall is not refunded.

⚠ Common mistake: Assuming a failed internal call always reverts the whole transaction. It only does if the calling contract propagates the revert (Solidity's high-level calls do this by default, but low-level .call() does not — it returns false and keeps going).

You can inspect real EVM execution on any confirmed transaction. On Etherscan, click any transaction hash, then navigate to the "Internal Txns" tab to see cross-contract calls. For full opcode-level traces, use Etherscan's "Geth Debug Trace" under the advanced "State" tab (available on some transactions), or use the Tenderly debugger, which provides a step-by-step opcode trace with stack, memory, and storage snapshots at every step.

For a practical exercise: take any Uniswap V3 swap transaction, open it in Tenderly, and watch the execution flow. You'll see the Router contract decode your calldata, perform validation, then CALL into the Pool contract, which executes the swap math, performs SSTOREs to update tick and liquidity state, then CALL the token contracts for the actual ERC-20 transfers. Each CALL creates a visible new frame with its own gas budget.

The OpenChain (formerly 4byte.directory) transaction decoder and Phalcon by BlockSec are also useful: Phalcon renders the entire call tree visually, showing gas consumption and value flow per frame. These tools transform the EVM from an abstraction into something you can directly observe.

⚠ Common mistake: Relying on Etherscan's simplified view and thinking it shows everything. Etherscan's main transaction page shows the top-level call only. Internal transactions, storage changes, and actual execution flow require the trace tools or the "State" tab.

• Trace a real transaction in Tenderly: Pick any swap you've done, paste the tx hash into tenderly.co, and step through the opcode execution. Watch how gas depletes at each SSTORE.
• Read the opcode reference: The evm.codes site maintains an interactive reference for every EVM opcode with gas costs, stack inputs/outputs, and examples. Spend 20 minutes here and storage costs will make permanent sense.
• Study EIP-1559 and EIP-2929 together: These two EIPs govern how gas is priced (base fee + priority fee) and how individual opcodes are metered (cold/warm access). Understanding both explains nearly every gas surprise you'll encounter.
• Inspect storage layouts on Etherscan: Go to any verified contract on Etherscan, click "Read Contract", and cross-reference the state variables with their slot numbers using the Solidity storage layout documentation. Tools like smlXL's storage layout explorer make this visual.