EVM Execution, Gas and Storage
Introduction
This branch treats a contract interaction as an executable trace, not a magical method call. It follows bytes through ABI dispatch, opcodes, call frames, gas accounting, persistent storage, logs, return data, and revert propagation.
Why It Matters
Storage collisions, delegate-call confusion, gas griefing, incorrect return handling, and fork-specific opcodes sit below Solidity syntax. Architecture and security reviews need this lower-level model.
Mental Model
Each call frame has code, caller/context, calldata, stack, transient memory, gas, and returndata; persistent storage belongs to the execution context. Only a successful top-level outcome commits the resulting state changes.
Questions This Branch Answers
- Which address supplies code and which address owns storage?
- What is observable after success versus revert?
- How do fork rules and warm/cold access change behavior and cost?
Scope
Creation/runtime bytecode, ABI, calls, storage/memory/calldata, logs/errors, gas, CREATE2, precompiles, and fork availability.
Out of Scope
Writing a complete production EVM, exhaustive opcode history, gas-price speculation, and treating gas optimization as more important than correctness.
Dependencies
State and consensus, hexadecimal/bytes, hashing, and basic compiler output.
Candidate Note Roadmap
evm-execution-trace— Single-step one transaction from calldata to committed state diff.storage-memory-and-calldata— Contrast lifetime, layout, mutability, and copying costs.bytecode-creation-and-runtime— Inspect deployment code and the runtime artifact it returns.abi-selectors-and-returndata— Encode calls and decode success, errors, and ambiguous return data.calls-delegatecall-and-staticcall— Compare code, storage, sender, value, and mutation contexts.gas-warm-cold-and-refunds— Measure metering without relying on obsolete folklore.logs-reverts-and-custom-errors— Separate receipts and logs from state and return channels.create2-precompiles-and-fork-availability— Test deterministic addresses and fork-specific capabilities.
Future Project
A bytecode and storage-layout laboratory driven by Forge traces and Cast, with tiny contracts that expose every call context and rollback boundary.
Initial Invariants
Decoded calldata selects the intended function; reverted executions commit no persistent mutations or logs; delegate calls preserve the documented storage context; layout probes match compiler metadata.
Initial Threat Model
Returndata confusion, storage collision, gas exhaustion/griefing, unbounded copying, unexpected callbacks, address precomputation mistakes, and opcode/fork mismatch.
Primary Sources
Ethereum execution specifications, Solidity internals documentation, and current EIPs linked through SOURCES.md.
Connects to: Solidity architecture, proxy storage, and exploit labs.