How Blockchain Works: Understanding Distributed Ledger Technology

The Fight Over the Notebook

Aisha, Rohan, and Meera run their school's cricket fund. Every rupee that comes in or goes out — subscriptions collected, a new ball bought, umpire fees paid — gets written by hand in a single spiral notebook that Aisha keeps in her bag. Three weeks before the inter-school tournament, Rohan says he paid Meera ₹300 for jerseys. Meera says she never received it. They flip to the page. The entry that should say "Rohan pays Meera ₹300" instead reads "Rohan pays Meera ₹30" — and there's a suspicious gap after the "3" where a zero could have been erased with a bit of spit and a fingernail.

Nobody can prove what the notebook originally said. There is exactly one copy, it was written in pencil, and only Aisha had it in her bag all week. This is not a story about three careless classmates — it is the oldest problem in record-keeping. Whenever a group of people who don't fully trust each other need to agree on a shared history of "who did what," two things can go wrong: someone can quietly change an old entry, or two people can remember the history differently and there's no way to tell whose version is correct. A blockchain is a specific, clever answer to exactly this problem. It is not magic internet money — it is a way of keeping a shared record so that changing old entries becomes practically impossible to do without everyone noticing. By the end of this chapter you will have built one, broken one, and understood precisely why breaking it is so hard.

Step One: More Copies Are Not Enough

The obvious first fix is: don't let one person hold the only notebook. Give Aisha, Rohan, and Meera each their own copy, and whenever a new entry is added, all three write it into their own notebook. Now if Aisha's copy is edited, Rohan's and Meera's copies still show the truth, and a majority vote settles the dispute. This idea — many independent copies of the same record, instead of one central copy controlled by a single person or company — is the first pillar of a blockchain. It is usually called a distributed ledger: "ledger" because it's a record of transactions, "distributed" because no single party holds the only master copy.

But copies alone don't fully solve the problem, for two reasons. First, if someone edits their copy on page 4 and doesn't bother updating page 5 and 6 to stay "consistent," how would anyone even notice the edit just by glancing at the notebook? A single tampered word looks completely ordinary sitting on a page. Second, with three people it's easy to hold a vote, but real systems — a national land registry, a cryptocurrency used by millions of people — might have thousands of independent copy-holders scattered across the world, and comparing every word of every notebook against every other notebook to catch a single altered rupee sign would be unbearably slow. We need something better than "compare everything word for word." We need a way to compress an entire page into a short signature such that if even one character on that page changes, the signature changes completely and obviously. That tool is called a hash function, and it is the actual engine that makes blockchains work.

Fingerprinting a Record: What Is a Hash Function?

A hash function takes any piece of text — a single word or an entire book — and produces a fixed-size number (or string) called a hash, deterministically: the same input always produces the same output, but there's no way to work backward from the hash to recover the input, and no way to predict how the hash will change just by looking at the input. Think of it as a blender that turns any amount of fruit into exactly one glass of juice — you can always tell if two glasses came from identical fruit (identical juice), but you can't "un-blend" the juice back into the original apple.

Real blockchains use a cryptographic hash function called SHA-256, which is far too complex to trace by hand in a classroom. To understand the idea without getting lost in cryptographic mathematics, we'll build a simplified toy hash function in Python. It is not secure enough for real use — we'll return to exactly why — but it behaves the same way structurally, and every line of it you can trace with a pencil.

def simple_hash(text):
    h = 0
    for ch in text:
        h = (h * 31 + ord(ch)) % 100000
    return h

print(simple_hash("Hi"))

Trace it by hand. ord(ch) gives the character's numeric code (a fixed number every character has — ord('H') is 72, ord('i') is 105). Starting with h = 0:

• First character 'H': h = (0 * 31 + 72) % 100000 = 72
• Second character 'i': h = (72 * 31 + 105) % 100000 = (2232 + 105) % 100000 = 2337

So simple_hash("Hi") outputs 2337 — and running the code confirms exactly that. The % 100000 at each step keeps the number bounded (never more than 5 digits) no matter how long the input text is — that's what makes the output a fixed-size fingerprint instead of growing forever. Change the input even slightly — "Hi " with a trailing space, or "hi" in lowercase — and every character's contribution multiplies through the running total differently, so the final number comes out completely different. That sensitivity to tiny changes is the entire point of a hash: it turns "did anything change?" from a slow word-by-word comparison into a single, instant number comparison.

