Starting With the Right Question
Most explanations of blockchain technology start with the technology. Blocks of transactions, chained together cryptographically, distributed across nodes. This is accurate but backwards. The technology is an implementation of an argument. Understanding the argument first makes the technology legible in a way that product descriptions never achieve.
The argument is this: *is it possible to create a system where participants who do not trust each other can nonetheless agree on a shared history, without requiring a trusted intermediary?*
This is not a new question. Cryptographers, computer scientists, and game theorists worked on variants of it for decades before Bitcoin. The blockchain answer combines their tools in a specific way. This article unpacks that combination, the thought process behind it, not just the result.
The Foundation: What Cryptographic Hash Functions Actually Do
A cryptographic hash function takes any input, a single character, a novel, a transaction record, an entire block of data, and produces a fixed-length output called a hash or digest. SHA-256, the function used in Bitcoin's proof-of-work, always produces 256 bits regardless of input size.
Three properties make cryptographic hash functions useful for building trust systems:
Determinism: The same input always produces the same output. This is trivially obvious but foundational, it means hashes are verifiable. Anyone with the input can independently compute the hash and check it matches.
Avalanche effect: Changing one bit of the input produces a completely different output, with no discernible relationship to the original. Change a single letter in a paragraph, and the SHA-256 hash is entirely different, not slightly different, not predictably different, but uncorrelated. This prevents an attacker from crafting modified inputs that produce a target hash.
Collision resistance: It is computationally infeasible to find two different inputs that produce the same hash. 'Computationally infeasible' is a precise claim, not 'impossible' but 'would require more computing power than exists on Earth, running longer than the age of the universe.' For SHA-256, this holds at the time of writing. *(Source: Analysis of Cryptographic Tools for Blockchain and Bitcoin, MDPI Mathematics, 2020)*
These three properties together mean that a hash is a fingerprint that cannot be faked. If you give me a document and its SHA-256 hash, I can verify that the hash matches the document. If you modify the document even slightly, the hash will change, and I will detect it immediately.
Hash Pointers: Chaining the History
The 'blockchain' in blockchain is built from hash pointers. Each block contains a cryptographic hash of the previous block's header. The chain of hashes creates a tamper-evident record: if you modify any historical block, its hash changes, which breaks the hash reference in the next block, which breaks the reference in the block after that, propagating forward through the entire chain.
An attacker who wants to rewrite history cannot simply modify a block. They must recompute the proof-of-work (or equivalent) for that block and every block that followed it, a computational task that, for mature chains with sufficient hash rate, is economically prohibitive.
The chain structure converts individual block validation into cumulative security. The older the block, the more computational work sits on top of it, the more expensive it is to rewrite. Bitcoin's oldest blocks are protected by over fifteen years of accumulated proof-of-work, a quantity of computation that no realistic adversary can replicate.
Merkle Trees: Efficient Verification at Scale
A block might contain thousands of transactions. Storing and verifying all of them in full is expensive, particularly for lightweight clients (mobile wallets, for example) that cannot store the entire blockchain.
The solution was developed by Ralph Merkle in 1979, a decade before blockchains existed, as a method for efficiently verifying large datasets. A Merkle tree is a binary tree structure where each leaf node contains a transaction hash, and each non-leaf node contains the hash of its two children. The root node, the Merkle root, is a single hash that commits to the entire set of transactions. *(Source: Prof Bill Buchanan OBE FRSE, 'After Five Decades, The Merkle Tree Still Reigns Supreme', Medium, March 2026)*
The useful property: if you want to verify that a specific transaction is included in a block, you do not need to download all the transactions. You need only the transaction itself and a 'Merkle proof', a path of sibling hashes from the transaction's leaf node to the Merkle root. The path length is logarithmic in the number of transactions: for a block with 4,096 transactions, a Merkle proof requires 12 hashes. This makes transaction verification efficient enough for lightweight clients on constrained devices.
The Merkle root is included in the block header. Miners commit to a specific set of transactions, the ones whose hashes build up to that root, when they mine the block. Changing any transaction changes the Merkle root, which changes the block header, which invalidates the proof-of-work. The inclusion commitment is cryptographically binding. *(Source: Helius, 'Cryptographic Tools 101. Hash Functions and Merkle Trees', helius.dev)*
Elliptic Curve Cryptography: The Signature Behind Every Transaction
Hash functions prove that data hasn't been modified. But blockchain also needs to prove authorship: that a transaction to send funds was authorized by the person who holds those funds, not by someone who copied the transaction.
This is the role of digital signatures, and most blockchain implementations use Elliptic Curve Digital Signature Algorithm (ECDSA) to produce them.
Elliptic curve cryptography is built on a mathematical structure: an elliptic curve over a finite field. Operations on points of this curve have a specific property, they are easy to perform in one direction and computationally infeasible to reverse. Multiplying a point on the curve by a scalar is straightforward. Recovering the scalar from the resulting point (the elliptic curve discrete logarithm problem) is believed to be computationally infeasible for curves with sufficient parameters.
In ECDSA, your private key is a large random number. Your public key is that number multiplied by a standard starting point on the curve. Anyone can verify a signature using the public key, but recovering the private key from the public key would require solving the discrete logarithm problem, which is not computationally feasible with known algorithms. *(Source: MDPI, 'Analysis of the Cryptographic Tools for Blockchain and Bitcoin', 2020)*
When you sign a Bitcoin transaction, ECDSA produces a signature that proves you know the private key corresponding to the address you are spending from, without revealing the private key itself. The network verifies the signature against your public key and confirms the transaction is authorized.
The Thought Process: How These Pieces Fit Together
What makes blockchains remarkable is not any individual cryptographic primitive. Hash functions, Merkle trees, and digital signatures each predate blockchain by decades. Bitcoin's contribution was the specific combination, and the economic incentive layer that makes the combination game-theoretically stable.
The thought process runs as follows:
1. We need participants to agree on a shared history without trusting each other or a central authority. 2. We can make history tamper-evident using hash chains, changing history requires recomputing all subsequent hashes. 3. We can make history recomputation economically prohibitive using proof-of-work, the computational cost of rewriting history exceeds the gain. 4. We can make transaction verification efficient using Merkle trees, lightweight clients can verify inclusion without storing everything. 5. We can make transaction authorization unforgeable using elliptic curve signatures, spending requires knowledge of the private key, which cannot be derived from public information.
None of these steps individually solves the problem. All of them together create a system where the cost of cheating exceeds the benefit of cheating, for rational participants, under realistic assumptions about available computing power.
Quantum Computing and the Long Horizon
No technical survey of blockchain cryptography is complete without acknowledging quantum computing. Shor's algorithm, if run on a sufficiently powerful quantum computer, would break elliptic curve cryptography, it can solve the discrete logarithm problem efficiently, which would allow recovery of private keys from public keys.
Hash-based cryptography, the Merkle tree structure, is believed to be quantum-resistant. The best known quantum algorithm for attacking hash functions (Grover's algorithm) provides only a quadratic speedup, which can be countered by increasing hash output size. SHA-256 with 128-bit quantum security becomes SHA-512 with comparable security against quantum attack. The hash chain structure that underlies blockchain's tamper-evidence is robust against the quantum threat we can currently characterize.
*(Source: Prof Bill Buchanan OBE FRSE, 'After Five Decades, The Merkle Tree Still Reigns Supreme', Medium, March 2026)*
The ECDSA signature layer is more vulnerable. Post-quantum signature schemes. CRYSTALS-Dilithium, FALCON, and others standardized by NIST in 2024, are the likely replacements for ECDSA in blockchain systems that need to plan for the quantum horizon. Transitioning existing blockchains to post-quantum signatures is a governance and coordination challenge as much as a technical one.
Reading Blockchain Claims Differently
Once you understand the cryptographic argument underlying blockchains, the landscape of blockchain claims looks different. 'Immutable' is not a mystical property, it is a quantified claim about computational cost. 'Trustless' means trust has been moved from institutions to mathematics and economic incentives. 'Decentralized' means the set of parties who can independently verify the rules has been expanded.
These are real properties, not marketing language. But they are properties with specific scope and conditions. A blockchain that is 'immutable' relative to today's computing power may not be immutable relative to tomorrow's. A protocol that is 'decentralized' in its consensus layer may be highly centralised in its governance layer.
The cryptographic thinking that produced blockchains is rigorous and honest about its assumptions. Blockchain evaluation should be equally rigorous, asking not 'does this use cryptography?' but 'does the specific cryptographic argument hold under realistic threat models?' The mathematics answers those questions. Knowing how to ask them is the beginning of sound blockchain judgment.
---
*Sources: MDPI Mathematics, 'Analysis of the Cryptographic Tools for Blockchain and Bitcoin' (2020, mdpi.com/2227-7390/8/1/131) · Prof Bill Buchanan OBE FRSE, 'After Five Decades, The Merkle Tree Still Reigns Supreme', Medium (March 2026) · Helius, 'Cryptographic Tools 101. Hash Functions and Merkle Trees' (helius.dev) · Space and Time, 'Understanding Merkle Trees' (spaceandtime.io) · ScienceDirect, 'Cryptographic Hash' overview*