My Knowledge Base

Ethereum Virtual Machine (EVM)

3 min read

Ethereum Virtual Machine (EVM)

The Ethereum Virtual Machine (EVM) is the runtime environment that executes smart contract code on the Ethereum blockchain. It is the defining technical innovation that made Ethereum a “programmable blockchain” rather than a simple ledger — and it has become the de facto standard adopted or emulated by dozens of other blockchains.

Design Principles

The EVM is designed around four properties:

PropertyWhat It Means
SandboxedExecution is isolated from the host environment; contracts cannot access the file system, network, or OS
DeterministicGiven identical inputs (world state + transaction data + block header), all nodes produce identical outputs — required for consensus
Turing-completeCan execute any computable function (tempered by gas limits to prevent infinite loops)
Stack-basedOperations work on a last-in-first-out stack rather than registers

Architecture

Data Areas

The EVM has three memory regions:

AreaPersistenceCapacityCost
StackTemporary (per call)1,024 items (256-bit each)Cheap
MemoryTemporary (per call)Expandable byte arrayQuadratic cost with growth
StoragePermanent (per contract)256-bit key → 256-bit valueExpensive (SSTORE ~20,000 gas)

Calldata provides read-only transaction input for function parameters.

Opcodes and Gas

Bytecode is a sequence of single-byte opcodes. Each opcode has a fixed gas cost:

  • ADD (addition) = 3 gas
  • SHA3 (keccak hash) = 30+ gas
  • SLOAD (read storage) = 100 gas
  • SSTORE (write storage) = 20,000 gas (first write)

Gas metering prevents denial-of-service attacks by making every computation economically bounded. A gas limit set by the transaction sender caps how much computation can occur; unused gas is refunded, but out-of-gas causes a revert.

Word Size

The EVM uses a 256-bit word size (32 bytes) — matching the output of keccak-256 hashing and enabling efficient cryptographic operations.

Execution Flow

  1. A transaction is broadcast and included in a block
  2. The EVM initialises execution context: sender address, available gas, input data
  3. A program counter fetches opcodes sequentially from the bytecode
  4. Each opcode modifies the stack, memory, or storage and decrements the gas counter
  5. Execution ends via:
    • STOP/RETURN — success; state changes committed
    • REVERT — failure; state changes rolled back, remaining gas refunded
    • Out-of-gas — failure; all gas consumed, state rolled back

Smart Contract Languages

Smart contracts are typically written in high-level languages that compile to EVM bytecode:

  • Solidity — the dominant language; JavaScript-like syntax
  • Vyper — Python-inspired; safety-focused, less feature-rich

Post-Merge Architecture (Execution Layer)

After The Merge (September 2022), the EVM runs as part of the execution layer, separated from the consensus layer:

  • Execution clients (e.g., Geth, Nethermind) run the EVM to process transactions and compute state roots
  • Consensus clients (Lighthouse, Prysm) coordinate block proposal and validation via proof-of-stake
  • The two layers communicate via the Engine API

The EVM as Industry Standard

The EVM has become a de facto cross-chain standard:

  • Arbitrum, Optimism, Base — Ethereum L2s that run the EVM (or near-EVM) for full compatibility
  • BSC (Binance Smart Chain) — EVM fork
  • Polygon, Avalanche C-Chain — EVM-compatible chains
  • Hyperliquid — performance-focused chain using EVM

This means smart contracts written for Ethereum can often be deployed on dozens of chains with minimal modification — a major competitive moat for the Ethereum ecosystem.

Sources

Related concepts: smart-contracts | ethereum | geth | gas | proof-of-stake | layer-2

Graph View

Backlinks