Chaining Records Together

A hash alone only fingerprints one page. The second idea — the one that turns a stack of pages into a chain — is to make every page's fingerprint depend on the fingerprint of the page before it. Each entry in the ledger, called a block, stores three things: the data itself (the transaction), the hash of the previous block, and its own hash, computed from both the data and the previous block's hash glued together. This is exactly what "blockchain" names: a chain of blocks, each one cryptographically welded to the one before it.

class Block:
    def __init__(self, index, data, previous_hash):
        self.index = index
        self.data = data
        self.previous_hash = previous_hash
        self.hash = self.compute_hash()

    def compute_hash(self):
        return simple_hash(str(self.index) + self.data + str(self.previous_hash))

b0 = Block(0, "Genesis Block", 0)
b1 = Block(1, "Aisha pays Rohan Rs500", b0.hash)
b2 = Block(2, "Rohan pays Meera Rs300", b1.hash)
b3 = Block(3, "Meera pays Aisha Rs700", b2.hash)

for b in [b0, b1, b2, b3]:
    print(f"Block {b.index}: prev_hash={b.previous_hash} hash={b.hash}")

The very first block, b0, is called the genesis block — it has no real predecessor, so its previous_hash is just set to 0 by convention. Running this code produces:

Block 0: prev_hash=0 hash=36107
Block 1: prev_hash=36107 hash=89873
Block 2: prev_hash=89873 hash=85184
Block 3: prev_hash=85184 hash=3092

Notice the pattern: Block 1's stored previous_hash (36107) is exactly Block 0's hash. Block 2's previous_hash (89873) is exactly Block 1's hash. Every block physically contains a copy of the fingerprint of the block behind it. This is what makes the sequence a genuine chain rather than just a list — each link is glued to its specific neighbour, not just numbered in order.

Why Tampering Breaks the Chain

Now let's do what a dishonest classmate might try: quietly change Block 2's data from "Rohan pays Meera Rs300" to "Rohan pays Meera Rs300000," hoping nobody notices a stray zero was added.

def is_valid(chain):
    for i in range(1, len(chain)):
        current = chain[i]
        prev = chain[i - 1]
        if current.previous_hash != prev.hash:
            return False
        if current.hash != current.compute_hash():
            return False
    return True

print(is_valid([b0, b1, b2, b3]))   # True, before tampering

b2.data = "Rohan pays Meera Rs300000"
print(is_valid([b0, b1, b2, b3]))   # ?

Before tampering, is_valid returns True: for every block, its stored hash matches what you'd get by recomputing the hash fresh from its own data, and its previous_hash matches its neighbour's actual hash. After the edit, the second check catches the crime immediately: Block 2's stored hash is still the old value, 85184, but recomputing the hash from its new (tampered) data gives a completely different number — 95158. The moment current.hash != current.compute_hash(), the function returns False. The forgery is exposed the instant anyone checks.

A clever forger might say: "Fine, I'll also update Block 2's stored hash field to 95158, so it matches its own tampered data." Try it — the validity check still fails, but now for the other reason: Block 3 was created earlier, and it permanently stored previous_hash = 85184, Block 2's original hash, baked in at the moment Block 3 was made. Block 2's new hash (95158) no longer matches what Block 3 says it should be. To hide the forgery completely, the attacker would have to also recompute Block 3's hash to match, which changes Block 3's hash, which breaks Block 4's stored link, and so on — the attacker must re-forge every single block from the tampered one to the most recent one, every time, on every single copy of the ledger held by every honest participant, faster than new blocks are being added. With three notebooks that's merely hard. With thousands of independently held copies spread across a network, it becomes computationally and practically unworkable — which is precisely the property blockchains are designed to guarantee.

Misconception Check: Hashing Is Not Encryption

