How Ethereum Actually Works: EVM, Execution, Consensus and State Explained

Most mental models of Ethereum are subtly wrong at the root. They frame it as a blockchain that happens to run smart contracts. Invert that framing and you get far closer to reality: Ethereum is a deterministic state machine whose sole purpose is to compute a single, globally agreed-upon state transition function, and the blockchain—consensus—merely selects which transitions to apply and in what order. The resulting world state, a mapping of every address to its current account data occupying well over 400 GB, is the actual product. Blocks are the audit log. State is the output.

Formally, the system implements σ' = Υ(σ, T), where σ is the world state before a transaction T, Υ is the state transition function (the EVM), and σ' is the world state after. Every full node on the network independently computes this function for every transaction in every block and arrives at the identical σ'. If they don't, they're on a different chain. That determinism is non-negotiable—it is enforced by gas metering, fixed opcode semantics, and the consensus protocol—and it is the single property that makes the entire system work.

Contrast this with Bitcoin's UTXO model, which tracks discrete coins. Ethereum tracks accounts with mutable balances, nonces, and in the case of contracts, persistent storage and executable code. A Bitcoin transaction consumes and creates outputs; an Ethereum transaction mutates a global state object. This distinction cascades into every design decision: how gas works, why storage is expensive, why re-entrancy attacks are possible, and why state growth is Ethereum's most pressing long-term scalability constraint.

The conceptual framework for the rest of this article follows the dependency graph of the protocol itself: state structure → transaction-driven execution → consensus that orders and finalises those executions → data layer that stores and proves it all.

Every address on Ethereum maps to an account object with four fields: nonce (number of transactions sent, or for contracts, number of contracts created), balance (in wei), storageRoot (a 32-byte hash committing to the contract's storage trie—empty for EOAs), and codeHash (the Keccak-256 hash of the account's EVM bytecode—the hash of the empty string for EOAs). Two account types exist: externally owned accounts (EOAs), controlled by a private key, and contract accounts, controlled by their code. Post-Pectra, EIP-7702 blurs this line—but more on that later.

These accounts live in the Modified Merkle Patricia Trie (MPT), a hexary (16-branch) trie structure where the path through the trie for any account is the Keccak-256 hash of its 20-byte address, nibble by nibble. The MPT is not stored inside blocks. Blocks contain only the 32-byte stateRoot—a single hash committing to the entire world state. Every full node maintains and updates its own local copy of this trie. When you read that the world state is ~400 GB+, that is the size of this trie on disk, not the size of the chain.

Each block actually commits to four tries: the state trie (accounts), each contract's storage trie (a separate MPT nested beneath the account's storageRoot), the transaction trie (all transactions in the block, keyed by index), and the receipt trie (execution results, logs, gas used). The nesting matters: modifying a single storage slot in a contract requires re-hashing up through the storage trie to produce a new storageRoot, then re-hashing up through the state trie to produce a new stateRoot. This cascading re-hashing is why SSTORE is so expensive—22,100 gas for a cold, fresh slot—and why state growth is an existential concern.

Account data is serialised using RLP encoding (Recursive Length Prefix), the execution layer's native serialisation format, while the consensus layer uses SSZ (Simple Serialize). The long-term plan is to transition the execution layer to SSZ, but as of March 2026, RLP remains canonical for state and transactions.

The state bloat problem is severe: ~280 million+ unique accounts, growing steadily. Even accounts with zero balance and no code persist in the trie unless explicitly removed. The protocol's answer is the transition from MPTs to Verkle Trees, which use vector commitments (specifically Pedersen commitments over the Bandersnatch curve) to produce proofs of ~150 bytes versus ~4 KB for MPT proofs. This is prerequisite to stateless validation, where a block proposer provides a compact witness alongside the block and validators can verify it without maintaining the full state. As of March 2026, Verkle devnets are running but the transition is not yet live on mainnet—and when it arrives, it will require migrating all existing state, likely via a gradual overlay approach.

Nothing in Ethereum executes without a transaction. There are no cron jobs, no event-driven triggers, no autonomous contract execution. Every state change traces back to a signed transaction originating from an EOA (or, with EIP-7702, from an EOA with delegated contract code). Even so-called automated systems—Chainlink Automation, Gelato, MEV searcher bots—are just off-chain processes that submit ordinary transactions.

