Blockchain

Ravi, Meera, and Arjun go on a three-day school trip. To keep things simple, they agree that whoever pays for something writes it down in one shared notebook, and at the end of the trip they will settle up based on what the notebook says. Day one: Ravi pays for the auto-rickshaw and writes "Ravi pays Meera Rs500" (Meera was holding the group's snack fund, so Ravi is repaying her). Day two: Meera pays Arjun back Rs200 for lunch. Day three: Arjun repays Ravi Rs100 for water bottles.

On the last evening, Arjun flips back through the notebook and notices something: the "500" on day one looks like it has been overwritten — it might originally have said "300". Nobody can prove it either way. The notebook has only one copy, and anyone who had it in their bag for five minutes could have changed a number in pencil. This is the exact problem that blockchain was invented to solve: how do you keep a shared record of transactions that nobody — not even the person holding it — can secretly rewrite? The answer combines two ideas you will build up from scratch in this chapter: a "fingerprint" for data called a hash, and a way of chaining records together so that changing an old entry breaks something that everyone can check.

Step 1: A Fingerprint for Data — What a Hash Function Does

Before we can understand blockchain, we need one tool: a function that takes any piece of text and turns it into a short "fingerprint" number, such that even a tiny change to the text produces a completely different fingerprint. In real systems this is called a hash function. Real ones (like SHA-256, which Bitcoin uses) are complicated to compute by hand, so let's build a simplified toy version ourselves — one you can actually calculate on paper — to understand the idea.

Here is our toy hash function. It looks at every character in a piece of text, converts each character to its ASCII code (the number that represents that character inside a computer — for example, capital "A" is 65, "B" is 66, and so on), adds all those codes together, and then takes the remainder when divided by 1000:

H(text) = (sum of ASCII codes of every character in text) mod 1000

Let's trace it on the word "BLOCK". The ASCII codes are B=66, L=76, O=79, C=67, K=75.

Sum = 66 + 76 + 79 + 67 + 75 = 363
H("BLOCK") = 363 mod 1000 = 363

Now watch what happens if we change just one character. H("CAT") sums C=67, A=65, T=84: 67 + 65 + 84 = 216, so H("CAT") = 216. If we simply add one trailing space, "CAT ", the space character has ASCII code 32, so the sum becomes 216 + 32 = 248. A single invisible space changed the fingerprint from 216 to 248. If we instead swap the last letter to get "CAR" (R=82 instead of T=84), the sum becomes 216 − 84 + 82 = 214. Every different piece of text tends to produce a different fingerprint, and even the smallest edit changes the result.

Important honesty check: our toy hash is deliberately simple so you can compute it by hand, but it is weaker than a real hash function. Because it is just a sum, "CAT" and "ACT" would produce the exact same fingerprint (216) even though the words are different — real hash functions like SHA-256 are designed so this almost never happens. Real cryptographic hash functions have three properties our toy version only approximates:

• Deterministic — the same input always gives the same output (our toy hash has this).
• Fixed-size output — no matter how long the input text is, the output is always the same size (SHA-256 always outputs a 256-bit number, usually written as 64 hexadecimal characters; our toy hash always outputs a number from 0–999).
• Avalanche effect — changing even one character should flip roughly half of the output's bits unpredictably. Our toy hash only changes the output by a small, somewhat predictable amount, which is why it's a teaching tool and not something you'd use to actually secure money.
• One-way — given the fingerprint, you cannot work backward to recover the original text; you can only guess texts and check if they match.

Step 2: Chaining Records Together

Now we build the actual notebook-replacement. Instead of one shared notebook, imagine each entry is written on its own separate card, which we'll call a block. Every block stores three things:

1. Data — the actual transaction, e.g. "Ravi pays Meera Rs500"
2. Previous Hash — the fingerprint of the block that came right before it
3. Hash — this block's own fingerprint, computed from its Data combined with its Previous Hash

That middle field is the trick. Because each block's fingerprint depends on the fingerprint of the block before it, every block is cryptographically glued to the one behind it. Let's build the trip's actual three-transaction record this way, using our toy hash H(text) = (sum of ASCII codes) mod 1000. The very first block in any chain has no predecessor, so by convention its "Previous Hash" is just "0".

Block 1
  Data:         "Ravi pays Meera Rs500"
  Previous Hash: 0
  Hash = H(Data + PreviousHash) = H("Ravi pays Meera Rs5000") = 827

Block 2
  Data:         "Meera pays Arjun Rs200"
  Previous Hash: 827   (copied from Block 1's Hash)
  Hash = H(Data + PreviousHash) = H("Meera pays Arjun Rs200827") = 47

Block 3
  Data:         "Arjun pays Ravi Rs100"
  Previous Hash: 47    (copied from Block 2's Hash)
  Hash = H(Data + PreviousHash) = H("Arjun pays Ravi Rs10047") = 904

Notice the pattern: Block 2 doesn't just store its own data — it stores 827, which is a fingerprint of everything that came before it. And Block 3's fingerprint of 904 is really a fingerprint of Block 3's data plus a trail back through Block 2 and Block 1. This is why people call it a "chain" — each link depends on every link before it.

Step 3: Why Tampering Gets Caught

Now let's actually try to cheat, the way someone might have edited "300" into "500" in the paper notebook, and see what happens to the chain. Suppose an attacker edits Block 2's data from "Meera pays Arjun Rs200" to "Meera pays Arjun Rs900" — trying to make it look like Meera owed Arjun much more. Anyone checking the ledger simply recomputes Block 2's hash from its (now-edited) data and its previous hash of 827:

H("Meera pays Arjun Rs900" + "827") = 54

But Block 3 was created earlier and still physically stores "Previous Hash: 47" — that number was written down before the tampering happened, and it never changed. Now there's a mismatch: Block 2 currently hashes to 54, but Block 3 says the block before it should hash to 47. Anyone in the class — or in a real network, any computer — can instantly see 54 ≠ 47 and know the chain has been tampered with, without needing to know what the original, honest value was.

Could the attacker cover their tracks by also editing Block 3's stored "Previous Hash" from 47 to 54, to make it match? They could try — but that edit changes one of the two inputs that produce Block 3's own hash. Recomputing it:

Originally: H("Arjun pays Ravi Rs100" + "47")  = 904
After fix:  H("Arjun pays Ravi Rs100" + "54")  = 902

Block 3's hash has now silently changed from 904 to 902. If there were a Block 4 after it (there isn't, in our 3-block trip ledger, but imagine there was), that block would still be holding "Previous Hash: 904" — and the mismatch reappears one block further down the chain. To hide one edit, the attacker must recompute every single block after it, all the way to the newest one. This is called being tamper-evident: blockchain doesn't make editing physically impossible, it makes editing loudly detectable, and the amount of recomputation needed grows with how far back you try to cheat.

Step 4: One Notebook Isn't Enough — Distribute the Copies

There's still a gap: what if the attacker controls the only copy of the chain and just redoes all the hashes correctly, start to finish? A perfectly self-consistent, entirely fake chain would look completely valid by our tamper-check alone. This is why real blockchains use a second idea: instead of one notebook, give every participant an identical copy. In Bitcoin, tens of thousands of computers around the world (called nodes) each hold their own full copy of the entire chain. If Ravi, Meera, and Arjun each kept their own copy of the trip ledger on their phones, an attacker would need to secretly edit and re-hash all three copies identically and simultaneously — and as soon as anyone compares their copy against a friend's, a mismatch in even one hash value exposes the fraud. This is the origin of the term distributed ledger: "distributed" refers to having many independent copies, not to any single copy being unbreakable.

Step 5: How Do Strangers Agree on What Gets Added Next?

One more question remains. If thousands of independent computers each keep their own copy, who is allowed to add the next block, and how do they all agree on it without trusting each other? Bitcoin's answer is called proof of work (informally, "mining"): before a computer is allowed to add a new block, it must solve a puzzle that is deliberately slow to solve by trial-and-error, but instant for everyone else to check once solved. The puzzle is: find an extra number (called a nonce) to tack onto the block's data such that the resulting hash satisfies some hard-to-hit condition — for example, "the hash must end in a 0."

Let's mine a tiny toy block ourselves. Take the data "BLOCK" (sum of ASCII codes: B=66, L=76, O=79, C=67, K=75, total 363). We need to find the smallest nonce n = 0, 1, 2, 3... such that H("BLOCK" + n) ends in a zero:

n=0: H = (363 + 48) mod 1000 = 411   -- ends in 1, no
n=1: H = (363 + 49) mod 1000 = 412   -- ends in 2, no
n=2: H = 413   n=3: H = 414   n=4: H = 415
n=5: H = 416   n=6: H = 417   n=7: H = 418
n=8: H = 419   -- ends in 9, no
n=9: H = (363 + 57) mod 1000 = 420   -- ends in 0. Solved!

It took 10 tries to find nonce = 9. Notice how easy it is to verify: anyone can plug in n=9, compute 420 in two seconds, and confirm it ends in a zero. But finding it required trying values one by one — there was no shortcut. That asymmetry (slow to search, fast to verify) is the whole point. Real Bitcoin mining uses a puzzle so much harder that finding a valid nonce takes specialized computers performing quintillions of attempts roughly every ten minutes, across the entire network combined — which is also why Bitcoin mining is famous for consuming huge amounts of electricity. Once one computer finds a valid nonce, it broadcasts the completed block to everyone; the other nodes verify it in an instant and add it to their own copies, and the whole network moves on to competing for the next block.

Correcting Three Common Misconceptions

Misconception 1: "Blockchain and Bitcoin are the same thing." Bitcoin is one application built on top of a blockchain. Blockchain itself is just the underlying data structure — hash-linked blocks, distributed across many copies — described in this chapter. It can be, and has been, used for things that have nothing to do with cryptocurrency: tracking the provenance of medicines through a supply chain, storing academic degree certificates so they can't be forged, or maintaining land ownership records.

Misconception 2: "Blockchain data can never be changed or hacked." As Step 3 showed, blockchain doesn't prevent editing — it makes editing detectable and, past a certain point, extremely expensive to hide. There is even a known real attack called a 51% attack: if a single attacker gains control of more than half of a network's total computing power (or, in some other blockchain designs, more than half of the participating nodes), they can out-race the honest majority and force the network to accept their version of history instead. This is expensive and has actually happened to smaller cryptocurrencies with less computing power defending them. "Tamper-evident and expensive to attack" is accurate; "unhackable" is not.

Misconception 3 (specific to India): "UPI runs on blockchain." Because UPI (Unified Payments Interface) is fast, digital, and often mentioned alongside "fintech innovation," students sometimes assume it must be blockchain-based. It is not. UPI is a centralized real-time payment system built and operated by the National Payments Corporation of India (NPCI), which routes transactions through a central switch connecting banks — the opposite architecture from a distributed ledger with no central authority. UPI is an excellent example of centralized fintech done well; it simply isn't blockchain.

Where Blockchain Actually Shows Up in India

Genuine (non-cryptocurrency) blockchain use in India tends to appear where tamper-evidence of records matters more than speed. A few Indian state governments — Telangana and Andhra Pradesh among them — piloted blockchain-based land record systems in the late 2010s, aiming to make it harder to silently alter who owns a piece of land, a problem that has historically fueled land disputes and litigation in India. Some Indian banks and trade-finance consortia have also piloted blockchain for verifying trade documents like letters of credit, where multiple banks need to trust a shared record without any one bank controlling it. These remain pilots and specific-purpose systems rather than everyday consumer technology — unlike UPI, you are not knowingly using a blockchain when you pay for chai with your phone.

Check Your Understanding

1. Using H(text) = (sum of ASCII codes) mod 1000, compute H("DOG"). (ASCII: D=68, O=79, G=71.) Then compute H("DOT") and explain in one sentence why the two answers differ.
2. In the Step 2 example, Block 2 stores "Previous Hash: 827." Explain in your own words what would happen — and how it would be caught — if someone tried to insert a brand-new fake Block 1.5 between Block 1 and Block 2, without recalculating anything in Block 2 or Block 3.
3. A friend says, "Our school could put every student's marksheet on a blockchain so no teacher could secretly change a grade after it's recorded." Using what you learned about distributed copies, explain what would actually be needed for this to work — a single central computer, or something else?
4. Using the mining example in Step 5, if the puzzle were changed so the hash must end in "20" instead of just ending in "0," would you expect mining to take roughly the same number of tries, more tries, or fewer tries? Explain why, based on how many possible last-two-digit endings there are (00 to 99) versus last-one-digit endings (0 to 9).
5. Explain the difference between "tamper-proof" and "tamper-evident" in your own words, using the trip ledger example.

Summary

A blockchain solves the problem of a shared record that no single party should be able to secretly rewrite. It does this with two combined ideas. First, a hash function converts any data into a short, deterministic fingerprint where even the smallest change in the input produces a different output — we built and traced a simplified toy version, H(text) = (sum of ASCII codes) mod 1000, by hand. Second, blocks are chained by making each block's hash depend on both its own data and the previous block's hash, so that editing an old block changes its hash and breaks the link the next block is holding — an effect that cascades forward through every later block. Because many independent copies of the chain are held across a distributed network of nodes, and because adding a new block requires solving a deliberately slow-to-find, fast-to-verify puzzle (proof of work), no single party can quietly rewrite history without being caught by the rest of the network. Blockchain is tamper-evident, not tamper-proof — and it is a general-purpose data structure, not a synonym for Bitcoin or for every piece of Indian digital-payment technology such as UPI.

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 blockchain 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 blockchain to at least 3 other topics you have studied.