Whitebox

Interactive explanations of the execution layer

Ethereum's execution layer,
made transparent.

Most of Ethereum is taught as a black box: dense specs on one side, app-layer tutorials on the other, nothing in between. Whitebox lives in that gap — one mechanism at a time, each with a live widget you can take apart. Written by a practitioner, for engineers who want to actually understand how it works under the hood.

Start with: You could have invented Ethereum → See the full path

Built for

  • Engineers who can read code and reason about systems
  • Node operators & infra people
  • Aspiring core / protocol contributors

Not for

  • "Crypto-curious" newcomers
  • Solidity / dApp beginners
  • Anyone wanting price talk
Start here Flagship explorable

You could have invented Ethereum

One page, one continuous build. Start with a single shared spreadsheet, animate the one thing wrong with it, fix exactly that, and repeat — until a programmable, staked world computer falls out as the only thing it could have become.

Open the explorable →

The Execution Layer, explained

An evergreen, ordered path through how Ethereum's EL actually works. Written once, built to last — not a content treadmill.

  1. 01 You could have invented Ethereum One page, one continuous build. Start with a single shared spreadsheet, animate the one thing wrong with it, fix exactly that, and repeat — until a programmable, staked world computer falls out as the only thing it could have become. Start here
  2. 02 The EVM: turning an account into a computer Chapter 1 gave us accounts and unforgeable, signed transactions — but a transaction could still only do one hard-coded thing: move value. This chapter derives the machine that lets an account run *any* program: a stack, a way to pay for computation, and three places to keep data. Build it and the EVM falls out. Start here
  3. 03 How a node syncs You download a fresh client and it has to catch up to a chain that's been running for years. The way it does that — and the five ways it could — is a clean little derivation, starting from the slowest, most paranoid method and earning every shortcut from there. Networking & sync
  4. 04 State & the trie: one hash for the whole world The EVM computes over storage — but where does that storage actually live, and how does a network of strangers agree it's byte-for-byte identical without shipping gigabytes to each other? This chapter derives the Merkle-Patricia trie: the structure that squeezes all of world state into a single 32-byte root you can update cheaply and prove against. Start here
  5. 05 Flat DB — reading state in one hop The protocol says state is a trie. It never says how to lay that trie on a disk and read it billions of times — and that's exactly where clients quietly compete. Nethermind's Flat DB, by Muhammad Amirul Ashraf, is a ground-up answer. Client internals
  6. 06 How consensus runs The capstone showed why proof of stake works. This is the clockwork that runs it — how a million validators with no leader take turns making one block every twelve seconds and agree on it. Slots, committees, epochs, finality, block builders, and the validator's whole life. Consensus
  7. 07 EIP-1559: the fee market that prices itself Before 1559, every transaction bid blind in a first-price auction — overpay or get stuck. Derive the replacement one fix at a time: a posted price, a thermostat that sets it, elastic blocks for the spikes, and a burn that removes the last bad incentive. EIPs
  8. 08 EIP-4844: blobs, cheap data for rollups Rollups must publish their data on L1 so anyone can verify them — but as permanent calldata it was ruinously expensive. Derive blobs one fix at a time: a separate data lane, a commitment to bind it, pruning after ~18 days, and its own fee market. EIPs
  9. 09 EIP-4337: account abstraction without touching the protocol EOAs are rigid: one key, gas only in ETH, one action at a time. Account abstraction makes accounts programmable — and EIP-4337 pulls it off with zero consensus changes, using a higher-layer transaction, a separate mempool, bundlers, and a singleton EntryPoint. EIPs
  10. 10 EIP-7702: giving your EOA superpowers, in place Account abstraction (4337) made smart accounts — but you had to move to a new address to use them. EIP-7702 upgrades your existing EOA where it sits: sign a delegation, your account points at a contract, and a call runs that contract's code as you — same address, same key. EIPs
  11. 11 EIP-2718: the envelope that let Ethereum add transaction types Ethereum had exactly one transaction format — an RLP list. Every new feature (access lists, the 1559 fee market, blobs, set-code) needed a new shape, and decoders had to guess which one they were looking at. EIP-2718 prefixes every transaction with a single type byte, turning one rigid format into an extensible, versioned family. EIPs
  12. 12 EIP-155: binding a signature to its chain A pre-155 Ethereum signature said who signed and what they signed — but never which network it was for. So the exact same signed bytes were valid on every chain that shared your address, and a transaction could be replayed across a fork like ETH/ETC. EIP-155 folds a chainId into what you sign, so a signature is locked to one chain. EIPs
  13. 13 EIP-4895: getting staked ETH back without a transaction After the Merge, a validator's 32 ETH and its rewards lived on the consensus layer with no way home. A normal transaction can't move them — there's no EOA, no key, nothing on the execution layer to sign. EIP-4895 inverts the flow: the consensus layer pushes withdrawals into each block, and the EVM just credits the balance. EIPs
  14. 14 EIP-3675: swapping Ethereum's engine mid-flight Proof of work secured Ethereum by burning energy — security was hashpower. The Merge replaced that engine with proof of stake while keeping the exact same EVM, accounts, and history. The trick: don't bootstrap PoS in place. Run it on a separate beacon chain first, then hand the steering wheel over at a fixed difficulty. EIPs
  15. 15 EIP-1153: a scratchpad that lasts exactly one transaction Contracts often need to pass data between calls inside one transaction — reentrancy locks, transient approvals, flash-accounting. The only shared mutable store was persistent storage: ~20,000 gas a slot, written to disk forever, even though you throw the value away when the transaction ends. EIP-1153 adds transient storage — same idea, but it vanishes at tx end. EIPs
  16. 16 EIP-4788: teaching the EVM to trust the beacon chain Post-Merge, the consensus layer holds exactly the data staking and restaking contracts need — validator balances, statuses, slashings — but the EVM can't see any of it, so projects leaned on trusted oracles. EIP-4788 exposes the parent beacon block root inside the EVM, so a contract can verify any consensus fact with a Merkle proof and no oracle. EIPs
  17. 17 EIP-2929 & 2930: pricing state access by what it really costs Reading state is the most disk-expensive thing a node does, but the EVM charged a flat, far-too-cheap price for it — so an attacker could touch thousands of slots for almost nothing and grind every node to a halt. The fix prices the first touch at its real cost and makes repeats cheap; access lists let a transaction pre-declare what it will touch. EIPs
  18. 18 EIP-7251: letting one validator hold more than 32 ETH Every validator's stake was capped at 32 ETH of earning balance, so a large staker had to run dozens or hundreds of separate validators — bloating the validator set and the consensus layer's workload, and forcing rewards to stop compounding at 32. EIP-7251 raises the cap to 2048 ETH and lets validators consolidate. EIPs
  19. 19 EIP-7: DELEGATECALL — borrow the code, keep your context Contracts wanted to reuse a shared library's logic without copy-pasting its bytecode into every one. But a normal CALL runs that logic in the library's own storage — useless for a library that's supposed to work on your data. DELEGATECALL runs borrowed code in the caller's context, and in doing so it quietly invented libraries, proxies, and upgradeable contracts. EIPs
  20. 20 EIP-150: when gas became a security parameter In 2016 an attacker discovered that Ethereum's most expensive operations — reading storage, loading accounts — were priced far below what they actually cost a node. A few cheap transactions could grind every node on Earth to a crawl. EIP-150 repriced them, and in doing so turned gas from a nominal fee into a line of defense. EIPs
  21. 21 EIP-140: REVERT — failing cheaply, and saying why Before Byzantium, a contract that hit a bad condition had one blunt option: throw — which undid its work but also torched every drop of the caller's remaining gas and returned no explanation. REVERT keeps the undo, gives the gas back, and lets the contract return an error. Every require("reason"), custom error, and try/catch you've ever written descends from it. EIPs
  22. 22 EIP-1014: CREATE2 — knowing an address before the contract exists A contract's address used to be derived from the deployer's nonce — a counter that changes with every deployment, so you could never predict where a contract would land. CREATE2 derives the address from the deployer, a salt you choose, and the code itself: no nonce. Now you can compute an address, fund it, and hand it out before the contract is deployed at all. EIPs
  23. 23 EIP-1344: CHAINID — replay protection for contract signatures EIP-155 bound transactions to their chain. But contracts increasingly verify their own signed messages — gasless approvals, meta-transactions, off-chain orders — and those had no chain identity, so a signature valid against a contract on one chain replayed against the same contract on another. CHAINID exposes the current chain's id to the EVM, so a contract can bind its signatures to the chain it's actually running on. EIPs
  24. 24 EIP-3529: killing the gas-refund loophole Freeing storage used to hand you a big gas refund — a nice idea that got gamed. Contracts hoarded refunds as 'gas tokens,' and refunds let a block do nearly twice the real work its gas limit implied. EIP-3529 doesn't abolish refunds; it shrinks them and caps them, so cleaning up state still pays a little but the exploit dies — and blocks stay predictable for the new fee market. EIPs
  25. 25 EIP-3541: reserving a byte for the future How do you leave room to add a whole new contract format later, when every possible first byte of code is already a valid opcode? You can't — unless you make one byte off-limits, on purpose. EIP-3541 forbids deploying new code that starts with 0xEF, turning that byte into reserved space that later upgrades (EOF, and EIP-7702's delegation designator) build on. EIPs
  26. 26 EIP-3855: PUSH0 — the opcode for the number everyone needed Putting the constant zero on the stack is one of the most common things EVM code does — and until 2023 there was no instruction for it. Compilers either spent an extra byte on PUSH1 0 or reached for a hack. PUSH0 is a one-byte opcode that does exactly one thing, and because zero is everywhere, that tiny win adds up across every contract. EIPs
  27. 27 EIP-6780: declawing SELFDESTRUCT SELFDESTRUCT could erase a contract's code and free its address — which let a different contract be redeployed at the same address (a 'metamorphic' contract) and made 'a contract can just vanish' a headache for Ethereum's whole state design. Removing it outright would break things, so EIP-6780 restricts it: it only truly deletes if the contract was created in the same transaction. EIPs
  28. 28 EIP-196/197: putting zero-knowledge proofs on-chain Verifying a zk-SNARK means doing elliptic-curve pairing math — thousands of field operations that, written as EVM bytecode, would cost more gas than an entire block holds. EIP-196 and 197 add that math as native precompiles, so a contract can check a proof in a few cheap calls. It's the quiet enabler of on-chain privacy and every validity rollup. EIPs
  29. 29 EIP-214: STATICCALL — a call that promises not to touch anything Contracts constantly call other contracts just to read a value — a price, a balance, a view function. But a normal call lets the callee do whatever it wants, including change state or re-enter you. STATICCALL is a call that the EVM guarantees is read-only: any attempt to modify state inside it reverts. A small guarantee that quietly underpins oracles, view functions, and reentrancy safety. EIPs
  30. 30 Altair: sync committees, or how a phone verifies Ethereum Proof-of-stake is secured by hundreds of thousands of validators — wonderful for security, hopeless for a light client that can't track them all. Altair adds a sync committee: a small, rotating group of 512 validators that signs each block, so a resource-limited client verifies one aggregate signature instead of a million attestations. It's what makes trustless light clients — and the bridges built on them — possible. EIPs
  31. 31 EIP-2028: the price cut that made rollups possible A rollup's whole security rests on posting its transaction data to L1, and that data was priced at 68 gas a byte — so expensive it was the dominant cost of every L2 and kept rollups from adding up. EIP-2028 cut it to 16. That one repricing, in 2019, is what opened the door to the rollup era — the door that blobs later widened. EIPs
  32. 32 EIP-7002: letting the owner, not the operator, exit a validator After the Merge, only a validator's consensus-layer signing key could trigger its exit — but the person who actually owns the stake often holds an execution-layer withdrawal credential, not that key. So a staking pool couldn't force out a rogue operator, and delegated staking rested on trust. EIP-7002 lets the withdrawal-credential holder trigger an exit from the execution layer. EIPs
  33. 33 EIP-4399: PREVRANDAO — where on-chain randomness comes from The EVM is deterministic — there's no 'random' opcode, because every node must compute the same result. Contracts that wanted randomness abused the DIFFICULTY opcode, which was weak and miner-manipulable — and which vanished at the Merge. EIP-4399 repurposes that opcode to expose the beacon chain's RANDAO, giving contracts a real (if biasable) randomness beacon. EIPs
  34. 34 EIP-2537: teaching the EVM the consensus layer's own signatures Ethereum's validators sign with BLS12-381 — a curve chosen for aggregatable signatures and strong security. But the EVM only knew the older, weaker bn128 curve, so a contract couldn't verify a beacon-chain signature at all. EIP-2537 adds native BLS12-381 precompiles, letting contracts check the consensus layer's own signatures — the missing piece for trust-minimized bridges. EIPs
  35. 35 EIP-6110: putting validator deposits in the block To become a validator you deposit 32 ETH to a contract on the execution layer — but the consensus layer used to learn about that deposit by polling and voting on the contract's state, a fragile 'eth1 voting' dance that added ~12 hours before activation. EIP-6110 puts deposits directly in the block, so the consensus layer just reads them. EIPs
  36. 36 EIP-2200: the storage price that postponed a fork Writing the same storage slot three times in one transaction paid full price three times — even though only the final value ever reaches disk. Net gas metering fixed that, but the first attempt (EIP-1283) made writes so cheap that a 2300-gas stipend call could suddenly modify storage, reopening reentrancy — and got Constantinople postponed. EIP-2200 re-ships it with a sentry. EIPs
  37. 37 EIP-3860: metering the code that makes code A contract's runtime bytecode has been size-capped since 2016 — but the initcode that produces it was neither capped nor charged for the O(n) work every node does to process it. Supply megabytes of initcode and the whole network scans it almost for free. EIP-3860 caps initcode and charges per word. EIPs
  38. 38 EIP-2935: keeping block hashes in state The BLOCKHASH opcode can only see the last 256 blocks — about 51 minutes. Older than that, it returns zero. But L2s, provers, and light clients need to reach further back, and stateless clients need those hashes in the state itself, not in a special header cache. EIP-2935 puts them in a ring buffer inside a system contract. EIPs
  39. 39 EIP-5656: the memory-copy opcode the EVM never had Copying a range of memory is one of the most basic things a program does — yet for years the EVM had no instruction for it. Contracts either ran a verbose MLOAD/MSTORE loop or abused the identity precompile as a roundabout memcpy. EIP-5656 finally adds MCOPY: one opcode, one copy. EIPs
  40. 40 EIP-1052: fingerprinting a contract in one opcode To check whether another address runs exactly the bytecode you expect, you used to copy its entire code into memory and hash it yourself — an O(code-size) operation just to get a 32-byte fingerprint. EIP-1052 adds EXTCODEHASH, which returns that hash directly, in constant time. EIPs
  41. 41 EIP-145: giving a 256-bit machine a shift instruction The EVM had AND, OR, XOR, and NOT from day one — but no bit-shift. Contracts faked shifting with multiplication and division by powers of two: costlier, bulkier, and unable to shift signed numbers correctly. EIP-145 adds native SHL, SHR, and SAR. EIPs
  42. 42 EIP-3198 & EIP-7516: letting the EVM read its own fee market EIP-1559 made the base fee a first-class protocol value — computed every block and burned. But a contract couldn't read it: GASPRICE only shows the fused base-plus-priority price the sender paid. EIP-3198 adds BASEFEE; EIP-7516 does the same for blobs. Two tiny opcodes that make the fee market legible on-chain. EIPs
  43. 43 EIP-7594: PeerDAS, blob data without downloading it all Blobs made rollup data cheap — but every node still downloaded every blob, so throughput couldn't grow. Derive PeerDAS one fix at a time: erasure-code each blob, split it into columns, custody a slice, and sample the rest until absence is a near-impossibility. EIPs
  44. ·· More explorables in progress Transactions, gas & the EVM, the mempool, block building, the engine API…