Design Ethereum

Ethereum as a World Computer

Where Bitcoin is a ledger that answers one question — who owns which coins — Ethereum is a replicated state machine that runs arbitrary programs. The mental model that earns immediate credit is exactly that: Ethereum is a single global computer whose state every node redundantly computes and agrees on, where the programs are smart contracts and every state transition is paid for in gas. That one reframe drives every design difference from Bitcoin, and the interviewer is listening for whether you lead with it.

Three ideas carry the system. First, state is an account model, not UTXOs: the world state maps addresses to accounts, and an account is either externally-owned (a keypair with a balance and a nonce) or a contract (a balance, a nonce, immutable code, and a persistent storage trie). Transactions mutate this shared state in place, which is what makes contracts composable but also what makes parallel validation hard. Second, computation runs on the EVM, a deterministic stack machine, and every opcode costs gas — the mechanism that both prices computation and halts infinite loops, since a transaction that runs out of gas reverts its changes but still pays. Third, since the Merge, ordering is decided by proof-of-stake: roughly 500k validators stake 32 ETH each, propose blocks on 12-second slots, and finalize checkpoints every epoch.

The task here is to design the node infrastructure for that world computer: the execution client that runs the EVM and holds state, the consensus client that follows the proof-of-stake fork choice, and the JSON-RPC layer that serves dApps and wallets. The scale to size for is roughly 1.2M transactions/day — but the read load dwarfs writes, with eth_call and log queries running 5–10× the write rate, against a ~1.3 TB state that grows relentlessly and punishes naive storage.

This question is harder than Bitcoin for two reasons, and naming them is the senior move. Ethereum runs two coupled chains (an execution layer and a consensus layer that talk over the Engine API), and it has no instant finality. A strong answer never claims a transaction is final the moment it is included; it anchors finality to epochs and justified/finalized checkpoints, and keeps a failure story ready — a deep reorg past a checkpoint confusing light clients, a blob-fee spike starving rollup batches, or a PBS builder withholding a block. Those details prove you understand Ethereum as an operating system under adversarial load, not a diagram that only runs forward.