Low Level Design: Blockchain Distributed Ledger

Introduction

Blockchain is an append-only distributed ledger where each block cryptographically links to the previous one. Immutability is guaranteed by hash chaining: altering any block invalidates all subsequent hashes. Consensus mechanisms ensure all nodes agree on the canonical chain without a central authority.

Block Structure

The block header contains: previous_block_hash, merkle_root, timestamp, nonce, difficulty_target, and version. The block body is a list of transactions. The block hash is computed as SHA256(SHA256(header)). For Proof of Work, the block_hash must be less than the difficulty_target. For Proof of Stake, the block is signed by the selected validator. Blocks are linked by including the previous_block_hash in each header, forming the chain.

Merkle Tree

The Merkle tree is a binary tree of transaction hashes. Leaf nodes are SHA256(transaction). Internal nodes are SHA256(left_child + right_child). The root is the Merkle root stored in the block header. This structure enables Merkle proofs: proving a transaction is included in a block with O(log N) hashes, without downloading the full block. SPV (Simplified Payment Verification) clients use Merkle proofs to verify transactions efficiently.

Proof of Work

Miners compete to find a nonce such that SHA256(SHA256(header)) is less than the difficulty_target. The process is probabilistic: expected solve time equals difficulty divided by hash_rate. Difficulty is adjusted every 2016 blocks to target a 10-minute block time. PoW is energy-intensive. A 51% attack requires controlling the majority of the network hash rate. Orphan blocks occur when two valid blocks are found simultaneously; the network eventually converges on one.

Proof of Stake

Validators stake collateral (cryptocurrency) to be eligible to propose and attest to blocks. A validator is selected proportionally to their stake. Ethereum’s PoS requires 32 ETH stake per validator; committees of validators attest to blocks each epoch (32 slots). Slashing penalizes validators for equivocating (signing conflicting blocks). PoS is energy-efficient compared to PoW. A 51% attack requires controlling 51% of the total staked value.

UTXO vs Account Model

Bitcoin uses the UTXO (Unspent Transaction Output) model: each transaction consumes previous UTXOs and creates new ones. Benefits include privacy (each transaction can use new addresses) and parallel validation (independent UTXO sets can be validated concurrently). Ethereum uses the account model: each address has a balance, a nonce (prevents replay), and contract storage. The account model is simpler for smart contracts. Sequential nonces prevent transaction replay attacks.

Transaction Validation

Validation steps: check that the signature is valid (sender signed with their private key); check that inputs are unspent (UTXO not previously spent, or account has sufficient balance); check that the nonce is correct (account model); check that the fee is at or above the minimum fee. Valid transactions are added to the mempool. Nodes gossip valid transactions across the P2P network.

Smart Contracts

Smart contracts are code deployed to the blockchain as bytecode (Ethereum EVM). All validating nodes execute them deterministically. State is stored in each account’s storage trie. Gas limits computation cost and prevents infinite loops. Solidity compiles to EVM bytecode. Deploying a contract creates a new account with a code hash. Contract calls trigger state transitions recorded on-chain.

{ “@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [ { “@type”: “Question”, “name”: “What role does a Merkle tree play in a blockchain ledger design?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “A Merkle tree is a binary hash tree where each leaf node holds the hash of a transaction and each internal node holds the hash of its two children. In Bitcoin, the Merkle root of all transactions in a block is stored in the block header. This lets a light client (SPV node) verify that a specific transaction is included in a block by downloading only O(log n) hashes rather than all n transactions — a Merkle proof. Any tampering with a single transaction changes its leaf hash, cascades up to the root, and invalidates the block header hash, making fraud detectable without full data.” } }, { “@type”: “Question”, “name”: “What are the tradeoffs between the UTXO model and the account model in blockchain ledger design?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “UTXO (Unspent Transaction Output), used by Bitcoin, treats each coin as a discrete output locked to an owner; spending consumes UTXOs and creates new ones. This enables easy parallel validation of non-overlapping UTXOs and provides strong privacy through coin selection, but state size grows with the number of unspent outputs and writing complex stateful logic is difficult. The account model, used by Ethereum, stores a global state trie mapping addresses to balances and contract storage. It is more intuitive for smart contracts and produces smaller transaction sizes, but sequential nonce ordering creates contention and replay-attack vectors, and global state makes sharding harder.” } }, { “@type”: “Question”, “name”: “How do Proof of Work and Proof of Stake consensus mechanisms compare in a system design context?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “PoW requires miners to expend real computational energy to produce a hash below a target difficulty. This makes Sybil attacks expensive but wastes energy proportional to hash rate and limits throughput (Bitcoin ~7 TPS). Finality is probabilistic — a block is considered final after enough confirmations. PoS validators lock (stake) cryptocurrency as collateral; the protocol selects block proposers weighted by stake. Energy use drops by ~99.95% (as seen with Ethereum’s Merge). Throughput can be much higher. Finality can be deterministic with BFT-style voting (Casper FFG). The main risk shifts from 51% hash power attacks to stake concentration; slashing conditions penalize equivocation to deter attacks.” } }, { “@type”: “Question”, “name”: “How does smart contract execution work at the system level?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “Smart contracts are bytecode stored at a contract account address on-chain. When a transaction targets that address, every full node runs the bytecode inside a sandboxed virtual machine (EVM for Ethereum). Execution is deterministic — same input always produces same state transition. Gas metering assigns a cost to each opcode; the sender pre-pays a gas limit, and unused gas is refunded. This prevents infinite loops (execution halts when gas runs out) and prices resource consumption. The EVM has no access to external network or filesystem; oracle patterns (e.g., Chainlink) inject external data via signed on-chain transactions to keep determinism intact.” } }, { “@type”: “Question”, “name”: “How are soft forks and hard forks handled in blockchain protocol design?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “A soft fork tightens the validity rules so that blocks valid under the new rules are still valid under the old rules — old nodes accept new blocks without upgrading. Bitcoin’s SegWit used a soft fork by encoding witness data in a field old nodes treat as always-true. Activation can be miner-signaled (BIP 9) or user-activated (UASF). A hard fork relaxes or changes rules incompatibly; old nodes reject new blocks, causing a permanent chain split unless all participants upgrade. Ethereum’s transition to PoS was a hard fork requiring coordinated client upgrades. In design, prefer soft forks when backward compatibility matters; use hard forks when you need to break constraints (e.g., increasing block size) and can coordinate the entire network.” } } ] }