How Blockchain Actually Works: Blocks, Hashes, and Consensus

Blockchain has been explained badly more often than almost any technology of the last two decades — usually either as a revolution requiring no detail, or as a scam requiring no detail. The underlying machinery is neither. It is a specific and rather elegant answer to a specific and genuinely hard question: how do strangers who do not trust each other agree on a shared record without anyone in charge?

This article builds that machinery from first principles. Hashes, then blocks, then chains, then signatures, then the hard part — consensus. No mathematics beyond arithmetic, no code, and no opinions about prices.

• What a hash function is and why everything depends on it
• How blocks chain together and why that makes tampering visible
• How digital signatures prove ownership without revealing secrets
• What consensus actually solves, and the main approaches
• Why the technology is slow, and what is done about it
• Where it genuinely fits and where a database is better

1. The problem being solved
2. Hash functions
3. What a block contains
4. Chaining, and why tampering shows
5. Digital signatures and ownership
6. The distributed ledger
7. Consensus: the actual hard part
8. Proof of work
9. Proof of stake
10. Forks and finality
11. Public, private and permissioned
12. Smart contracts
13. Why it is slow, and scaling
14. What it genuinely guarantees
15. Where it fits, and where a database is better
16. Twelve misconceptions
17. A worked example: following one transaction
18. Glossary
19. Frequently asked questions

1. The problem being solved

Start with what banks do. When you transfer money, a bank updates its ledger. You trust it not to invent entries, not to reverse yours, and not to spend the same balance twice. That trust is the product, and it works well enough that most people never think about it.

Now remove the bank. Several thousand strangers, none trusted, need to agree on who owns what. Anyone can lie. Anyone can pretend to be several people. Messages arrive out of order or not at all. Some participants are actively trying to cheat.

The core difficulty is double spending. Digital things copy perfectly, so nothing stops someone sending the same unit to two people simultaneously. A bank prevents this by being the single authority on order. Without one, the network must agree on order itself — and agreeing on order among untrusting parties, with no referee, is the whole problem.

Blockchain's answer: make the record append-only, make tampering detectable, and make agreement on what to append expensive enough that cheating costs more than it gains.

2. Hash functions

Everything rests on this, so it is worth getting right.

A hash function takes any input — a word, a document, a video — and produces a fixed-length output, typically written as a long string of hexadecimal characters. Four properties matter:

• Deterministic. The same input always produces the same hash.
• Fast to compute. Hashing a large file takes moments.
• One-way. Given a hash, there is no practical way to recover the input other than guessing.
• Avalanche. Change one character and the output changes completely and unpredictably — not slightly, entirely.

The avalanche property is the one to hold on to. It means a hash is a fingerprint: if two documents have the same hash, they are the same document, and if a single byte differs, the hashes look completely unrelated.

A fifth property matters for what follows: collision resistance. Finding two different inputs with the same hash should be computationally infeasible. For the functions in use, it is — the search space is so large that no amount of computing power available now makes it practical.

3. What a block contains

A block bundles transactions together with some bookkeeping. The essential parts:

The Merkle root deserves a moment because it is genuinely clever. Transactions are hashed in pairs, those hashes hashed in pairs, and so on up to a single root hash. Changing any transaction changes the root. But you can prove a specific transaction is included by supplying only a handful of hashes along its path — not the whole block. That is what lets a lightweight device verify a payment without storing hundreds of gigabytes.

4. Chaining, and why tampering shows

Each block contains the hash of its predecessor. That single fact is where the security comes from.

Suppose block 500 contains a transaction someone wants to alter. They change it. The block's contents change, so its hash changes. But block 501 contains the old hash of block 500 — so block 501 is now inconsistent. To fix it, they must alter block 501, which changes its hash, which breaks block 502. And so on to the present.

Altering one historical record therefore requires rebuilding every block after it. If producing blocks is expensive, rebuilding thousands is prohibitively so — and meanwhile the honest network keeps extending the real chain, so the attacker is racing to catch up while falling behind.

