About

Turning the black box into a white box.

Ethereum's execution layer is one of the most consequential pieces of software running in the world, and almost nobody outside a few client teams can say they truly understand it. Not because engineers can't — because the material forces a bad choice. On one side: the Yellow Paper and raw client source, precise but unforgiving. On the other: app-layer courses that stop at solidity and never reach the protocol. The bridge between intuition and spec is just… missing.

Whitebox is that bridge. The unit here isn't a wiki page — it's an explorable: one mechanism paired with a live widget you can take apart, layered so you choose your depth. Intuition when you want the shape of the thing. Mechanism when you want to see it move. Real spec and client code when you want the ground truth. And pointers onward when you're ready to go deeper than I can take you in one page.

I write in the first person on purpose. This is how I, as an execution-layer engineer, actually hold these systems in my head — the analogies I reach for, the details that turned out to matter, the places where the spec surprised me. It's a point of view, not an anonymous reference.

How it's built

The widgets aren't illustrations bolted onto prose — they run the real thing. The trie in the main explorable is a genuine Merkle-Patricia Trie: real RLP, real hex-prefix encoding, real keccak256, producing the same stateRoot a live client would, verified byte-for-byte against a reference implementation. If a widget shows you a hash, you can trust the hash.

The two layers

There's an evergreen spine — The Execution Layer, explained — written once and meant to last. And a thin, low-frequency notes layer: short, plain-English reads on what changed in the protocol when a hardfork ships.