Long-form technical writing on execution models, consensus, EVM foundations, and verifiable AI. Each insight makes Web3 clearer.
Editor's pickThree mature paths break past single-threaded execution — Sealevel-style deterministic pre-declaration, Block-STM-style optimistic concurrency control, and Sui-style object models. This piece compares their assumptions, developer costs, and fit with EVM compatibility.
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.
Parallel EVM rarely fails on transfer benchmarks, but often collapses on AMM, lending, and NFT mint traffic. This article explains how conflict hotspots form, how read/write-set granularity drives conflict rates, and how peak TPS degrades under real workloads.
Is higher TPS bought with more expensive hardware and fewer validators? This piece unpacks checkable dimensions — validator requirements, geography, and client diversity — and discusses engineering responses such as BLS aggregation, without hype. Not investment advice.
TPS, BPS, confirmation latency, finality, and conflict rate are routinely blurred together. This piece gives reusable definitions, common misuse patterns, and the disclosure checklist you should demand of any benchmark — not investment advice.
Contract developers, client engineers, and researchers care about parallel EVM for different reasons. This piece gives three reading paths that point only to articles already published on this site, so each audience can find what to read — and what to skip.
"EVM compatible" is often flattened into a marketing line. What actually sets migration cost is bytecode semantics, the precompile set, JSON-RPC behavior, and whether Foundry/Hardhat still work unchanged. This piece separates those four layers and explains why parallelism makes compatibility harder to keep.
Choosing an optimistic parallel EVM Layer 1 means simultaneous trade-offs in settlement domain, compatibility, and parallelism strategy. This piece states what Bitroot solves and does not solve — boundaries, not slogans — and how its technical pieces support each other.
Optimistic concurrency control began in 1981 database research and now underpins many parallel EVMs. This primer explains the read–validate–write phases, contrasts OCC with pessimistic locking and MVCC, and names the extra determinism and Byzantine constraints blockchains add.
Three mature paths break past single-threaded execution — Sealevel-style deterministic pre-declaration, Block-STM-style optimistic concurrency control, and Sui-style object models. This piece compares their assumptions, developer costs, and fit with EVM compatibility.
"Scaling" is often treated as one problem. This piece splits it into consensus, data availability, execution, and settlement — and places L2s, sharding, standalone DA, and L1 parallel execution on that map, including where parallel EVM sits.
Major Ethereum congestion events share one design root — the EVM executes transactions one at a time. This piece explains why raising the gas limit and EIP-1559 cannot rewrite that execution model, and how confirmation delay amplifies the single-thread ceiling.
