Blockchain foundations —
and where it came from
By the end of this module you can explain a blockchain to a regulator without hand-waving: what a hash is, why blocks chain, how strangers agree, and why "immutable" comes with asterisks. We start with the 44-year story that got us here.
L1A brief history: six eras
Blockchain was not invented in 2008. Bitcoin assembled four older ideas — digital cash, hash-chained timestamps, proof-of-work, and peer-to-peer networks — into one system that finally worked without a central operator.
The 2016–19 enterprise wave failed mostly on business models, not technology (Module 08/09 does the autopsies). The 2024–26 wave is different in kind: regulation exists (MiCA, GENIUS Act), the instruments are institutional (tokenized deposits, digital bonds), and the players are JPMorgan and Aon rather than startups. That's why this course exists now.
L2The problem: shared truth without a referee
Every financial system is a ledger — a list of who owns what, and what happened when. The traditional fix for disagreement is a trusted central party: a bank clears payments; an insurer's core system is the single source of truth for policies. That works, at three costs:
- Reconciliation. Every organisation keeps its own ledger, so counterparties endlessly re-compare records (insurer ↔ reinsurer ↔ broker bordereaux is a classic).
- Trust concentration. The operator can err, fail, be hacked, or cheat — and everyone inherits that risk.
- Auditability. Proving after the fact that history wasn't quietly edited is hard when one party controls the database.
A blockchain is a replicated, append-only ledger where the participants themselves — not a referee — agree on each new entry, and where rewriting old entries is made computationally or politically expensive. Everything else in this module is the machinery that makes those two properties real.
L3Hashing — the fingerprint function
A cryptographic hash function (this course uses SHA-256) turns any input into a fixed 64-hex-character fingerprint with four properties:
| Property | Meaning | Why insurance cares |
|---|---|---|
| Deterministic | Same input → same hash, always | Anyone can re-verify a record's fingerprint years later |
| Avalanche | Change one character → a completely different hash | Silent edits to a claim record are unhideable |
| One-way | Cannot recover the input from the hash | You can publish a fingerprint of PII without publishing the PII |
| Collision-resistant | Infeasible to find two inputs with the same hash | A fingerprint uniquely commits to one document |
Hash-as-commitment is the cheapest blockchain idea to adopt: hash a policy document or an AI decision log, anchor the hash, keep the data in your normal database. Galileo's audit ledger and Module 11's auditable-AI pattern are both elaborations of this one trick.
L4Blocks, chains, and Merkle trees
A block is a batch of transactions plus a header. The header contains the hash of the previous block — which is what turns independent batches into a chain: edit any historical block and every later block's hash breaks.
prev (chains history) and the merkle root (summarises contents).A Merkle tree pair-wise hashes transactions upward to a single root. Its gift is the Merkle proof: you can prove "claim C-77 is in block 42" with just ~log₂(n) hashes — the basis of light clients, and of audit-friendly designs where a regulator verifies inclusion without receiving your whole book.
L5Interactive: break a chain with your own hands
This is a live 4-block chain computing real SHA-256 in your browser. The rule: a block is valid when its hash starts with 00.
1. The avalanche effect — one character changed everything. 2. Chaining — corruption propagates forward, so old history is the hardest to fake. 3. Mining is just a brute-force search for a lucky nonce; "difficulty" = how many leading zeros you demand. On Bitcoin the target is astronomically harder and re-mining the whole chain would out-cost nation states — that's the security budget.
L6Keys, signatures, wallets
Ownership on a blockchain is cryptographic, not administrative:
- A private key is a random 256-bit number. Its owner can produce a digital signature over any message.
- The matching public key (and its short form, an address) lets anyone verify the signature — proving the holder authorised that exact transaction, without revealing the key.
- A wallet is just software that stores keys and signs; a seed phrase is a human-readable backup of the keys. Lose it: funds gone. Leak it: funds gone. There is no "forgot password."
For an insurer, "who holds the keys" becomes an operational-risk question: HSMs, key ceremonies, m-of-n multi-signature approvals, and recovery procedures. Custody is a bigger project than the chain itself — one reason permissioned platforms (Module 03) put identity management first.
L7Transactions & state: UTXO vs accounts
UTXO model
The ledger is a set of unspent coins ("unspent transaction outputs"). A transaction consumes some UTXOs and creates new ones — like paying with physical notes and getting change. Simple to verify in parallel; awkward for rich shared state.
Account model
The ledger is a mapping of accounts → balances + contract storage, updated by transactions. Feels like a bank database, which is why business logic (smart contracts, Module 02) lives here. Corda, interestingly, went UTXO-like for privacy reasons.
L8Consensus — how strangers agree
Consensus answers one question: whose block is next? The answer differs by how much you trust the participants.
| Family | How it picks the writer | Trust setting | Cost profile | Examples |
|---|---|---|---|---|
| Proof of Work | Whoever wins the hash lottery (mining) | Fully open, adversarial | Energy-heavy; probabilistic finality | Bitcoin |
| Proof of Stake | Validators stake capital; misbehaviour is financially "slashed" | Open, adversarial | ~99.95% less energy than PoW; fast finality | Ethereum since 2022 |
| BFT voting (PBFT/IBFT/Raft-like) | Known validators vote; tolerate up to ⅓ faulty/malicious | Identified members (consortium) | Cheap, instant finality; needs governance | Fabric ordering, Besu IBFT, Corda notaries |
Galileo runs 3 blockchain nodes that it fully controls — so consensus there is not adversarial at all; it's closer to a replicated append-only log with BFT-style ordering. That's typical for the audit-ledger pattern: the chain's value is tamper-evidence and ordering, not decentralised trust. Ask "who are the validators, and who governs them?" of every enterprise chain you meet.
L9Public, consortium, private — and the immutability asterisk
Anyone joins
Ethereum, Bitcoin. Maximum neutrality & auditability; least privacy and control. Insurance fit: parametric retail, crypto-native cover, anchoring proofs.
Members join
Fabric, Corda, Besu networks run by an industry group. Shared workflows between competitors (claims, KYC, reinsurance). Fit: most enterprise insurance cases — if governance holds (see B3i).
One operator
Single-company chain, like Galileo's. Tamper-evident audit within one trust domain. Honest question to ask: would a signed append-only database do?
1. Immutability is economic/political, not physical: a public chain can fork (Ethereum did after the DAO hack); a 3-node private chain can be rewritten by its operator. 2. Immutability of garbage is garbage forever — data quality still matters. 3. GDPR/PDPA right-to-erasure means PII goes off-chain; the chain keeps hashes. Design for these from day one.
▶Watch
The original live demo our playground recreates. Watch after playing.
The best single explainer ever made. Watch for: how signatures + the ledger combine.
Six-minute recap to send to colleagues.
Gary Gensler's MIT lectures — the finance-first view. Optional depth.
Sources for this module: Antonopoulos & Wood, Mastering Ethereum (concepts); Peng, Blockchain for Big Data (architecture layers, consensus taxonomy); public history records. Energy figure: Ethereum Foundation post-Merge estimate.