
Sequentia Explores: The Mathematics of Crypto
Part VI: Building a Blockchain – The Math of a Distributed Ledger
Lecture 37: Building a Chain of Blocks: How Hashing Creates an Immutable History
In our last lecture, we dissected the anatomy of a single transaction—the fundamental building block of a blockchain. We saw how digital signatures provide unforgeable authorization for payments. But how are these individual transactions organized into the secure, shared ledger we call a blockchain?
Today, we explore the simple yet brilliant mechanism that gives the blockchain its name and its most powerful property: immutability. We’re talking about the “chain.”
The core idea is this: each new block of transactions is mathematically and chronologically linked to the block that came before it, creating a continuous, unbreakable chain stretching all the way back to the very first block ever created. The cryptographic “glue” that holds this chain together is the hash function.
Anatomy of a Block Header
A block in a blockchain is essentially a container for a batch of new, verified transactions. In addition to the list of transactions, each block has a block header, which contains crucial metadata. For our purposes, the three most important pieces of data in the header are:
- The Merkle Root: As we’ve briefly mentioned, this is a single hash that acts as a unique fingerprint for all the transactions included in this block.
- The Nonce: This is the random number the miner found to solve the Proof-of-Work hash puzzle for this block.
- The Hash of the Previous Block: This is the key that forges the chain.
Forging the Links: Chaining the Hashes
Here’s how the chain is constructed:
When a miner is trying to create a new block (let’s call it Block 100), they gather new transactions and create the Merkle root. They then take this Merkle root, the timestamp, and other metadata, and crucially, they include the entire hash of the previous block (Block 99) in the header of their new block.
The miner’s job is then to find a nonce such that the hash of Block 100’s entire header (which now contains the hash of Block 99) starts with the required number of leading zeroes.
When they succeed and publish Block 100, its hash becomes a permanent part of the public record. Now, when the next miner starts working on Block 101, what must they include in its header? The hash of Block 100.
This creates a recursive, nested dependency:
- The hash of Block 101 depends on the data in Block 101 and the hash of Block 100.
- The hash of Block 100 depends on the data in Block 100 and the hash of Block 99.
- The hash of Block 99 depends on the data in Block 99 and the hash of Block 98.
- …and so on, all the way back to the beginning of the chain.
Why This Creates Immutability (The Tamper-Evident Ledger)
This chaining of hashes is what makes the blockchain so incredibly resistant to tampering. Let’s imagine an attacker, Mallory, wants to alter a transaction from a long time ago, say in Block 50, to send some bitcoin to herself instead of the original recipient.
Let’s see what happens:
- Mallory Alters Data in Block 50: She changes a transaction within Block 50.
- The Merkle Root Changes: Because the transaction data has changed, the Merkle root for Block 50, which is a fingerprint of all its transactions, will change completely (due to the avalanche effect of hashing).
- The Hash of Block 50 Changes: Because the Merkle root in the header of Block 50 has now changed, the entire hash of Block 50 will also change to a completely new, unpredictable value.
- The Chain Breaks: Here’s the critical part. Block 51 was created containing the original hash of Block 50. Now that the hash of Block 50 has changed, the “Previous Block Hash” stored in Block 51 is no longer valid. The link between Block 50 and Block 51 is broken.
- A Cascade of Invalidity: Since the hash of Block 50 is now different, for Block 51 to be valid again, Mallory would have to re-calculate its hash. But if she changes Block 51’s header, that will change the hash of Block 51. This, in turn, will break the link to Block 52, because Block 52 contains the old hash of Block 51.
To successfully alter one transaction in Block 50, Mallory would have to:
- Change the transaction and re-calculate the Merkle root for Block 50.
- Find a new nonce for Block 50 to solve its Proof-of-Work puzzle again.
- Update the “Previous Block Hash” in Block 51 and find a new nonce for it.
- Update the “Previous Block Hash” in Block 52 and find a new nonce for it.
- …and continue this process for every single block from Block 50 all the way to the present.
She would have to re-mine dozens, hundreds, or thousands of blocks, and she would have to do it faster than the entire rest of the global Bitcoin network, which is continuing to add new, valid blocks to the original chain.
This is computationally impossible. The amount of energy and processing power required to rewrite even a small portion of the blockchain’s history would be astronomical, far exceeding the resources of any single entity.
This is why the blockchain is often called tamper-evident. You can change the past, but doing so breaks the chain in such an obvious and catastrophic way that everyone on the network would immediately reject your fraudulent version. The shared history is secured not by hiding it, but by linking it together with a fragile, yet unbreakable, chain of cryptographic hashes.