The Ethereum Virtual Machine (EVM) is the sandboxed computation engine built into Ethereum that executes smart contracts — the self-executing programs that power everything from token transfers to decentralized finance. Think of it as a global, shared computer that thousands of nodes run simultaneously, with every node producing the exact same output for any given input.
Understanding the EVM unlocks why Ethereum works the way it does, why transactions cost gas fees, and why an entire ecosystem of blockchains decided to copy its design.
What the EVM actually does
When you deploy a smart contract to Ethereum, you are not uploading human-readable code. You upload bytecode — a compact series of low-level instructions called opcodes. Each opcode does something simple: push a number onto a stack, add two values, read from storage, send ether. The EVM interprets these opcodes one at a time, in a strictly deterministic order.
“Deterministic” is the crucial word. No matter which of the tens of thousands of Ethereum nodes runs your contract, every single one must arrive at the same result. This is what makes trustless execution possible: no central authority decides what the contract does — the rules of the EVM do.
The stack machine
The EVM is a stack-based machine. Rather than using named registers (like a typical CPU), it operates on a last-in, first-out stack. Instructions pop values off the top of the stack, operate on them, and push results back. Developers write smart contracts in high-level languages like Solidity or Vyper, and a compiler translates those into the EVM’s bytecode. Most users never see bytecode — but the EVM executes nothing else.
Storage, memory, and calldata
The EVM gives each contract three places to hold data:
| Location | Persists between calls? | Cost | Typical use |
|---|---|---|---|
| Storage | Yes | High | Balances, ownership records, settings |
| Memory | No (cleared each call) | Low | Temporary computation |
| Calldata | No (read-only input) | Very low | Arguments passed to a function |
Writes to storage are the most expensive operations a contract can perform. This is intentional: permanent data must be replicated across every node forever, so the network charges accordingly through gas.
Gas: metering every instruction
Every opcode has a fixed gas cost. A simple addition costs 3 gas. Writing a 32-byte word to storage can cost thousands. When you send a transaction, you set a gas limit — the maximum computation you are willing to pay for. The network charges you for exactly what was consumed, up to that limit.
Gas serves two purposes: it compensates validators for computation and storage, and it prevents infinite loops from freezing the network. A contract that loops forever simply runs out of gas and reverts, leaving the rest of the chain unaffected.
Gas is not wasted on failed transactions in the sense of changing state, but the computation still happened — so you do pay for the gas consumed before a revert. This is a common surprise for newcomers.
From source code to execution
Here is the typical path a smart contract takes from a developer’s editor to running on-chain:
- Write — A developer writes Solidity (or another EVM-compatible language).
- Compile — The compiler outputs ABI (the interface description) and bytecode.
- Deploy — A deployment transaction carries the bytecode; Ethereum stores it at a new address.
- Call — Any user or other contract sends a transaction to that address. The EVM loads the bytecode and begins executing from the appropriate entry point.
- Finalize — All nodes independently execute the same bytecode, reach consensus on the resulting state change, and the new state is committed to the chain.
The ABI acts as a translation layer. It tells wallets and dapps how to encode function calls into the byte format the EVM expects, and how to decode the results it returns.
What “EVM-compatible” means
Ethereum’s design became so widely adopted that many other blockchains chose to implement the same virtual machine. A chain is EVM-compatible when its nodes can execute the same bytecode, recognize the same opcodes, and support the same developer tooling as Ethereum.
This matters enormously in practice. A smart contract written for Ethereum can often be deployed to an EVM-compatible chain with little or no modification. Tools like Hardhat, Foundry, and MetaMask work across all of them. Audited contract code can be reused rather than rewritten.
Major networks that adopted the EVM include:
- Polygon PoS — a sidechain offering lower fees (/coins/polygon/)
- BNB Smart Chain — a high-throughput chain developed by Binance (/coins/bnb/)
- Avalanche C-Chain — the contract chain within the Avalanche ecosystem (/coins/avalanche/)
- Arbitrum and Optimism — optimistic rollups that inherit Ethereum’s security while reducing fees
Even chains built on entirely different foundations — like zkSync and Scroll — have invested in EVM equivalence so that Ethereum developers feel at home.
EVM-compatible vs. EVM-equivalent
There is a subtle but important distinction:
- EVM-compatible means the chain can run most Ethereum contracts. Minor differences in precompiles, opcodes, or gas schedules may exist.
- EVM-equivalent (or “type-1 zkEVM”) means the chain aims to be byte-for-byte identical to Ethereum’s execution layer, making it possible to verify Ethereum blocks directly inside a zero-knowledge proof.
The push toward equivalence is one of the central engineering challenges in layer-2 development.
The limits of the EVM
The EVM’s design reflects priorities from 2015. It was not built for the transaction volumes blockchains now aspire to, and several of its design choices create friction:
- Sequential execution — The EVM processes transactions one at a time within a block, leaving CPU cores idle. Parallel execution is an active area of research.
- Fixed opcode costs — Gas prices are set by protocol rules rather than real-time resource pricing, sometimes leading to mispriced operations that attackers exploit.
- No native randomness — The EVM cannot generate unpredictable randomness on its own, which is why blockchain games and lotteries rely on oracles or commit-reveal schemes.
Ethereum Improvement Proposals (EIPs) regularly adjust the EVM — adding new opcodes, repricing operations, and expanding capabilities — while preserving backward compatibility so existing contracts continue to function.
Key takeaways
- The EVM is a deterministic, stack-based virtual machine that executes smart contract bytecode identically on every Ethereum node.
- Every opcode costs gas, which prevents infinite loops and compensates validators for computation and storage.
- Contracts are stored as bytecode on-chain and called via transactions; high-level languages like Solidity compile down to this bytecode.
- EVM compatibility allows smart contracts and developer tools to be reused across dozens of blockchains without rewriting from scratch.
- The distinction between EVM-compatible and EVM-equivalent matters for zero-knowledge rollups that aim to verify Ethereum execution cryptographically.
- Known limitations — sequential execution, fixed opcode pricing, no native randomness — are active areas of protocol improvement.
Next up: Token Standards