L02: Blockchain Fundamentals

Master the technical architecture of blockchain: blocks, chains, hashes, distributed ledgers, and immutability.

⏱️ Estimated Time: 2-3 hours for complete mastery

Learning Objectives

By the end of this study session, you will be able to:

  • Describe the structure and components of a blockchain block
  • Explain how blocks are linked together using cryptographic hashes
  • Calculate simple hash values and understand hash properties
  • Understand Merkle trees and their role in efficient verification
  • Explain the concept of immutability and why rewriting history is costly
  • Compare distributed ledgers to traditional centralized databases
  • Analyze the trade-offs between different blockchain architectures

Study Path

Read Summary Slides

Start with the summary slides (PDF). Pay special attention to block structure diagrams and Merkle tree illustrations.

Interactive Exploration

Use the Anders Brownworth blockchain demo to see blocks and chains in action. Try modifying data to see how hashes change.

Complete Practice Problems

Work through all 10 practice problems below. Several involve hash calculations and Merkle tree construction.

Take the Quiz

Test your knowledge with Quiz 2. Aim for at least 80% correct.

Build a Block (Optional)

Try the Block Building assignment for hands-on practice.

Key Concepts Summary

Block Structure

Block Header:

  • Previous block hash - Links to parent block
  • Timestamp - When block was created
  • Merkle root - Summary of all transactions
  • Nonce - Number used in proof-of-work

Block Body: Contains all transactions in the block

Cryptographic Linking

Each block contains the hash of the previous block, creating a chain:

Block N → hash(Block N-1) → hash(Block N-2) → ... → Genesis Block

Why this matters: Changing any historical block invalidates all subsequent blocks, making tampering detectable and costly.

Hash Function Properties

  • Deterministic: Same input always produces same output
  • Fast: Quick to compute
  • Avalanche effect: Tiny input change → completely different output
  • One-way: Cannot reverse (find input from output)
  • Collision-resistant: Extremely hard to find two inputs with same hash

Merkle Trees

A tree of hashes where:

  • Leaf nodes = transaction hashes
  • Parent nodes = hash of concatenated child hashes
  • Root = single hash summarizing all transactions

Benefits: Verify specific transaction inclusion with O(log n) hashes instead of downloading entire block.

Distributed vs. Centralized Ledgers

Centralized: Single database, fast, trusted operator, single point of failure

Distributed: Many copies, slower, trustless verification, censorship-resistant

Key difference: Blockchain replaces trust in operator with trust in cryptography and consensus.

Immutability

Why blockchain is "append-only":

  • Changing block N requires recalculating all hashes from N onward
  • Requires redoing all proof-of-work (expensive!)
  • Must outpace honest chain (51% attack)
  • Cost typically exceeds any potential gain

Practice Problems

Problem 1: List the four main components of a block header and explain the purpose of each.
Answer:
1. Previous block hash: Creates the chain linkage; changing any past block breaks this link
2. Timestamp: Records when block was created; ensures chronological ordering
3. Merkle root: Single hash summarizing all transactions; enables efficient verification
4. Nonce: Number varied during mining to find valid proof-of-work; proves computational effort
Problem 2: If you change one character in transaction #3 of Block 100, which blocks become invalid? Why?
Answer: Blocks 100, 101, 102, ... all future blocks become invalid. Here's why:
- Changing transaction #3 changes its hash
- This changes the Merkle root of Block 100
- This changes Block 100's header hash
- Block 101 contains Block 100's hash, so Block 101's hash becomes invalid
- Block 102 contains Block 101's hash, so Block 102 becomes invalid
- The cascade continues to the latest block
This is the core of immutability - you can't secretly change history because it breaks the entire chain forward.
Problem 3: A block contains 8 transactions. Draw the Merkle tree structure and calculate how many hashes are needed to verify transaction #5 is included (without downloading all transactions).
Answer:
                        Root
                       /    \
                      H1     H2
                     / \     / \
                   H3  H4  H5  H6
                   /\  /\  /\  /\
                  T1T2T3T4T5T6T7T8
To verify T5 is included, you need:
1. Hash of T5 (you calculate this yourself)
2. Hash of T6 (to compute H5)
3. H4 (to compute H2)
4. H1 (to compute Root)
Total: 3 additional hashes needed vs. downloading all 8 transactions. This is O(log n) efficiency - for 1000 transactions, you'd need only ~10 hashes.
Problem 4: Explain the "avalanche effect" in hash functions. Why is this property critical for blockchain security?
Answer: The avalanche effect means changing even a single bit in the input produces a completely different, unpredictable hash output - typically 50% of output bits flip.

Example: hash("Block 100") vs hash("Block 101") → entirely different hashes

