BR Academy
Intro to Blockchain: How It Works and Why It Matters
0%
Exit course
Blocks, Hashes, and Cryptography·Lesson 8 of 25·12 min

Why Blockchain Is Immutable

The Concept

"Immutable" doesn't mean literally, physically impossible to change — it means changing history requires redoing an enormous, rapidly compounding amount of work, verified and rejected by everyone else if you don't do it faster than the entire rest of the network combined. This lesson connects everything from Module 2 so far: block structure (header/body), hashing (deterministic, avalanche, one-way), and Merkle trees (one root represents all transactions).

Here's the chain of logic:

  1. Each block's header contains the previous block's hash (from "Anatomy of a Block").
  2. That header hash is derived partly from the Merkle root, which represents every transaction in the block (from "Merkle Trees and Proof").
  3. Hashing is an avalanche function — change one transaction, and the Merkle root changes completely, which changes the header hash completely (from "How Hashing Works").

So: if an attacker alters a transaction in block #100, block #100's Merkle root changes, which changes block #100's header hash. But block #101's header stores a reference to the original block #100 hash — so block #101 now points to a hash that no longer matches. To make the chain internally consistent again, the attacker must also recompute block #101's header (and therefore its hash), which breaks block #102's reference, requiring its recomputation too — and so on, all the way to the current tip of the chain.

In a proof-of-work network (Module 5), "recomputing a header" isn't free — it requires redoing the computational work that originally produced a valid block, for every block from the altered one to the present, while the honest network keeps adding new blocks on top at the same time. The attacker isn't just racing to catch up once — they're racing an entire network's combined computing power, continuously, for as long as it takes. This is why security increases with depth: a transaction in the most recent block is more vulnerable than one buried under 100 subsequent blocks, because rewriting it means outpacing the whole network's work across 100+ blocks.

This also explains a practical rule of thumb used throughout the crypto industry: exchanges and merchants wait for a specific number of confirmations before treating a deposit as final — commonly 1 for small amounts, 6 or more for larger Bitcoin transactions, and different thresholds on faster-but-differently-secured networks. That number isn't arbitrary superstition; it's a direct, calculable function of how much cumulative work (or stake, in proof-of-stake systems — Module 5) would need to be redone to reverse the transaction at that depth, weighed against the value being protected. A $10 coffee purchase and a $2 million property sale reasonably use different confirmation thresholds, because the cost of a successful attack only matters relative to what's at stake.

Proof-of-stake networks (Module 5) achieve a similar immutability guarantee through a different mechanism: instead of requiring attackers to out-compute the network, they require attackers to control and be willing to forfeit a large amount of staked capital, which gets automatically destroyed ("slashed") if validators are caught trying to rewrite finalized history. The cascading-hash logic in this lesson still applies identically — what changes between consensus models is what makes redoing the work costly: electricity and hardware in proof-of-work, or capital at risk of slashing in proof-of-stake.

Worked Example

Suppose an attacker wants to alter a transaction buried in block #95, and the current chain tip is block #100 (5 blocks of depth). Tracing the cascade:

  • Block #95's transaction changes → Merkle root changes → block #95's header hash changes.
  • Block #96's header stored a reference to the old #95 hash → now invalid → #96 must be recomputed → its hash changes.
  • Block #97's header pointed to the old #96 hash → now invalid → must be recomputed → changes.
  • The same cascades through #98, #99, and #100.

The attacker must redo the valid-block-producing work for blocks #95 through #100 (six blocks), all while the honest network is simultaneously extending the real chain with new blocks. Unless the attacker controls a large majority of the network's computing power (the "51% attack" scenario in Module 5), they fall further behind with every passing minute.

Exercise

In your own words, write two or three sentences explaining why a transaction with 100 confirmations (buried under 100 subsequent blocks) is considered dramatically safer against reversal than one with only 1 confirmation (the very next block after it was included). Use the cascading-hash logic from this lesson, not just "it's older so it's safer."

Then write one sentence explaining why a $10 purchase and a $2 million property sale might reasonably use different confirmation-count thresholds before being treated as final, even though the underlying cascading-hash security logic is identical for both.

Recap

  • Immutability comes from each block's header linking to the previous block's hash, which depends on the Merkle root, which depends on every transaction.
  • Altering an old block forces recomputation of every block after it — a race against the entire honest network's combined work.
  • The deeper a block is buried (more confirmations), the more computationally expensive and practically infeasible rewriting its history becomes.

Resources

Module quiz

6 questions · pass mark 70% · retake any time

1. What does a block contain?
2. What is a hash?
3. Why is it important that changing one transaction would change the block's hash?
4. What is a Merkle tree?
5. What is the purpose of the nonce in a block?
6. Why can't you reverse a hash to find the original input?
← Merkle Trees and Proof Public and Private Keys →