Design Blockchain Node

Problem Statement: Trust-Minimized Full Node

A blockchain full node is the infrastructure that lets you believe the chain without trusting anyone — it downloads every block, re-executes every transaction, and verifies every state transition against consensus rules, so it can answer "what is the canonical state?" from first principles rather than asking a third party. Designing one means building four things that run together: a P2P sync engine that gossips with peers, a consensus validator that accepts or rejects blocks, a mempool that holds pending transactions, and an RPC edge that serves queries to wallets, indexers, and dapps.

The scale is concrete and worth stating before any architecture. Ethereum produces a block every ~12s; a pruned node holds ~1.2 TB while an archival node (full historical state) runs many TB and grows continuously. Bitcoin is ~600 GB, growing ~50 GB/year. Solana is brutal on I/O — its ledger and account churn make it effectively IOPS-bound rather than capacity-bound. Post-Merge Ethereum also splits the node into an execution layer (EL: geth/reth/erigon) and a consensus layer (CL: a beacon client) that talk over the Engine API, a split that reshapes the whole design.

The consistency model to name up front: a node is strongly consistent at its own tip — when it commits a block, its state is exactly that block's state — but the network is only eventually consistent, because nodes briefly see different tips during propagation and reorgs. The job is to make a single node correct and fast, and to behave sanely when the network disagrees with it. The incidents that actually define this problem — a stalled sync, a corrupted database, a deep reorg, RPC abuse from heavy debug_traceTransaction calls — are what an interviewer is probing for, not a generic boxes-and-arrows microservice diagram.