Key takeaways
- A block is just a batch of transactions plus a fingerprint of the block before it, which is what creates the chain.
- Hashing makes tampering detectable: change one byte and every fingerprint after it stops matching.
- Consensus decides which version of history everyone accepts; in proof of work that decision is anchored to real energy spent by miners.
- Security is economic, not magical. Rewriting history is possible in principle but is made deliberately costly.
Most explanations of blockchain start with a metaphor and never come back. The chain of blocks, the digital ledger, the trustless machine. None of that tells you what is actually happening when a transaction is made. This piece works through the mechanics in order: what a block contains, what a hash does, how the network agrees on one history, and why changing that history is expensive rather than impossible.
A block is a batch with a backwards reference
A blockchain does not record transactions one at a time. It groups them into blocks, and each block is published as a unit. Inside a typical block you will find a set of transactions, a timestamp, some protocol bookkeeping, and one field that matters more than the rest: a reference to the block that came before it.
That backwards reference is not a sequence number. It is a cryptographic hash of the previous block’s header. Because the hash depends on the entire contents of that earlier block, the reference doubles as a fingerprint. If anything in the earlier block changes, the fingerprint changes, and the link no longer matches.
Chain those references together and you get a structure where every block implicitly commits to the whole history before it. That is the actual meaning of the word chain here. It is not a metaphor about links. It is a specific data structure where each element carries a verifiable summary of everything prior.
Hashing: the part that makes tampering visible
A cryptographic hash function takes input of any size and produces a fixed-length output. Three properties make it useful here. The same input always produces the same output. A tiny change to the input produces a completely different output, with no resemblance to the original. And working backwards from an output to find an input that produces it is computationally impractical.
Put together, those properties give you a tamper-evident seal. You cannot forge a hash to match altered data, and you cannot alter data quietly enough to keep its hash the same. Anyone holding a copy of the chain can recompute the hashes themselves and see immediately whether the history they were handed is internally consistent.
Most chains also use a hash tree, often called a Merkle tree, to summarise the transactions inside a block. Transactions are hashed in pairs, then those hashes are hashed in pairs, repeatedly, until a single root hash remains. That root goes in the block header. The practical benefit is that a lightweight client can prove a specific transaction is in a block without downloading the whole block, which is what makes mobile wallets viable. You can read more on the vocabulary in our glossary.
Consensus: choosing which history counts
Hashing tells you whether a chain is internally consistent. It does not tell you which of two consistent chains is the real one. That is the consensus problem, and it is the harder half.
In proof of work, the right to publish the next block is earned by finding a hash below a target value. Because hash outputs are effectively unpredictable, the only way to find one is to try enormous numbers of candidates. That trying is what mining hardware does, and it consumes electricity. When a miner finds a valid solution, they broadcast the block, and everyone else can verify it instantly by computing the hash once.
This asymmetry is the design’s core: expensive to produce, trivial to check. Nodes then follow a simple rule. When two valid chains exist, adopt the one with the most accumulated work. Since accumulated work maps to real energy spent, the rule effectively says: believe the history that was most expensive to build.
Difficulty adjusts over time so that blocks arrive at roughly a target interval regardless of how much hardware is pointed at the network. If more miners join, difficulty typically rises and each machine earns a smaller share. This is why hashrate and difficulty carry information for anyone following the network rather than only the price, and why we publish them on the mining dashboard.
Proof of stake reaches the same goal by different means, tying block production rights to capital committed to the protocol rather than energy spent outside it. Neither approach is strictly better in all conditions, and the trade-offs are worth understanding on their own terms. We compare them in proof of work versus proof of stake.
Why rewriting history costs money
Suppose someone wants to erase a payment they made several blocks ago. They must produce a replacement block that excludes the payment, which changes that block’s hash, which breaks every link after it. So they must also rebuild every subsequent block. Meanwhile the honest network keeps extending the real chain.
To win, the attacker must build faster than everyone else combined, for long enough to overtake. On a well-established proof of work chain that means acquiring and running a majority of the hardware, paying for the electricity, and accepting that success would likely damage the value of the very asset they are attacking. The defence is not that the attack is forbidden. It is that the attack is a bad trade.
This has an important corollary that promotional material tends to skip: security scales with the cost of attack. A small chain with modest hashrate is meaningfully easier to reorganise than a large one. Treating all blockchains as equally immutable is a mistake.
What blockchains do not guarantee
A blockchain guarantees that recorded data has not been quietly altered and that participants agree on ordering. It does not guarantee that the data was true when it was written. If someone records that a shipping container holds a particular cargo, the chain faithfully preserves that claim, including if the claim was false. This is the oracle problem, and it limits many of the supply chain use cases that get promoted enthusiastically.
Nor does a blockchain make software correct. Code deployed on-chain can contain bugs, and the same immutability that protects the ledger can make those bugs permanent. That is a separate subject, and an important one.
Reading the network rather than the narrative
Once the mechanics are clear, some observable quantities start to mean something. Block interval and difficulty describe how contested block production is. Hashrate describes how much hardware is committed. Mempool depth describes congestion and therefore fee pressure. None of these predict price, and anyone claiming otherwise is overselling. But they describe the state of the system in a way that headlines usually do not.
If you want to go further, our learn section works through the surrounding concepts, and the methodology page explains where our data comes from and what we do not claim to know. Nothing here is investment advice; it is an account of how the machinery works.
Frequently asked questions
What actually stops someone editing an old transaction?
Nothing stops them editing their own copy. What stops the edit spreading is that every other participant can check it. Each block carries a hash of the previous block, so altering an old transaction changes that block's hash, which invalidates the link held by the next block, and so on to the tip of the chain. To make the edit stick, an attacker would have to redo the work for every block after the one they changed, faster than the honest network is extending the chain, and then convince others to adopt their version. That is a cost problem rather than a cryptography problem, and the cost is the point.
Is a blockchain the same thing as a database?
It has a database inside it, but the interesting part is the rules about who may write and how disagreements are settled. An ordinary database has an administrator who decides what is true. A public blockchain replaces that administrator with a protocol, so participants who do not trust each other can still converge on one history. That is a genuine capability, but it costs throughput, storage and energy. If you already have a trusted administrator, a normal database is usually the better engineering choice.
Why do people talk about confirmations rather than a transaction being final?
Because settlement on a proof of work chain is probabilistic rather than instant. When your transaction first appears in a block, there is a small chance that a competing block wins out and your transaction returns to the pending pool. Each additional block built on top makes reversal exponentially more expensive, so the transaction becomes progressively harder to undo. Waiting for more confirmations is simply choosing a lower probability of reversal. How many is enough depends on the value at stake and the security of the chain involved.
Exploring blockchain, crypto, and DeFi innovation. Ex-fintech analyst turned journalist, spotlighting real-world use cases of blockchain. Writer at Cryptocurrency Miners.
