Lesson 3 — The Background You Need
How Does Blockchain Actually Work?
Learning Material
1 pagesLesson 3 — The Background You Need
Understanding the Complex: How Does Blockchain Actually Work?
Before we can understand how a blockchain works, we need to understand what it's solving — and why the obvious solution doesn't work.
Start with databases. A database is a structured collection of records that can be read and written. Your bank runs a database: a table with account numbers, names, and balances. When you transfer money, two rows update — yours decreases, the recipient's increases. Simple, fast, reliable.
The key word is: centralized. There is one database, controlled by one institution, on servers owned by that institution. The institution is the authority. If the institution says your balance is €500, your balance is €500.
This is overwhelmingly how information is stored and managed. It works because we trust the central party — the bank, the government, the platform — to keep records accurately and honestly. We verify this through auditing, regulation, and reputation. When it fails, we have courts and regulators.
But what happens when you can't rely on a central party? What if the parties involved in a transaction don't share a legal system? What if the intermediary itself is the problem?
The Byzantine Generals Problem
In 1982, computer scientists Leslie Lamport, Robert Shostak, and Marshall Pease published a paper describing what they called the Byzantine Generals Problem. It's become one of the most cited problems in distributed computing — and understanding it makes Nakamoto's solution immediately comprehensible.
Imagine a group of Byzantine army generals, each commanding a separate division, surrounding an enemy city. They need to coordinate — either all attack together, or all retreat together. A divided action will fail. They can only communicate by messenger.
The problem: some generals might be traitors. A traitor might send different messages to different generals — telling one to attack while telling another to retreat. The messengers themselves might be intercepted or corrupted. How do loyal generals reach a reliable consensus when they can't trust all participants?
This turns out to be a precise formalization of a problem that appears everywhere in distributed computing: how do independent nodes in a network reach agreement when some nodes might be faulty, slow, or actively malicious?
For decades, the answer was: it's very hard. You can tolerate some fraction of faulty nodes, but coordination requires either trusting a central coordinator or using expensive communication protocols that don't scale well.
Nakamoto's 2008 paper proposed a new answer to this question — one that uses cryptography and economic incentives rather than identity and trust.
Cryptography as Foundation
To understand blockchains, you need a working intuition about two cryptographic tools. You don't need the mathematics — just the concepts.
The first is a hash function. A hash function takes any input — a word, a document, an entire library — and produces a fixed-length output called a hash or digest. SHA-256, the function used in Bitcoin, always produces a 256-bit output regardless of input size. The same input always produces the same output. But change a single character in the input, and the output changes completely and unpredictably — this is the avalanche effect.
Crucially, the process is one-way: given the output, you cannot reconstruct the input. And it's collision-resistant: finding two different inputs that produce the same output is, for practical purposes, computationally impossible. A hash is, in essence, a fingerprint of data — a compact, unique identifier that reveals nothing about the data itself.
The second is asymmetric cryptography. In this scheme, you generate a pair of mathematically related keys: a private key (which you keep secret) and a public key (which you share freely). Anything encrypted with the private key can be decrypted only with the public key — and vice versa. This enables digital signatures: you "sign" a message with your private key, and anyone with your public key can verify that the signature is genuine without ever seeing your private key.
What this means in practice: I can prove I authorized a transaction — that I am the person who controls a particular account — without sharing a password, without identifying myself by name, and without involving any intermediary.
Put these two ideas together — hash functions and digital signatures — and you have the cryptographic foundation of a blockchain. Records can be linked in a chain where each one contains the hash of the previous one: tamper with any record, and every subsequent hash becomes invalid. Transactions can be authorized with cryptographic signatures: forge a signature, and verification fails.
What's still missing is the coordination problem. If everyone has their own copy of the ledger, and no central authority decides who's right, how do thousands of independent computers agree on which version is the truth?
That's what consensus mechanisms solve — and that's the heart of lesson five.
First, though, lesson four will take the cryptographic tools apart in detail, following Alice's 0.1 Bitcoin transaction from her wallet to Bob's, step by step, to see exactly where the math happens and why it works.
Next lesson: The cryptographic foundation — hash functions in action, digital signatures explained, and a step-by-step walk through how Alice's Bitcoin transaction is secured.
Reading time: approx. 8–9 minutes