Blockchain and Distributed Ledger: The Structure and the Network Types
A distributed ledger is one record of the same facts held by several parties at once, kept in step by an agreed procedure rather than by one party sending copies to the others. A blockchain is one way of building such a record and not another name for it. The structure fixes exactly one thing: no single holder can quietly change an entry everybody else already holds.
Every question worth asking about a shared record turns out to be a question about who holds it and who may write to it, and not a question about software. Naming the holders first settles the rest: which network type this is, what it costs to agree a single entry, what the arrangement takes out of somebody's working day, and whether it was worth building at all. With the holders named wrongly, no amount of engineering rescues the idea. Parties decide more than machinery does.
What is a distributed ledger, and how is it different from an ordinary database?
A wedding fund run by five people is the whole problem in miniature, so start there. Five cousins collect contributions for a cousin's wedding and each of them keeps a small notebook. Every notebook is honest. Each cousin writes down only what passed through their own hands, and one of them writes in pencil, so every notebook is also incomplete. Two weeks before the wedding they sit down to work out what has actually come in, and the evening goes on rather longer than any of them expected. Nobody has done anything wrong. There are simply five records of one set of facts and no agreed way of putting them together.
Now change one thing. Put a single register on the table in the middle, let all five write into it in front of each other, and let none of them take it home. The facts have not changed and the money has not changed. The agreeing now happens at the moment each entry is made rather than two weeks later, so the evening's work at the end has gone.
The single register in the middle is what a distributed ledger is, and the definition is about custody and permission rather than about technology. A distributed ledgerOne record of the same facts held by several parties at once and kept in step by an agreed procedure. is one record of the same facts held by several parties at once, kept in step by a procedure all of them accepted in advance. An ordinary database is the other arrangement: one party holds the record that counts, and everybody else gets told what is in it. If the holder edits a row at four in the afternoon, the other parties find out when they are told, or when they next ask, or never.
A distributed ledger has no centre, and the absence matters as much as anything it has. No holder sits in the middle with arrows radiating out to the rest. Sumeru Bank Limited, an invented bank, is one of five holders and has no more standing in the record than the other four. If Sumeru rewrites entry 0413 on its own machine tonight, the other four still hold the original, and the disagreement is visible the moment anyone looks. Nothing in that protection is cryptographic. The protection is four other people in the room.
How does a blockchain actually construct one of those records?
By grouping entries and then tying each group to the one before it. Entries are collected into a group, the group is closed, and a short value is computed from everything inside it. The resulting value is a fingerprintA short value computed from an entry or a group of entries, which changes if anything inside it changes.: change so much as a digit inside the group and the value that comes out is different. The next group then carries the previous group's fingerprint inside itself. Its own fingerprint therefore depends on the one before, and that one on the group before it, all the way back.
The school register does the same job without any of the vocabulary. In a register where each new sheet begins by copying a short code printed at the foot of the previous sheet, and where the code at the foot of each sheet is worked out from everything written on it, one attendance mark on the second sheet cannot be altered on its own. The code at the foot of the second sheet no longer comes out right, so the code copied onto the third sheet is wrong, and the fourth and the fifth are wrong after it. The change itself has not been prevented. Making the change quietly has been prevented.
A blockchainOne way of constructing a shared record, in which entries are grouped and each group carries a fingerprint of the group before it. makes an alteration visible rather than impossible, and the whole of its reputation rests on that one distinction. The chaining does not put a lock on the past. The chaining removes the possibility of editing the past without anyone noticing. For a record held by several parties, that is the property that actually matters.
Why are the two words not interchangeable?
Blockchain vs Distributed Ledger Technology, and what gets lost when the two words are swapped
A distributed ledger is the arrangement: several parties, one record, an agreed procedure for adding to it. A blockchain is one construction of that record, the one that groups entries and chains the groups together with fingerprints. Every blockchain is therefore a way of keeping a shared record. Not every shared record is a blockchain. A set of parties can agree to keep one record in step by other means entirely, and several do.
The relation is that of a building to a construction method. A load bearing wall is one way of holding a roof up. A frame is another. Somebody who uses the words wall and building as synonyms will end up unable to ask whether the roof needs holding up at all. Whether the roof needs holding up is the only question that decides anything.
The arrangement is what gets lost when the two words are used as one, and the arrangement is the part that decides whether any of this is worth doing. A room asked whether it needs a blockchain produces a debate about software. The same room asked who holds the record today, who is allowed to write to it, and how much time those parties currently spend agreeing their versions with each other settles within ten minutes into either a real case or none at all. Almost every proposal that fails, fails on the second set of questions and never reaches the first.
Is every distributed ledger a blockchain?
Who may read and who may write, and how many kinds of network does that give?
Blockchain Network Types, the four of them, numbered
Two questions settle it. Who may read the record, and who may write to it. Each question has two answers, anyone or only named parties, so there are four combinations, and every other difference that gets talked about follows from where a given arrangement sits in that grid. The four are numbered so that a later question can point at one without ambiguity, and the numbering is a teaching device rather than anybody's official list.
Type 3 is the one with a name of its own in ordinary use. A permissionedA record where the parties who may read and write are named in advance under an agreement. arrangement is one where the parties who may read and write are named in advance, and the naming is done in a contract rather than in software. The most important part of a type 3 arrangement is therefore a document that a lawyer drafted, not a component that an engineer built.
Which network type describes a record shared between five named institutions under an agreement, and why would a regulated lender pick that one?
Which of the four does a regulated institution actually use?
Type 3, and the reason has almost nothing to do with speed or cost. On any given day a regulated lender has to be able to answer four questions. Who holds a record containing its customers' details? In what country does that holder sit? If that holder walks away, what happens to the record? And who is accountable when something in it turns out to be wrong? On a type 1 or type 2 arrangement the set of holders is whoever turned up, and the four questions have no answers at all. None of that is a criticism of the open types. A named accountable party is a requirement of the institution, not a feature of the record.
The proposal a bank actually receives most often is type 4, a shared record it will hold entirely by itself, and type 4 is an ordinary database carrying the cost of a structure whose whole point is other holders. There is nobody to disagree with an entry, nobody holding a copy that still matches when a row is edited, and nothing to keep in step. Every property that made the arrangement worth discussing came from the other four parties in the picture, and the proposal has removed all four of them.
A firm proposes a shared record that it alone will hold and write to. What has it proposed?
What is a smart contract, and is it either of those two words?
Smart Contract, and why it is neither smart nor a contract
A smart contractA written rule stored on the shared record that carries itself out when a stated condition is met. is a written rule stored on the shared record that carries itself out when a stated condition is met. The definition is that short. Somebody wrote the wording. The wording sits where every holder can see it. When the condition it names becomes true, the rule runs, and it runs because running is what it does rather than because anyone decided in the moment that it should.
Most people already live with one. A standing instruction at a bank that moves Rs 5,000/- to a landlord on the fifth of every month is exactly this shape: a written rule, held somewhere neutral, that executes on a condition. The instruction will pay the landlord on the fifth of the month after the tenant moved out, and it will pay them while the tenant is asleep, and it will pay them while the tenant is arguing with them. Nobody would call that instruction clever, and nobody would take it to a court as the tenancy agreement. The instruction is automation with the word contract stuck to it.
The property that makes a stored rule attractive and the property that makes it unforgiving are one property. The wording therefore has to be settled before it is stored rather than after. People choose this arrangement because the rule cannot be quietly rewritten by whichever party it happens to favour. The same sentence says the rule cannot be quietly stopped by whichever party it happens to hurt. One half cannot be kept without the other.
A smart contract runs and moves an amount its author no longer wants moved. What happens?
What does the structure actually fix?
One thing, and it fits in a sentence. No single holder can quietly change an entry that everybody else already holds. The word doing the work is quietly. Read the sentence twice. A holder can absolutely change its own version. The other holders still hold what was there before, and the chaining makes the alteration announce itself, so no holder can change its own version and have the change pass unnoticed.
Everything a shared record is famous for reduces to that one sentence, and a proposal that promises anything beyond it is promising something the structure does not supply. It does not make the entries true. The structure does not make the parties honest. Nothing in it verifies that the person who sent an instruction was entitled to send it. The structure removes one specific possibility from the world, the possibility of a silent rewrite by one party, and that possibility is worth removing precisely when several parties would otherwise have to trust one of their number to hold the only copy.
State in one sentence what a shared record actually fixes.
What does the structure leave exactly as it was?
Whether the entry was right when it was written. A shared entry proves that all the holders hold the same words. The entry does not prove that the words were true, that the person who sent them meant to send them, or that they were entitled to send them at all. The record starts working after the instruction arrives rather than before, and those three separate questions get no answer from it.
A shared record meets the consent question here, and comes off worse than people expect. A record is provable when it holds who did what, when, on what wording and under what authority. A shared record supplies the when and the what with great confidence, and it is silent about the who and the under what authority unless somebody wrote those into the entry as well. The structure guards the record against later editing and offers nothing at all about what went into it, so a wrong entry becomes a permanent wrong entry rather than a temporary one. That is not a defect. The behaviour is what the structure was built for, applied to a case it was never built to help.
An entry on a shared record is wrong. What can the structure do about it?
What happens when something is sent wrongly on a record nobody can alter?
The remedy is a second entry that cancels the first, and both of them stay in the record forever. Anyone who has kept a cash book in ink knows the move already. The wrong figure is not scratched out. A scratched out figure is exactly what a scratched out figure looks like to whoever reads the book next. A reversing line goes underneath, and the book now carries the mistake and the correction as two permanent facts. An offsetA second entry that cancels the effect of a first one, because the first cannot be removed. is that reversing line, and on a shared record it is the only remedy available.
Sumeru Bank Limited found out what that costs in ordinary counting. Its pilot carried 1,200 instructions on a permissioned distributed ledger shared with 4 other institutions. Three of the 1,200 were sent wrongly, or 0.25 per cent. Not one of the three could be removed. Each needed a second instruction sending the amount back, so the record ended the pilot holding 1,203 entries describing 1,197 intended transfers. The instruction count and the entry count separated the moment something went wrong and they never came back together.
Six entries now describe three mistakes, and they will still be there in ten years. At 0.25 per cent that is not a scandal. At a rate a person would call ordinary it becomes one. On a record like this a correction never replaces anything. The correction accumulates beside the mistake, and anyone reading the record later has to work out which pairs cancel and which do not.
Where does a shared record save real work, and where does it save none at all?
Here is the test, and it costs nothing to apply. Count the parties who each keep their own record of the same events. Then count the pairs among them. A pair is where the work is: two parties, two records, one conversation to agree them. Each such conversation is a reconciliationChecking two records of the same events against each other, which needs two parties to be worth doing., and the pairs are the only thing a shared record actually removes. The pairs among a set of parties come to the number of parties times one less than that, all halved. Five parties make ten pairs. Eight make twenty eight. One party makes none. There is nobody on the other side of the table.
So the decision has two questions in it and neither one is about technology. Are there several parties who each keep their own record of the same events? And do those parties currently spend real time agreeing those records with each other? If either answer is no, a shared record has no work to do in that situation, whatever else is true about it.
Five institutions each keep their own record of the same transfers. How many pairs have to agree their records with each other?
Add a party, and watch the lines that have to be agreed appear between them
One control: the number of parties who each keep their own record of the same events, from 1 to 12. One consequence: the pairs among them who have to agree their two records, drawn as an actual line between every two parties, against the single record a shared arrangement puts in their place. The default of 5 parties is Sumeru Bank Limited plus the 4 other institutions in its pilot, and it reads 10 pairs against 1 shared record. Move the control down to 1 party and the picture empties: 0 pairs, and nothing at all for a shared record to remove. The bank's own daily 430 item reconciliation sits in exactly that position.
Parties who each keep their own record: 5
Educational illustration. Every party is assumed to keep its own record of the same events, every pair is assumed to agree its two records with the other, and the shared arrangement is assumed to replace all of that with one record. The party count is generic; the default of 5 is the invented bank's own pilot, being Sumeru Bank Limited plus 4 other institutions. Sumeru Bank Limited built its intake chain for Rs 2,40,00,000/- once and runs it for Rs 65,00,000/- a year, and neither figure covers the pilot, so the control carries no money figure.
A daily reconciliation runs between a bank and its own core ledger. Would a shared record help?
What did the pilot at Sumeru Bank Limited actually carry?
The pilot ran on a tokenised deposit, meaning a claim on the bank recorded as a token on the shared record, over a permissioned arrangement shared with 4 other institutions. The deposit sat on network type 3 in the numbering above. SettlementThe moment a transfer becomes final between the parties to it. between the five fell from 1 working day to under a minute. The fall is a real result and the reason the pilot is worth reading at all.
| What was measured | The reading |
|---|---|
| Holders of the record | 5 |
| Network type | 3 |
| Length of the pilot | 3 months |
| Instructions carried | 1,200 |
| Settlement between the five, before | 1 working day |
| Settlement between the five, after | under a minute |
| Instructions sent wrongly | 3, being 0.25 per cent |
| Instructions that could be removed | 0 |
| Offsetting instructions needed | 3 |
| Intended transfers | 1,197 |
| Entries the record now holds | 1,203 |
The two ends of the table reconcile in both directions and it is worth doing the arithmetic yourself. Take the 1,200 sent, remove the 3 that were wrong, and 1,197 transfers were actually intended. Take the same 1,200 and add the 3 offsets that had to be written afterwards, and the record holds 1,203. The 6 entries between those two numbers are three mistakes and three corrections, and they are the permanent residue of the 0.25 per cent. The pilot did not go to production at Sumeru Bank Limited.
The error that gets made, and what it costs
Sumeru Bank Limited read the pilot as a settlement result, and it was one. Settlement between five institutions fell from a working day to under a minute and nobody has to apologise for that. The bank did not read the 1,203 against the 1,197. A record nobody can alter is not a record that is always right; it is a record whose mistakes stay visible for good, and the correction sits beside the mistake for the life of the arrangement rather than replacing it. Anybody reading the record in five years has to work out for themselves which entries cancel which.
The second finding was quieter and cost more. Sumeru Bank Limited runs a reconciliation of 430 items every working day, and that reconciliation is between the bank and its own core banking ledger. There is one party to it. The 430 is the daily list rather than one item for every loan decided, and it happens to sit at 430 because of how the bank's own volumes fall. A shared record has nothing to share when there is one party. Cutting settlement between five institutions to under a minute could do nothing whatever for the daily list, and the daily list is where the clerical time was actually going. The pilot worked and was not extended, and the honest reason is not that the structure failed. The reason is that a shared record solves a coordination problem this bank did not have.
How a lender, an analyst or a household actually uses this
An operations head at a lender reads any proposal of this shape with four questions and about ten minutes. Who holds the record today, by name? Who else would hold it, by name, and have any of them agreed in writing? How much time do those parties currently spend agreeing their versions with each other, measured rather than estimated? And what happens when an entry turns out to be wrong. On this structure that means naming who writes the offset and who explains the pair of entries to a customer.
An analyst reading a firm's announcement about a shared record does the same arithmetic from outside. Count the named parties in the announcement. If the number is one, the announcement describes a database and the interesting question is why the firm chose to describe it this way. If the number is five, ask what those five were doing before. The saving is the pairs and nothing else. The value of the arrangement is the reconciliation work it removes, so it can be estimated from the party count before anyone has chosen a single piece of software.
And a household meets the same test at a much smaller scale. Four flatmates who each keep their own note of who paid the electricity bill have six pairs to sort out at the end of the month, and one shared sheet on the wall removes all six. One person living alone, keeping one note, has nothing to remove, and the shared sheet would be an extra thing to maintain. Sumeru Bank Limited spent Rs 2,40,00,000/- building its intake chain and Rs 65,00,000/- a year running it, and neither figure covers the pilot. The flatmate example shows for nothing the test those figures should have been put against first.
The bodies that set the expectations, and where each one states them
Where a regulated lender in India shares customer records with named institutions under an agreement, the expectations on outsourcing, on where data sits and on what a customer consented to are set by the Reserve Bank of India at rbi.org.in. Where the institution is a market intermediary rather than a lender, the equivalent expectations sit with the Securities and Exchange Board of India at sebi.gov.in. The international work on shared records between institutions originates with the Bank for International Settlements at bis.org, and what India actually does is stated by the two Indian bodies named above rather than by that work.
Covered separately. The categories of digital asset a lender may meet, who controls one, and what happens when a private key is lost are covered separately. Publicly issued digital tokens traded on open markets are covered separately as well, and any Indian position on them is stated by the Reserve Bank of India and the Securities and Exchange Board of India. How a daily reconciliation is run is established elsewhere.
Sources
| Source | Document | Site |
|---|---|---|
| Reserve Bank of India | Expectations on a regulated lender covering outsourcing, data and what a customer consented to, and the Indian position on publicly issued digital tokens | rbi.org.in |
| Securities and Exchange Board of India | Equivalent expectations where the institution is a market intermediary, and the Indian position on publicly issued digital tokens traded on open markets | sebi.gov.in |
| Bank for International Settlements | Material on shared records held between institutions, cited as the origin of the international work rather than as the Indian position | bis.org |
Sumeru Bank Limited, its intake chain and its pilot are invented.
Educational material. Not advice on any investment, tax, budget or market position.
