How a Blockchain Actually Works

Blockchain & Web3 Fundamentals

Course 1 · Chapter 3 · How a Blockchain Actually Works: Blocks, Chains & Merkle Trees

Chapter 2 built the two tools blockchain relies on: hash functions and public-key signatures. This chapter assembles them into the actual structure the word "blockchain" describes — what's really inside a block, how a Merkle tree efficiently proves a transaction is really in one, and precisely how chaining blocks together by hash makes the whole ledger tamper-evident.

What's Actually Inside a Block

A block splits into two real parts: a small block header and a much larger block body containing the actual list of transactions. The header is what gets hashed, chained to the previous block, and mined — it's deliberately small and fixed-size, while the transaction list underneath it can be large.

Block N — Header

previous block hash — the hash of Block N−1's own header

merkle root — a single hash summarizing every transaction in this block

timestamp — roughly when this block was created

difficulty target (bits) — how hard the proof-of-work puzzle for this block must be

nonce — "number used once," adjusted by miners while searching for a valid hash (Chapter 4)

Block N — Body

Transaction 1, Transaction 2, Transaction 3, … (every transaction included in this block)

Merkle Trees: Proving One Transaction Is In a Block, Efficiently

A block can contain thousands of transactions. If you wanted to prove — and have someone else verify — that one specific transaction is genuinely included in a specific block, the naive approach would be handing over every single transaction in the block and re-hashing all of them. A Merkle tree, named after Ralph Merkle, who patented the concept in 1979 (the patent was published in 1982), solves this far more efficiently.

A Merkle tree is a binary tree of hashes: every "leaf" is the hash of one individual transaction, and every node above that is the hash of its two children's hashes combined. This repeats, layer by layer, until a single hash remains at the very top — the Merkle root, which is the one value actually stored in the block header.

Merkle Root

Hash(AB)Hash(CD)

Hash(A)Hash(B)Hash(C)Hash(D)

Tx ATx BTx CTx D

The real payoff: to prove transaction B is included, you don't need every transaction in the block — only Hash(A) and Hash(CD), the small handful of sibling hashes on the path up to the root. Anyone can recompute Hash(AB) from Hash(A) and Hash(B), then Hash(ABCD) from that and Hash(CD), and check the result against the block header's own stored Merkle root. The number of hashes needed grows only with the logarithm of the number of transactions, not linearly with all of them — genuinely efficient even for a block with thousands of transactions inside it.

Simplified Payment Verification (SPV) This efficiency is exactly what lets a lightweight Bitcoin wallet — one that hasn't downloaded the entire multi-hundred-gigabyte blockchain — still verify that a specific payment to it is genuinely included in a block. It downloads only the block headers and a short Merkle proof for its own transaction, rather than every transaction in every block ever mined.

A Real, Documented Vulnerability — Second-Preimage Attacks A naive Merkle tree implementation can be vulnerable to a real attack where a completely different set of leaf data produces the exact same Merkle root, if internal nodes and leaf nodes aren't distinguished from each other during hashing. Real, production systems (Certificate Transparency is one documented example) defend against this by prefixing leaf hashes and internal node hashes with different marker bytes before hashing, so an internal node's hash can never be mistaken for, or substituted by, a leaf's hash. This is a genuine implementation detail worth knowing, not a flaw in the core Merkle tree concept itself.

Chaining Blocks Together

The "chain" in blockchain comes from one specific field in the header: every block stores the hash of the block that came immediately before it. This single design choice is what turns a list of independent blocks into a genuinely tamper-evident chain.

Here's precisely why, using the avalanche-effect property Chapter 2 already established: if anyone alters even a single transaction inside Block N after the fact, Block N's own header hash changes completely and unpredictably. But Block N+1 already has Block N's original hash hard-coded into its own header — so Block N+1 no longer correctly references Block N at all. Worse for the attacker, Block N+1's own header hash has therefore also changed, breaking Block N+2's own reference to it, and so on all the way to the current tip of the chain.

Why This Is Genuinely Expensive to Fake, Not Just Awkward Altering one old block doesn't just break one link — it forces an attacker to redo the proof-of-work (Chapter 4) for that block and every single block after it, all before the honest network extends the real chain even further ahead. The deeper in the past a block is, the more blocks sit on top of it, and the more computational work an attacker would need to outrun the entire rest of the network to catch up and overtake — which is precisely why a transaction buried under many later blocks is considered far more secure than one in the most recent block.

Structure	What It Contains	What It Enables
Merkle tree	A binary tree of transaction hashes, collapsing to one root	Efficiently proving one transaction belongs to a specific block, without downloading them all
Block chain (the header link)	Each block header storing the hash of the block before it	Making the entire history tamper-evident — altering the past breaks every block after it

Chapter 4 covers the piece this chapter has deliberately left open: exactly what "proof-of-work" means, why finding a valid nonce is deliberately expensive, and how a distributed network of mutually distrusting participants uses this to agree on one single, shared version of the chain.

Hands-On Exercises

Three exercises reinforcing block structure, Merkle proofs, and the chain-of-hashes tamper-evidence mechanism before Chapter 4 covers consensus.

Exercise 1

A block contains 8 transactions, arranged in a Merkle tree exactly like the diagram in this chapter but one level deeper. If you wanted to prove transaction #5 (out of 8) is included in the block, how many sibling hashes would you need, and why is that number so much smaller than handing over all 8 transactions?

→ Solution

Exercise 2

Explain precisely why an attacker who wants to secretly alter a transaction from 5 blocks ago can't just recompute that one block's hash and move on — walk through what actually breaks, block by block, and what the attacker would have to redo to fix it.

→ Solution

Exercise 3

Explain, in your own words, why a lightweight wallet using Simplified Payment Verification (SPV) can trust that its own transaction is really in a block without downloading and checking every other transaction in that block.

→ Solution

Quick Reference

Block header — previous block hash, Merkle root, timestamp, difficulty target, nonce.
Block body — the actual list of transactions included in the block.
Merkle tree — a binary tree of hashes (Ralph Merkle, 1979/1982 patent) collapsing many transactions into one root hash.
Merkle proof — only log₂(n) sibling hashes needed to prove one transaction belongs to a block of n transactions.
SPV (Simplified Payment Verification) — lightweight wallets verify their own transactions using headers and Merkle proofs, without the full chain.
The chain — each block stores the previous block's hash; altering any past block breaks every block's link after it, all the way to the tip.