Students very often confuse hashing with encryption because both turn readable data into unreadable-looking gibberish. They are fundamentally different tools. Encryption is reversible on purpose — if you have the correct key, you decrypt the scrambled data and get the original message back exactly. Hashing is deliberately one-way — there is no "un-hash" key, and no legitimate procedure recovers "Rohan pays Meera Rs300" starting only from the number 85184. A hash isn't for hiding a message; it's for producing a short, tamper-evident fingerprint of a message that's already sitting right there in the block, in plain view. Anyone can read Block 2's data directly. What they can't do is quietly change it without the fingerprint giving them away.

No Boss Allowed: Reaching Agreement Without a Central Authority

Chaining hashes solves tamper-detection on one notebook. It does not, by itself, decide who is allowed to write the next entry when nobody is in charge. Compare two systems you already use. When you pay someone through UPI, the National Payments Corporation of India's servers are the single, central authority: they hold the one true record of your balance, and your bank app simply trusts whatever that central server says. This is fast and works well precisely because everyone trusts NPCI and the banking system behind it — but it is not a blockchain, and it's a common misconception to call it one. A real blockchain assumes the opposite: no single company, bank, or government controls the ledger. Thousands of independent computers (called nodes) each hold their own full copy of the entire chain, and they must somehow agree, without a boss, on which new block gets added next and in what order — because if two nodes added two different "next blocks" at the same time, the chain would split into two conflicting versions. The procedure a network uses to reach this agreement is called a consensus mechanism, and the original, most famous one is Proof of Work.

Proof of Work: Making the Right to Add a Block Expensive

The idea behind Proof of Work is simple to state: instead of just letting anyone add the next block for free (which anyone dishonest would abuse constantly), a node has to solve a deliberately difficult, pointless-looking puzzle before its proposed block is accepted by the rest of the network. The puzzle: find an extra number — called a nonce — which, when combined with the block's data and hashed, produces a hash smaller than some target value. There's no clever shortcut to find such a nonce; the only known method is to try nonce = 0, then 1, then 2, and so on, hashing each time and checking.

data = "Block2:Rohan pays Meera Rs300"

for target in [1000, 50000]:
    nonce = 0
    while True:
        attempt = simple_hash(data + str(nonce))
        if attempt < target:
            print(f"target<{target}: nonce={nonce} hash={attempt} attempts={nonce + 1}")
            break
        nonce += 1

Running this against a strict target (the hash must land below 1000, out of a possible range of 0 to 99,999 — roughly a 1-in-100 chance per guess) takes 1,701 attempts before nonce 1700 finally produces a hash of 28. Loosen the target to below 50,000 — roughly a coin flip's odds per guess — and the very first attempt, nonce 0, already succeeds, giving hash 38106. This is the essence of difficulty in Proof of Work: the network controls how strict the target is, and a stricter target means solvers must burn through vastly more electricity and computing time, on average, before finding a valid nonce. Real Bitcoin miners run this same search — using SHA-256, not our toy hash — at roughly one hundred quintillion attempts per second across the whole network, restlessly trying nonce after nonce.

