What is a blockchain network actually agreeing on?

A network reaches consensus on one thing above all: the order of transactions, and therefore which of several possible histories counts as the real one. It does not agree on what anything is worth, on whether a transaction was sensible, or on any fact that lives outside the ledger. Everything else described as consensus is built on that narrow foundation.

The problem being solved, stated precisely

Digital records copy perfectly, which is exactly the property that makes a purely digital bearer instrument hard. If a balance is just a number in a file, the same balance can be spent twice by sending two conflicting messages to two different recipients. Conventional payment systems solve this by appointing one database as authoritative: the bank's ledger is correct because it is the bank's ledger, and any disagreement is resolved by looking at it.

A distributed ledger removes the appointed operator, so thousands of independent copies have to converge on the same history without any of them being in charge, while some unknown fraction of participants may be faulty, offline, or actively dishonest. That is the whole engineering problem. The academic name for it is Byzantine fault tolerance; the practical name is a consensus mechanism.

Two jobs that are often confused: validity and ordering

Validity is checked locally and needs no vote. Every node can independently confirm that a transaction carries a correct digital signature, that it spends coins that exist under the chain's accounting model — unspent outputs in a UTXO design, balances in an account model — and that it obeys the resource limits of the protocol. A block containing an invalid transaction is not a contested block; it is simply rejected by everyone who checks, no matter who produced it or how much work stands behind it.

Ordering is the part that genuinely requires agreement, because two transactions can each be individually valid and yet be mutually exclusive. Both spend the same coin; only the first in the accepted order takes effect. Pending transactions sit in each node's mempool in no canonical sequence at all, and the mempool is not a queue with a guaranteed order — it is a local, approximate, constantly changing set. Consensus is the procedure that turns that unordered set into one sequence, block by block.

Why the right to propose has to be costly

An open network cannot count votes by identity, because identities are free to create. A protocol that gave one vote per participant would be captured by whoever was willing to run ten thousand copies of the software, an attack named after the fictional patient with many personalities. The only durable answer is to attach the right to propose a block to something scarce and externally verifiable.

Proof of work attaches it to computation, which costs electricity and hardware time outside the system. Proof of stake attaches it to capital locked inside the system, which the protocol can destroy. The two designs are usually presented as rivals, and they do differ in important ways, but they are answers to one question: who gets to speak next, and what does lying cost them.

The chain, mechanically

Each block contains a compact fingerprint of the previous block, produced by a hash function. Because the fingerprint changes completely if any input byte changes, altering an old block invalidates every fingerprint after it. That is the sense in which history is immutable: not that it is impossible to change, but that changing it requires redoing everything built on top, in public, faster than everyone else is building forward. The chain of fingerprints runs back to a first block, the genesis block, which Bitcoin's network produced in January 2009. Position in the chain is measured as block height.

The decisive rule is the one nodes use to choose between competing chains. Under proof of work it selects the chain with the most cumulative work; proof-of-stake designs use variants weighted by attesting stake. This is why consensus is not a meeting or a poll at a moment in time. Each node applies the same deterministic rule to the same evidence and independently arrives at the same answer, which is what allows a node that was offline for a month to catch up without asking anyone's permission.

What consensus explicitly does not decide

It does not establish facts about the outside world. A contract that needs an exchange rate, a temperature, or a shipment confirmation gets it from an oracle, and the consensus rules will faithfully record whatever that off-chain data feed says, including nonsense. It does not make code correct: a smart contract that drains itself will be executed exactly as written, which is why smart contract risk is treated as a separate category of risk entirely.

It does not guarantee that a given transaction gets included, only that whatever is included is ordered consistently; refusal to include is censorship risk and lives at a different layer. And it does not decide the rules themselves. Changing what counts as valid is governance, not consensus, and it happens through software releases and coordinated activation rather than through the block-by-block process described here.

Reading it in data

Three published figures describe a consensus system's shape more usefully than any narrative about it. Block time sets the pace at which the order is extended and the granularity of every downstream measurement. Node count approximates how many parties are checking rules independently rather than trusting someone else's answer. The Nakamoto coefficient counts the smallest number of entities that would have to cooperate to control block production, which is a far sharper question than whether a network calls itself decentralized. None of the three is a quality score, and each is an estimate with a documented method.

The next lessons in this track take the two dominant answers apart in turn, starting with the cost proof of work imposes and the bond proof of stake requires. To see how these figures are compiled for individual networks, look at network activity and the metric catalog, and read methodology for how node counts and coefficients are estimated rather than observed.