Critical for security because:
1. Makes tampering obvious - you can't make small changes unnoticed
2. Prevents targeted manipulation - can't predict how to modify data to get desired hash
3. Enables proof-of-work - must try many nonces to find hash meeting difficulty target
4. Protects against forgery - can't construct valid-looking blocks without proper inputs
Problem 5: Bitcoin aims for 10-minute block times. Why not make blocks every 10 seconds for faster transactions?
Answer: Faster blocks create problems:
1. More orphan blocks: With slow network propagation, miners often work on outdated chains, wasting work
2. Reduced security per block: Same total hash power spread over more blocks = less work per block
3. Favors centralization: Well-connected miners with fast propagation have advantage
4. Storage overhead: More blocks = more headers to store and validate

The 10-minute interval balances speed vs. security. Faster confirmation needs come from Layer 2 solutions (Lightning Network) rather than faster base-layer blocks.
Problem 6: Calculate: A blockchain has 500,000 blocks. An attacker wants to rewrite block #250,000. If each block takes 10 minutes to mine, how long would it take to rewrite history (assuming attacker has same hash power as entire honest network)?
Answer:
Blocks to rewrite: 500,000 - 250,000 = 250,000 blocks
Time per block (with 50% of network): 20 minutes
Total time: 250,000 × 20 minutes = 5,000,000 minutes = ~9.5 years

BUT: During those 9.5 years, the honest network continues adding new blocks, so the attacker must catch up to a moving target. With equal hash power, the attacker never catches up - they need >50% to eventually overtake the honest chain. This makes deep reorgs economically infeasible.
Problem 7: Compare database architectures: Why would a bank use a traditional SQL database instead of a blockchain? Give 3 technical reasons.
Answer:
1. Performance: SQL databases handle 10,000+ transactions/sec; blockchains do 7-50 tx/sec due to consensus overhead
2. Privacy: Banks need confidential transactions; public blockchains are transparent by design
3. Flexibility: Banks need to reverse fraud, comply with regulations, correct errors - blockchain's immutability makes this difficult

Banks don't need decentralization (they're the central authority) so blockchain's benefits don't outweigh costs. They might use private/permissioned blockchains for specific inter-bank settlement use cases.
Problem 8: True or False: "Blockchain makes data impossible to change." Explain your answer with technical detail.
Answer: FALSE - This is a common misconception. Blockchain data CAN be changed, but it's:

1. Extremely expensive: Requires redoing all proof-of-work from that point onward
2. Requires majority control: Need 51%+ hash power to outpace honest chain
3. Publicly visible: Deep reorganizations are obvious to network participants
4. Economically irrational: Cost typically exceeds any gain

More accurate statement: "Blockchain makes data economically impractical to change without majority control, and any change is detectable." The security comes from incentive alignment, not technical impossibility.
Problem 9: Genesis block challenge - Why is the genesis block (first block) special? What doesn't it have that every other block has?
Answer: The genesis block has no previous block hash (or has a hardcoded zero/null value) because it's the first block - nothing came before it. All other blocks contain a hash of the previous block.

The genesis block is also special because:
- It's hardcoded into the software (every node has the same genesis block)
- Often contains a message (Bitcoin's references a newspaper headline from Jan 3, 2009)
- Its timestamp establishes the blockchain's beginning
- It's the common ancestor of all blocks, making it the ultimate trust anchor
Problem 10: Advanced - Light clients (SPV wallets) don't download full blocks. Using Merkle trees, explain how they can verify a payment was included in block #500,000 without downloading the entire blockchain.
Answer: Light client verification process:

1. Download all block headers (~80 bytes each = 40 MB for 500k blocks) - contains Merkle roots
2. Request Merkle proof from full node for specific transaction in block #500,000
3. Receive: Transaction + sibling hashes needed to reconstruct path to Merkle root
4. Verify: Hash transaction, combine with siblings, hash up the tree
5. Check: Does computed root match the Merkle root in block header #500,000?
6. Confirm: Block #500,000 is in the main chain (has most proof-of-work)

Security assumption: Light client trusts that most hash power is honest, but doesn't trust individual full nodes (can verify proofs independently).

External Resources

Interactive Tools

Videos

Articles

Documentation

Self-Check Questions

Before moving to Lesson 3, ensure you can confidently answer these questions:

  • Can you draw and label the components of a blockchain block?
  • Can you explain why changing historical data breaks the chain?
  • Can you construct a simple Merkle tree and verify transaction inclusion?
  • Can you list and explain three properties of cryptographic hash functions?
  • Can you explain the difference between distributed and centralized ledgers?
  • Can you calculate the cost of rewriting blockchain history?

If you answered "yes" to all, you're ready for Lesson 3: Cryptographic Foundations!