Interactive, explorable explanations of how Ethereum really works — cryptography, state, the EVM, consensus, and networking — for engineers who want real depth, not hand-waving.https://ankushindaniil.github.io/https://ankushindaniil.github.io/whitebox/eip-150-io-repricing/https://ankushindaniil.github.io/whitebox/eip-150-io-repricing/A step-by-step derivation of EIP-150 (Tangerine Whistle, October 2016). Why IO-heavy opcodes like SLOAD, CALL, BALANCE, and EXTCODESIZE were priced far below their real disk cost; how the 2016 Shanghai denial-of-service attacks exploited that gap to nearly halt the chain; the realization that gas is a security parameter that must track real resource consumption, not a nominal price; how EIP-150 sharply raised those opcodes' costs and added the 63/64 rule capping how much gas a call can forward; and the legacy — it broke gas-hardcoded contracts, spawned the empty-account cleanup of EIP-161, and its blunt across-the-board raise is what EIP-2929 later refined into cold/warm access pricing.Sun, 13 Sep 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-214-staticcall/https://ankushindaniil.github.io/whitebox/eip-214-staticcall/A step-by-step derivation of EIP-214 (STATICCALL), shipped in Byzantium (October 2017). Why calling another contract merely to read something was dangerous — an ordinary CALL lets the callee execute arbitrary code, including modifying its own or others' state and re-entering the caller, so reading from an untrusted contract was an attack surface; and how STATICCALL (0xFA) fixes it by executing the callee in a frame where any state-changing opcode (SSTORE, CREATE, SELFDESTRUCT, LOG, value-bearing CALL) reverts, guaranteeing a read-only call — which is how Solidity enforces view/pure calls at the EVM level, how contracts safely read untrusted oracles, and a building block for reentrancy safety.Sun, 13 Sep 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-2929-2930-access-lists/https://ankushindaniil.github.io/whitebox/eip-2929-2930-access-lists/A step-by-step derivation of EIP-2929 (gas cost increases for state access) and EIP-2930 (optional access lists) — why a single flat price for SLOAD and account access is the wrong shape — too cheap for a cold first touch that hits disk, too dear for the common case of touching the same slot repeatedly, and how cold/warm pricing fixes both: the first access to an address or storage slot in a transaction is 'cold' and pays the real cost (2600 for an account, 2100 for a slot) while every repeat is 'warm' at 100 gas, tracked in a per-transaction access set — and how EIP-2930's type-0x01 access-list transaction (the first user of the EIP-2718 envelope) lets a transaction pre-declare the addresses and slots it will touch so their first access is charged the warm price, for a small upfront fee.Sun, 13 Sep 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-4844-blobs/https://ankushindaniil.github.io/whitebox/eip-4844-blobs/A step-by-step derivation of EIP-4844 (proto-danksharding) — why rollups must post data for availability, why calldata was the wrong place (permanent and priced against execution), and how blobs fix it: a separate EVM-invisible data lane, a 48-byte KZG commitment that binds each blob, pruning after ~18 days (availability, not storage), and a separate blob-gas fee market. The change that dropped L2 fees by 10–100×.Sun, 13 Sep 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-7594-peerdas/https://ankushindaniil.github.io/whitebox/eip-7594-peerdas/A step-by-step derivation of EIP-7594 (PeerDAS), the headline of Ethereum's Fusaka upgrade (mainnet December 3, 2025). EIP-4844 gave rollups a cheap data lane, but every full node still downloaded and stored every blob — capping how far blob throughput could rise. PeerDAS fixes it with data-availability sampling: each blob is erasure-coded so any 50% reconstructs the whole, split into 128 columns spread across the p2p network, each node custodies only a slice, and verifies the rest is available by randomly sampling columns — driving the odds of undetected withheld data to cryptographically negligible. With blob-parameter-only (BPO) forks raising capacity between hardforks, this is Ethereum's first step into Danksharding.Sun, 13 Sep 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/how-a-node-syncs/https://ankushindaniil.github.io/whitebox/how-a-node-syncs/A step-by-step, animated derivation of Ethereum node sync. Start by replaying every block from genesis (full sync), then earn each faster method as a fix for the last one's flaw — fast sync (download the trie), snap sync (flat ranges + heal), light clients (headers + proofs), and checkpoint sync (trust a recent finalized anchor). Each trade between trust, speed, and disk made concrete.Sun, 13 Sep 2026 00:00:00 GMTNetworking & syncexplorablehttps://ankushindaniil.github.io/whitebox/how-consensus-runs/https://ankushindaniil.github.io/whitebox/how-consensus-runs/A step-by-step, animated tour of how Ethereum's proof-of-stake consensus actually runs — 12-second slots and the RANDAO proposer lottery, committees and attestations, epochs with Casper-FFG justification and finalization, proposer-builder separation (builders, relays, MEV-Boost), and the validator lifecycle from a 32-ETH deposit through attesting to exit or slashing. Each piece derived from the flaw in the last.Sun, 13 Sep 2026 00:00:00 GMTConsensusexplorablehttps://ankushindaniil.github.io/whitebox/state-and-the-trie/https://ankushindaniil.github.io/whitebox/state-and-the-trie/A from-scratch derivation of Ethereum's state trie. Starting from the need for every node to agree on identical world state, we invent the Merkle-Patricia trie one flaw-fix at a time: a plain map has no fingerprint; one hash commits but forces a full re-hash and proves nothing in isolation; a Merkle tree gives cheap updates and inclusion proofs; making the key itself the path yields a canonical trie; and collapsing unbranched runs gives the Merkle-Patricia trie. Covers the leaf/extension/branch node types, why keys are hashed into nibbles, how a single balance change re-hashes only its path to a new state root, and how that root sits in the block header so agreeing on a header means agreeing on all of state.Sun, 13 Sep 2026 00:00:00 GMTStart hereexplorablehttps://ankushindaniil.github.io/whitebox/eip-1052-extcodehash/https://ankushindaniil.github.io/whitebox/eip-1052-extcodehash/A step-by-step derivation of EIP-1052 (the EXTCODEHASH opcode), shipped in Constantinople (February 2019). Why obtaining a fingerprint of another account's code was expensive — the only tools were EXTCODESIZE and EXTCODECOPY, so to hash a contract's code you had to copy the whole thing into memory (cost proportional to its size, plus memory expansion) and then run KECCAK256, all to produce a single 32-byte identity — and how EIP-1052 adds EXTCODEHASH (0x3f), which returns the keccak256 of an account's code in one constant-time opcode; plus the sharp edges to handle: a non-existent account hashes to zero while an existing account with no code (an externally owned account) hashes to the well-known empty-string hash, and the classic 'code size is zero' contract-detection trick remains defeatable during a contract's constructor; the payoff is cheap code-identity checks — verifying a counterparty runs known-safe bytecode, distinguishing contracts from EOAs, and confirming a CREATE2 deployment matches its expected code.Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-145-bitwise-shifting/https://ankushindaniil.github.io/whitebox/eip-145-bitwise-shifting/A step-by-step derivation of EIP-145 (bitwise shifting instructions), shipped in Constantinople (February 2019). Why a word-oriented 256-bit VM shipped without shift opcodes was a real gap — bit shifting underlies packing struct fields, bitmap manipulation, fixed-point math, and cryptography, yet contracts had to emulate a left shift as multiplication by 2ⁿ and a right shift as division by 2ⁿ, paying for a MUL/DIV plus pushing the 2ⁿ constant and still unable to express a correct arithmetic (sign-preserving) right shift because DIV rounds toward zero — and how EIP-145 adds three native opcodes, SHL (0x1b), SHR (logical, 0x1c), and SAR (arithmetic, 0x1d), each costing the base 3 gas and shifting directly with no constant to push; the payoff is cheaper and smaller bytecode for all the bit manipulation that packing and cryptography depend on, a correct signed shift via SAR, and — since compilers emit them automatically — leaner contracts for free.Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-2200-sstore-metering/https://ankushindaniil.github.io/whitebox/eip-2200-sstore-metering/A step-by-step derivation of EIP-2200 (structured, net-effect SSTORE gas metering), shipped in Istanbul (December 2019). Why the original per-operation SSTORE pricing overcharges — a slot written several times in one transaction pays the full cost each time, though only the net change is persisted, penalizing counters, reentrancy locks, and temporary-storage patterns — and how net gas metering prices SSTORE by its net effect versus the value at the start of the transaction; then the cautionary tale of EIP-1283, whose cheap (as low as 200-gas) writes broke the assumption that a 2300-gas call stipend could never modify storage, reopening a reentrancy vector and forcing Constantinople to be postponed and the change reverted; and how EIP-2200 restores net metering safely by adding a sentry that reverts SSTORE when less than 2300 gas remains, keeping the savings while closing the stipend hole — a direct ancestor of transient storage (EIP-1153).Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-2935-historical-block-hashes/https://ankushindaniil.github.io/whitebox/eip-2935-historical-block-hashes/A step-by-step derivation of EIP-2935 (serve historical block hashes from state), shipped in Prague/Electra (May 2025). Why the BLOCKHASH opcode's 256-block window (~51 minutes) is limiting — contracts, rollups, cross-chain provers, and light clients often need older block hashes, and the opcode was served from a client-side header cache rather than from the state, which is awkward for stateless Ethereum — and how EIP-2935 stores each block's parent hash in a ring buffer inside a system contract's storage (writing the hash at slot (number − 1) mod 8191), making the last 8191 block hashes readable with a plain SLOAD and, crucially, part of the witnessed state; the payoff is a much larger lookback window, block hashes that stateless clients can access from state without a special cache, cheaper trust-minimized cross-chain and historical proofs, and yet another instance of the same ring-buffer-in-a-system-contract pattern used by EIP-4788's beacon root.Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-3198-basefee-opcode/https://ankushindaniil.github.io/whitebox/eip-3198-basefee-opcode/A step-by-step derivation of EIP-3198 (the BASEFEE opcode, London, August 2021) and its blob-era sibling EIP-7516 (the BLOBBASEFEE opcode, Cancun/Deneb, March 2024). Why exposing these fees mattered — EIP-1559 computes a base fee each block and EIP-4844 computes a blob base fee, both first-class protocol values, yet a contract could only see GASPRICE, which after 1559 is the effective price (base fee plus priority tip) fused together, so on-chain gas oracles, meta-transaction relayers, and smart accounts computing gas reimbursements could not read the base fee alone — and how EIP-3198 adds BASEFEE (0x48) to push the current block's base fee and EIP-7516 adds BLOBBASEFEE (0x4a) to push the current blob base fee, each a one-instruction read of a value the protocol already computes; the payoff is contracts that can reason about the fee market on-chain — accurate gas reimbursement, congestion-aware logic, and rollups pricing their data-availability costs against the blob base fee — the small but necessary reads that complete EIP-1559 and EIP-4844.Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-3860-initcode-metering/https://ankushindaniil.github.io/whitebox/eip-3860-initcode-metering/A step-by-step derivation of EIP-3860 (limit and meter initcode), shipped in Shanghai (April 2023). Why contract creation had a denial-of-service gap — runtime bytecode is capped at 24576 bytes (EIP-170) and paid for on deposit, but the initcode that returns it was uncapped and its per-byte processing (notably JUMPDEST analysis, which every node runs over the whole initcode) was not metered, so an attacker could submit enormous initcode that forces O(n) work across the network at far below its true cost — and how EIP-3860 closes it by charging 2 gas per 32-byte word of initcode and capping initcode at 49152 bytes (twice the runtime limit), so the cost tracks the work and the size is bounded; the payoff is DoS-safe creation, a consistent pair of limits alongside EIP-170's runtime cap, and a small but real gas bump for CREATE/CREATE2 factory patterns.Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-5656-mcopy/https://ankushindaniil.github.io/whitebox/eip-5656-mcopy/A step-by-step derivation of EIP-5656 (the MCOPY opcode), shipped in Cancun/Deneb (March 2024). Why the EVM lacked a native memory-to-memory copy despite it being a ubiquitous operation — contracts had to loop MLOAD then MSTORE word by word (many opcodes, extra gas, bloated bytecode) or misuse the identity precompile at address 0x04 as an ersatz memcpy (paying call overhead for an opaque hack) — and how EIP-5656 adds the MCOPY opcode (0x5e), which pops destination, source, and length and copies that many bytes of memory in a single instruction with correct overlap semantics, priced like the other copy opcodes (a base cost plus 3 gas per word plus memory expansion); the payoff is cheaper and smaller code for the countless memory copies in ABI encoding, cryptography, and data manipulation, retirement of the identity-precompile trick, and — because compilers emit it automatically — contracts getting cheaper simply by recompiling.Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-6110-onchain-deposits/https://ankushindaniil.github.io/whitebox/eip-6110-onchain-deposits/A step-by-step derivation of EIP-6110 (validator deposits on chain), shipped in Prague/Electra (May 2025). Why the pre-merge deposit flow was slow and fragile — the consensus layer discovered deposits by polling the execution-layer deposit contract and voting on its state ('eth1 data' voting) with a long follow distance, delaying validator activation by roughly half a day — and how EIP-6110 instead includes deposit events directly in the execution block as a new request type, so the consensus layer reads them from the very block it is already processing, no polling and no voting; the payoff is activation time collapsing from hours to minutes, retirement of the fragile eth1-voting mechanism, and deposits joining withdrawals and consolidations in one uniform 'execution-layer request → consensus layer processes' framework.Thu, 02 Jul 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/altair-sync-committees/https://ankushindaniil.github.io/whitebox/altair-sync-committees/A step-by-step derivation of Ethereum's Altair upgrade (October 2021), which introduced sync committees for light-client support. Why a light client (phone, browser, another chain) can't verify proof-of-stake the full way — checking attestations from a constantly-changing set of ~1,000,000 validators is far too heavy — leaving it to trust an RPC provider; and how a sync committee fixes it: a randomly-sampled subset of 512 validators, rotating each ~27-hour period, signs every block header, so a light client verifies a single aggregate BLS signature against 512 known public keys; and how the next period's committee is committed in the current beacon state so the client hops forward period-to-period via a Merkle proof, following the head trustlessly from a single weak-subjectivity checkpoint — with the tradeoff that 512 is a smaller trust set than full consensus.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-1014-create2/https://ankushindaniil.github.io/whitebox/eip-1014-create2/A step-by-step derivation of EIP-1014 (CREATE2), shipped in Constantinople (February 2019). Why the original CREATE opcode derives a contract's address from keccak(sender, nonce) — making the address unpredictable (the nonce ticks with every deploy) and un-reusable; how CREATE2 instead computes the address as keccak256(0xff ‖ sender ‖ salt ‖ keccak256(init_code))[12:], depending only on the deployer, a chosen salt, and the init code — no nonce, so the same inputs always yield the same address and it can be computed before deployment; and what that unlocks: counterfactual deployment (fund and use an address before its contract exists — state channels, lazily-deployed wallets, account-abstraction addresses), deterministic factories, and the metamorphic-contract footgun of redeploying different code at the same address.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-1344-chainid/https://ankushindaniil.github.io/whitebox/eip-1344-chainid/A step-by-step derivation of EIP-1344 (the CHAINID opcode), shipped in Istanbul (December 2019). Why EIP-155 only protected transactions, leaving contract-verified signatures (EIP-712 typed data, permit, meta-transactions) replayable across chains and forks that share a contract's address; why hardcoding the chain id at deploy time fails on a chain split (the constant survives unchanged on both sides); and how CHAINID (0x46) returns the current chain's id at runtime so a contract can fold it into its EIP-712 domain separator — binding each signature to the chain it was signed for, with the caveat that a cached domain separator must be recomputed if CHAINID changes.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-140-revert/https://ankushindaniil.github.io/whitebox/eip-140-revert/A step-by-step derivation of EIP-140 (REVERT), shipped in Byzantium (October 2017). Why aborting a contract call used to mean throwing — which reverted state but consumed all remaining gas and returned no data, punishing legitimate failed conditions and leaving no way to explain them; how the REVERT opcode (0xfd) fixes all three at once by atomically undoing the current frame's state changes, refunding the unused gas, and returning an error blob; and how that single instruction underpins require with reason strings, custom errors, and try/catch, because a sub-call's revert comes back to the caller as a catchable failure carrying its reason. Notes Byzantium's other big ships — STATICCALL and the alt_bn128 pairing precompiles that made on-chain zk verification possible.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-196-197-bn128-precompiles/https://ankushindaniil.github.io/whitebox/eip-196-197-bn128-precompiles/A step-by-step derivation of EIP-196 and EIP-197 (the alt_bn128 elliptic-curve precompiles), shipped in Byzantium (October 2017). Why verifying a zk-SNARK on-chain requires elliptic-curve addition, scalar multiplication, and pairing checks that are astronomically expensive as EVM bytecode — far beyond a block's gas limit; and how precompiles solve it: the protocol provides native implementations of these operations on the alt_bn128 curve at reserved addresses (0x06 ecAdd, 0x07 ecMul, 0x08 ecPairing), callable like a contract but priced at their real, low cost — so a verifier contract can check a SNARK in a handful of calls, which seeded on-chain privacy (mixers like Tornado Cash) and validity/zk-rollups (verify one proof for a whole batch of L2 transactions).Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-2028-calldata/https://ankushindaniil.github.io/whitebox/eip-2028-calldata/A step-by-step derivation of EIP-2028 (calldata gas cost reduction), shipped in Istanbul (December 2019). Why rollups must publish their compressed batch data on L1 as calldata so anyone can reconstruct and verify L2 state — and why, at 68 gas per non-zero byte, that data was a rollup's dominant cost and kept L2 fees high; how EIP-2028 lowered the non-zero calldata cost from 68 to 16 gas (zero bytes stayed 4), roughly a 4× reduction, chosen as a safe balance against the larger worst-case block size cheaper data allows; and how that made optimistic and zk rollups economically viable, opening the L2 scaling era — the precursor to EIP-4844, which later moved rollup data off calldata into far cheaper blobs.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-2537-bls-precompiles/https://ankushindaniil.github.io/whitebox/eip-2537-bls-precompiles/A step-by-step derivation of EIP-2537 (BLS12-381 precompiles), shipped in Prague/Electra (May 2025). Why Ethereum's consensus layer signs with BLS12-381 (aggregatable, ~128-bit-secure) while the EVM only had the Byzantium-era bn128 curve — too weak and the wrong curve for verifying beacon-chain signatures — and why implementing BLS12-381 as bytecode is infeasible for the same reason any pairing is; and how EIP-2537 adds native precompiles for BLS12-381 (G1/G2 addition and multiplication, the pairing check, and map-to-curve), so a contract can verify a BLS signature — including a sync committee's — in one cheap call, enabling trust-minimized bridges that verify Ethereum's consensus on another chain, on-chain aggregate-signature schemes, and finally aligning the EVM with the curve the consensus layer already uses.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-3529-refund-reduction/https://ankushindaniil.github.io/whitebox/eip-3529-refund-reduction/A step-by-step derivation of EIP-3529 (reduction in refunds), shipped in London (August 2021) alongside EIP-1559. Why the original SSTORE-clear and SELFDESTRUCT gas refunds — meant to reward freeing state — were exploited as gas tokens (store slots when gas is cheap, clear them for a refund when gas is dear) and let a block's real work reach up to twice its gas limit; why refunds couldn't simply be removed (that would over-punish legitimate state clearing); and how EIP-3529 removes the SELFDESTRUCT refund, cuts the SSTORE-clear refund from 15000 to 4800, and tightens the total-refund cap from gasUsed/2 to gasUsed/5 — killing gas tokens and bounding block work near the limit, which is exactly why EIP-1559 needs predictable blocks, and why the SSTORE-reset reentrancy-guard trick got expensive enough to motivate transient storage.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-3541-ef-reservation/https://ankushindaniil.github.io/whitebox/eip-3541-ef-reservation/A step-by-step derivation of EIP-3541, shipped in London (August 2021). Why introducing a new on-chain code format needs a marker that legacy bytecode can never start with — and why none exists, since every byte value 0x00–0xff already decodes as some EVM opcode; how EIP-3541 solves it by fiat, rejecting the deployment of any new contract whose code begins with 0xEF (existing 0xEF contracts are grandfathered); and what that one reserved byte unlocked: the EVM Object Format (EOF) container prefix 0xEF00, and EIP-7702's delegation designator 0xef0100 — both of which rely on no ordinary contract code being able to start with 0xEF.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-3855-push0/https://ankushindaniil.github.io/whitebox/eip-3855-push0/A step-by-step derivation of EIP-3855 (the PUSH0 opcode), shipped in Shanghai (April 2023). Why pushing the constant zero — ubiquitous in EVM code — had no dedicated opcode, forcing compilers to use PUSH1 0x00 (two bytes, three gas) or hacks like RETURNDATASIZE (one byte, but relying on returndata being empty); and how PUSH0 (0x5F) fixes it as a one-byte, two-gas instruction that pushes zero, shrinking contract bytecode (cheaper deployment, more headroom under the 24KB code-size limit), trimming execution cost, and letting the fragile RETURNDATASIZE trick be retired.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-4399-prevrandao/https://ankushindaniil.github.io/whitebox/eip-4399-prevrandao/A step-by-step derivation of EIP-4399 (PREVRANDAO), shipped with the Merge (Paris, September 2022). Why the EVM has no randomness opcode — determinism requires every node to reach the same result — and why contracts abused the DIFFICULTY opcode (0x44) as a weak, miner-biasable randomness source that disappeared when proof-of-work ended; how EIP-4399 repurposes that same opcode, renamed PREVRANDAO, to return the beacon chain's previous RANDAO value (randomness mixed by validators each block), giving contracts a 32-byte randomness beacon; and the crucial caveat that it's weak randomness — a block proposer knows the value ahead of time and can skip its slot to bias it — so it suits low-stakes uses but high-value applications should use commit-reveal schemes or a verifiable random function.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-7-delegatecall/https://ankushindaniil.github.io/whitebox/eip-7-delegatecall/A step-by-step derivation of EIP-7 (DELEGATECALL), shipped in Homestead (2016). Why contracts needed to reuse shared code without duplicating bytecode; why a plain CALL executes the callee's code in the callee's storage (with the caller as msg.sender), which makes a shared library operate on the wrong account's data; how CALLCODE ran the code in the caller's storage but clobbered msg.sender; and how DELEGATECALL fixes both — running the callee's code entirely in the caller's context (caller's storage, balance, and the original msg.sender/msg.value preserved). Ends on what it unlocks: Solidity libraries, the proxy pattern, upgradeable contracts, and the direct line to EIP-7702.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-6780-selfdestruct/https://ankushindaniil.github.io/whitebox/eip-6780-selfdestruct/A step-by-step derivation of EIP-6780 (SELFDESTRUCT restriction), shipped in Cancun (March 2024). Why the original SELFDESTRUCT — which deleted a contract's code, cleared its storage, and freed its address — was dangerous: combined with CREATE2 it enabled metamorphic contracts (redeploy different code at the same address, so an audited address could silently change), and the ability to delete arbitrary state in one instruction badly complicated the roadmap toward statelessness and Verkle trees; why it couldn't simply be removed (some contracts depend on it); and how EIP-6780 keeps the full delete only when a contract selfdestructs in the same transaction it was created, otherwise merely transferring its balance while leaving code and storage intact — killing metamorphic contracts, preserving legitimate same-transaction helpers, and simplifying state semantics.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-7002-el-withdrawals/https://ankushindaniil.github.io/whitebox/eip-7002-el-withdrawals/A step-by-step derivation of EIP-7002 (execution-layer triggerable exits and withdrawals), shipped in Prague/Electra (May 2025). Why validator exits could originally be initiated only by the validator's active consensus-layer signing key, leaving the execution-layer withdrawal-credential holder — the actual economic owner, often a staking-pool or smart contract — unable to withdraw or force-exit; and how EIP-7002 fixes it: the 0x01/0x02 withdrawal-credential address submits a request to a predeployed withdrawal-request system contract, which the consensus layer reads each block and processes as a partial withdrawal or full exit — using the same 'execution-layer request → system contract → consensus layer acts' pattern as beacon-chain withdrawals — making staking trustless and programmable from the execution layer (a pool can force out a rogue operator), and composing with EIP-7251 and EIP-7702.Wed, 24 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-1153-transient-storage/https://ankushindaniil.github.io/whitebox/eip-1153-transient-storage/A step-by-step derivation of EIP-1153 (transient storage) — why passing mutable data between calls within a single transaction forced contracts to abuse persistent SSTORE/SLOAD (≈20,000 gas to set a slot, written to the state trie forever, then reset to zero leaning on capped gas refunds), and how transient storage fixes it with two opcodes, TSTORE and TLOAD: a per-contract slot→word store that is cheap and fixed-gas, never written to disk, shared across calls and sub-calls within the transaction, rolled back when a frame reverts, and automatically discarded (cleared to zero) when the transaction ends — making reentrancy guards, transient approvals, and flash-accounting cheap and clean with no state bloat.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-155-replay-protection/https://ankushindaniil.github.io/whitebox/eip-155-replay-protection/A step-by-step derivation of EIP-155 (simple replay attack protection) — why an early Ethereum signature carried no chain identity, so the same signed transaction was valid on any chain sharing your account and could be replayed across a chain split, and how the fix works: include chainId (with two zero placeholders) in the RLP that gets hashed and signed, and encode it in v as chainId·2 + 35 + parity, so a signature made for one chain produces the wrong hash — and a failed signer recovery — anywhere else, while legacy v=27/28 transactions stay valid but unprotected.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-1559-fee-market/https://ankushindaniil.github.io/whitebox/eip-1559-fee-market/A step-by-step derivation of Ethereum's EIP-1559 fee market — from the broken first-price gas auction to a protocol-posted base fee, a ±12.5%-per-block controller that targets half-full blocks, elastic 2× blocks that absorb demand spikes, and the burn-plus-tip split that made fees predictable and ETH partly deflationary. With the live base-fee simulator.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-2718-typed-transactions/https://ankushindaniil.github.io/whitebox/eip-2718-typed-transactions/A step-by-step derivation of EIP-2718 (typed transaction envelope) — why one RLP format made every new transaction feature a backward-incompatible guessing game, and how a single leading type byte fixes it: a typed transaction is TransactionType ‖ TransactionPayload, the type byte 0x00–0x7f can never collide with a legacy RLP list (which starts ≥ 0xc0), so one look at the first byte disambiguates legacy from typed — and each later EIP (2930, 1559, 4844, 7702) just claims the next number.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-3675-the-merge/https://ankushindaniil.github.io/whitebox/eip-3675-the-merge/A step-by-step derivation of EIP-3675 (the Merge / upgrade consensus to proof-of-stake) — why proof of work tied security to ever-growing hashpower and energy, and how Ethereum switched to proof of stake without touching the EVM, state, or history: the beacon chain was launched separately in 2020 and ran PoS in parallel with no execution payload, then at a Terminal Total Difficulty mining stopped deciding the head and the beacon-chain fork-choice took over, the PoW header fields were neutralized (difficulty and nonce to 0, ommers emptied, mixHash repurposed as prevRandao, block reward to 0), and the execution layer became an engine driven by the consensus layer over the Engine API (engine_newPayload to execute and validate, engine_forkchoiceUpdated to set the head).Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-4337-account-abstraction/https://ankushindaniil.github.io/whitebox/eip-4337-account-abstraction/A step-by-step derivation of ERC/EIP-4337 — why EOAs are limiting, why native account abstraction would need a hard fork, and how 4337 gets smart accounts (multisig, passkeys, recovery, batching, sponsored or token gas) entirely in the application layer: UserOperations in a separate mempool, bundlers that wrap them into one transaction, a singleton EntryPoint that validates and executes each, and paymasters that pay the gas.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-4788-beacon-root/https://ankushindaniil.github.io/whitebox/eip-4788-beacon-root/A step-by-step derivation of EIP-4788 (beacon block root in the EVM) — why the execution layer had no trust-minimized access to consensus-layer state (validator balances, statuses, slashings, withdrawal credentials, RANDAO), forcing liquid-staking and restaking protocols onto trusted oracles, and how the fix works: you don't need the whole state, only an authentic commitment to it — the beacon block root is a hash-tree-root over all beacon state — so the protocol stamps the parent beacon block root into the EVM every block via a new parentBeaconBlockRoot header field and a system call that writes a (timestamp → root) pair into a predeployed ring-buffer 'beacon roots' contract (~8191 slots, ~27 hours); a contract then calls that predeploy with a timestamp to get an authentic root and verifies a Merkle proof of any validator fact against it.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-4895-withdrawals/https://ankushindaniil.github.io/whitebox/eip-4895-withdrawals/A step-by-step derivation of EIP-4895 (beacon-chain push withdrawals) — why, between the Merge and Shanghai, staked ETH and rewards were stranded on the consensus layer with no path back to the execution layer (no EL account, no key, so no transaction could pull them), and how the fix works: the consensus layer pushes a list of withdrawal objects into each execution block (a system-level operation with no signature, no sender, no gas), the block gains a withdrawals list and a withdrawalsRoot in the header, and the EVM simply credits each withdrawal's Gwei amount to its recipient address — with partial 'skim' withdrawals of rewards above 32 ETH and full withdrawals of an exited validator's whole balance, both swept automatically.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-7251-max-effective-balance/https://ankushindaniil.github.io/whitebox/eip-7251-max-effective-balance/A step-by-step derivation of EIP-7251 (increase the maximum effective balance) — why the 32 ETH effective-balance cap forced large stakers to shard a single stake across many validators (bloating the validator set and the consensus layer's per-epoch message load, adding operational overhead, and preventing rewards from compounding past 32 ETH), and how the fix works: raise MAX_EFFECTIVE_BALANCE from 32 to 2048 ETH so one validator can hold and earn on a much larger balance, add a new 0x02 compounding withdrawal credential and an execution-layer consolidation request to merge existing 32 ETH validators into one, keep the 32 ETH MIN_ACTIVATION_BALANCE as an opt-in floor for solo stakers, and preserve security because a validator's voting weight scales with its balance — shipped in Pectra (2025).Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/eip-7702-set-eoa-code/https://ankushindaniil.github.io/whitebox/eip-7702-set-eoa-code/A step-by-step derivation of EIP-7702 (set EOA code) — why 4337 forced a migration to a new address, and how 7702 lets an existing EOA delegate to a contract instead: a type-0x04 transaction with a signed authorization sets the account's code to a 0xef0100 delegation pointer, and any call then loads the delegate's code and runs it in the EOA's own context — unlocking batching, sponsored gas, and session keys on the address you already have.Tue, 23 Jun 2026 00:00:00 GMTEIPsexplorablehttps://ankushindaniil.github.io/whitebox/the-evm/https://ankushindaniil.github.io/whitebox/the-evm/A from-scratch derivation of the Ethereum Virtual Machine. Starting from accounts that can only transfer value, we invent programmability one constraint at a time: store code in the account and run it on a minimal stack machine (watch (2+3)×4 execute opcode by opcode), meter every instruction with gas so computation is paid-for and always terminates (the halting problem forces it), and split data into a stack, memory, and storage by lifetime and cost. Ends with a live bytecode stepper running real EVM execution.Tue, 23 Jun 2026 00:00:00 GMTStart hereexplorablehttps://ankushindaniil.github.io/whitebox/flat-db-nethermind/https://ankushindaniil.github.io/whitebox/flat-db-nethermind/How an Ethereum client physically stores the state trie on disk, derived from the flaw in each layout — from hash-keyed nodes and Nethermind's HalfPath (every read still walks the trie) to Ashraf's Flat DB, which reads accounts directly from flat RocksDB columns and keeps the trie only to recompute the stateRoot, with a layered-snapshot scheme for reorgs. The real speedup, and the honest disk and complexity it costs.Mon, 22 Jun 2026 00:00:00 GMTClient internalsexplorablehttps://ankushindaniil.github.io/whitebox/you-could-have-invented-ethereum/https://ankushindaniil.github.io/whitebox/you-could-have-invented-ethereum/The single, complete explanation of how Ethereum works — a step-by-step, fully-animated derivation from scratch (signatures, accounts, the Merkle-Patricia trie, the hash-linked blockchain, proof-of-stake consensus, the EVM, and gas), each piece introduced exactly when the last one's flaw demands it, with the real differentially-tested engines woven into the steps and the spec detail behind each. Original analogies, adapted to Ethereum.Sun, 21 Jun 2026 00:00:00 GMTStart hereexplorablehttps://ankushindaniil.github.io/whitebox/notes/2026-06-pectra-state/https://ankushindaniil.github.io/whitebox/notes/2026-06-pectra-state/A short, plain-English protocol note — the state-tree roadmap shifted from Verkle trees to a binary Merkle tree (EIP-7864). Here's the why, for engineers.Mon, 15 Jun 2026 00:00:00 GMTnote