A transaction contains: nonce, gas parameters, the recipient address (or empty for contract creation), value in wei, data (calldata or initcode), and the ECDSA signature components (v, r, s, plus chainId for replay protection per EIP-155). Since EIP-2718 introduced the transaction envelope format, multiple types coexist: Type 0 (legacy), Type 1 (EIP-2930, with access lists), Type 2 (EIP-1559, with maxFeePerGas and maxPriorityFeePerGas), Type 3 (EIP-4844, carrying blob commitments), and as of Pectra, Type 4 (EIP-7702, setting temporary code on the sender's EOA). Each type has different fields and different signing serialisation. If you're parsing raw transactions, you must check the first byte: 0x00–0x7f indicates typed, 0xc0–0xff indicates legacy RLP.

The transaction lifecycle proceeds: the user creates and signs the transaction → it propagates across the gossip network into the mempool (each node's local pool of pending transactions) → a builder selects and orders transactions into a block (typically via MEV-Boost) → the block proposer commits to the block → execution clients process each transaction sequentially, applying state transitions → a receipt is generated per transaction (status, gas used, logs) → the resulting stateRoot is included in the block header → attesters verify and the block progresses toward finality.

Intrinsic gas costs apply before any EVM execution: 21,000 gas base, plus 4 gas per zero byte and 16 gas per non-zero byte of calldata, plus EIP-2930 access list costs if applicable. Contract creation transactions carry an additional 32,000 gas surcharge plus 200 gas per byte of deployed code. These costs exist to price the non-execution overhead: signature verification, state reads, trie updates, and calldata storage in the block.

The Ethereum Virtual Machine is a stack-based state transition function specification. Emphasise specification: there is no persistent EVM process running anywhere. Each transaction invocation creates a fresh execution context, which is destroyed when execution completes. Different clients (Geth in Go, Nethermind in C#, Besu in Java, Reth in Rust, Erigon in Go) implement this specification independently, and the fact that they all produce the same state root for every block is the acid test of correctness.

The EVM has three data regions. The stack is a last-in-first-out structure with a maximum depth of 1,024 items, each 256 bits (32 bytes) wide. All opcode operands come from and go to the stack. Exceeding 1,024 items triggers an exception and reverts the execution context. The memory region is byte-addressable, linear, volatile (cleared between execution contexts), and expands dynamically—but expansion costs gas quadratically, a deliberate throttle on memory-intensive computation. Memory at offset n costs approximately 3 gas per word for small allocations but scales as 3a + a²/512 where a is the number of words, making unbounded memory use prohibitive.

Storage is the persistent layer: a mapping from 256-bit keys to 256-bit values, backed by the per-contract storage trie. The gas cost asymmetry is staggering: MSTORE costs ~3 gas, SSTORE costs 20,000 gas for a fresh slot or 5,000 for an update (with EIP-2929 cold/warm dynamics layered on top). That ~6,600x cost ratio reflects the real-world burden of modifying a trie that must be re-hashed up to the state root and persisted indefinitely across all full nodes.

Dencun introduced a fourth region: transient storage via EIP-1153's TSTORE and TLOAD opcodes. Transient storage persists for the duration of a single transaction and is automatically cleared afterward, at a cost of just 100 gas per operation. This enables dramatically cheaper re-entrancy guards, cross-contract callback data passing, and ERC-20 approval-in-context patterns. Experts recognise transient storage as a genuinely new primitive, not just a gas optimisation—it changes which design patterns are economically viable.

When a contract executes CALL, DELEGATECALL, or STATICCALL, a new execution context is created with its own stack and memory, though DELEGATECALL preserves the caller's storage context and msg.sender. The call depth limit of 1,024 frames prevents stack overflow attacks. The 63/64 gas forwarding rule (EIP-150) ensures that a parent context always retains at least 1/64th of remaining gas, preventing griefing attacks where a sub-call is designed to consume exactly all gas.

Solidity, Vyper, and other high-level languages compile to EVM bytecode: a flat sequence of bytes where each byte is either an opcode (one of ~140+ defined instructions) or an immediate data argument to a PUSH instruction. The bytecode is what gets deployed on-chain, stored under the account's codeHash, and executed byte by byte by the program counter.

Opcodes fall into categories. Arithmetic operations (ADD, MUL, SUB, DIV, SDIV, MOD, SMOD, ADDMOD, MULMOD, EXP, SIGNEXTEND) operate on 256-bit unsigned or signed integers. Comparison and bitwise opcodes (LT, GT, SLT, SGT, EQ, ISZERO, AND, OR, XOR, NOT, SHL, SHR, SAR, BYTE) enable conditional logic. KECCAK256 hashes an arbitrary memory region and is central to storage slot calculation—Solidity computes mapping slots as keccak256(key . slot).

Stack manipulation opcodes—PUSHn (PUSH1 through PUSH32), DUPn (DUP1 through DUP16), SWAPn (SWAP1 through SWAP16)—are the most frequently occurring in compiled bytecode, because every value must be loaded onto the stack before any operation can use it. Flow control uses JUMP, JUMPI (conditional), JUMPDEST (valid jump target marker), and the implicit fall-through of sequential execution.

System-level opcodes interact with the broader state: CALL, DELEGATECALL, STATICCALL, CREATE, CREATE2, BALANCE, EXTCODESIZE, EXTCODECOPY, EXTCODEHASH, SLOAD, SSTORE, LOG0–LOG4, and SELFDESTRUCT (now severely restricted). Environment opcodes like ADDRESS, ORIGIN, CALLER, CALLVALUE, GASPRICE, COINBASE, TIMESTAMP, NUMBER, and CHAINID provide contextual information. BLOCKHASH returns the hash of one of the previous 256 blocks (not further)—a commonly misunderstood limitation that affects on-chain randomness patterns.

The Ethereum Object Format (EOF), introduced via multiple EIPs in Pectra, restructures bytecode with a typed container format, separated code and data sections, removes dynamic jumps in favour of static relative jumps (RJUMP, RJUMPI), and increases the maximum contract code size to 49,152 bytes (up from 24,576 per EIP-170). EOF is opt-in—legacy bytecode continues to function—but new contracts can leverage its stricter validation and gas improvements.

Precompiled contracts at addresses 0x01 through 0x09 provide native implementations of operations too expensive for the EVM: ecRecover (0x01), SHA-256 (0x02), RIPEMD-160 (0x03), identity/memcopy (0x04), modular exponentiation (0x05), elliptic curve operations on the BN256 curve (0x06, 0x07, 0x08), and BLAKE2f (0x09). Pectra added the BLS12-381 precompile (EIP-2537), critical for BLS signature verification and SNARKs.

Gas is not primarily a fee mechanism—it is a deterministic metering system that guarantees all nodes halt at the same instruction if computation exceeds the limit. Without gas, a single infinite loop would halt the entire network. Every opcode has a fixed gas cost so that execution is identical on a Raspberry Pi and a data centre server: they might take different wall-clock time, but they will consume the same gas and reach the same outcome.

EIP-1559, active since August 2021, split the gas fee into a base fee (algorithmically determined, burned entirely) and a priority fee (tip to the block proposer). The base fee adjusts by a maximum of ±12.5% per block, targeting 50% utilisation of the gas limit. When blocks are above target, the base fee rises; below target, it falls. This mechanism provides dramatically better fee estimation compared to the pre-1559 first-price auction, but it does not reduce fees during sustained congestion—it merely makes them predictable.

The base fee burn has had profound economic consequences. Cumulatively, ~4.5–5 million ETH has been burned by early 2026. In high-activity periods, the burn rate exceeds new issuance (~1,700 ETH/day post-Merge), making ETH temporarily deflationary. Validators receive only priority tips plus any MEV extracted—a fundamentally different economic model than the PoW era.

The gas limit per block sits at approximately 36 million following Pectra and subsequent community-driven validator voting, with the EIP-1559 target at half that (~18M as the elasticity mechanism aims for 50% utilisation of the max). For simple ETH transfers at 21,000 gas each, the theoretical maximum throughput is approximately 143 per 12-second slot, or ~12 TPS. For a Uniswap V3 swap consuming ~150,000 gas, it's closer to 20 per slot, or ~1.7 TPS. The metric that actually describes Ethereum's capacity is gas per second (~3 million), not transactions per second.

Post-EIP-2929, the cold/warm access pattern adds another layer. First access to a storage slot within a transaction costs 2,100 gas; subsequent accesses cost 100 gas. First access to an external account costs 2,600 gas; subsequent accesses cost 100 gas. This 20x+ differential means the order in which a contract touches storage slots within a single transaction materially affects total gas cost. EIP-2930's access lists allow pre-declaring which slots and addresses a transaction will touch, paying the cold cost upfront but ensuring warm pricing during execution—a meaningful optimisation for complex DeFi transactions.

Gas refunds, once generous enough to incentivise gas-token exploits, were sharply curtailed by EIP-3529 (London, August 2021), which capped refunds at 20% of total gas consumed (down from 50%) and removed the refund for SELFDESTRUCT entirely.

Since The Merge on 15 September 2022, Ethereum's consensus runs on Proof of Stake. Validators deposit 32 ETH (with Pectra's EIP-7251 allowing a maximum effective balance of 2,048 ETH per validator) and are assigned duties: proposing blocks and attesting to them.

Time is divided into 12-second slots and 32-slot epochs (~6.4 minutes). In each slot, one validator is pseudo-randomly selected as the block proposer (using RANDAO mixed with the validator index), and a committee of validators is assigned to attest. Attestations are votes on the head of the chain (via LMD-GHOST) and on epoch boundary checkpoints (via Casper FFG).

LMD-GHOST (Latest Message Driven Greediest Heaviest Observed SubTree) is the fork choice rule. When two competing blocks exist, validators follow the fork with the most cumulative attestation weight, counting only each validator's latest message. This provides real-time chain selection in the presence of network delays or short reorgs.

Casper FFG provides economic finality. It works on epoch boundary checkpoints: validators vote to justify a checkpoint (requiring 2/3 supermajority of stake), and a justified checkpoint becomes finalised when the next epoch's checkpoint is also justified. Finality therefore takes a minimum of 2 epochs—64 slots, ~12.8 minutes. A finalised block cannot be reverted without at least 1/3 of all staked ETH being slashed, which at ~34 million ETH staked represents ~11+ million ETH in economic security. The distinction between a block at the head of the chain (probabilistic, reorgable) and a finalised block (economically secure) is one of the most commonly confused concepts.

Single Slot Finality (SSF) would collapse finality to a single 12-second slot, but as of March 2026 this remains at the research and prototyping stage, with significant challenges around the number of validators (~1.05 million) that must participate in each slot's vote.

The proposer's staking APR sits at roughly 3.0–3.5% base yield, with MEV tips adding approximately 0.5–1.5%. Those staking through liquid staking protocols or running validators at home can estimate their projected returns using our staking calculator.

Every Ethereum node since The Merge runs two separate processes. The execution client (Geth, Nethermind, Besu, Erigon, or Reth) maintains the state, executes the EVM, manages the mempool, and handles legacy JSON-RPC. The consensus client (Prysm, Lighthouse, Teku, Nimbus, or Lodestar) handles PoS duties: tracking validators, processing attestations, running the fork choice, and communicating with the beacon chain P2P network.

These two processes communicate via the Engine API, a localhost JSON-RPC interface. Three core methods drive the interaction: engine_newPayloadV3 (the consensus client sends a new execution payload for the execution client to validate), engine_forkchoiceUpdatedV3 (the consensus client informs the execution client of the current head, safe, and finalised blocks and optionally triggers block building), and engine_getPayloadV3 (the execution client returns a built block to the consensus client for proposal).

This separation is elegant but introduces a real failure surface. In May 2023, a Prysm-Geth interaction bug caused a subset of validators to fail to produce blocks. If one client pair has a bug, it affects only those validators. But if a single client exceeds 33% of the validator set and has a finalisation-affecting bug, the network cannot finalise. Worse: if a single client exceeds 66% and produces an invalid state root, the chain can finalise an incorrect state, requiring social consensus and a hard fork to recover. As of March 2026, Geth's execution-layer share has dropped toward ~45% and Prysm's consensus-layer share toward ~35% thanks to concerted community efforts around client diversity, but these figures remain dangerously high.

Understanding Ethereum execution in 2026 without understanding MEV (Maximal Extractable Value) is like understanding an internal combustion engine while ignoring the fuel injection system. Approximately 90%+ of mainnet blocks are now produced through the MEV-Boost pipeline rather than being built locally by the proposing validator.

The pipeline works as follows. Searchers identify MEV opportunities: arbitrage, liquidations, sandwich attacks, just-in-time (JIT) liquidity provision. They construct transaction bundles and submit them to builders. Builders assemble complete blocks, optimising for total value, and submit sealed bids to relays. Relays validate the blocks (ensuring they're valid and the bid is honoured) and present only the block headers and bid values to the proposer, who selects the highest bid and signs a commitment—crucially, without seeing the block contents. The relay then reveals the block body.

This de facto proposer-builder separation (PBS) exists entirely outside the protocol. MEV-Boost is middleware, not a protocol feature. Enshrined PBS (ePBS) would move this into the protocol itself, reducing trust assumptions on relays, but as of March 2026 ePBS is still in active design with multiple competing proposals.

The implications for transaction inclusion are significant. Your transaction's journey is not mempool → proposer → block. It's mempool → potentially observed by searchers → bundled by a builder → routed through a relay → signed by a proposer. If you broadcast a large swap through the public mempool, searchers can sandwich it. Private mempools and order-flow auctions (Flashbots Protect, MEV Blocker) exist to mitigate this, but they introduce their own trust assumptions. Users bridging tokens or executing large swaps through ChangeNOW bypass the public mempool entirely for the off-chain portion, though the on-chain settlement still enters the standard pipeline.

EIP-4844, activated with Dencun on 13 March 2024, introduced blob transactions (Type 3)—a separate data channel designed for Layer 2 rollups. Each blob is 128 KB and is committed to via KZG polynomial commitments, allowing compact proofs that the data exists without requiring every node to store it permanently.

Pectra increased the blob target from 3 to 6 per block and the maximum from 6 to 9. Blobs are propagated over a separate gossip network, retained by consensus nodes for ~18 days (~4,096 epochs), and then pruned. They are not accessible to the EVM—only their commitments (via the BLOBHASH opcode and the point evaluation precompile) are visible during execution.

Blobs have a separate fee market from execution gas, with their own base fee mechanism targeting the blob gas target. When blob demand is low, blob fees are near zero—which is why L2 transaction costs dropped by 90%+ after Dencun. When demand spikes (as happened during inscription-related activity in late 2024), blob fees can rise sharply.

Full Danksharding extends this concept with data availability sampling (DAS), where nodes verify data availability by downloading only random subsets of blob data. PeerDAS, the network-layer protocol for this, is under active development and expected in the 2026–2027 timeframe.

Pectra's EIP-7702 is a quiet revolution in Ethereum's account model. It allows an EOA to include a special authorisation in a Type 4 transaction that temporarily sets a code pointer on the EOA to an existing contract's code. For the duration of execution (or until overwritten), the EOA behaves like a smart contract wallet—capable of batching multiple operations, sponsoring gas for other users, implementing custom validation logic, and more.

This changes the security model in a fundamental way. Prior to EIP-7702, an EOA's behaviour was entirely predictable: it could send ETH, call contracts, and that was it. Now, an EOA's behaviour is context-dependent, determined by whatever code it delegates to. Wallet developers, dApps, and protocols that make assumptions about EOA behaviour (checking tx.origin == msg.sender as an EOA-only guard, for example) must reassess. Combined with ERC-4337 bundlers, EIP-7702 moves Ethereum meaningfully toward native account abstraction without requiring users to migrate to new addresses. Users managing multiple accounts and tracking cost basis across delegated transactions may find tools like Koinly increasingly necessary to handle the added complexity for HMRC reporting.

An honest treatment of Ethereum requires cataloguing where it breaks.

Client diversity failure remains the most critical systemic risk. A supermajority bug in a single execution or consensus client can cause the chain to finalise an invalid state, requiring a community-coordinated hard fork to resolve. The inactivity leak mechanism, designed to eventually restore finality if >1/3 of validators go offline, takes weeks to fully activate and results in significant capital losses for affected validators. In a supermajority client bug scenario, validators running the buggy client would be slashed or leak, losing potentially 50%+ of their stake before finality is restored on the correct chain.

Re-entrancy remains a live concern despite mitigations. The pattern exploits the fact that state changes persist across execution context boundaries within a single transaction. When contract A calls contract B, and B calls back into A before A has finished updating its state, A may operate on stale data. The DAO hack (2016) was the canonical example. Transient storage (EIP-1153) provides cheaper re-entrancy guards, but the fundamental pattern—external calls before state updates—persists wherever developers forget or misapply the checks-effects-interactions pattern.

State growth is an existential long-term constraint. The state trie grows monotonically (with minor exceptions) because there is no mechanism to charge for ongoing storage. Every contract deployed, every new account created, every storage slot written adds to the burden every full node must carry indefinitely. The Verkle Tree transition and statelessness roadmap address this for validators, but for full nodes reconstructing state, the problem persists. State expiry proposals have been repeatedly deferred due to the complexity of resurrection proofs and the UX impact of expired state.

Finality delays have occurred multiple times. The beacon chain experienced finality delays in May 2023 (lasting several epochs) caused by a combination of high attestation load and client bugs. During a finality delay, the network continues producing blocks (liveness is maintained) but no new blocks reach economic finality, meaning sufficiently motivated attackers could theoretically reorg the chain. Exchanges and bridges that wait for finality before crediting deposits experience corresponding delays.

SELFDESTRUCT restrictions (EIP-6780) broke metamorphic contract patterns that relied on deploying, destroying, and redeploying contracts at the same address with different code (using CREATE2 + SELFDESTRUCT). Post-Dencun, SELFDESTRUCT only fully destroys a contract if called in the same transaction as its creation. This eliminated a vector for on-chain mutability that some protocols relied on and others considered a security risk.

Gas observability edge cases arise because the GAS opcode returns the remaining gas at that point in execution. This means that the exact gas value can differ depending on the call context, making gas-dependent logic non-portable across different transaction contexts. Combined with the 63/64 rule, gas forwarding to sub-calls is always slightly less than expected, which can cause hard-to-diagnose failures in contracts that assume specific gas availability.

The BLOCKHASH limitation deserves mention: only the hashes of the most recent 256 blocks are accessible via the BLOCKHASH opcode. Contracts that need older block hashes for verification (e.g., optimistic oracle designs) must maintain their own on-chain history or rely on EIP-2935 (historical block hash accumulator), introduced in Pectra to store 8,192 block hashes in a system contract.

The proliferation of Layer 2 rollups has created a taxonomy of EVM relationship types that most people conflate. EVM-equivalent (Type 1 zkEVM, per Vitalik's classification) rollups replicate Ethereum's state transition function exactly—same opcodes, same gas costs, same trie structures. EVM-compatible (Type 2–2.5) rollups run the same opcodes but may differ in gas schedules, precompiles, or minor edge cases. EVM-compatible with differences (Type 3) rollups support most but not all opcodes or have different compilation targets. Alternative VMs (Type 4) compile Solidity to a different VM entirely (e.g., zkSync Era's custom VM).

The practical consequence: a contract that works on mainnet may behave differently on an L2 depending on the type. Gas costs diverge, BLOCKHASH behaviour differs (L2s return L2 block hashes, not L1), COINBASE returns the L2 sequencer or a different value, and SELFDESTRUCT behaviour may vary. Developers and auditors must understand exactly which EVM type their target L2 implements.

Primary sources, on-chain references, and dashboards to verify every claim in this article:

The Python Execution Layer Specification (EELS) at github.com/ethereum/execution-specs is the canonical executable reference for the EVM's state transition function, superseding the Yellow Paper for edge cases. The consensus specifications at github.com/ethereum/consensus-specs define the beacon chain, Casper FFG, and LMD-GHOST.

For state data: etherscan.io/nodetracker for client diversity statistics; beaconcha.in and rated.network for validator performance, staking yield, and attestation data; ultrasound.money for real-time ETH supply, burn rate, and issuance tracking; blobscan.com for blob transaction analysis and blob fee market data.

For execution: evm.codes provides a comprehensive interactive opcode reference with gas costs, stack inputs/outputs, and fork-by-fork changes. The execution-spec-tests repository (github.com/ethereum/execution-spec-tests) contains the authoritative test vectors that every client must pass.

For MEV: flashbots.net/transparency-dashboard and mevboost.pics show real-time MEV-Boost relay statistics, builder dominance, and proposer revenue. relayscan.io provides relay-level data.

For the Verkle transition: verkle.info and the Ethereum Foundation's Verkle devnet trackers document the current state of the migration. EIP-6800 (Verkle state tree) is the primary specification.

For deeper protocol understanding: the Ethereum Improvement Proposals at eips.ethereum.org are primary source documents for every protocol change referenced in this article. Key EIPs: 1559 (fee market), 2718 (typed transactions), 2929 (cold/warm access), 3529 (gas refund reduction), 4844 (blobs), 6780 (SELFDESTRUCT restriction), 7251 (max effective balance), 7702 (EOA code delegation), 1153 (transient storage), and 2537 (BLS12-381 precompile).