Blockchain Basics: What the Machinery Actually Does

That is the whole design, and it is genuinely elegant. This is the most purely technical article in the pillar and the least contested — the mechanics below are not a matter of opinion. The article is also careful about one thing throughout: explaining what the machinery does is not the same as explaining what it is worth, and this article does only the first.

Four components

The hash. A hashing function takes any input — a word, a file, a list of transactions — and produces a fixed-length string of characters. Three properties make it useful. The same input always gives the same output; a trivially different input gives a completely different output, with no resemblance to the first; and the process cannot practically be run backwards to recover the input from the output. So a hash is a fingerprint: compact, unique in practice, and impossible to forge by working backwards. If you have the hash of a document, you can verify later whether a document is that same document, without storing it. The chain. Transactions are gathered into a block. Each block includes the hash of the previous block among its contents. That single design decision does the heavy lifting: because a block's hash depends on all its contents, and its contents include the previous block's hash, altering any earlier transaction changes that block's hash, which invalidates the next block, and the next, all the way to the present. Tampering is not prevented — it is made detectable and expensive, which is a different and more achievable goal. The network. Rather than one authoritative copy, many participants hold the ledger and broadcast transactions to each other. There is no server to compromise and no office to compel, and equally no administrator to correct an error. And the consensus rule, which is the part people find least intuitive and which matters most. When two participants propose different next blocks, something must decide which is accepted, and the answer cannot be "a trusted authority" without abandoning the design. The mining and proof-of-stake article covers the two dominant approaches; the point here is structural. Under proof of work, adding a block requires solving a computational puzzle that is expensive to attempt and trivial to verify — so producing a competing history means redoing that expense faster than the rest of the network produces the real one. Under proof of stake, the right to propose blocks is allocated among participants who have committed assets that can be forfeited for misbehaviour, so dishonesty carries a financial penalty rather than an energy cost. Both are answers to the same question: how do you make lying more expensive than telling the truth, without anyone being in charge? That framing is the most useful sentence in this article.

What it guarantees, and five things it does not

What a blockchain does guarantee is narrow and real: that the recorded sequence of transactions has not been altered without detection, that each transaction was authorised by whoever held the relevant private key, and that all participants running the same rules will agree on the same history. Those are meaningful properties. Now the five things it does not do, because this is where readers are misled. It does not make data true. A blockchain records what it was told, reliably. If someone records that they own a building they do not own, the ledger faithfully preserves a false claim — garbage in, garbage permanently. The integrity is of the record, not of reality. It does not give a token value. The ledger tracks ownership of units; whether those units are worth anything is the contested question the previous article set out, and no amount of cryptographic soundness bears on it. It does not make transactions reversible or recoverable. A transaction sent to the wrong address is gone; a private key lost is a permanent loss of access with no institution to appeal to; a key stolen is an authorised transfer as far as the network is concerned. This is the single most practically consequential fact in the pillar and the custody article returns to it. It does not guarantee decentralisation in practice. The design permits it; the outcome depends on how validation, development, and access are actually distributed, and concentration is common — a small number of validators or mining operations, a small development team, a handful of exchanges through which most access flows. And it is not unbreakable. If a single party controlled a majority of validation capacity, it could in principle reorder or block transactions — the 51% attack. On the largest networks this is prohibitively expensive; on small ones it has happened. And the surrounding software — exchanges, bridges, wallets, smart contracts — has been compromised repeatedly, which is worth stating precisely: the ledger's integrity has held up well, and the things built around it have not. Most reported crypto losses come from the periphery rather than from a broken chain. Two final distinctions. Public versus permissioned: the properties above describe open networks anyone can join; a permissioned ledger run by known parties is a different thing with different trust assumptions, and much corporate blockchain work is of that kind. And finality is probabilistic on some designs — a transaction becomes progressively harder to reverse as blocks accumulate rather than being irrevocable the instant it appears, which is why receiving parties wait for confirmations.