What is the EVM?
The Ethereum Virtual Machine (EVM) is the runtime environment that executes smart contract bytecode on Ethereum. Think of it as a decentralized, global computer — every node in the Ethereum network runs a copy of the EVM, ensuring that smart contracts execute identically everywhere.
The EVM is what makes Ethereum “programmable.” Before Ethereum, blockchains (like Bitcoin) could only process simple transactions. The EVM introduced Turing-complete computation — meaning it can run any program (with the gas limit as the only constraint).
The EVM is not just on Ethereum. It’s been adopted by dozens of L1s (BNB Chain, Avalanche C-Chain, Polygon, Fantom) and all major L2s (Arbitrum, Optimism, Base, Scroll). This ecosystem of EVM-compatible chains is the largest in crypto.
How the EVM Works
The Execution Pipeline
- Write smart contract in Solidity (or Vyper)
- Compile to EVM bytecode (the low-level machine code the EVM understands)
- Deploy by sending a transaction with the bytecode
- Execute when someone calls a function — the EVM processes the bytecode instructions
- State change — the EVM updates on-chain storage if the execution succeeds
- Gas metering — each instruction costs gas, and the total must not exceed the gas limit
EVM Architecture
┌─────────────────────────┐
│ Smart Contract │
│ (Solidity → Bytecode) │
├─────────────────────────┤
│ EVM Runtime │
│ ┌─────────┐ ┌────────┐ │
│ │ Stack │ │ Memory │ │
│ ├─────────┤ ├────────┤ │
│ │Storage │ │ Program│ │
│ │(permanent)│ │Counter│ │
│ └─────────┘ └────────┘ │
├─────────────────────────┤
│ Blockchain State │
│ (balances, nonces, etc) │
└─────────────────────────┘- Stack: LIFO stack for computation (max 1,024 items)
- Memory: Volatile byte array (resets after each call)
- Storage: Persistent key-value store (persists across transactions)
- Program Counter: Tracks which bytecode instruction to execute next
Opcodes
The EVM has ~150 opcodes (operations), including:
| Category | Opcodes | Examples |
|---|---|---|
| Arithmetic | ADD, MUL, DIV, MOD | Mathematical operations |
| Comparison | LT, GT, EQ, ISZERO | Compare values |
| Memory | MLOAD, MSTORE, SLOAD, SSTORE | Read/write memory and storage |
| Environment | CALLER, VALUE, TIMESTAMP, BLOCKHASH | Access blockchain context |
| Control flow | JUMP, JUMPI, STOP, REVERT | Branching and halting |
| Cryptographic | SHA3, ECRECOVER | Hash functions, signature verification |
| Contract interaction | CALL, DELEGATECALL, STATICCALL | Call other contracts |
EVM Gas Costs
Every opcode has a fixed gas cost. This prevents infinite loops (exhausting gas) and incentivizes efficient code:
| Operation | Gas Cost | Notes |
|---|---|---|
| ADD (addition) | 3 | Very cheap |
| MUL (multiplication) | 5 | Still cheap |
| SLOAD (read storage) | 2,100 (warm) / 2,100+ (cold) | Expensive — storage reads are costly |
| SSTORE (write storage) | 2,100 (update) / 22,100 (new) | Very expensive — writing new storage is costliest |
| CALL (call another contract) | 700 base + 2,600 warm | Calling contracts is expensive |
| SHA3 (hash) | 30 + 6 per word | Moderate cost |
EVM Equivalence
Types of EVM Compatibility
| Type | Definition | Examples |
|---|---|---|
| Type 1 (Full) | Bytecode-identical to Ethereum | Scroll |
| Type 2 (Almost) | EVM-equivalent with minor differences | zkSync, Polygon zkEVM |
| Type 2.5 | EVM-compatible with gas cost changes | Some modified EVMs |
| Type 3 (Almost) | Nearly EVM-compatible, but not quite | Early zkEVMs |
| Type 4 (High-level) | Solidity-compatible but different VM | Starknet (Cairo VM) |
Most developers prefer Type 1-2 EVMs because existing Solidity tools (Hardhat, Foundry, Etherscan) work without modification.
The EVM Ecosystem
Chains Running the EVM
| Chain | Type | TVL | Notes |
|---|---|---|---|
| Ethereum | Native | $50B+ | The original |
| Arbitrum | L2 (Type 2) | $15B+ | Most popular L2 |
| Base | L2 (OP Stack) | $8B+ | Coinbase-backed |
| Optimism | L2 (OP Stack) | $5B+ | OP Superchain |
| BNB Chain | L1 (Type 2) | $5B+ | EVM-compatible since launch |
| Polygon zkEVM | L2 (Type 2) | $100M+ | ZK EVM |
| Avalanche C-Chain | L1 (Type 2) | $1B+ | Subnet architecture |
Development Tools
| Tool | Purpose |
|---|---|
| Hardhat | Development framework |
| Foundry | Fast development (Rust-based) |
| Ethers.js / Viem | JavaScript libraries for interacting with the EVM |
| OpenZeppelin | Audited contract library |
| Slither | Static analysis security tool |
| Remix | Browser-based IDE |
Limitations of the EVM
- 256-bit word size: All values are 256 bits, even when smaller would suffice (wastes gas)
- No native floating point: All math is integer-based (precision handled in application code)
- Sequential execution: No parallel processing within a single transaction
- Storage is expensive: SSTORE costs 20,000+ gas, making on-chain data storage costly
- Stack depth limit: Max 1,024 items (deeply recursive functions can fail)
Frequently Asked Questions
Q: Is Solana EVM-compatible? A: No. Solana uses its own runtime (SVM) and smart contracts are written in Rust, not Solidity. However, projects like Neon and Eclipse are building EVM-compatible environments on Solana.
Q: Can the EVM be upgraded? A: The EVM evolves through Ethereum Improvement Proposals (EIPs). Major changes include: EIP-1559 (fee market), EIP-4844 (blob transactions), and Shanghai/Cancun upgrades. Changes require network consensus.
Q: What’s the difference between EVM and WASM? A: EVM uses custom bytecode designed for blockchain. WASM (WebAssembly) is a general-purpose runtime used by chains like Polkadot, Cosmos, and NEAR. WASM supports more languages but is newer to the blockchain space.