This is the whole trick, and it is worth appreciating how modest it is: no cryptographic magic, just the observation that if each entry commits to the previous one, history becomes structurally rigid.

5. Digital signatures and ownership

Chaining prevents altering history. Something else must prevent spending what you do not own.

The mechanism is public-key cryptography. Each participant has a pair of mathematically related keys. The private key is secret. The public key is shared freely and serves as an address.

The relationship: something signed with the private key can be verified with the public key, and the private key cannot be derived from the public one.

So a transaction works like this. You create it — "send this amount from my address to theirs" — and sign it with your private key. Anyone can verify, using your public key, that the signature is genuine and that the transaction has not been altered since signing. Nobody learns your private key in the process.

The consequences are absolute in a way traditional systems are not. Whoever holds the private key controls the funds. There is no recovery, no customer service, no override. Lose the key and the balance is permanently unreachable — visible on the ledger, provably yours, and unspendable. Have it stolen and the thief's transactions are as valid as yours, because validity means correctly signed and nothing more.

6. The distributed ledger

No single copy of the chain exists. Thousands of computers each hold one and communicate constantly.

The basic flow: a transaction is broadcast to the network. Nodes check it — is the signature valid, does the sender have the funds, is it well-formed — and pass valid ones onward. Each node keeps a pool of pending transactions. Periodically, some participant assembles a block from that pool and broadcasts it. Every node independently verifies the block and, if it checks out, appends it and starts working from the new tip.

Independent verification is the key property. Nobody trusts the block producer. Every node checks every rule itself: signatures, balances, block structure, and whether the difficulty requirement was met. A block breaking any rule is simply rejected, and a producer who tries gains nothing.

This is what "trustless" actually means, and the word is unhelpful. It is not that trust is absent; it is that trust in participants is replaced by verification of rules. You trust the mathematics and your own software, not the strangers.

7. Consensus: the actual hard part

Now the genuine difficulty. Any number of participants might produce a block at the same moment, with different contents. Which one is real?

An obvious answer — take a vote — fails immediately, because anyone can create unlimited identities. A vote among identities is won by whoever creates the most, which costs nothing. This is the Sybil problem, and it defeats most naive approaches.

The insight behind every workable consensus mechanism: tie influence to something scarce. Something that cannot be faked by creating more identities. The two dominant answers tie it to computation and to capital.

8. Proof of work

To produce a valid block, you must find a hash below a target value. Since hashes are unpredictable, the only method is to try: change the nonce, hash the block, check, repeat. Billions of times per second, across the network.

The asymmetry is what makes it work. Finding a valid hash takes enormous effort; verifying one takes a microsecond. Everyone can instantly confirm you did the work.

The rule for disagreement: the chain with the most accumulated work wins. If two valid blocks appear simultaneously, the network temporarily splits, and whichever branch is extended first becomes the accepted one. The other is discarded.

This makes rewriting history economically absurd. To alter a block ten deep, you must redo its work and the work of everything after, faster than the entire honest network extends the real chain. That requires controlling more than half the total computing power — the 51% attack — and on a large network the hardware and energy cost exceeds anything the attack could plausibly yield.

The cost is energy, and it is not incidental. The security is the energy expenditure; making it cheap would make the chain cheap to rewrite. That trade-off is the central and legitimate criticism of the approach, and it is what motivated the alternative.

9. Proof of stake

Instead of tying influence to computation, tie it to capital that is locked up and forfeitable.

Participants deposit — stake — a quantity of the network's own currency. The protocol selects block producers from among them, weighted by stake. Produce a valid block and you earn a reward. Behave dishonestly — sign contradictory blocks, or attempt to rewrite history — and a portion of your stake is destroyed. This is slashing, and it is what replaces the energy cost.

