Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Research · Ethereum

The Ethereum Virtual Machine

Every Ethereum node runs the same virtual machine over the same inputs and must reach the same result. The EVM is deliberately small — a stack, a byte-addressed memory, a persistent store, and a fixed instruction set — and every step of it is metered.

Last reviewed 2026-09-21Source: Ethereum Yellow Paper and execution-specsInstruction semantics and gas costs are described qualitatively; consult the specification for current constants.

The machine and its memory model

The EVM is a stack machine with a 256-bit word size. Arithmetic, comparison and bitwise operations all work on 256-bit values, which is wide enough to hold a hash, an address or a storage slot index without packing. The stack is limited to 1,024 items, and most instructions take their operands from the top of it and push their result back. There are no registers and no general-purpose addressing modes; the instruction set is small and each opcode does one thing.

Alongside the stack the machine has three other data areas, and confusing them is the most common source of misunderstanding about Ethereum execution. Memory is a byte-addressed scratch space that exists only for the duration of one call and is cleared when the call returns. Storage is the contract's persistent key-value store, where each slot is 256 bits wide and writes survive across transactions. Calldata is the read-only input the caller supplied, and it is immutable for the duration of the call. A fourth area, the return data buffer, holds the output of the most recent external call.

The distinction between memory and storage is where the cost model bites. Memory is cheap and grows quadratically in cost as it is expanded, so a contract that allocates a large buffer pays for it. Storage is expensive because it is part of the state every node must keep, and writing a slot that was previously zero costs far more than overwriting a slot that already held a value. Clearing a slot back to zero refunds part of the cost, which is why contracts that delete data are cheaper than contracts that accumulate it.

The instruction set

The opcodes fall into a handful of families. The table groups them by what they do rather than listing every code, because the families are what determine a contract's cost profile.

Families of EVM opcodes grouped by function, with the resource each family consumes.
FamilyRepresentative opcodesDominant cost
Arithmetic and logicADD, MUL, EXP, LT, AND, SHLFixed gas per operation; EXP scales with exponent size
Stack and flowPUSH, POP, DUP, SWAP, JUMP, JUMPIFixed gas per operation
MemoryMLOAD, MSTORE, MSTORE8, MSIZEGas plus a quadratic expansion charge
StorageSLOAD, SSTOREHighest per-operation cost; writes depend on the slot's prior value
EnvironmentADDRESS, CALLER, CALLVALUE, NUMBER, TIMESTAMP, CHAINIDFixed gas per operation
Calls and creationCALL, STATICCALL, DELEGATECALL, CREATE, CREATE2Base cost plus gas forwarded to the callee
LoggingLOG0 through LOG4Per-byte cost plus a per-topic cost
HaltingSTOP, RETURN, REVERT, INVALID, SELFDESTRUCTRefunds or consumes the remaining gas depending on the opcode

Last reviewed 2026-09-21Source: Ethereum Yellow Paper, Appendix HGas constants change with protocol upgrades; the specification is authoritative.

Two opcodes deserve separate mention because they define what a contract can do to another contract. CALL transfers control to another address with a specified amount of gas and a specified value, and the callee executes in its own storage context. DELEGATECALL transfers control in the same way but executes the callee's code in the caller's storage context, preserving the caller's address and value. The second is the mechanism behind upgradeable contracts and behind libraries that operate on a caller's data, and it is also the mechanism behind a class of exploits: a delegatecall to untrusted code hands that code the ability to write the caller's storage.

REVERT is the other opcode worth naming. It halts execution, undoes every state change made during the call, and returns the unused gas along with an optional reason string. That is different from an invalid opcode or an out-of-gas condition, which also undo the state changes but consume all the gas forwarded to the call. The distinction is why a well-written contract checks its conditions early and reverts rather than failing later: a revert is cheap, and an out-of-gas failure is not.

Why execution is metered

A virtual machine that runs arbitrary code supplied by strangers needs a way to stop. The halting problem says a general program cannot be analysed in advance to decide whether it terminates, so Ethereum does not try. Instead every opcode has a price, every transaction carries a gas limit, and execution stops when the limit is exhausted. Gas is the unit of that price, and it is deliberately separated from the fee paid for it: the protocol sets how much gas each operation costs, and the market sets what a unit of gas costs in ether.

That separation is what makes the fee market upgradeable without changing the execution semantics. When EIP-1559 changed how transaction fees are priced, it changed the fee, not the gas. When a hard fork reprices an opcode — as several have, to reflect the real cost of the work or to close a denial-of-service vector — it changes the gas, not the fee. A contract's behaviour is defined in gas, and its cost to a user is gas multiplied by a price the market decides.

The metering also bounds what a single call can do. A transaction specifies a gas limit, and a contract that forwards gas to another contract must decide how much to forward. Forwarding everything leaves the caller unable to handle a failure; forwarding too little causes the callee to run out of gas. The convention that has emerged is to forward a fraction and to check the return value, which is why the "check the return value of an external call" rule appears in every Ethereum security guide.

Sources and references

The machine model, opcode families and metering described above are taken from Ethereum's formal specification and its executable specification.

  • The EVM definition and gas schedule. Ethereum Yellow Paper, Ethereum: A Secure Decentralised Generalised Transaction Ledger: the machine state, the instruction set and the fee schedule are specified in the appendices.
  • The executable specification. ethereum/execution-specs, Execution Specs: a Python implementation of the protocol that tracks the current opcode semantics and gas costs.
  • The EVM from a developer's perspective. ethereum.org, Ethereum Virtual Machine (EVM): the stack, memory, storage and calldata model as documented for contract authors.
  • Opcode reference. evm.codes, EVM Opcodes Reference: an interactive listing of every opcode with its current gas cost.

Related reading