What the EVM is
Ethereum's state is a large data structure holding all accounts and balances, and the EVM defines the rules for computing a new valid state from block to block. Every node runs the same computation on the same inputs and gets the same result.[1]
The formal definition lives in the Ethereum Yellow Paper, which specifies the machine state, the instruction set and the gas rules mathematically. Each execution client is an independent implementation of that specification.[2]
Determinism is the whole point. There is no clock, no randomness source and no network access inside the EVM. A contract can only read the chain state and the transaction's inputs, which is why oracles exist to bring outside data on chain.
The EVM also has precompiled contracts: fixed addresses where the client runs native code for expensive cryptography instead of interpreting bytecode. The Yellow Paper specifies them, including ECDSA public key recovery at address 1 and SHA-256 at address 2, which is how contracts can verify signatures and hashes at a reasonable gas cost.[2]
Stack, memory and storage
The EVM executes as a stack machine with a depth of 1,024 items. Each item is a 256-bit word, a size chosen for ease of use with 256-bit cryptography such as Keccak-256 hashes and secp256k1 signatures.[1]
During execution, a contract also has transient memory, a byte array that is cleared when the transaction ends. Its permanent data lives in storage, a word-addressed map that is part of the contract account and therefore part of global state.[1]
These three areas have very different costs. Stack operations are the cheapest, memory grows in cost as it expands, and writing to storage is the most expensive thing a contract routinely does, because every node must keep that data indefinitely.
Opcodes and gas
Smart contracts compile to EVM bytecode, a sequence of one-byte opcodes. Ethereum.org's opcode reference lists them with their gas costs: ADD, MUL, SLOAD, SSTORE, CALL, CREATE and so on.[3]
Gas exists to bound computation. A transaction sets a gas limit; each opcode subtracts its cost; if gas runs out, execution reverts. That rule is what makes an infinite loop harmless: it simply exhausts the sender's gas.[4]
The EVM's instruction set is not frozen. Upgrades add opcodes and reprice old ones. The Solidity compiler's EVM version setting exists because code compiled for a newer fork may use opcodes older forks do not have.[5]
The gas limit is also a safety margin. Ethereum.org's example: set a 50,000 gas limit on a simple ETH transfer and the EVM consumes 21,000, refunding the unused 29,000. Set it at 20,000 and the transaction is rejected during validation, before inclusion, and no gas is consumed.[4]
Blocks have a gas budget too. Each block targets half of the current block gas limit, and the base fee rises when blocks are fuller than the target and falls when they are emptier. That is why the same contract call costs more during a busy mint than on a quiet Sunday.[4]
See also: Gas fee explained
How a contract call runs, step by step
Everything starts with a signed transaction. Ethereum.org lists its fields: the recipient, a value in wei (1 ETH is 10^18 wei), optional input data, a gasLimit, maxPriorityFeePerGas, maxFeePerGas and a nonce. When the recipient is a contract, the input data tells the EVM which function to run and with what arguments.[8]
The client loads the contract's bytecode and starts at byte 0 with an empty stack. Each opcode pops its inputs from the stack and pushes its result. The program counter moves forward, or jumps when the code hits JUMP or JUMPI, which is how compiled if-statements and loops work at the machine level.[3]
Reads from storage use SLOAD and writes use SSTORE. A call to another contract uses CALL, which starts a new execution frame with its own stack and memory while drawing on the same transaction's gas budget.[3]
There is also transient storage: data that persists across internal calls in the same transaction but is cleared when the transaction ends. Ethereum.org notes it is modeled as part of the EVM state rather than the execution frame, yet it is never committed to the state trie.[1]
If execution fails, for example on a revert, an invalid opcode or running out of gas, the EVM discards the state changes. The gas already consumed is still charged, because nodes did the work.[4]
A worked example: paying for execution
Ethereum.org's gas page uses a simple ETH transfer. It costs 21,000 units of gas. With a base fee of 10 gwei and a 2 gwei priority tip, the sender pays 21,000 x (10 + 2) = 252,000 gwei, which is 0.000252 ETH.[4]
Under the EIP-1559 fee model described on the same page, the base fee portion is burned and the tip goes to the validator. So in this example 210,000 gwei are destroyed and 42,000 gwei go to the block proposer.[4]
A token swap costs far more gas than 21,000, because the EVM runs contract code: reading pool balances from storage, doing arithmetic, writing new balances, and emitting events. The formula is the same, gas used times price per gas, but gas used depends on which opcodes ran.
| Area | Lifetime | Relative cost |
|---|---|---|
| Stack | Current call only | Lowest |
| Memory | Current transaction only | Grows as it expands |
| Storage | Permanent, part of state | Highest |
| Calldata | Read-only transaction input | Paid per byte |
Limits built into the machine
EIP-170 caps the size of deployed contract code at 0x6000 bytes, which is 24,576 bytes. Its rationale is a quadratic-cost vulnerability: calling a contract means loading its whole code, so very large contracts made calls too expensive for nodes relative to their gas price. Large protocols split their logic across several contracts or proxies.[6]
EIP-3860 limits initcode, the code that runs once to deploy a contract, to 49,152 bytes and charges 2 extra gas for every 32-byte chunk of it.[7]
Combined with the 1,024-item stack, these limits are why Solidity developers sometimes hit a "stack too deep" compiler error or a contract-size warning long before they run out of ideas.
The stack depth has a direct effect on code. Solidity keeps local variables on the stack and can only reach the top 16 slots with the DUP and SWAP opcodes listed in the opcode reference, which is why a function with too many local variables fails to compile with a stack-too-deep error.[3]
EVM-compatible chains
Because the EVM is specified in public, other networks implement it too, including layer 2 rollups that post results to Ethereum and several alternative layer 1 networks. The links below go to RPC endpoints for some of them.
For users, compatibility means the same address, the same private key, and the same wallet work across these networks; only the chain id and the RPC endpoint change. For developers it means the same Solidity code and tooling deploy with a configuration change.
Compatibility is not identity. Chains differ in gas pricing, precompiles, supported opcodes and finality. A contract that relies on a new opcode may fail on a chain that has not adopted the matching Ethereum upgrade, so check the target chain's EVM version before deploying.[5]
Tooling follows the same pattern. An EVM wallet sends the same eth_ JSON-RPC calls to every compatible network, which is why adding a new chain to a wallet usually means entering one RPC URL and one chain ID rather than installing new software.
See also: Ethereum RPC · Arbitrum RPC · Optimism RPC · Base RPC · BNB Chain RPC · Polygon RPC
The bottom line
Think of the EVM as a shared, metered computer: 256-bit words, 1,024 stack slots, a 24,576-byte code limit, and a gas price on every instruction. For users, that explains why a swap costs more than a transfer. For builders, the costliest mistakes are storage writes and code size, so measure both before mainnet, not after.
Educational content, not financial advice. Crypto assets are volatile; do your own research.