A fingerprint that changes if anything does
The building block is a hash: a function that takes any input and returns a fixed-length
string. Two properties make it useful. The same input always produces the same output, and
changing the input in any way, by one character or one digit, produces a completely different output, with no resemblance to the first.
So a hash works as a fingerprint for a body of data. Publish the hash, and anyone can check
later whether the data still matches it. If a single value has been altered, the recomputed
hash will not match, and the alteration is detectable without needing to know what the original
said.
Chaining the fingerprints together
Now put transactions into a block, and include in that block the hash of the previous one.
The second block’s own hash therefore depends on the first block’s contents. The third depends
on the second, and so on. The list is chained, and each link commits to everything behind it.
That is what makes an old entry hard to change. Editing a transaction from a thousand blocks
ago changes that block’s hash, so the next block no longer points at anything real, so it must
be redone, and so must every block after it. The cost of the edit is the cost of rebuilding the entire chain since, while everyone else keeps extending the real one.
-
Transactions are broadcast
A signed transaction is announced to the network and sits in a pool of pending work,
waiting to be included by whoever writes the next block. -
A writer is selected
Some mechanism decides who gets to append. Doing computational work, or committing stake,
are the two common answers, and both exist to make the right to write costly enough that
spamming it is unprofitable. -
The block is built and hashed
The chosen writer bundles pending transactions, includes the previous block’s hash, and
publishes the result to everyone. -
Everyone else checks it
Other participants validate the block independently against the rules. A block that breaks
them is discarded, which is the part that stops a writer simply inventing balances.
Agreement without an authority
Chaining alone does not settle disagreements. If two valid blocks appear at once, the network
briefly holds two versions, and something has to decide which continues. The usual rule is
mechanical: keep extending whichever branch has the most accumulated work or stake behind it,
and abandon the other.
This is why confirmations matter. A transaction one block deep might be on the branch that
loses. Several blocks deep, the branch has enough behind it that displacing it would require
outpacing the rest of the network, and the probability of that falls quickly with each block.
Where the guarantee stops
A blockchain guarantees that a record was not altered after it was written. It says nothing
about whether the record was true when it was written. A false statement committed to the
chain is now a permanent false statement, and no amount of cryptography fixes that. This is
the limit that most blockchain-for-everything proposals run into.
Public and private chains are barely the same thing
The word covers two designs that share a data structure and almost nothing else. A public chain
lets anyone read it, write to it and check it, and its security comes from the cost of
overpowering a large open set of participants.
A private or permissioned chain restricts who may write and often who may read. That removes
the need for expensive consensus and makes it far faster, and it also removes the property that
made the public version interesting. If a defined group controls who writes, that group can
agree to rewrite, and the record is trustworthy exactly to the degree the group is.
This is worth keeping straight because most corporate announcements describe the second while
borrowing the language developed for the first. A permissioned ledger is a reasonable piece of
shared infrastructure between parties who already have contracts with each other. It is not
tamper-proof in the sense the word carries elsewhere on this page.
When it is the wrong tool
Almost always, if the parties involved already trust a common record-keeper. A blockchain
trades throughput, cost and flexibility for the ability to do without one. Where that ability
is not needed, the trade is pure loss, and the resulting system is a slow database with
unusual failure modes and extra vocabulary.
The honest test is whether you can name the parties who disagree and the reason no single one
of them can be trusted to keep the ledger. If that question has a real answer, the structure
earns its cost. If it does not, a conventional database will be faster, cheaper and easier to
correct when something goes wrong.





Be the first to comment