How Blockchains Work

The double-spending problem seemed mathematically impossible—digital money without a central authority. The solution combines three mathematical tools that have existed for decades. All three have existed for decades. The breakthrough was wiring them together into a single protocol.

How do blockchains work? They solve the double-spending problem using cryptography and distributed ledgers. Instead of trusting a bank, blockchains let anyone verify transactions while making fraud prohibitively expensive. The system works because cheating costs more than it is worth.

Hash Functions: Digital Fingerprints

Hash functions verify that a massive document has not been altered by sending only a tiny piece of information to prove it.

A hash function takes any input—whether a single word, an entire book, or a block containing thousands of transactions—and produces a fixed-size output: a unique digital fingerprint.

Consider these SHA-256 hashes:

SHA-256("Hello") = 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
SHA-256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Changing just the capitalization of one letter creates a completely different hash. This is the avalanche effect: tiny input changes produce wildly different outputs.

Hash functions are deterministic—the same input always gives the same output. "Hello" will always produce 185f8db3.... They are also irreversible: computing a hash takes milliseconds, but working backward from one would take billions of years even with every computer on Earth running simultaneously. And they exhibit the avalanche effect, where changing even one bit of input completely changes the output.

In blockchains, hashes create immutable history. Every block contains the hash of the previous block. If someone modifies a transaction from last week, they change that block's hash, which breaks the next block's reference to it. To hide the change, they would need to recalculate every subsequent block's hash faster than the network adds new ones—practically impossible.

Digital Signatures: Proving Ownership

Digital signatures use public/private key pairs to prove ownership mathematically instead of relying on banks.

Traditional authentication relies on shared secrets like passwords. That does not work for a system with no central authority and no way to share secrets privately. Digital signatures enable authentication without revealing any secret information.

Digital signatures use asymmetric cryptography—mathematical relationships that go one way: quick to compute forward, infeasible to reverse. When you create a digital signature system, you generate two mathematically related numbers: a private key and a public key. The private key must remain secret. The public key can be shared freely.

The private key creates a digital signature for a specific transaction. The signature is unique to both your private key and the exact transaction content. Anyone can use your public key to verify that the signature could only have been created by someone with the corresponding private key.

Without your private key, creating a valid signature is computationally impossible, even with access to millions of previous signatures. To prevent an attacker from replaying an old transaction, each signature must include unique data—often a simple counter called a nonce—which ensures every signature differs from every other signature.

Once you sign a transaction, you cannot claim you did not authorize it. The math proves it, and you cannot deny it later—a property called non-repudiation.

In blockchains, this is how wallets work. Your wallet stores your private keys and signs transactions—that is all it does. The coins themselves live on the blockchain as ledger entries.

Merkle Trees: Efficient Verification

How do you verify that a specific transaction exists in a block containing thousands of other transactions without downloading the entire block?

Merkle trees organize data in a binary tree where each leaf is a transaction, and each parent node contains the hash of its two children. This structure continues up the tree until you reach a single root hash that represents the entire dataset.

To prove any transaction exists in the tree, you only need the transaction and the Merkle path: the sibling hashes needed to reconstruct the root. For a tree with one million transactions, you need only about 20 hashes to prove inclusion—a few kilobytes instead of gigabytes.

The verification process works like this:

1. Start with your transaction and hash it

2. Combine your hash with its sibling hash and hash the result

3. Repeat until you reach the root

4. Compare your calculated root with the known root

If the roots match, the transaction is provably in the block. If anyone changes any transaction, the root hash changes completely, which makes tampering immediately detectable.

In blockchains, Merkle trees make verification practical. Light clients—devices without space to store the entire blockchain—can verify transactions with just a few kilobytes of proof. The security is just as strong: if the Merkle path checks out, the transaction is provably in the block.

Blocks and Chains

Transactions are grouped into blocks. Each block contains:

• A list of transactions

• A timestamp

• The hash of the previous block

• A Merkle root of all transactions

• Additional metadata

The hash of the previous block creates the chain. Block 100 contains the hash of Block 99. Block 99 contains the hash of Block 98. This linking continues all the way back to the genesis block—the first block in the chain.

This structure makes tampering obvious. Changing any transaction changes its block's hash, which breaks the next block's reference to it. To hide the tampering, an attacker would need to recalculate that block's hash, then the next block's hash, then every subsequent block, all while the network continues adding new blocks. The further back in history the tampered transaction is, the more work is required to cover it up.

Distributed Ledgers

A distributed ledger means thousands of computers each keep a complete copy of the transaction record—not one bank maintaining the official version. Every transaction gets broadcast to all participants, who validate it independently. If the transaction is valid, it gets added to their copy of the ledger.

This distribution makes fraud obvious. If someone tries to modify their local copy to give themselves more money, their copy no longer matches everyone else's copy. The network sees the discrepancy and rejects the fraudulent version. An attacker would need to convince the majority of the network to accept their false version, which becomes economically prohibitive as the network grows.

The distributed ledger eliminates the single point of failure. No single entity controls the system, no single server can go down and break everything, and no single company can censor transactions or freeze accounts. As long as some participants remain online, the network continues functioning.

A Transaction's Journey

These components work together every time someone sends cryptocurrency. Here is what happens when Alice sends 1 BTC to Bob:

1. Alice's wallet constructs a transaction ("transfer 1 BTC from Alice to Bob") and signs it with her private key. The digital signature proves Alice authorized this specific transfer.

2. The wallet sends the signed transaction to the network. Nodes check the signature and confirm Alice has sufficient funds. Valid transactions sit in the memory pool until a miner picks them up.

3. A miner collects pending transactions from the pool, organizes them into a Merkle tree, and includes the previous block's hash to extend the chain.

4. The miner finds a valid hash for the block (more on this in the consensus lesson). This costs real computational work, making it expensive to propose fraudulent blocks.

5. The miner broadcasts the completed block. Every node independently verifies: Are all signatures valid? Do all senders have sufficient funds? Does the block hash meet the difficulty requirement? Does it correctly reference the previous block?

6. Nodes that verify the block add it to their copy of the chain. Alice's transaction is now recorded. As more blocks build on top of it, the transaction gets harder to reverse—after six blocks (~60 minutes for Bitcoin), reversal is economically impossible.

Bob's wallet detects the new balance. The transfer is complete. No bank or intermediary was involved, and anyone on the network can verify the transfer independently.

Creating Trust Without Authority

Together, hashes catch tampering, signatures prove ownership, Merkle trees keep verification lightweight, and distribution removes any single point of control. Every participant can independently verify the entire history using only their own computational resources—without trusting anyone, sharing secrets, or depending on a single server.

Traditional systems gate access through intermediaries. Blockchains flip that: anyone can verify, and cheating is obvious. It works because the math makes cheating cost more than playing fair.

These cryptographic primitives prevent tampering and prove ownership. But if anyone can propose new transactions, how do thousands of strangers agree on which version of the ledger is correct? Consensus mechanisms solve this coordination problem.