BC4: How a shared ledger agrees: blocks, consensus and finality
Many copies, one record
🎯You'll be able to
Explain why a shared ledger needs a way to agree, and what the double-spend problem is.
🏠The everyday picture
Five members each keep a copy of the group's register. If two members write different entries at the same time, they need a rule to decide which goes first, or the copies drift apart.
📘What it really is
- Nodes: computers that each keep a full copy of the ledger, check new transactions against the rules, and pass them on.
-
Double spend: with digital money, the same coin could be sent to two people at once. Without one agreed order, both might accept it.
-
Consensus: the rules nodes follow to agree which block comes next, so every honest node ends up with the same history.
-
Open or closed: in a public (permissionless) ledger, anyone can run a node and help produce blocks; in a permissioned ledger, only approved members can.
-
Why it's hard: messages are delayed, nodes crash, and some may lie. A good protocol keeps working as long as enough nodes are honest.
📝A worked example
Input: a member tries to spend the same 0.5 test ether twice, to two shops, at the same moment.
Steps:
- Both transactions reach different nodes first.
- The network agrees on one block that contains only one of them, the one the block producer chose.
- Every node then refuses the other, because the balance has already been spent in the agreed history.
Expected output: one payment succeeds and the other fails, on every honest node.
🌍Where it's used
- Bitcoin solved the double spend without a central party in 2009.
- Ethereum orders transactions and contract calls.
- Replicated databases use related ideas inside one company.
📝Case scenario
A federation's three offices each kept their own spreadsheet of loans and synced them weekly by email. Twice, two offices approved loans against the same savings in the same week. A shared ledger with an agreed order would have refused the second approval at the time.
🖱️Try it
Run npm run chain and look at the first lines: the network's chain ID and its accounts. Then stop it. Success: you can say which
single node is producing blocks on the practice network, and why that's different from a public network.
⚠️Common mistakes
- Thinking copies are enough. Sign: "every node has a copy, so it's safe". Fix: copies also need a rule to agree.
- Confusing the practice network with a public one. Sign: claims based on a single local node. Fix: say it's one node.
- Assuming all nodes are honest. Sign: no plan for liars. Fix: protocols that tolerate some faults.
🛠️For your project
The practice network started by npm run chain is a single node that makes a block for each transaction. Project 3's app connects to
it like it would to a public node.
✅Quick check
What is the double-spend problem?
Show the answer
The same digital money being sent to two people, unless the network agrees on one order.
What does consensus give every honest node?
Show the answer
The same agreed history of blocks.