The waiting room before the ledger
Imagine a busy post office. You drop your letter in the slot, but it doesn't fly to its destination the instant it leaves your hand. It joins a pile of other letters waiting to be sorted, stamped, and loaded onto the next truck. A blockchain transaction works the same way. The moment you sign and broadcast it, the payment is real and ready — but it is not yet *in* the ledger.
That pile of waiting letters is the mempool — short for *memory pool*. It is the holding area for transactions that are valid but not yet confirmed. Crucially, there is no single central mempool: every full node keeps its own copy in memory, and gossips new transactions to its neighbours, so a freshly broadcast payment ripples across the whole network in seconds.
Choosing and ordering: why fees buy priority
A block can only hold so much. Block space is scarce — there is a limit on how many transactions fit, and a new block is produced only every so often (about every 10 minutes on Bitcoin, every 12 seconds on Ethereum). When more people want in than there is room for, something has to decide the order.
That something is a fee. Each transaction can attach a fee — a small payment offered to whoever builds the block. The producer is free to pick whichever waiting transactions it likes, and since its reward grows with the fees it collects, it naturally reaches for the highest-paying ones first. So a fee is really a bid for a scarce seat: pay more and you tend to be confirmed sooner; pay little and you may sit in the mempool through several blocks until traffic calms down.
Sealing the block: a header plus a list
Once the producer has chosen and ordered its transactions, it packages them into a block. A block has two parts: a long list of transactions (the body) and a small fixed-size summary on top called the block header. Think of the header as the cover page of a chapter — tiny, but it describes and locks down everything inside.
+=====================================+ | BLOCK HEADER | | prev block hash : a7f3... (link) | | merkle root : 9c1d... (body) | | timestamp : 12:04:31 | | rule value : difficulty/nonce | +=====================================+ | BODY (tx list) | | #1 Alice -> Bob fee 0.005 | | #2 Carol -> Dan fee 0.004 | | #3 Eve -> Frank fee 0.002 | | ... | +=====================================+
The header carries just a few key fields. It holds the hash of the previous header — the backward link that turns a heap of blocks into a *chain*. It holds a single fingerprint that summarises every transaction in the body (the Merkle root, drawn from a Merkle tree), so changing any one transaction would change this number and shatter the seal. And it holds rule-related values — a timestamp, and on a proof-based chain, things like a difficulty target and a nonce. Because the header commits to the whole body, hashing this tiny summary is enough to vouch for everything inside.
But who gets to build it?
We have quietly skipped the most important question. Selecting transactions, ordering them, and assembling a header is easy — any node could do it. So who is allowed to add the next block to the chain that everyone accepts? If it were a free-for-all, two people could publish conflicting blocks and the network would split.
Answering that — fairly, without a boss, among strangers who don't trust each other — is the whole job of a consensus mechanism. It is the rule that decides who earns the right to seal the next block, and why everyone else agrees to follow. That is exactly where we go next: the costly lottery of proof of work, and its lighter cousin, proof of stake.