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.
- proof of work basics
- blocks & fork choice
The Merge is often described as “Ethereum switched to proof of stake,” which undersells how delicate it was. Imagine replacing a plane’s engine in flight, without the passengers — the EVM, every account, the entire transaction history — noticing a bump. The hard constraint of EIP-3675 is exactly that: change how blocks are agreed while keeping everything blocks contain byte-for-byte identical. You can’t just flip proof of work to proof of stake in one fork and hope the new security holds. Let’s derive how it was actually done.
The problem: paying for security in electricity
Under proof of work A consensus rule where producing a valid block requires finding a nonce that makes the block hash fall below a target. The only way is to try enormous numbers of nonces, so block production costs real computation — and thus electricity. , every miner races to guess a nonce that makes their block hash small enough. The only strategy is to try astronomically many guesses, so the chain’s security is literally proportional to how much hashing — and therefore how much electricity — is being spent. To attack the chain you’d need to out-hash everyone, which is expensive; but honest security costs the same energy, paid forever, plus issuance to reward miners and a creeping centralization toward whoever has the cheapest power and hardware.
We want to keep the chain’s contents — the EVM, accounts, balances, contract code, the whole history — and replace only the engine that decides which block comes next, swapping “burn energy to win” for “stake ETH and get slashed if you cheat.”
→ Step 2: build the new engine off to the side first.
Don’t bootstrap in place — run a beacon chain alongside
The cold-start problem is solved by not starting cold. Launch the proof-of-stake system as a separate chain — the beacon chain A standalone proof-of-stake chain launched in December 2020. It ran validators, attestations, and finality with no user transactions and no EVM — purely to grow a staked validator set and prove the consensus worked before it took over. — well ahead of time. Starting in December 2020, it ran proof of stake for real: validators deposited 32 ETH, produced and attested to beacon blocks, and exercised finality — but those blocks carried no execution payload. No EVM, no user transactions, just consensus, accruing a large, battle-tested validator set and stake while the PoW chain kept doing the actual work.
By the time of the Merge, proof of stake wasn’t an experiment switched on under load — it had nearly two years and millions of staked ETH behind it. All that remained was to connect the two: let the proven PoS chain start choosing the execution blocks.
→ Step 3: pick a finish line miners can’t fake.
Hand off at the Terminal Total Difficulty
You need a switchover point no one can rush or stall. A block height could be skipped or contested; instead, use accumulated work. Every PoW block adds its difficulty to a running total difficulty, and the Merge fires at a pre-agreed Terminal Total Difficulty A fixed cumulative-difficulty threshold (the TTD). The first block whose total difficulty crosses it is the last PoW block; from there the beacon chain's fork-choice decides the head. Because it's based on accumulated work, it can't be skipped or faked. (the TTD). The first block to cross it is the last block mining ever decides. From the next block on, the beacon chain’s fork-choice (LMD-GHOST for the head, Casper FFG for finality) picks the canonical chain. And the now-meaningless proof-of-work header fields are neutralized: difficulty and nonce go to 0, the ommers/uncles list is emptied, the old mixHash slot is repurposed to carry prevRandao (the beacon chain’s randomness), and the block mining reward becomes 0 — issuance moves entirely to the consensus layer.
→ Step 4: wire the engine to the driver.
The execution layer becomes an engine the CL drives
After the Merge, your node is really two programs: a consensus-layer client (the beacon node) and an execution-layer client (the old Geth/Nethermind/etc.), talking over a private, authenticated Engine API The internal JSON-RPC interface between the consensus and execution clients. The CL uses it to feed the EL blocks to execute and to tell it which head to build on; the EL replies VALID or INVALID. Users never call it. . The consensus layer drives; the execution layer executes. The CL asks the EL to run a block with engine_newPayload — the EL executes the transactions, applies the state transition, and answers VALID or INVALID — and uses engine_forkchoiceUpdated to set the canonical head and, when this validator is the proposer, to start building the next payload. The CL then attests and finalizes. The EVM never changed; it just took a new boss.