Almost everything written about this starts with the phrase “a distributed ledger”, which teaches nothing. This chapter builds it from the bottom, and assumes you know what a database is and nothing else.
One honest note before we start, because this site is built from job-posting data.
Across the 4,556 job descriptions behind the rest of this site, the word “blockchain” appears zero times. So do Solidity and Ethereum. Six job titles contain the word and not one description elaborates.
That corpus is infrastructure, security and AI employers — it contains no banks and no crypto companies, so it is the population least likely to mention it. But it is worth saying plainly: this book is here because the subject is worth understanding, not because the evidence says it is a career bet. The banking book has the honest scorecard on where it is actually deployed.
Read the bottom panel carefully. Everything to that point is a tamper-evident log, which is a normal thing you could build in an afternoon.
The idea that makes it different
A node is just a computer running the blockchain's software and holding a full copy — the equivalent of a database replica. The difference is what it does with that copy.
This is the sentence to take away. Almost every sensible design decision in this field follows from asking whether you actually have the problem in the right-hand box.
The question to ask before anyone builds anything
“Who exactly do we not trust?”
If the answer names a real party whose cooperation you need but whose word you cannot take — strangers on the internet, a competitor, a government you do not control — then this architecture is doing something for you.
If the answer is “well, nobody really, but we want an audit trail”, you want a database with hash-chained rows, and you will get real SQL joins, thousands of writes per second, and the ability to delete something when a regulator tells you to.
The banking chapters in this site's other book are, almost entirely, the story of organisations that answered that question badly and spent years finding out.
One more piece of the structure
Each block also stores a Merkle root — a single hash summarising every transaction in that block, computed by hashing them in pairs, then hashing the pairs, up to one value. Why it matters practically: it lets you prove a particular transaction is in a block by supplying a short chain of hashes rather than the whole block. It is the reason a phone wallet can verify a payment without downloading hundreds of gigabytes.
Check yourself
What does a hash chain actually give you?Tamper evidence. Altering an old block changes its fingerprint, which breaks the next block's pointer, and the damage cascades forward through everything after it.Could you build that in Postgres?Yes, in an afternoon — a column per row holding a hash of that row plus the previous row's hash. That part is not the interesting bit.What does 'decentralised' actually mean?Not that there is no database. That there is no operator whose say-so the rest of the network is required to trust — every copy re-runs and re-checks everything itself.What does that property cost?Over 20,000 Bitcoin machines each storing and re-validating the entire history, forever. You pay in redundancy for not needing to trust anyone.When is the difference imaginary?When the participants already trust each other or have contracts — five banks, three shipping firms. They can trust an operator, so a shared database with hash-chained rows gives the same tamper-evidence far more cheaply.What is the one question to ask first?Who exactly do we not trust? If the honest answer is 'nobody, we just want an audit trail', you want a database.