Chapter 12 Key Takeaways: The Ethereum Virtual Machine

Core Concepts

1. The EVM is a deterministic, stack-based virtual machine

Every Ethereum node runs its own copy of the EVM. Given identical state and the same transaction, every node must produce identical results. The EVM achieves this through a stack-based architecture with a 256-bit word size, approximately 140 opcodes, and strict sandboxing that forbids all nondeterministic operations (I/O, randomness, network access). The stack holds up to 1,024 items, but only the top 16 are directly accessible.

2. The three data locations have dramatically different costs

• Stack: Free (cost is embedded in opcodes). Volatile. Limited to 1,024 items.
• Memory: Cheap for small sizes (3 gas per word), but expansion cost is quadratic. Volatile — resets each call.
• Storage: Extremely expensive (20,000 gas for new slot, 5,000 for update, 2,100 for cold read). Persistent across transactions. This is where state lives.

The single most important gas optimization principle: minimize storage writes. One SSTORE costs as much as ~6,600 ADD operations.

3. Gas costs reflect real network resource consumption

Gas pricing is not arbitrary. It tracks the hardware cost hierarchy: CPU operations (ADD: 3 gas) are cheapest, memory operations (MLOAD: 3 gas + expansion) are moderate, and disk/state operations (SSTORE: up to 20,000 gas) are expensive. The cold/warm distinction (EIP-2929) adds precision by charging more for first-time access (disk read) than cached access (memory hit). Gas costs are also a security mechanism — they prevent DoS attacks, ensure execution termination, and historically provided implicit reentrancy protection through the .transfer() gas stipend.

4. Solidity compiles to two distinct bytecode phases

Creation bytecode runs once during deployment: it executes the constructor, initializes state, then copies and returns the runtime bytecode. Runtime bytecode is stored permanently on-chain and contains the function dispatcher (matching 4-byte selectors from calldata to function bodies) and all function implementations. Understanding this two-phase model explains why constructors cannot be called after deployment and why contract code is immutable.

5. Contract interaction opcodes have distinct security properties

• CALL: Executes code at another address in a new context (new stack, memory; target's storage).
• STATICCALL: Like CALL but enforces read-only — reverts on any state modification.
• DELEGATECALL: Executes target's code in the caller's context (caller's storage, msg.sender, msg.value). Powers proxy patterns but is dangerous if storage layouts are mismatched.

The call stack is limited to 1,024 frames. Failed calls push 0 on the stack; they do not automatically revert the caller.

6. ABI encoding standardizes all external contract communication

Function calls are identified by a 4-byte selector (first 4 bytes of keccak256 of the function signature). Parameters are encoded in 32-byte words: static types inline, dynamic types via offset/data pointers. Events encode indexed parameters as topics (enabling efficient filtering) and non-indexed parameters in the data field. Custom errors (Solidity 0.8.4+) use the same selector scheme, saving gas versus string error messages.

7. The sandbox is the foundation of trustless execution

The EVM's inability to perform I/O, access files, generate randomness, or make network requests is not a limitation — it is the mechanism that makes decentralized consensus possible. Every restriction eliminates a source of nondeterminism. The oracle problem (needing external data on-chain) is a direct consequence of this design, solved through oracle networks rather than VM modification.

Common Misconceptions

Rules of Thumb

1. When estimating gas, count the SSTOREs. Storage operations typically dominate total gas cost for any function that modifies state. Everything else is rounding error by comparison.

2. Cache storage reads in local variables. The first SLOAD costs 2,100 gas (cold). Reading the same slot again costs only 100 gas (warm), but reading a local variable on the stack costs 3 gas. For values read multiple times, uint256 cached = stateVar; saves gas.

3. Pack structs carefully. Solidity packs multiple variables smaller than 256 bits into single storage slots. Ordering struct fields by size (smallest together) minimizes the number of slots and thus the number of SSTORE operations.

4. Never rely on gas costs for security. Gas prices change with network upgrades. Any security assumption that depends on a specific gas cost (like the 2,300 stipend preventing SSTORE) can be invalidated by a future EIP.

5. DELEGATECALL is a loaded weapon. It executes foreign code with full access to your storage. Use established proxy patterns (OpenZeppelin's TransparentProxy or UUPS) rather than rolling your own.

6. Check return values from CALL. At the EVM level, a failed CALL does not revert the caller. Solidity's high-level syntax adds checks automatically, but low-level .call() does not.

7. Understand what lives where. If you cannot answer "is this variable on the stack, in memory, or in storage?" for every piece of data in your function, you do not yet understand your contract's gas profile.

Key Formulas and Numbers

Bridge to Chapter 13

You now understand the machine. In Chapter 13, you will learn to program it. Solidity is a high-level language that compiles to the opcodes, stack operations, and storage patterns covered in this chapter. Every Solidity construct — mapping, require, modifier, event, inheritance — has a direct translation to EVM bytecode. When a Solidity function "does not work as expected," the EVM-level behavior is always the ground truth. The bytecode does not lie.