How Does the Ethereum Virtual Machine (EVM) Work?
Ethereum is known not only as the second-largest cryptocurrency by market cap, but also as the first widely adopted programmable blockchain. The ability to deploy smart contracts and build DeFi protocols, NFT marketplaces, DAOs, games and other decentralized applications has turned it into the foundation of the wider Web3 ecosystem. At the core of this programmability is the Ethereum Virtual Machine (EVM) — the virtual machine that executes smart contract code and defines how the state of the network changes.
In this guide, we will take a deep look at what the EVM is, how it is structured, what its architecture consists of, how bytecode is executed, why gas is needed, what kinds of accounts and state exist, what opcodes are, why EVM-compatibility has become a standard for new blockchains, and what the future might look like for the EVM in the context of Ethereum scaling.
1. What Is the Ethereum Virtual Machine in Simple Terms?
The Ethereum Virtual Machine is an abstract computing machine that executes smart contract code on the Ethereum network. It runs on top of the blockchain and provides:
- identical execution results on all nodes in the network;
- isolation and security for smart contract execution;
- state management for all accounts and contracts;
- resource limitations via the gas mechanism.
In simple terms, the EVM is often referred to as a global decentralized computer. Every Ethereum node runs its own local instance of the EVM, which executes the same instructions and thus synchronously maintains the same blockchain state.
2. Core Functions of the EVM
The EVM performs several fundamental functions without which Ethereum would not work as it does today:
- Execution of smart contracts. All code written in Solidity, Vyper or other languages is compiled into bytecode that the EVM executes.
- State transitions. Each transaction is a transition from one global network state to another; the EVM ensures this transition is correct.
- Account management. It maintains user and contract accounts, their ETH balances, nonces, code and storage.
- Gas accounting. The EVM calculates how many computational resources each operation consumes and enforces limits.
- Deterministic execution. The same transaction must produce exactly the same result on all nodes.
3. EVM Architecture: Main Components
The EVM is a stack-based virtual machine that behaves somewhat like a simple processor. It operates on several key data structures and abstractions.
3.1. Accounts in the EVM
Ethereum has two types of accounts:
| Account Type | Description | Key Characteristics |
|---|---|---|
| EOA (Externally Owned Account) | An account controlled by a user's private key. | Has an ETH balance and a nonce but no code. Transactions can only be initiated from EOAs. |
| Contract Account | A smart contract account that stores code and persistent storage. | Has no private key and cannot “sign” transactions itself. It is activated by calls from other contracts or EOAs. |
3.2. Stack
The stack is the primary data structure used by the EVM. It is a LIFO structure (last in, first out) that can hold up to 1024 elements. All arithmetic, logical and many other operations work via the stack: instructions read operands from the stack and push results back.
3.3. Memory
Memory is a temporary, byte-addressable, linear storage space available during a transaction or contract call. After the call finishes, memory is discarded. The cost of using memory grows as the amount of memory used increases.
3.4. Storage
Storage is a contract’s persistent memory. Data in storage is kept on-chain permanently (as long as the chain exists), which is why any SSTORE operations are among the most expensive in terms of gas. Storage is organized as a key–value store with 256-bit words.
3.5. Bytecode and Opcodes
Smart contracts are typically written in high-level languages like Solidity. They are then compiled into bytecode — a sequence of instructions composed of opcodes (operation codes). These opcodes are what the EVM actually executes.
Examples of opcodes:
ADD,MUL,SUB— arithmetic operations;AND,OR,NOT— logical operations;SLOAD,SSTORE— interacting with storage;CALL,DELEGATECALL— calling other contracts;JUMP,JUMPI— modifying control flow;LOG1–LOG4— generating events (logs).
4. The Gas Mechanism: How the EVM Limits Resources
Like any computing system, Ethereum needs a mechanism to prevent abuse of computational resources. In centralized systems, this is controlled by admins or server limits. In decentralized Ethereum, this is enforced by the gas mechanism.
Gas is the unit that measures how much computational work a given operation requires in the EVM. Every instruction has a gas cost. For example, a simple addition may cost a few gas units, while a storage write can cost thousands.
| Operation | Opcode Example | Typical Cost (gas, approximate) |
|---|---|---|
| Arithmetic | ADD, MUL |
3–5 |
| Storage read | SLOAD |
800 |
| Storage write (new slot) | SSTORE |
20 000 |
| Contract call | CALL |
700 + variable part |
The cost of a transaction in ETH is determined by the formula:
Transaction Cost = Gas Used × Gas Price
The user specifies a gas limit (max gas) and a gas price (or max fee), and the network calculates how much was actually consumed. If gas runs out before the contract finishes, the transaction is reverted, and state changes are rolled back (except for gas already spent). Any unused gas (within the specified limit) is refunded according to the current fee model.
5. How the EVM Executes a Smart Contract: Step-by-Step Example
5.1. Step 1: Creating and Signing a Transaction
A user (EOA) creates a transaction: specifying the contract address to call, the call data (encoded function selector + arguments), gas limit, max fee, etc. The transaction is then signed with the user’s private key.
5.2. Step 2: Entering the Mempool
Once signed, the transaction is broadcast to the network and enters the mempool — the set of all pending transactions waiting to be included in a block. Validators select transactions with the most attractive fees.
5.3. Step 3: Transaction Processing by a Validator
When a validator (in Ethereum’s Proof of Stake era) builds a block, they sequentially execute transactions in the EVM. For each transaction:
- the signature and structure are verified;
- it is checked whether the account has enough balance to pay for gas;
- the sender’s nonce is validated and incremented;
- the contract’s bytecode is loaded into the EVM.
5.4. Step 4: Bytecode Execution
The EVM starts executing the contract’s opcodes. Each instruction:
- reads/writes data to the stack, memory, or storage;
- updates the internal state of the virtual machine;
- reduces the remaining gas balance.
If an error occurs or gas runs out during execution, the transaction is considered failed, and any state changes (except for the gas cost) are reverted.
5.5. Step 5: Updating the Global State
After a contract executes successfully, the EVM produces a new state:
- account balances are updated;
- contract storage is modified;
- logs (events) are generated and become available via RPC and indexers;
- the block’s state root is updated.
The new block with the updated state is broadcast to other nodes, which re-execute the same transactions and must reach exactly the same result. If a node gets a different result, it rejects the block.
6. Ethereum’s State Model and the EVM’s Role
Ethereum’s state is represented as a set of accounts and relationships between them. Internally, it is stored as tree-like data structures (Merkle Patricia Tries), which allow efficient integrity checks and provide cryptographic “fingerprints” of the state.
The EVM acts as a state machine: the previous state and a batch of transactions go in, and a new state comes out. This process is strictly deterministic: there are no random elements that could alter the result of execution.
7. Programming Languages and the EVM: Solidity, Vyper and Others
Although the EVM itself only understands bytecode, developers almost never write contracts directly in opcodes. Instead, they use high-level languages that compile down to EVM bytecode.
- Solidity — the most popular language for Ethereum, syntactically similar to JavaScript/TypeScript.
- Vyper — a more minimal language with Python-like syntax and a stronger focus on simplicity and security.
- Yul — a lower-level intermediate language closer to raw EVM bytecode.
The process looks like this: a developer writes a contract in Solidity → the compiler (e.g. solc) converts the code into bytecode → at deployment, this bytecode is stored in the contract account → on each call, the EVM reads this bytecode and executes it.
8. Advantages of the EVM as a Computational Model
The Ethereum Virtual Machine offers several important advantages that have made it a de facto standard:
- Universality. The EVM is a Turing-complete machine: in theory, you can implement any logic on it.
- Decentralization. The same logic runs on thousands of nodes with no central controller.
- Security. Execution isolation, gas limits, and a clear state model.
- Cross-chain compatibility. Many blockchains implemented EVM compatibility, enabling the same smart contracts to run in different networks.
- Huge ecosystem. Tools, libraries, frameworks and a massive number of examples and battle-tested contracts.
9. Limitations and Drawbacks of the EVM
The EVM also has weaknesses that developers must keep in mind:
- Limited throughput. Every node must re-execute the same code, so complex computations are expensive.
- Expensive storage. Persistent on-chain storage is very costly, forcing developers to optimize every byte.
- Risk of bugs in contracts. Smart contracts are immutable in practice: one bug can cost millions.
- Isolation from the outside world. Contracts cannot directly call HTTP APIs or databases — they must rely on oracles.
10. EVM-Compatible Blockchains
The popularity of the EVM has led other blockchains to implement compatibility with it in order to attract existing Ethereum developers and projects. This lets teams deploy the same smart contracts with minimal or no changes.
The best-known EVM-compatible networks include:
- BNB Chain;
- Polygon (PoS chain);
- Avalanche C-Chain;
- Fantom;
- Arbitrum, Optimism (L2 networks for Ethereum);
- Gnosis Chain and others.
EVM compatibility has become a kind of “gold standard” for new chains because developers don’t need to learn new languages or tooling — it’s enough to know Solidity and the Ethereum tooling stack.
11. Smart Contract Security and the EVM’s Role
While the EVM provides deterministic execution and resource limits, smart contract security depends heavily on the developer. The EVM does not “understand” whether the contract’s logic matches the intended economic design: it simply executes the bytecode.
Common smart contract vulnerabilities include:
- Reentrancy attacks (re-entering the same function before the previous call is fully completed);
- Integer overflow/underflow (for older Solidity versions without built-in checks);
- Incorrect access control (missing
onlyOwner, hidden backdoors); - Oracle manipulation (price or data feeds being exploited);
- Business logic errors (incorrect formulas, wrong order of operations, etc.).
To mitigate these risks, teams use smart contract audits, formal verification, standardized libraries (such as OpenZeppelin), and robust coding patterns and best practices.
12. The Future of the EVM: Scaling and Evolution
Ethereum is actively moving toward scaling and greater efficiency. This evolution directly impacts the role of the EVM.
12.1. L2 Solutions and Rollups
Increasingly, computation is being moved to Layer 2 solutions (Arbitrum, Optimism, zkSync, Scroll, etc.), many of which preserve EVM compatibility or even implement zkEVM — proofs of correct EVM execution using zero-knowledge technology.
12.2. eWASM and Potential EVM Replacement
For several years, the Ethereum community has discussed a potential move from the EVM to eWASM (Ethereum-flavored WebAssembly), which could potentially:
- be faster and more efficient;
- support many more programming languages;
- provide a more flexible execution model.
However, the EVM has such a massive ecosystem that a complete and rapid migration is unlikely. A gradual integration or hybrid models are more realistic scenarios.
13. Conclusion
The Ethereum Virtual Machine is the foundation on which the modern Ethereum ecosystem is built, as well as a large part of the wider multi-chain Web3 landscape. It determines how smart contracts are executed, how network state changes, how resources are accounted for, and how deterministic, secure execution is guaranteed.
Understanding how the EVM works is critically important for smart contract developers, DeFi protocol architects, security auditors, and anyone seriously involved with Ethereum or EVM-compatible chains. Knowledge of the stack, memory, storage, gas, transactions, account types and the state model makes it possible to write more efficient, secure and gas-optimized code.
In the coming years, the EVM’s role is unlikely to diminish. On the contrary, thanks to rollups, zkEVM solutions and L2 infrastructure, it may become even more central as a shared standard across many blockchain networks that together form a single programmable global economy.