Why does making block-creation expensive prevent cheating? Because rewriting old history the way our forger tried earlier now requires much more than recomputing a few cheap hashes — it requires redoing the expensive puzzle-solving for the tampered block and every block after it, faster than the rest of the honest network is solving fresh puzzles and extending the real chain. One dishonest node cannot realistically out-compute thousands of honest nodes combined. This is why Proof of Work is sometimes summarised as "security through wasted effort" — the effort isn't actually wasted; it's the very thing that makes cheating economically irrational. (It's worth knowing that Proof of Work is not the only consensus mechanism — Ethereum, for example, switched in 2022 from Proof of Work to an alternative called Proof of Stake, where the "cost" of misbehaving is putting your own cryptocurrency holdings at risk of being forfeited, instead of burning electricity. The underlying goal — making it expensive to lie — stays the same.)

Immutable Doesn't Mean Impossible — the 51% Nuance

Here is a second misconception worth correcting precisely, because CBSE-level rigor demands it: people often say a blockchain is "unhackable" or that rewriting history is "mathematically impossible." That overstates it. What Proof of Work actually guarantees is that rewriting history requires controlling more computing power than the rest of the honest network combined — commonly called a 51% attack. If a single miner, or a coalition of miners, genuinely controlled the majority of a network's total computing power, they could, in principle, out-race everyone else and force through an alternate version of recent history. This is not a theoretical loophole invented for this chapter — it is exactly why large, widely-distributed networks with many independent participants are so much more trustworthy than small ones: the more independent nodes genuinely competing to extend the real chain, the more computing power an attacker would need to acquire, and the more economically absurd the attack becomes. "Immutable" in blockchain therefore means practically and economically unfeasible to alter, backed by real, measurable computing cost — not a mathematical impossibility.

Where This Actually Gets Used

Satoshi Nakamoto's 2008 paper, "Bitcoin: A Peer-to-Peer Electronic Cash System," is what introduced this exact combination — hash-linked blocks plus Proof of Work consensus among untrusted nodes — as a way to let strangers agree on who owns what money without a bank in the middle. Ethereum, proposed by Vitalik Buterin and launched in 2015, extended the same underlying chain-of-blocks idea to also store small programs, called smart contracts, that run automatically when conditions are met — for instance, releasing payment the instant a delivery is confirmed, with no need for either party to trust the other or a middleman. Land ownership records are another area where India has genuine, well-documented reasons to be interested: title fraud, duplicate registrations, and quietly altered ownership entries have been long-standing problems in paper- and database-based land registries, which is exactly the "notebook" problem from the start of this chapter, at the scale of an entire state. This is why a few Indian state governments have piloted blockchain-based land record systems as an experiment — the tamper-evidence property you just built by hand is precisely the property such a registry needs.

Active Recall: Test Yourself

1. In your own words, explain why storing "many independent copies" of a ledger is not, by itself, enough to prevent tampering — what extra ingredient does a real blockchain add, and what problem does that ingredient solve?
2. Using simple_hash as defined in this chapter, trace by hand what simple_hash("No") evaluates to. (ord('N') is 78, ord('o') is 111.) Show your working step by step, the way the chapter traced simple_hash("Hi").
3. A friend tells you: "I encrypted the ledger entry, so nobody can read it, but it's still hashed so I can still prove it wasn't changed." Spot and correct the confusion in this sentence.
4. Block 5 in a chain stores previous_hash = 71234. Block 4's currently computed hash is 71234. An attacker edits Block 4's data and recomputes Block 4's hash, getting 90501, and updates Block 4's stored hash field to match. Walk through is_valid as defined in this chapter and state precisely which comparison, on which block, first returns False.
5. Explain, using the idea of a 51% attack, why a blockchain with only 3 participating nodes offers much weaker tamper-resistance than one with 30,000 independently operated nodes, even though both use exactly the same hashing and Proof of Work rules.
6. Is India's UPI system a blockchain? Justify your answer using the specific difference between centralized and distributed ledgers discussed in this chapter.

Diagram: A Valid Chain vs. a Tampered One

Summary

A blockchain solves a trust problem, not a computing-speed problem: how can people who don't fully trust each other agree on a shared, tamper-evident history without a central boss holding the only master copy? It does this with three ingredients stacked on top of each other. First, every participant keeps their own full copy of the ledger — a distributed ledger, unlike a centralized system such as UPI where one authority's server is the single source of truth. Second, every block of data is fingerprinted with a hash function and stores the previous block's hash inside itself, so editing any block's data breaks the mathematical link to every block that comes after it — this is what tamper-evidence actually means, and you traced it by hand with simple_hash and watched is_valid catch a forged entry. Third, a consensus mechanism such as Proof of Work makes the right to add the next block expensive to earn — through the nonce-guessing search you ran yourself — which means rewriting history requires re-earning that right for every subsequent block, faster than the rest of an honest, decentralized network is adding new ones. "Immutable" describes this economic and computational cost, not a literal impossibility — a 51% attack remains the theoretical (and occasionally real) limit. Together, these three ingredients are what let strangers — across a cricket team's notebook or across a global cryptocurrency network — trust a shared record without trusting each other individually.

Think About It

Think about this: How would you explain how blockchain works: understanding distributed ledger technology to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where how blockchain works: understanding distributed ledger technology is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting how blockchain works: understanding distributed ledger technology to at least 3 other topics you have studied.