Ethereum Virtual Machine (EVM)

The EVM guarantees that a given smart contract, with the same inputs and state, will produce the exact same output on every node in the network. This determinism is fundamental for consensus, preventing forks caused by differing computational results. It is achieved through a strictly defined instruction set and the absence of random, non-deterministic opcodes.

Every computational step (opcode) in the EVM has a predefined gas cost. This system:

• Prevents infinite loops and Denial-of-Service attacks by requiring upfront payment.
• Decouples the cost of computation from the volatile price of Ether, providing predictable transaction fees.
• Compensates validators for the resources (CPU, memory, storage) they expend executing code.

The EVM is a stack machine, operating on a last-in, first-out (LIFO) data structure with a depth of 1024 items. Most operations pop arguments from the stack and push results back onto it. This design is simple, efficient to implement, and enables formal verification. Complementary memory (volatile byte array) and storage (persistent key-value store) provide additional data handling capabilities.

Smart contracts execute in a completely sandboxed environment. They have no direct access to the host system's files, network, or other processes. Contracts can only interact with:

• The blockchain's own state (storage, balance).
• The context of the current transaction (msg.sender, msg.value).
• Other contracts via defined interfaces. This isolation contains bugs and malicious code, protecting the network's integrity.

Smart contracts written in high-level languages like Solidity are compiled into EVM bytecode, a compact representation of low-level instructions called opcodes. The EVM interprets this bytecode sequentially. Opcodes are categorized into groups for:

• Stack operations (PUSH1, POP)
• Arithmetic & Logic (ADD, LT)
• Control Flow (JUMP, JUMPI)
• Environmental access (CALLER, BALANCE)
• Storage & Memory (SLOAD, MSTORE)

At its core, the EVM is a state transition function. It takes two inputs: the current world state (a mapping of accounts to their balances and storage) and a transaction. It processes the transaction—which may involve contract creation or message calls—and deterministically outputs a new, updated world state and a set of logs. This function is the atomic unit of blockchain state change.

The Ethereum Virtual Machine (EVM) is the runtime environment that executes all smart contracts and transactions on the Ethereum network. It is a deterministic, sandboxed virtual machine that ensures code runs exactly as programmed, isolated from the host computer's network and filesystem. Every node in the network runs the EVM to reach consensus on state changes.

• Key Property: State Machine - It maintains a global state (account balances, contract code) that is updated with each new block.
• Core Function: It processes opcodes (low-level instructions) compiled from high-level languages like Solidity.

An EVM-compatible blockchain is any network that can execute the same bytecode and use the same tooling as Ethereum's mainnet. This is achieved by implementing the EVM specification, allowing developers to deploy existing contracts with minimal changes.

• Primary Benefit: Developer Portability. Tools (MetaMask, Hardhat, Truffle), languages (Solidity, Vyper), and contract logic work across chains.
• Common Implementations: Layer 2s (Arbitrum, Optimism), alternative L1s (Avalanche C-Chain, Polygon PoS), and sidechains (BNB Smart Chain).

The EVM uses a gas metering system to price computational work, preventing infinite loops and allocating network resources. Each opcode has a fixed gas cost, and transactions specify a gas limit and gas price.

• Execution Flow: A transaction triggers the EVM, which runs code until it completes, runs out of gas, or encounters an error.
• State Changes: If execution succeeds, gas is paid to validators, and the global state (like token balances) is permanently updated. Failed transactions revert state changes but still consume gas for the work done.

The EVM's architecture is built around several core data structures and execution concepts:

• World State: A mapping of addresses to account states (balance, nonce, storage root, code hash).
• Storage: A persistent key-value store unique to each smart contract.
• Memory: A volatile, expandable byte array used during contract execution.
• Stack: A last-in-first-out (LIFO) data structure with a max depth of 1024 items, used for all computations.
• Calldata: Immutable input data passed with a transaction.

EVM compatibility has become the dominant standard for smart contract platforms, creating a massive, interconnected multi-chain ecosystem. This drives liquidity fragmentation but also innovation in scalability and specialization.

• Layer 2 Scaling: Rollups (Optimistic & ZK) use the EVM for compatibility while moving execution off-chain.
• Alternative L1s: Networks like Avalanche C-Chain and Polygon PoS use the EVM to attract developers and liquidity from Ethereum.
• Cross-Chain Bridges: Much of the bridge infrastructure is designed to facilitate asset and state transfer between EVM chains.

The EVM executes bytecode, a low-level, machine-readable instruction set compiled from high-level languages like Solidity or Vyper. This bytecode is stored on-chain and defines the contract's immutable logic. Key characteristics include:

• Deterministic Execution: The same bytecode and input always produces the same output.
• Gas Costs: Each opcode in the bytecode has an associated gas cost.
• Immutable Logic: Once deployed, the bytecode cannot be altered, though data storage can change.

Gas is the unit of computational work on the EVM, paid for with the network's native currency (e.g., ETH). It prevents infinite loops and allocates network resources. The gas fee is the transaction cost, calculated as Gas Units Used * Gas Price. Key mechanisms include:

• Gas Limit: The maximum gas a user is willing to spend.
• Base Fee: The minimum fee per gas unit, burned by the protocol (post-EIP-1559).
• Priority Fee: A tip to incentivize validators to include the transaction.

The EVM state is a global data structure mapping accounts to their balances and storage. It consists of:

• World State: The master mapping of all account addresses to their state.
• Account Storage: A key-value store unique to each smart contract, where persistent data is kept.
• Transient Storage: A temporary storage area (introduced in Cancun) that lasts only for the duration of a transaction. State changes are finalized when a block is validated and added to the chain.

Opcodes are the fundamental, low-level instructions that the EVM executes. Each opcode (e.g., ADD, SSTORE, CALL) performs a specific operation and consumes a predefined amount of gas. The complete set defines the EVM's capabilities, including:

• Arithmetic & Logic: ADD, MUL, AND.
• Stack & Memory Operations: PUSH1, POP, MLOAD.
• Storage & Execution Control: SSTORE, JUMP, CALL.
• Blockchain Context: NUMBER, BALANCE, BLOCKHASH.

Networks that implement the EVM specification, allowing them to execute bytecode and smart contracts identical to Ethereum's. This creates massive interoperability. Examples include:

• Layer 2s: Arbitrum, Optimism, Base (use Ethereum for security).
• Sidechains: Polygon PoS, Gnosis Chain.
• Alternative Layer 1s: Avalanche C-Chain, BNB Smart Chain, Fantom.
• Testnets: Goerli, Sepolia, Holesky. Developers can deploy the same contract code across these chains with minimal changes.

The primary high-level programming languages used to write smart contracts for the EVM.

• Solidity: The most widely adopted, object-oriented language, syntactically similar to JavaScript/C++. It enables complex contract structures and inheritance.
• Vyper: A Pythonic language designed for security and simplicity, with fewer features to minimize attack surfaces and enhance auditability. Both compile down to standard EVM bytecode, but promote different design philosophies for smart contract development.