Why Do We Need Blockchain?

Postgres with an append-only audit table, every row signed, replicated to a standby, backed up hourly. That handles most of what people describe when they describe wanting a blockchain. It is faster, it is cheaper, your team already knows how to run it, and you can hire people who have done it before.

So the honest question is not "what can blockchain do". It is: what does that setup fail at, and does your situation actually hit that failure?

What the audit log already gives you#

Take the signed-audit-log design seriously for a moment, because it is the real competitor.

• History — every change recorded, with who made it and when
• Tamper evidence — sign each row, chain the signatures, and edits become detectable in exactly the way a blockchain makes them detectable
• Availability — replicas and backups
• Verifiability — anyone with the public key can check the signatures

That is a lot of the pitch, already. If you find yourself listing those four as reasons to adopt a chain, the design has not been examined closely enough.

The thing the audit log cannot do#

Here is what remains: whoever runs the database can still rewrite it.

Not undetectably — the signatures make edits visible. But they control the copy everyone reads from. They can drop a row and reissue signatures over the shortened history. They can refuse to serve a record. They can go offline. If the other parties want to prove what the record said last Tuesday, they are proving it against a copy the operator controls.

That is the gap. And it only matters if you cannot appoint an operator everyone accepts.

The four conditions#

Before a chain earns what it costs, all four of these need to hold. Not most. All four.

Most proposals fail at condition two. A supply chain project with one dominant buyer and forty suppliers has an obvious authority: the buyer. They are already setting the terms. A chain does not change who has power in that relationship; it just makes the database slower.

What it costs when the conditions do hold#

Even then, go in with the price in view.

• Throughput. Every write is agreed by many machines rather than executed by one. Orders of magnitude, not percentages.
• Latency. A write is not final when it is accepted; it is final when enough of the network has agreed. On some designs that is sub-second. On others it is minutes, with a probability attached rather than a guarantee.
• Operational surface. Key management, node upgrades that must be coordinated across organisations, network partitions between parties who do not share an ops team.
• Irreversibility, which cuts both ways. The property that makes the record trustworthy also makes a mistaken write permanent. Systems handling real value need a deliberate answer for this, and "we will be careful" is not one.

The version of this you can say at work#

When someone proposes a chain, the useful response is not enthusiasm and not dismissal. It is four questions:

1. Who writes to this record, and how many of them are there?
2. If we had to appoint one party to hold it, who would object, and on what grounds?
3. What does a disagreement between parties cost us today?
4. Who needs to verify the history without asking us for a copy?

Clear answers to all four, and you have a real case. Vague answers to any, and what is actually wanted is a shared database with better access control — which is a good thing to want, and much easier to deliver.

That is not a dismissal of the technology. It is the only way to tell where it genuinely earns its place, which is what makes the cases where it does worth taking seriously.

Next#

With the why settled, the mechanism becomes much easier to follow. Episode three walks a transaction from the moment it is signed to the moment it is final.