What Is the EVM?

In brief

The EVM is Ethereum’s deterministic execution environment. Given valid pre-state and a transaction, it executes message calls or contract creation and produces post-state, logs, gas usage, and a success or failure result.

It is a stack machine with 256-bit words and a maximum stack depth of 1,024 items. It exposes volatile memory, persistent per-account storage, and transaction-scoped transient storage. Compiled contract bytecode consists of opcodes such as ADD, SLOAD, CALL, and LOG.

Execution clients implement the EVM. Consensus clients do not replace it: they handle proof-of-stake consensus, while execution clients validate transactions and execution payloads. The Yellow Paper is a foundational formal reference, but current behavior also depends on later network-upgrade EIPs and maintained execution specifications.

A deterministic state transition

Ethereum is more than a list of payments. Its state includes accounts, ETH balances, contract code, and contract storage. Ethereum.org summarizes the transition as:

Y(S, T) = S'

For the same valid old state S and transaction input T, conforming execution clients must derive the same new state S'. Determinism is a consensus requirement: a contract cannot directly fetch a changing web page or weather API during execution, because nodes could receive different answers. Oracles instead place externally sourced data into on-chain state through transactions.

The EVM’s scope is execution. It does not choose the canonical proof-of-stake chain, schedule validators, provide peer-to-peer networking, or store every historical state by itself. Those responsibilities sit elsewhere in Ethereum’s protocol and client stack.

Stack, memory, storage, and transient storage

Stack. Most opcodes take operands from and return values to a last-in-first-out stack. Each item is a 256-bit word, and the stack cannot exceed 1,024 items.

Memory. Each call frame has temporary, linearly addressed byte memory. Expanding it costs gas. Memory disappears when that execution frame ends and is never committed to Ethereum state.

Persistent storage. Contract accounts have key/value storage that survives transactions and contributes to global state. SLOAD and SSTORE access the currently executing contract’s storage. Storage access is comparatively expensive, and exact costs can change through protocol upgrades.

Transient storage. EIP-1153 added TLOAD and TSTORE. Transient storage is private to its owning contract, shared by that contract’s relevant frames during one transaction, follows revert behavior, and is discarded at transaction end. It is not global scratch space shared freely by every contract in the transaction.

Code and calldata. A contract account’s bytecode is executed when a message call reaches it. Application conventions commonly use the first four bytes of calldata as a function selector and ABI-encode the arguments, but the EVM itself only sees bytes and opcodes; Solidity function names are not stored as executable instructions.

Gas meters execution

Gas is a unit of computational effort, not a currency. On Ethereum, the transaction sender pays a fee denominated in ETH for gas consumed. Each opcode has a gas rule, and memory expansion, account access, storage access, call behavior, and refunds also affect the total.

A plain transaction with empty calldata that transfers ETH to an account with no code has an intrinsic gas requirement of 21,000. That number should not be generalized to every “wallet-to-wallet” address: under EIP-7702, an EOA can delegate code, so sending to that address can trigger execution.

An eth_call simulates execution without submitting an on-chain transaction, so the caller is not charged ETH. The simulation still performs metered computation and can be subject to a gas limit. Likewise, Solidity’s view and pure labels do not make internal calls free when they occur inside an on-chain transaction.

Failure does not mean zero cost. A REVERT rolls back state changes from the reverted scope and can return error data, but gas already spent is not refunded merely because execution reverted. Running out of gas consumes the provided execution gas and reverts changes.

Bytecode is the authority

Users usually interact through Solidity source, an ABI, a wallet, and a block explorer. The EVM executes deployed bytecode, not the source-code label or verified-source badge. A verified build helps users compare source and bytecode, but the bytes at the called address determine behavior.

Contract calls can create nested execution frames. CALL, DELEGATECALL, and STATICCALL differ in which address, code, storage context, sender, and value they expose. Those details are why proxy contracts and reentrancy can be difficult; they are not simply “one function calling another.”

Specifications and implementations

The Yellow Paper formally describes Ethereum and the EVM using mathematical notation. It remains valuable, but it is not by itself a current changelog for every post-publication fork. Core EIPs specify changes such as new opcodes or transaction behavior, and the Ethereum execution-specs repository tracks execution-layer network upgrades.

Independent clients must agree at consensus-critical boundaries. Geth, Nethermind, Besu, Erigon, and Reth may use different languages and internal designs, but they must produce the same protocol result. A disagreement can cause a consensus failure, which is why shared tests and precise fork specifications matter.

“EVM compatible” needs a checklist

An EVM-compatible chain may support Solidity contracts and Ethereum wallet RPCs without matching Ethereum exactly. Compatibility can differ across:

• supported network-fork rules and opcodes;
• precompiles and gas schedules;
• transaction types and chain IDs;
• JSON-RPC methods and tracing behavior;
• block fields, finality, fee assets, and chain-specific system contracts.

EIP-155 added chain IDs to protected legacy transaction signatures, but it deliberately left older unprotected signatures valid. Chain ID support therefore reduces cross-chain replay risk; it is not a blanket guarantee that every signature or message is domain-separated.

Solana is not an EVM chain. Its programs are sBPF executables, mutable state is passed in separate accounts, and execution is metered in compute units. Bitcoin Script is another distinct environment focused on validating spending conditions.

What users actually encounter

When a wallet displays “contract interaction,” it is usually preparing calldata and fee limits for EVM execution. A node’s execution client runs the transaction; the receipt records status, gas used, and logs. Explorers decode those bytes using known or supplied ABIs, but decoded labels are an interpretation, not an extra EVM safety layer.

EIP-7702 lets an EOA set a delegation designator so calls to it execute code from another address. It changes account behavior, not the EVM’s basic role: the delegated code still executes under Ethereum’s execution rules.