The economic logic parallels proof of work: attacking requires controlling a large fraction of staked capital, and using it to attack destroys the value of the very asset you had to acquire. You would be burning your own holdings to damage the thing that gives them value.

Neither is strictly superior. Proof of work's security is anchored outside the system in physical cost; proof of stake's is anchored inside it, which is more efficient and more circular. Both work in practice at scale.

10. Forks and finality

A fork is a split in the chain. Temporary ones happen routinely when two producers succeed at once and resolve within a block or two.

Deliberate forks are different. A soft fork tightens rules so that new blocks remain valid to old software — backward compatible. A hard fork changes rules so that old software rejects new blocks, requiring everyone to upgrade. When a community disagrees about a hard fork, the chain permanently splits into two networks with shared history and separate futures. This has happened, and the resulting arguments are political rather than technical.

Finality is the related practical question: when is a transaction irreversible? Under proof of work, never absolutely — only increasingly improbable to reverse as blocks accumulate. Convention treats a handful of confirmations as settled for ordinary amounts and more for large ones. Under many proof-of-stake designs, finality is explicit: after a defined period, reversal would require destroying an enormous quantity of stake, and the protocol declares the block final.

11. Public, private and permissioned

Not every chain is open, and the distinction changes the value proposition substantially.

Public. Anyone can read, transact and participate in consensus. Maximum openness, maximum censorship resistance, lowest throughput, and no way to remove data.

Private. A single organisation controls participation. Fast, controllable — and at that point one should ask what the chain adds over a well-run database with an audit log. Frequently the honest answer is: not much.

Permissioned or consortium. Several known organisations jointly operate it. This is the configuration where the technology genuinely earns its place in business settings: the participants do not fully trust each other but must share a record, and none is willing to let another host it. A shipping consortium, a group of banks, a supply chain with several independent parties.

The useful test: is there a party everyone would accept as the operator? If yes, use a database — it will be faster, cheaper and easier. If genuinely no, a shared ledger with cryptographic guarantees is solving a real problem.

12. Smart contracts

Some chains support programs stored on the ledger that execute when invoked. The term is misleading — they are neither contracts in the legal sense nor especially smart. They are deterministic programs whose execution every node reproduces and verifies.

What makes them distinctive: once deployed, a contract runs exactly as written, and nobody — including its author — can stop it or alter it. That is the appeal and equally the danger. A bug is permanent. Substantial sums have been lost to logic errors that in an ordinary system would have been a patch and an apology.

Their genuine strengths are automatic execution without an intermediary, transparent and auditable logic, and composability — contracts calling other contracts to build layered systems. Their genuine weaknesses are immutability, execution cost proportional to complexity, and complete dependence on external data being fed in honestly by an oracle, which reintroduces a trusted party at exactly the point the design was meant to eliminate one.

13. Why it is slow, and scaling

A public blockchain processes a handful to a few dozen transactions per second. A conventional payment network handles tens of thousands. The gap is not an implementation failure; it is inherent.

Every node processes every transaction. That is what independent verification means. Throughput is therefore bounded by what a single ordinary node can handle — and raising that bound means fewer people can afford to run nodes, which concentrates the network and erodes the decentralisation that justified the design.

This tension is often stated as a trilemma between decentralisation, security and scalability, with the claim that you can have two. It is a simplification, and it captures the real trade-off well enough to be useful.

The main responses:

• Layer two. Move most activity off the main chain, settling periodically. Parties transact directly and only the net result is recorded. This is where the greatest practical throughput gains have come from.
• Sharding. Split the network so each portion handles a subset, rather than everyone processing everything.
• Larger blocks. Simple, effective, and it raises the cost of running a node — the trade-off that has caused the most heated disagreements.
• Better proofs. Cryptographic techniques allowing a compact proof that a large batch of transactions was processed correctly, which one node can verify cheaply.

14. What it genuinely guarantees

Being precise here prevents most disappointment.

