The Ethereum Virtual Machine (EVM) is a quasi-Turing-complete, stack-based virtual machine that serves as the runtime environment for executing smart contracts on the Ethereum blockchain and all EVM-compatible networks. It is the computational engine at the heart of Ethereum, responsible for processing every state transition – from simple ETH transfers to complex decentralized finance (DeFi) protocol interactions – in a deterministic, sandboxed manner that ensures every node on the network reaches the same result for any given transaction.
The EVM operates by executing low-level instructions called opcodes, which are compiled from high-level programming languages such as Solidity and Vyper into bytecode. Each opcode performs a specific atomic operation – arithmetic calculations, memory manipulation, storage reads and writes, cryptographic hashing, and control flow logic. When a user or contract initiates a transaction that calls a smart contract, the EVM loads the contract’s bytecode from the blockchain’s state trie and processes it instruction by instruction, consuming a metered resource called “gas” for each operation. This gas metering mechanism prevents infinite loops and resource abuse by requiring the transaction sender to pay for the computational work their transaction demands.
Critically, the EVM is designed to be completely deterministic and isolated. Given identical inputs and the same blockchain state, every node running the EVM will produce exactly the same output. This determinism is what allows thousands of nodes worldwide to independently verify transactions and maintain consensus on the global state of the Ethereum network. The EVM’s sandboxed design also ensures that smart contract execution cannot access the host machine’s filesystem, network, or operating system, preventing malicious contracts from compromising the nodes that run them.
The EVM’s influence extends far beyond Ethereum itself. Its architecture has become the de facto standard for smart contract execution across the blockchain industry. Major networks including BNB Smart Chain (BSC), Polygon, Avalanche C-Chain, Arbitrum, Optimism, Fantom, Cronos, and dozens of others have adopted EVM compatibility, allowing developers to deploy the same Solidity smart contracts across multiple chains with minimal modification. This cross-chain compatibility has created an enormous ecosystem of shared tooling, developer knowledge, and composable protocols that collectively form the backbone of the decentralized application (dApp) ecosystem.
Origine e storia
2013: Vitalik Buterin published the Ethereum whitepaper, proposing a blockchain with a built-in Turing-complete programming language that could execute arbitrary smart contracts. The whitepaper outlined the concept of a virtual machine as the execution layer, distinguishing Ethereum from Bitcoin’s limited Script language.
2014: Gavin Wood authored the Ethereum Yellow Paper, formally specifying the EVM’s architecture in rigorous mathematical terms. The Yellow Paper defined the instruction set, gas costs, state transition function, and memory model that would govern smart contract execution. This formal specification became the canonical reference for all EVM implementations.
2015: Ethereum launched on July 30 with the Frontier release. The EVM went live with its initial set of approximately 140 opcodes, enabling the first smart contracts to execute on a public blockchain. Early contracts were simple – token issuers and multisig wallets – but they proved the EVM’s viability as a general-purpose computation engine.
2016: The DAO hack on June 17 exposed a critical reentrancy vulnerability in EVM smart contract design. Approximately $60 million worth of ETH (roughly 3.6 million ETH) was drained from The DAO contract through a recursive calling exploit. While the vulnerability was in the smart contract code rather than the EVM itself, the incident catalyzed deep research into EVM security patterns and led to the development of checks-effects-interactions and reentrancy guard design patterns. The fallout also led to Ethereum’s contentious hard fork, which split the chain into Ethereum (ETH) and Ethereum Classic (ETC).
2017-2018: The ICO boom drove massive adoption of Ethereum smart contracts, stress-testing the EVM at unprecedented scale. The ERC-20 token standard became the most widely deployed contract type, and the EVM processed millions of token transfers. CryptoKitties (December 2017) famously congested the network, revealing the EVM’s throughput limitations.
2019-2020: The DeFi summer of 2020 brought protocols like Uniswap, Aave, and Compound into the mainstream, pushing the EVM to handle increasingly complex multi-contract interactions. Gas prices spiked to hundreds of gwei, and EVM gas optimization became a critical skill for Solidity developers.
2021-2022: EVM-compatible chains exploded in popularity. BSC, Polygon, Avalanche, Fantom, and Arbitrum each launched EVM-compatible execution environments, enabling developers to port Ethereum dApps with minimal effort. The term “EVM-compatible” became a marketing requirement for new layer-1 and layer-2 chains.
2022-2024: Ethereum’s Merge to Proof-of-Stake (September 2022) did not change the EVM itself but altered the consensus layer beneath it. Research into EVM successor architectures intensified, with proposals for the EOF (EVM Object Format) upgrade and discussions about eventual migration to eWASM or RISC-V-based execution environments. The Dencun upgrade (March 2024) introduced EIP-4844 blob transactions, expanding the EVM’s data availability capabilities for rollups.
In parole semplici
Think of the EVM as a giant shared calculator that runs the same program on thousands of computers simultaneously. Every computer gets the exact same answer because the calculator’s rules are perfectly defined. If anyone tries to cheat, all the other computers immediately know because their answers don’t match.
Imagine a vending machine with a very detailed instruction manual. When you insert coins (gas) and press buttons (send a transaction), the machine follows its instructions step-by-step to dispense your item (execute the contract). The instruction manual is the same for every vending machine in the world, so you always know what pressing a particular button will do.
The EVM is like a universal translator for smart contracts. A developer writes code in a human-readable language (Solidity), the EVM translates it into machine instructions (bytecode), and then every Ethereum node speaks that same machine language. It’s why a contract written once can run on Ethereum, Polygon, BSC, and Arbitrum without being rewritten.
Picture a notarized escrow service with an incorruptible robot as the agent. You give the robot specific rules (“release this money only when both parties sign”), and the robot follows them precisely – no bribes, no mistakes, no downtime. The EVM is that robot, and the rules are the smart contract code.
It’s like an arcade machine where every game costs tokens. Simple games (basic transfers) cost just a few tokens, while complex games (DeFi swaps through multiple pools) cost many more. If you run out of tokens mid-game, the machine stops and your game is over – but you don’t get your tokens back. That’s how gas works in the EVM.
Importante: The EVM is deterministic but not infallible. Bugs in smart contract code deployed to the EVM can lead to exploits and loss of funds. The EVM executes exactly what it’s told – if the instructions are flawed, the results will be too. Always audit smart contracts before interacting with them, especially when significant value is at stake.
Principali caratteristiche tecniche
Stack-Based Architecture
The EVM uses a last-in-first-out (LIFO) stack with a maximum depth of 1,024 elements
Each stack element is 256 bits (32 bytes) wide, matching Ethereum’s native word size
Arithmetic and logic operations pop operands from the stack and push results back
The stack-based design simplifies formal verification and keeps the implementation compact
Unlike register-based VMs (such as LLVM), the stack architecture avoids register allocation complexity
Opcode Instruction Set
The EVM defines approximately 140+ opcodes organized into categories: arithmetic, comparison, bitwise, hashing, environment, block, stack/memory/storage, logging, system, and push/dup/swap operations
Each opcode has a fixed or dynamic gas cost defined in the Yellow Paper, updated through EIPs (e.g., EIP-2929 increased cold storage access costs)
Migliori DELEGATECALL opcode enables the proxy pattern, which is foundational to upgradeable smart contracts
How EVM Execution Works
A transaction is submitted to the network targeting a contract address with calldata specifying the function and parameters
The EVM loads the target contract’s bytecode from the world state trie into its execution context
A new execution frame is created with allocated memory, an empty stack, and the transaction’s gas limit
The program counter starts at byte 0, and the EVM reads and executes opcodes sequentially
Each opcode consumes gas according to its defined cost – if gas runs out, execution halts with an “out of gas” exception and all state changes are reverted
When execution completes successfully, state changes (storage writes, balance transfers, new contract deployments) are committed to the world state
A transaction receipt is generated containing the execution status, gas used, emitted event logs, and any return data
Gas Metering System
Gas serves as the unit of computational effort, pricing each opcode proportionally to its resource consumption
Simple operations like ADD cost 3 gas, while storage writes (SSTORE) cost 5,000-20,000 gas depending on whether the slot is being set from zero or modified
The base transaction cost is 21,000 gas, with additional costs for calldata (4 gas per zero byte, 16 gas per non-zero byte)
EIP-1559 (London upgrade, August 2021) introduced a base fee that is burned plus an optional priority fee (tip) to the block builder
The block gas limit (~30 million as of 2024) caps total computation per block, effectively limiting EVM throughput
Modello di memoria e archiviazione
Stack: Volatile, 1024-element LIFO stack for intermediate computations – free to use but limited in depth
Memory: Volatile, byte-addressable linear memory that expands as needed – costs gas proportional to the square of allocated size
Storage: Persistent, 256-bit key-value store associated with each contract address – the most expensive resource (20,000 gas for a new slot write)
Calldata: Read-only input data attached to the transaction – cheaper than memory and storage, used for function parameters
Vantaggi e svantaggi
Vantaggi
Svantaggi
Cross-Chain Portability: Smart contracts written for the EVM can be deployed on dozens of EVM-compatible chains (BSC, Polygon, Avalanche, Arbitrum, Optimism) with minimal changes
Performance Limitations: The stack-based architecture and sequential execution model limit throughput to roughly 15-30 transactions per second on Ethereum mainnet
Massive Developer Ecosystem: Solidity is the most widely known smart contract language, with extensive tooling (Hardhat, Foundry, Remix, OpenZeppelin) and developer resources
High Gas Costs: Complex operations on Ethereum mainnet can cost hundreds of dollars in gas fees during peak congestion, pricing out small users
Battle-Tested Security: Nearly a decade of production use with billions of dollars secured, the EVM’s core specification has proven remarkably strong against direct exploits
256-Bit Word Size Overhead: The 256-bit native word size is excessive for most operations, wasting resources on padding and increasing gas costs for simple computations
Deterministic Execution: Guaranteed identical results across all nodes, enabling trustless verification and consensus without central coordination
Limited Computation Model: No native support for floating-point arithmetic, parallelism, or off-chain data access, requiring workarounds for many real-world use cases
Formal Specification: Gavin Wood’s Yellow Paper provides a rigorous mathematical specification, enabling multiple independent implementations (Geth, Nethermind, Besu, Erigon) that interoperate perfectly
Smart Contract Immutability: Once deployed, bytecode cannot be changed – bugs become permanent unless proxy patterns (which add complexity and risk) are used
Rich Composability: The EVM’s standardized interface allows contracts to interact with each other smoothly, enabling DeFi’s “money lego” composability
Storage Bloat: Persistent state storage grows indefinitely. Node storage requirements for standard full nodes are lower due to pruning, but specialized archive nodes (which store the full state history) can require storage exceeding 1 TB
Upgradeability Through EIPs: The opcode set and gas schedule can be updated through Ethereum Improvement Proposals, allowing the EVM to evolve without breaking existing contracts
Reentrancy Vulnerability Surface: The CALL opcode’s ability to transfer execution to external contracts creates a class of reentrancy bugs that remain the most common exploit vector
Risk Management
Rischio di vulnerabilità dei contratti intelligenti
The EVM faithfully executes flawed code – reentrancy attacks, integer overflows (pre-Solidity 0.8), and access control bugs have led to billions in losses
Mitigation: mandate professional audits from firms like Trail of Bits, OpenZeppelin, or Certik before mainnet deployment; use formal verification tools like Certora and K Framework
Implement the checks-effects-interactions pattern and use OpenZeppelin’s ReentrancyGuard for all external calls
Gas Price Volatility Risk
Sudden network congestion can spike gas prices from 10 gwei to 500+ gwei, making contract interactions prohibitively expensive
Mitigation: implement gas price oracles and maximum gas price parameters in dApp frontends; use layer-2 solutions (Arbitrum, Optimism, Base) for cost-sensitive operations
Consider EIP-4844 blob transactions for data-heavy rollup operations
Cross-Chain Compatibility Risk
EVM-compatible chains may implement subtle differences in opcode behavior, precompile availability, or gas scheduling
Mitigation: test contracts on each target chain’s testnet; be cautious with chain-specific opcodes like CHAINID and BASEFEE; maintain per-chain deployment configurations
State Bloat and Sustainability Risk
Every contract deployment and storage write permanently increases the global state, raising hardware requirements for full nodes
Mitigation: minimize storage usage through efficient data packing (multiple values per 32-byte slot); support research into stateless Ethereum and state expiry proposals (EIP-4444)
Rilevanza culturale
The EVM has become the defining standard of the smart contract era, establishing Ethereum’s architectural decisions as the lingua franca of decentralized computing. The phrase “EVM-compatible” has evolved from a technical specification into a marketing buzzword – new blockchain projects routinely advertise EVM compatibility as a core feature, recognizing that access to Ethereum’s developer ecosystem and existing smart contract libraries is essential for adoption.
The Solidity programming language, which compiles to EVM bytecode, has created an entire professional category of “Solidity developers” who command premium salaries in the tech industry. Bootcamps, university courses, and online platforms like CryptoZombies have trained large numbers of developers specifically for EVM-based development.
The EVM’s gas mechanism has permeated crypto culture. Phrases like “gas wars,” “gas optimization,” and “out of gas” have become everyday vocabulary in crypto communities. The frustration of failed transactions due to insufficient gas has spawned countless memes, and the quest for lower gas fees has driven the entire layer-2 scaling narrative.
In the developer community, “EVM equivalence” vs. “EVM compatibility” has become an important distinction. Projects like Optimism’s OP Stack aim for full equivalence (identical opcode behavior), while others settle for compatibility (same Solidity code compiles and deploys but with minor behavioral differences). This distinction matters deeply for security and composability and has become a key evaluation criterion for infrastructure decisions.
Esempi del mondo reale
Uniswap Multi-Chain Deployment
Scenario: Uniswap, the largest decentralized exchange by volume, needed to expand beyond Ethereum mainnet to serve users priced out by high gas fees.
Implementazione Because Uniswap’s smart contracts were written in Solidity for the EVM, the protocol was deployed on Polygon, Arbitrum, Optimism, BSC, Base, Avalanche, and Celo with minimal contract modifications. The same core AMM logic (constant product formula) runs identically on every EVM-compatible chain.
Risultato: Uniswap processes substantial daily trading volume across multiple EVM chains. Users on Arbitrum and Polygon typically pay fractions of a cent per swap compared to several dollars on Ethereum mainnet during congestion, while the protocol’s security model remains fundamentally identical across all deployments.
The DAO Hack and EVM Reentrancy
Scenario: In June 2016, an attacker exploited a reentrancy vulnerability in The DAO’s smart contract, which was deployed on the EVM. The contract’s withdraw function sent ETH before updating the user’s balance, allowing the attacker to recursively call withdraw before the balance was set to zero.
Implementazione The attacker crafted a malicious contract that, when receiving ETH via the EVM’s CALL opcode, would immediately call back into The DAO’s withdraw function. The EVM dutifully executed each recursive call, draining approximately 3.6 million ETH (around $60 million at the time).
Risultato: The Ethereum community executed a controversial hard fork to reverse the theft, creating Ethereum (ETH) and Ethereum Classic (ETC). The incident became the definitive case study for EVM security, leading to the development of reentrancy guards, the checks-effects-interactions pattern, and detailed audit practices that define the industry today.
Aave on Arbitrum via EVM Equivalence
Scenario: Aave, a leading DeFi lending protocol with substantial total value locked, sought to deploy on Arbitrum to offer users lower-cost borrowing and lending.
Implementazione Arbitrum’s Nitro upgrade achieved near-complete EVM equivalence, meaning Aave’s complex multi-contract system (including flash loans, variable/stable rate logic, and governance modules) could be deployed without modification. The same Solidity source code, compiled to the same EVM bytecode, runs on Arbitrum’s optimistic rollup execution environment.
Risultato: Aave on Arbitrum became one of the largest DeFi deployments on any layer-2, with gas costs reduced by roughly 90-95% compared to Ethereum mainnet. The smooth deployment demonstrated the power of EVM equivalence for complex protocol migrations.
NFT Minting Gas Wars
Scenario: During high-profile NFT launches like Yuga Labs’ Otherside mint (April 30, 2022), thousands of users simultaneously attempted to execute EVM transactions to mint NFTs, creating extreme gas competition.
Implementazione Users set increasingly high gas prices to ensure their minting transactions were included in the next block, with some reports of gas costs reaching roughly 2-2.5 ETH per mint at the peak. The EVM processed each minting call sequentially within each block, with block builders ordering transactions by gas price.
Risultato: The Otherside mint burned over $150 million in ETH gas fees within about 24 hours (estimates from multiple outlets range from roughly $150 million to $176 million), demonstrating both the EVM’s robustness under extreme load and its fundamental throughput limitations. The event accelerated adoption of EVM-based layer-2 solutions for future NFT launches.
Tavola di comparazione
Caratteristica
EVM (Ethereum)
SolanaVM (SVM)
CosmWasm (Cosmos)
Move VM (Aptos/Sui)
Architettura
Stack-based, 256-bit word
Register-based, BPF bytecode
WebAssembly-based
Register-based, resource-oriented
Lingua madre
Solidità, Vyper
Rust, C
Ruggine
Sposta
Modello di esecuzione
Sequential per block
Parallel (Sealevel)
Sequential per block
Parallel (object-centric)
Gas/Fee Model
Gas with base + priority fee
Compute units + priority fee
Gas with configurable pricing
Gas units with storage rebates
Cross-Chain Adoption
50+ chains (BSC, Polygon, Arbitrum, etc.)
SVM-compatible chains emerging
IBC-connected chains (50+)
Limited (Aptos, Sui, Movement)
Ecosistema degli sviluppatori
Largest (Hardhat, Foundry, OpenZeppelin)
Growing (Anchor framework)
Moderate (CosmWasm tooling)
Emerging (Move Prover)
Verifica formale
Yellow Paper specification; K-EVM
Limited formal tooling
Moderate (CosmWasm checks)
Move Prover (built-in)
Termini correlati
Solidity – The most widely used high-level programming language for writing EVM smart contracts, featuring static typing, inheritance, and an extensive standard library.
Gas (Etereo) – The unit of computational effort required to execute operations on the EVM, paid by transaction senders to compensate validators for processing their transactions.
Smart Contract – Self-executing programs stored on the blockchain and run by the EVM, containing the business logic for decentralized applications.
Bytecode – The low-level machine code compiled from Solidity or Vyper that the EVM directly executes, consisting of sequences of opcodes and their arguments.
EVM-Compatible Chain – Any blockchain that implements the EVM specification, allowing Solidity smart contracts to be deployed and executed without modification.
Rollup di livello 2 – Scaling solutions like Arbitrum and Optimism that execute EVM transactions off-chain and post compressed proofs or data back to Ethereum for security.
Carta gialla di Ethereum – Gavin Wood’s formal mathematical specification of the EVM, defining every opcode, gas cost, and state transition rule.
ABI (Application Binary Interface) – The standard encoding format for calling EVM smart contract functions and decoding their return values, enabling interoperability between contracts and frontends.
EIP-1559 – The Ethereum Improvement Proposal that reformed the EVM’s gas fee market by introducing a burned base fee and optional priority tip mechanism.
Contratto di delega – A design pattern using the EVM’s DELEGATECALL opcode to create upgradeable smart contracts by separating storage from logic.
Opcodes – The fundamental instruction set of the EVM, each performing a single atomic operation such as addition, storage access, or contract calling.
State Trie – The Merkle Patricia Trie data structure that stores the global state (account balances, contract storage, bytecode) accessed by the EVM during execution.
FAQ
Q: What does “EVM-compatible” mean and why does it matter? A: EVM-compatible means a blockchain implements the same virtual machine specification as Ethereum, allowing smart contracts written in Solidity to be deployed without modification. This matters because it gives new chains instant access to Ethereum’s massive ecosystem of developer tools (Hardhat, Foundry, Remix), audited contract libraries (OpenZeppelin), and existing dApp codebases. Chains like BSC, Polygon, Avalanche C-Chain, Arbitrum, and Optimism are all EVM-compatible, which is why the same protocols (Uniswap, Aave, SushiSwap) can operate across all of them.
Q: Why does the EVM use gas instead of just charging fixed fees? A: Gas exists because different operations consume vastly different amounts of computational resources. A simple addition takes negligible effort, while writing to persistent storage requires disk I/O across thousands of nodes globally. Gas prices each operation proportionally to its true resource cost, preventing attackers from spamming the network with expensive computations at low cost. The gas mechanism also provides a natural halting guarantee – even if a contract contains an infinite loop, it will eventually run out of gas and stop, protecting the network from denial-of-service attacks.
Q: What happens when a smart contract runs out of gas during EVM execution? A: When gas is exhausted mid-execution, the EVM immediately halts and reverts all state changes made during that transaction – storage writes, balance transfers, and contract creations are all undone as if the transaction never happened. However, the gas fee is still consumed and paid to the block validator, because the computational work was already performed. This is why setting an appropriate gas limit is important: too low and the transaction fails (wasting the gas), too high and you risk overpaying if the operation completes early (though unused gas is refunded).
Q: How is the EVM different from a regular computer’s processor? A: Unlike a physical CPU, the EVM is a virtual machine – software that simulates a computer. Key differences include: (1) the EVM is completely deterministic, meaning it produces identical outputs on every machine, while physical CPUs can have non-deterministic behaviors; (2) the EVM charges for every operation via gas, while CPUs process instructions at hardware speed; (3) the EVM has persistent blockchain storage, while CPU memory is volatile; (4) the EVM runs identically on thousands of nodes simultaneously, while a CPU runs on a single machine. Think of it as a deliberately slow, deliberately expensive computer designed for trustless global consensus rather than performance.
Q: Can EVM smart contracts be updated or fixed after deployment? A: Directly, no – EVM bytecode is immutable once deployed. However, the proxy pattern (using the DELEGATECALL opcode) allows developers to create upgradeable contracts. A proxy contract stores the state and delegates execution to an implementation contract that contains the logic. To upgrade, developers deploy a new implementation contract and update the proxy to point to it. This pattern is used by most major DeFi protocols but introduces governance and centralization risks (whoever controls the proxy upgrade can change the contract’s behavior). Transparent proxies (EIP-1967) and UUPS proxies are the most common implementations.
Q: What is the difference between EVM equivalence and EVM compatibility? A: EVM compatibility means a chain can run Solidity smart contracts, but there may be subtle differences in opcode behavior, gas costs, or precompile availability. EVM equivalence means the chain implements the EVM specification identically, opcode-for-opcode, so that even low-level bytecode and debugging tools work exactly as they do on Ethereum. Optimism’s Bedrock upgrade and Arbitrum Nitro both aim for EVM equivalence, while older chains like BSC are EVM-compatible but not fully equivalent. Equivalence matters for complex contracts that depend on specific gas costs or opcode behaviors.
Q: Will the EVM eventually be replaced? A: There are active proposals and research into EVM successor technologies, including eWASM (Ethereum-flavored WebAssembly), RISC-V, and the EOF (EVM Object Format) upgrade path. However, replacing the EVM faces an enormous backwards-compatibility challenge – billions of dollars in smart contracts are deployed as EVM bytecode, and any replacement must either support existing contracts or provide a smooth migration path. The most likely near-term evolution is the EOF upgrade series, which modernizes the EVM bytecode format while maintaining compatibility. A full replacement, if it happens, is likely years away and would need to coexist with the current EVM for an extended transition period.
I prestiti garantiti da Bitcoin stanno entrando in quello che Silicon Valley Bank descrive come un nuovo capitolo istituzionale, con standard di prestito più rigorosi, in crescita
L'Unione Europea sta rivalutando la sua storica normativa sulle criptovalute a soli tre anni dall'entrata in vigore del quadro normativo Markets in Crypto Assets (MiCA).
