Is a blockchain just a database?

It is a kind of database, but a constrained one. Records can be appended but not silently edited, every participant can hold a full copy, and the network agrees on updates through a consensus protocol rather than a single administrator. Those properties are what distinguish it from an ordinary database.

What stops someone from rewriting an old block?

Each block commits to the previous block's hash, so changing an old block alters every hash after it. To make the tampered chain accepted, an attacker would also have to redo the consensus work for all later blocks and out-compete the honest network — which is designed to be economically or computationally impractical.

Do all blockchains use proof-of-work?

No. Proof-of-work is one Sybil-resistance mechanism, popularized by Bitcoin. Many networks now use proof-of-stake, where validators are selected in proportion to staked value and can be penalized for misbehavior. Other schemes exist too; the choice affects energy use, finality, and security assumptions.

How does a blockchain work? | Blockchain Research

A shared ledger, copied many times

At its core, a blockchain is a database that is shared and synchronized across many independent computers. The Ethereum documentation describes a blockchain as a public database updated and replicated across a network of machines. Each computer — usually called a node — keeps its own copy of the ledger, and the network has rules for keeping every copy in agreement.

Two design choices set a blockchain apart from a conventional client–server database. First, the ledger is append-only: new records are added, but existing records are not meant to be quietly rewritten. Second, there is no central administrator with unilateral authority over the data. Instead, the participants follow a shared protocol that decides which updates are valid and in what order they apply. Removing the trusted middleman is the entire point, and most of a blockchain’s machinery exists to make that work safely.

Transactions, blocks, and the chain

The smallest unit of activity is a transaction — an instruction such as “move this value from A to B” or “run this contract function with these inputs.” Transactions are broadcast to the network, where nodes check them for validity: correct signatures, sufficient balance, proper formatting, and so on.

Valid transactions are gathered into a block. A block is essentially a batch of ordered transactions plus a header containing metadata: a timestamp, a summary of the transactions it contains, and — crucially — a reference to the block that came before it.

That backward reference is what makes it a chain. Each block stores the cryptographic hash of the previous block. A hash is a fixed-length fingerprint produced by a one-way function: the same input always yields the same output, any change to the input produces a wildly different output, and you cannot run the function backwards to recover the input. Because every block embeds its predecessor’s hash, the blocks form a tamper-evident sequence stretching back to the very first block, called the genesis block.

Why the links matter

Suppose an attacker wants to alter a transaction buried ten blocks deep. Editing that transaction changes the contents of its block, which changes that block’s hash. But the next block recorded the old hash, so it no longer matches — and so does every block after it. The tampering cascades forward and becomes immediately visible. To pass the change off as legitimate, the attacker would have to rebuild every subsequent block and convince the network to adopt their rewritten history instead of the honest one. As we’ll see, the consensus layer is what makes that prohibitively expensive.

Most blockchains also organize the transactions inside a block using a Merkle tree, a structure that hashes transactions in pairs, then hashes those hashes, repeatedly, until a single Merkle root remains in the block header. This lets a node prove that a specific transaction is included in a block without downloading every transaction — a property the Bitcoin whitepaper relies on for lightweight verification.

Reaching agreement without a coordinator

Linking blocks with hashes makes tampering detectable, but it doesn’t by itself decide whose version of the next block the network should accept. In an open network, anyone can join, and two nodes might propose different next blocks at the same moment. The system needs a way to converge on one shared history. That is the job of the consensus mechanism.

The Ethereum docs define consensus as the full stack of protocols and incentives that let a distributed set of nodes agree on the state of the chain. A consensus mechanism typically combines two things: a Sybil-resistance mechanism that makes it costly to gain outsized influence by spawning fake identities, and a fork-choice rule that tells nodes which competing chain to treat as canonical.

Proof-of-work

Bitcoin introduced proof-of-work. To propose a block, a participant (a “miner”) must repeatedly hash the block header while varying a number called a nonce, searching for an output below a difficulty target. Finding such a hash takes enormous trial-and-error computation, but verifying a found solution is instant. Because adding each block costs real energy, rewriting history means redoing that work for every block since the point of change — and racing the rest of the network while doing so.

Proof-of-stake

Many newer networks use proof-of-stake, where the right to propose and attest to blocks is allocated in proportion to value that participants lock up as collateral. Validators who follow the rules earn rewards; validators who try to cheat can have part of their stake destroyed. Here the cost of attacking is economic rather than computational — controlling the chain requires acquiring and risking a large fraction of the total stake.

Resolving forks

Temporary forks are normal. Two valid blocks can appear at nearly the same height, splitting the network briefly. The fork-choice rule resolves this — for example, by favoring the chain with the most accumulated work, or the one with the greatest weight of validator attestations. Within a few blocks the network reconverges, and transactions on the abandoned branch return to the pending pool. This is why a freshly published transaction is not yet certain; deeper blocks are progressively safer to rely on.

Putting it together: the state machine

It helps to think of a blockchain as a replicated state machine. There is a shared state — account balances, contract storage, and so on. Each block is an ordered batch of transactions that deterministically transforms the state from one snapshot to the next. Because every node applies the same transactions in the same order under the same rules, every honest node computes the same resulting state. The hash links secure the history, consensus secures which history is canonical, and deterministic execution ensures everyone ends up at the same current state.

That combination — an append-only linked log, a Sybil-resistant agreement protocol, and deterministic shared execution — is what lets mutually distrustful parties maintain a single, consistent ledger without trusting any one of them. Everything else, from smart contracts to tokens, is built on this foundation.

How does a blockchain work?