Design a Permissionless Public Blockchain

Problem statement

Design a public blockchain where anyone may run a node, submit transactions, and participate in block production without asking permission. There is no operator, no allowlist, no support desk that can reverse a state transition. The system must therefore produce a single canonical history agreed by mutually distrustful participants, some of whom are actively adversarial, using only voluntary resources: hash power or staked capital, bandwidth, disk, and CPU.

This inverts ordinary distributed-systems thinking. In a company backend you control identity, membership, and the failure domain; you can retry, roll back, and page an on-call engineer. In a permissionless chain, identity is a keypair, membership is churn under attack, and rollback is theft. Every design choice — consensus, block structure, transaction validation, fee market, gossip topology, state representation — must survive the assumption that a well-funded adversary controls a large minority of peers, validators, and bandwidth.

The four planes of the design

1. Network plane: peer discovery, gossip of transactions and blocks, sync of new nodes, resistance to eclipse and denial-of-service.
2. Consensus plane: who may propose a block, how forks are resolved, when a prefix of history becomes safe to treat as immutable (finality), and what misbehavior is slashable.
3. Execution plane: the transaction model (account or UTXO), deterministic state transition function, gas metering, and the virtual machine or script interpreter.
4. State plane: the authenticated state structure (Merkle trie), storage layout, pruning, and proofs that let a light client verify without trusting anyone.

Public operating baseline versus design assumptions

Public chains prove the category works at real scale. Bitcoin sustains roughly 3–7 transactions per second with 1 MB base blocks (4 million weight units after SegWit) and a 10-minute target interval; its public hash rate sat in the hundreds of exahashes per second across 2024–2025. Ethereum's base layer processed on the order of 1–1.7 million transactions per day in 2024–2025 (roughly 13–20 tx/s) with 12-second slots and a gas limit publicly raised through the 30–45 million range during 2025. Solana publicly targets sub-second slots and tens of thousands of theoretical TPS while suffering repeated halts in 2021–2023, including a roughly 17-hour outage in September 2021. These are cited public figures, not our requirements.

For capacity planning this answer explicitly assumes a mature proof-of-stake chain with 150 tx/s sustained inclusion, 600 tx/s peak mempool ingress, 6-second slots, 10,000 active validators, 150 million account leaves, and a 45 million gas block limit. Unless tied to a citation, every number is a stated design assumption, target, or budget.

Why 'just use Proof of Work' is a weak answer

Consensus is a trade-off surface, not a product choice: Nakamoto consensus buys simple Sybil resistance and monotonic liveness but pays in energy, slow finality, and hardware industrialization; proof-of-stake buys cheap finality and slashing but pays in weak-subjectivity bootstrapping and stake-centralization pressure. A strong answer picks one primary mechanism, states the security budget it buys, and shows the fallback behaviors when its assumptions break.