Mcap -- BTC -- ETH -- SOL -- BNB -- XRP -- F&G -- View Market
Loading prices…

EVM

EVM

Ethereum Virtual Machine. The runtime that executes smart contract bytecode on Ethereum and every chain that wants to be compatible with Ethereum's tooling.

Ethereum 3 min read

The EVM — Ethereum Virtual Machine — is the runtime that executes smart contract bytecode on Ethereum. It is a simple stack-based virtual machine with about 140 opcodes, deterministic execution, and a built-in metering system (gas) that counts how much computation every instruction costs. Every Ethereum node runs an EVM implementation, and they all have to produce the exact same result for the same input, because any disagreement would fork the chain.

It is also, by accident of history, the dominant execution environment for smart contracts across the whole crypto industry. Polygon, BNB Chain, Avalanche’s C-Chain, Fantom, Arbitrum, Optimism, Base, zkSync, Linea, Scroll, and dozens of others all run EVM-compatible execution layers. The reason is simple: there are far more Solidity developers than developers for any other smart contract language, there are far more audited EVM contracts than for any other environment, and Metamask speaks EVM natively. Any chain that wants to attract existing developers and users shows up with an EVM.

What It Is Technically

The EVM is deliberately simple. There are no floating-point numbers (all arithmetic is on 256-bit integers), no concurrency (transactions execute sequentially), no I/O beyond reading from contract storage, and no randomness beyond what can be derived from block hashes. This is all by design. The point of a virtual machine for smart contracts is that execution has to be deterministic — every node running the same transaction has to arrive at the same result — and removing sources of nondeterminism is the easiest way to guarantee that.

Contracts are written in a high-level language (Solidity is overwhelmingly the most common, Vyper is a distant second, and a few projects still use raw Yul) and compiled to EVM bytecode. The bytecode gets deployed to an address, and users call its functions by sending transactions. Every opcode executed costs gas, and the transaction fails (with no state changes committed) if it runs out of gas mid-execution.

The Bottleneck

The EVM was designed for correctness rather than performance, and it shows. Execution is single-threaded. Storage reads and writes are expensive. There is no built-in way to parallelise across contracts. All of this was fine when Ethereum was a small network and nobody cared about throughput, but it is a real bottleneck now.

The current response is twofold. Layer 2 rollups (Arbitrum, Optimism, Base) execute EVM bytecode in their own environments and post compressed results back to Ethereum, getting around the base-layer throughput limit while preserving compatibility. Longer term, projects like Monad and Sei are working on parallel-EVM designs that let independent transactions execute simultaneously. Whether any of these meaningfully change the EVM’s position is unclear — the lock-in is enormous, and “compatible with Ethereum” is a competitive moat that has survived a decade of alternatives.