What a blockchain does that an ordinary database cannot

A blockchain is a database with one unusual property: no single participant can quietly change what it already says, and anyone can check that for themselves. Almost everything else about it is worse than an ordinary database, and deliberately so. The design spends considerable resources purchasing one specific thing, which is agreement about history among parties who have no reason to trust each other.

What is actually stored

Transactions are grouped into a block. Each block contains a compact fingerprint of the previous one, produced by a hash function, so blocks form a chain in which altering an old entry changes every fingerprint after it. Inside a block, transactions are summarized by a Merkle tree, which lets a small device verify that one transaction is included without downloading everything else.

Two accounting styles exist. Bitcoin tracks discrete unspent outputs, where spending consumes an output and creates new ones, so a balance is really a set of pieces rather than a number. Ethereum and most later chains keep a running balance per address, which makes contract programming simpler and turns replay protection into a separate problem solved by a per-account counter. Either way, the current state is not trusted from a server; each full node derives it by replaying history under identical rules and rejecting anything that violates them.

Verification, not storage, is the point. A node that disagrees with the majority about whether a block is valid follows its own rules and ignores that block. This is why a network can refuse an upgrade that the largest operators want, and why rule changes are negotiated socially rather than deployed unilaterally.

The expensive part is agreement

Ordering is the hard problem. Thousands of machines receive transactions in different sequences and must converge on one canonical order without a coordinator. A consensus mechanism solves this by making the right to propose the next block scarce and costly. Under proof of work the cost is electricity spent searching for a hash below a target, with difficulty adjusting so that blocks arrive at roughly a fixed rate regardless of how much hardware joins. Under proof of stake the cost is capital placed at risk: a validator bonds the native asset and can lose part of it for provably contradictory behavior.

Both approaches deliver a similar guarantee in different shapes. Rewriting recent history requires either redoing accumulated work faster than the rest of the network extends it, or coordinating a large fraction of bonded capital and accepting its destruction. Neither makes rewriting impossible; both make it expensive enough to reason about, which is what finality actually means. Bitcoin's first block in January 2009 and every block after it are secured this way, and Ethereum switched from proof of work to proof of stake at the Merge in September 2022.

What the design gives up

The trade-offs are severe, and understating them makes the rest of the field harder to read.

• Capacity is bounded by what an ordinary machine can verify, not by what a data center can process, because every full node processes everything.
• Writes cost money, since block space is scarce and sold by auction, so there is a floor under the economics of any application built on top.
• There is no administrator, therefore no reversal of a mistaken payment, no soft delete and no support desk with an override.
• There is no confidentiality at the ledger level; balances and flows are public, and firms make a business of clustering addresses into probable identities.
• Changing the rules requires a fork, which is a political process among users, operators and developers rather than a deployment.
• Latency to a confident settlement is measured in seconds to minutes, not microseconds, and it varies with network conditions.

Set against an ordinary database, the contrast is stark on every axis except the one that matters. An operator-run database allows only authorized writers, is auditable only by parties the operator admits, costs nothing per write, reverses entries routinely, keeps data confidential by default, and changes schema through a migration. A public chain accepts writes from anyone who can sign and pay, is verifiable by anyone from the first block onward, prices each write in a market, and cannot revert an entry without a chain reorganization or a new offsetting transaction.

When an ordinary database is the better tool

If one organization is trusted to maintain the record, replication across strangers gains nothing and costs a great deal. A private chain run by a single company has the throughput penalty without the property that justifies it, since the operator can still rewrite history and no outsider is meaningfully verifying anything. The honest test is whether removing the trusted party is worth losing speed, privacy and reversibility, and for most applications the answer is no.

The design also does not verify facts about the outside world. A chain can guarantee that a message was signed by a particular key and included at a particular height. It cannot guarantee that a delivery happened, that an identity is genuine, or that a reported price is accurate; that requires an oracle, which reintroduces trust at a different point in the system. Confusing ledger integrity with real-world truth is the single most common error in reading these systems, and it is the mechanism behind a large share of documented protocol failures.

Reading a chain as data

Because verification is open, a public chain produces an unusually complete measurement surface, and this is what makes the rest of this site possible. Block time shows whether production is running to schedule. Node count and the Nakamoto coefficient approximate how concentrated control is, the second by asking how few entities would need to cooperate to disrupt consensus, which is a more informative question than how many participants exist in total.

Daily transactions describe usage, with the caveat that a transaction is not a unit of economic value: low-cost chains attract mechanical activity, and one transfer of a large sum counts the same as a trivial one. Counts of this kind are best read alongside fees and transferred value rather than on their own.

The network activity pages carry these series per chain, and the metric catalog gives the exact definition and source behind each one. The next lesson takes the cost side of the same design, examining why space in a block has a price at all.