Long-form technical writing on execution models, consensus, EVM foundations, and verifiable AI. Each insight makes Web3 clearer.
Editor's pickExecution clients treat the EVM as a swappable executor behind a state-access interface. go-ethereum's built-in interpreter, evmone, and revm occupy different niches; multi-implementation consistency is guaranteed by spec test vectors, while the interpreter's optimization headroom concentrates on dispatch, gas metering, and memory management.
Read article →Execution clients treat the EVM as a swappable executor behind a state-access interface. go-ethereum's built-in interpreter, evmone, and revm occupy different niches; multi-implementation consistency is guaranteed by spec test vectors, while the interpreter's optimization headroom concentrates on dispatch, gas metering, and memory management.
State variables land in 32-byte slots in declaration order: small types share a slot, mappings and dynamic arrays derive positions by hashing, and inheritance order shifts slot numbers wholesale. These placement rules explain why upgradeable proxies must steer clear of the slots the compiler would otherwise assign.
The four call instructions differ by only a couple of numbers in bytecode, yet their semantics decide whose context the code runs in, whose storage it writes, and what msg.sender and address(this) become. Comparing CALL, CALLCODE, DELEGATECALL, and STATICCALL one by one makes clear why proxies depend on DELEGATECALL and why STATICCALL was introduced.
Taking raw calldata apart to explain the ABI: the 4-byte selector comes from truncating the canonical signature, static types fill a whole word, and dynamic types are addressed two levels deep through an offset and a length; events write indexed arguments into topics in exchange for searchability. The ABI is not self-describing, so both decoding and upgrades are constrained.
The Ethereum Yellow Paper writes block-level state transition as a nested call, which makes evaluation order part of the specification. Where one-transaction-at-a-time semantics come from, why read-write set conflicts cannot be determined in advance, what determinism and simplicity of verification buy, and how this design origin is being answered head-on are the threads that follow.
The stateRoot field in a block header is only 32 bytes, yet it binds every account, balance, and contract storage slot across the network. This piece takes apart the node structure of the Merkle Patricia Trie and the design of the storage trie hanging beneath each account, explains how Merkle proofs support off-chain verification, and asks who ends up paying for state bloat.
Gas is the EVM's resource metering unit, while its price is set by the fee market; conflating the two leads to misjudging the boundaries of scaling and execution halts. This piece breaks down intrinsic and dynamic costs, explains what out-of-gas and REVERT each give back, and says who receives EIP-1559's base fee and tip.
The same 32 bytes of data can cost two orders of magnitude more or less in gas depending on whether it sits in memory, storage, or transient storage, and its lifetime is completely different too. This piece takes the three storage kinds apart along three lines — ownership, lifetime, and pricing — and explains where a reentrancy lock, a temporary array, and a state variable each belong.
The EVM is a stack machine with no registers: 256-bit words, a 1024-item stack depth, and a program counter that can only jump to JUMPDEST. The fetch-decode-execute loop explains why stack underflow and overflow burn all the gas, and what a stack machine buys and gives up relative to a register machine.
Treating Ethereum as a ledger of transfers misses its most important part: variables in account storage that can be read and written at will. Following the Yellow Paper's state transition function Υ(σ, T), Ethereum is a distributed state machine, and the EVM is the execution specification for that state transition. Bit-for-bit replay across the whole network then imposes a set of hard constraints on execution semantics.
