Loading system design…
Loading system design...
Design a blockchain / distributed ledger system that maintains an immutable, append-only chain of blocks across a decentralised peer-to-peer network with no central authority. The system uses cryptographic hashing (SHA-256 / Keccak-256) to chain blocks, Merkle trees for efficient transaction proofs, and consensus mechanisms (Proof of Work — computational puzzle mining, or Proof of Stake — validator staking with slashing) to achieve agreement among potentially adversarial nodes. It supports transaction processing with digital signatures (ECDSA/Ed25519), smart contract execution (EVM), state management (Merkle Patricia Trie), and Layer 2 scaling (Optimistic Rollups, ZK Rollups).
| Metric | Value |
|---|---|
| Throughput (L1 — Bitcoin) | ~7 TPS |
| Throughput (L1 — Ethereum) | ~15–30 TPS |
| Throughput (L1 — Solana) | ~50,000 TPS |
| Throughput (L2 — Rollups) | 2,000–10,000+ TPS |
| Block time (Bitcoin) | ~10 minutes |
| Block time (Ethereum) | ~12 seconds |
| Finality (PoW, 6 confirmations) | ~60 minutes |
| Finality (PoS, Ethereum) | ~12–15 minutes |
| Network nodes (Bitcoin) | ~17,000 full nodes |
| Network nodes (Ethereum) | ~6,000 full nodes |
| Chain size (Ethereum, pruned) | ~1 TB |
| Chain size (Ethereum, archive) | ~15 TB |
Immutable append-only ledger: maintain a chain of blocks where each block contains a set of transactions; each block includes a cryptographic hash of the previous block → forming a chain; once a block is appended, its contents cannot be altered without invalidating all subsequent blocks; the ledger is the single source of truth
Decentralised peer-to-peer network: no central authority; nodes communicate via a gossip protocol over a P2P network; any node can join or leave; all nodes maintain a full copy of the blockchain (full nodes); no single point of failure; the system operates correctly even if some nodes are malicious (Byzantine fault tolerance)
Consensus mechanism: nodes must agree on which transactions are valid and their order; Proof of Work (PoW): miners solve a computational puzzle (find nonce such that hash(block) < target difficulty); Proof of Stake (PoS): validators stake tokens, selected proportional to stake; consensus ensures all honest nodes converge on the same chain
Transaction processing: users submit signed transactions (e.g., 'Alice sends 5 BTC to Bob'); transactions include: sender, receiver, amount, digital signature (ECDSA/Ed25519), nonce (prevents replay); nodes verify: signature is valid, sender has sufficient balance, nonce is correct; valid transactions added to the mempool (pending pool)
Cryptographic security: SHA-256 (Bitcoin) or Keccak-256 (Ethereum) for block hashing; ECDSA or Ed25519 for transaction signing; Merkle tree of transactions in each block (enables efficient membership proof — prove a transaction is in a block without downloading the full block); public-key cryptography for wallet addresses
Smart contracts (programmable ledger): support deploying and executing Turing-complete programs on the blockchain (Ethereum model); smart contract = code stored on-chain that executes when triggered by a transaction; use cases: token standards (ERC-20), decentralised exchanges (DEX), lending protocols, NFTs; execution is deterministic and verifiable by all nodes
State management: maintain global state — account balances (account-based model: Ethereum) or unspent transaction outputs (UTXO model: Bitcoin); state updated after each block; state stored in a Merkle Patricia Trie (Ethereum) for efficient state proofs; state root hash included in block header for verification
Block propagation: when a miner/validator produces a new block → propagate to all nodes in the network via gossip; block must reach majority of nodes quickly (< 10 seconds) to minimise stale/uncle blocks; compact block relay (send only transaction IDs, not full transactions — receiving node already has most transactions in mempool)
Fork handling: network delays or simultaneous block production → temporary forks (two valid blocks at the same height); resolution: longest chain rule (PoW — chain with most accumulated work wins) or finality gadget (PoS — checkpoint-based finality, blocks finalised after 2/3 validator attestations); transactions in orphaned blocks returned to mempool
Light clients and SPV: support lightweight clients that don't download the full blockchain (hundreds of GB); Simple Payment Verification (SPV): download only block headers → verify transaction inclusion via Merkle proof; light clients trust that the longest chain is valid (security assumption); enables mobile wallets and resource-constrained devices
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In