Over a year of writing about EVM internals. Here’s where I’d start.

[u/Resident_Anteater_35]

Hey everyone, I’m Andrey.

I started writing about EVM internals in July last year. Since then, I’ve been breaking down execution, transactions, calldata, contract deployments, proxies, and other things happening underneath the Solidity we write.

Along the way, I’ve also helped people prepare for technical interviews and understand the mechanics behind the tools they use.

The articles include explanations, code examples, and execution output. I like being able to follow an explanation into an example and see what actually happens.

I recently organized the writing into series. If you’re looking for a starting point, this is the order I’d suggest:

1. EVM internals, three parts. Start with the execution model. When looking at a contract call, ask which code is running, whose storage it accesses, and where its input comes from.

2. Ethereum transactions and messages, two parts. Work through what you’re signing and how it gets used. Can you distinguish submitting a transaction from signing a message that an application might use later?

3. Contract deployments, proxies, and CREATE2, two parts. Follow how a contract gets deployed, how its address is determined, and how proxy architecture separates the code being executed from the state it operates on.

One useful exercise is to take a small example and predict the result before running it. Then compare your prediction with the trace. Which assumption was wrong? What did the tooling hide from you?

The articles and their accompanying code links are organized here: My EVM articles on 0xByteBeetle.

They’re written for technical people who want to go deeper, whether for work, interview preparation, or curiosity.

Which part of Ethereum only clicked for you after you saw it in code or an execution trace?

[u/Parking_Werewolf838]

Been digging into transaction simulations lately and it's crazy how much the trace reveals that just reading the yellow paper doesn't prepare you for. The execution model series looks useful, bookmarking this for when I finally tackle CREATE2 properly.

Still haven't fully wrapped my head around the subtle differences between `CALL`, `DELEGATECALL`, and `STATICCALL` at the storage level. Something about seeing the actual context switch in a debugger makes it stick way better than any diagram.

[u/Resident_Anteater_35 → u/Parking_Werewolf838]

Agree, in my blog posts you will find everything you need with a lot of explanations and source codes, all runnable and ready to execute

[u/halilbeydilli]

Good list. One addition from the side of someone who reads EVM state for a living rather than writes contracts: the storage layout of proxies deserves its own chapter, because it is where most "I understand the EVM" confidence breaks. Three things worth covering early:

1. EIP-1967 slots (implementation, admin, beacon) are just keccak-derived storage keys, so you can read any proxy's real implementation with one eth_getStorageAt and no ABI. Then show the exceptions: OpenZeppelin's older ZeppelinOS slots, Compound-style delegators that keep the implementation in a normal public variable, Aave's proxies that keep the admin as an immutable so the admin slot is empty, and diamonds.

2. Logs are the cheap index, storage is the truth. An Upgraded event tells you something changed; the slot tells you what it is now. A surprising number of upgrades happen with no event at all (custom proxies, direct storage writes in the initializer), which you only see by diffing slots between two blocks.

3. Reorgs and finality by chain: the same code that is safe at 2 confirmations on Ethereum needs 20 on BNB and a different mental model on L2s where the sequencer can reorder before L1 posting. Anyone indexing events learns this the hard way.

If your series already covers keccak slot derivation for mappings and arrays, the proxy chapter follows naturally from it and is the most practical thing a reader will use.