It does guarantee: that recorded history has not been altered; that transactions were authorised by the holder of the relevant key; that all participants see the same record; that rules are enforced identically for everyone; and that no single party can censor or reverse arbitrarily.

It does not guarantee: that recorded information is true. This is the most important limitation and the most frequently glossed over. A chain records that someone claimed a shipment contains organic coffee. It cannot verify the coffee. Garbage entered honestly is garbage recorded permanently and immutably.

It also does not guarantee that the code is correct, that keys are held securely, that participants behave well outside the protocol, or that a majority cannot collude.

The gap between "the record is tamper-evident" and "the record is true" is where most disillusioned projects have foundered. Blockchain solves the first problem completely and the second not at all.

15. Where it fits, and where a database is better

Genuine fits: value transfer between parties without a shared intermediary; multi-party records where no single operator is acceptable; provenance where each handoff is signed by the party responsible; systems whose rules must be verifiably beyond any single party's control; and settlement between institutions that reconcile constantly and expensively.

Poor fits, which is most things: anything with a natural trusted operator; anything requiring high throughput or low latency; anything requiring data deletion, since immutability and privacy regulation conflict directly; anything needing complex queries, which chains are poor at; and anything where "blockchain" was chosen before the problem was defined.

A blunt but reliable test: describe the problem without using the word. If the description still calls for several mutually distrusting parties sharing an authoritative record with no acceptable operator, the technology fits. If it describes storing data reliably, a database fits.

16. Twelve misconceptions

1. "It cannot be hacked." The chain is tamper-evident; wallets, exchanges, contracts and keys are attacked constantly.
2. "It makes data true." It makes data unaltered. Entirely different.
3. "It is anonymous." Most public chains are pseudonymous and permanently traceable — arguably less private than cash.
4. "Transactions are free." Fees pay for inclusion and rise with demand.
5. "It is instant." Confirmation takes minutes on many networks by design.
6. "Everything should be on-chain." Storage is extremely expensive; most data belongs elsewhere with only a hash recorded.
7. "Smart contracts are legally binding." They are programs. Legal status depends on jurisdiction and surrounding agreements.
8. "Private blockchains have the same properties." They lose most of what makes public ones distinctive.
9. "Proof of work is wasteful for no reason." The expenditure is the security. One may still judge the price too high.
10. "It removes intermediaries." It relocates them — exchanges, wallets, oracles and node providers are intermediaries.
11. "51% attacks are theoretical." They have happened repeatedly on smaller networks.
12. "Immutable means permanent." Only while enough independent participants keep running nodes.

17. A worked example: following one transaction

Trace a single payment from creation to settled history.

Creation. The sender's wallet builds a transaction: source, destination address, amount, and a fee offered for inclusion. Nothing has been sent anywhere; this is a document.

Signing. The wallet hashes the transaction and signs that hash with the private key. The signature is attached. The key never leaves the device. Anyone can now verify authorisation without learning anything secret.

Broadcast. The signed transaction goes to a few connected nodes. Each independently checks the signature against the sender's public key, confirms the funds exist and are unspent, and validates the structure. Valid, so each forwards it to its own peers. Within seconds it has propagated across the network, and every node holds it in a pending pool.

Selection. Block producers choose from the pending pool, preferring higher fees since block space is limited. This is why a low fee means waiting: it is an auction, not a queue.

Block production. Under proof of work, the producer assembles candidate transactions, computes the Merkle root, includes the previous block's hash, and begins varying the nonce, hashing repeatedly until the result falls below the target. Billions of attempts, no shortcut. Under proof of stake, a validator is selected by the protocol and assembles the block directly, with the stake at risk standing in for the computational cost.

Propagation and verification. The block is broadcast. Every node checks it independently — every signature, every balance, the Merkle root, the previous hash, and the difficulty requirement. This takes a fraction of a second, which is the asymmetry the whole design rests on. Any failure means rejection, and the producer's effort is wasted entirely.

One confirmation. The transaction is in the chain. It is not yet safe. If another producer found a competing block at nearly the same moment, a temporary fork exists and one branch will be discarded.

Settlement. Each subsequent block makes reversal exponentially harder, since an attacker would have to outpace the entire network from that point. After a handful of blocks, reversal is impractical for any ordinary amount. Under a proof-of-stake design with explicit finality, the protocol declares the block final after a defined period and reversal would require destroying an enormous quantity of staked capital.

Permanence. The transaction is now in a record held by thousands of independent nodes worldwide, each of which verified it. No party can alter or remove it, including the sender, the recipient and the block producer. The record will show, permanently and publicly, that this address sent that amount to that address at that time.

What it does not show. Who those parties are. What the payment was for. Whether whatever was promised in return was delivered. Every one of those questions lives outside the system, and confusing what the ledger proves with what it does not is where most of the technology's disappointments begin.

18. Glossary

19. Frequently asked questions

If everything is public, how is anything private?

It is pseudonymous rather than anonymous. Addresses are not names, but every transaction is permanently public, and analysis linking addresses to identities is a mature discipline. Once one address is linked to a person, its entire history is exposed. Chains designed for genuine privacy use additional cryptography and are the exception rather than the norm.

What happens if I lose my private key?

The funds are permanently unreachable. There is no recovery mechanism, because a recovery mechanism would be a party with override authority — precisely what the design exists to eliminate. This is why custodial services exist and why they reintroduce the trust the technology was meant to remove.

Is proof of work worth the energy?

That is a value judgement rather than a technical question, and the technical part is that the expenditure is not waste in the design's own terms — it is the security. Whether that security is worth the cost depends on what you think the network is for. Proof of stake demonstrates that comparable security is achievable at negligible energy cost, with different trade-offs around concentration.

Can a blockchain be shut down?

A large public one, not easily — there is no server to seize and nodes are spread across many jurisdictions. But access can be restricted, exchanges regulated and participation discouraged, which affects usefulness without touching the network. A small chain with few nodes is considerably more fragile than the framing usually suggests.

Should my company use blockchain?

Probably not, and the test is simple: is there any party all participants would accept as the operator of a shared database? If yes, use the database — faster, cheaper, easier to change, and able to delete data when the law requires. If genuinely no, and several mutually distrusting parties must share an authoritative record, then the technology is solving your actual problem.

How does it prove a product is authentic?

It does not. It proves that someone with a particular key asserted something at a particular time, and that the assertion has not been altered since. Whether the assertion was true depends entirely on the honesty of whoever made it and the physical controls around the goods. The ledger makes lies permanent and attributable, which has value, and it does not make them detectable.

What is the difference between a coin and a token?

A coin is native to its chain and used to pay fees and secure the network. A token is created by a contract running on a chain and depends on that contract's code for its rules. The distinction matters practically: a coin's behaviour is defined by the protocol, a token's by whatever its author wrote, which may contain anything.

Is the technology mature?

The core machinery — hashing, signatures, chaining, consensus — is well understood and has run for over a decade under continuous adversarial pressure, which is a stronger test than most systems face. The layers built on top are considerably less mature, and most of the losses have occurred there rather than in the foundations.

Key takeaways

• Hashing plus chaining makes history rigid. Altering one entry means rebuilding everything after it.
• Signatures prove authorisation without revealing secrets — and losing the key is final.
• Consensus is the hard part, solved by tying influence to something scarce and forfeitable.
• Every node verifies everything, which is the source of both the trust model and the throughput ceiling.
• It guarantees the record is unaltered, not that it is true. The most consequential distinction in the field.
• Most problems want a database. The technology fits where no acceptable operator exists.

Understood as machinery rather than as a movement, blockchain is a specific tool for a specific and narrow problem — coordinating a shared record among parties who cannot appoint a referee. It solves that problem well, at a real cost in speed and complexity, and it solves nothing else. Knowing precisely which problem that is turns out to be most of the expertise.