A block is a sealed page in a shared notebook
Imagine a notebook that thousands of strangers share. Every few minutes someone fills a fresh page with a batch of payments, then seals the page with a wax stamp and writes, in the corner, the stamp of the previous page. Anyone can flip backward page-by-page, each page pointing to the one before it, all the way to the very first page ever written. That sealed, back-referencing page is a block, and the whole bound notebook is the blockchain — a distributed ledger no single person owns.
Open one block and you find exactly two parts. The header is the small summary stamp — in Bitcoin it is precisely 80 bytes, no matter how busy the block is. The body is the actual list of transactions, which can be a megabyte or more. The header is what gets hashed, chained, and quoted by the next block; the body is the payload it vouches for. This guide dissects both, and then the single field that links one block to the last.
The header: a 80-byte summary that seals the block
The block header is the heart of the design, because the header — not the body — is what gets hashed to give the block its identity. A Bitcoin header packs six fields into 80 fixed bytes:
- version (4 bytes) — which consensus rules this block follows.
- previous block hash (32 bytes) — the hash of the parent block's header. This is the backward link (Section 4).
- Merkle root (32 bytes) — one fingerprint of every transaction in the body (Section 3).
- timestamp (4 bytes) — when the miner built the block, as Unix epoch seconds.
- bits / target (4 bytes) — the difficulty target the block hash must come in under.
- nonce (4 bytes) — the throwaway number a miner grinds to make the hash satisfy the target.
{
"version": 1,
"prevBlockHash": "0000000000000000000000000000000000000000000000000000000000000000",
"merkleRoot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
"timestamp": 1231006505, // 2009-01-03 18:15:05 UTC
"bits": "0x1d00ffff", // the difficulty target
"nonce": 2083236893
}
// SHA-256(SHA-256(header)) ->
// 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fA block's identity is its header hash. Bitcoin computes it as SHA-256 applied twice to the 80-byte header. Notice what this means: the body is never hashed directly into the block's identity — it enters only through the 32-byte Merkle root. Change anything in the body and the root changes; change the root (or any other header field) and the whole block hash changes. That single chain of consequences is the entire security idea, and the next two sections trace it.
The body: many transactions, one root
The body is an ordered list of transactions. In Bitcoin the first one is special — the coinbase transaction that mints the block reward out of thin air — followed by every ordinary payment the miner chose to include. A busy block holds a few thousand of them. The next guides in this rung open a transaction up field by field; here we only care how the header summarizes the whole list.
It does not list the transactions in the header — it stores a single 32-byte Merkle root that fingerprints all of them at once. You built one of these in the previous rung: pair up transaction hashes, hash each pair, and keep climbing until a single hash remains at the top. Reorder, add, remove, or alter even one transaction and that root comes out completely different. So an 80-byte header, fixed in size forever, can faithfully commit to a body of any size.
The link backward: how a chain is born
Now the field that gives the structure its name. Every header carries the previous block hash — the header hash of its parent. Follow those pointers and you walk backward through history, block to block to block. This is a singly linked list, except the pointer is not a memory address you could quietly repoint; it is a cryptographic hash baked into the header and thus into the block's own identity.
Where does the chain end? At the genesis block — block 0 — which has no parent, so its previous-hash field is filled with all zeros. Bitcoin's genesis block was mined on 3 January 2009 and famously embeds a newspaper headline, *"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks,"* in its coinbase. Every block in existence ultimately points back to that one hardcoded root.
Block 100 Block 101
+---------------------------+ +---------------------------+
| prevHash: <hash of #99> | | prevHash: 0xA1B2... <-----+--+
| merkleRoot: 0x7f3c... | | merkleRoot: 0x9d04... | |
| timestamp, bits, nonce | | timestamp, bits, nonce | |
+---------------------------+ +---------------------------+ |
hash = 0xA1B2... --------------------------------------+
(this block's id becomes the next block's prevHash)Why tampering is obvious: the domino effect
Here is the payoff. Suppose an attacker wants to quietly edit one old transaction — say, in block 100, redirecting a payment to themselves. Watch the dominoes fall:
- Editing the transaction changes the body, so block 100's Merkle root no longer matches — recomputing it yields a different root.
- To keep the header consistent they must write the new root into it — but that changes the header, so block 100's hash changes too.
- Block 101 stored the old hash of block 100 in its prevHash field. It no longer matches. The chain is now visibly broken at 101.
- To repair the break they must rewrite block 101's prevHash, which changes block 101's hash, which breaks block 102 — and so the damage cascades all the way to the tip of the chain.
- And every rewritten header's hash must still fall under the difficulty target, so they must re-do the proof of work for every block from 100 to the tip — faster than the honest network keeps extending it.
That cascade is what people mean by a blockchain's immutability. Be precise, though: the structure alone makes tampering tamper-evident, not impossible. Anyone re-checking the hashes instantly sees the chain doesn't add up. What makes rewriting genuinely expensive is consensus plus accumulated work — an attacker would need to out-mine the entire honest network, the classic 51% attack that lets them rewrite recent blocks in a chain reorganization. The deeper a block is buried, the more work sits on top of it, and the more practically permanent it becomes. That is why we wait for 'confirmations.'
Two real headers: Bitcoin vs. Ethereum
The pattern — header seals body, header links to parent — is universal, but the headers differ. A Bitcoin header commits to just one thing: a single Merkle root over the block's transactions. An Ethereum header is richer, carrying three roots: a transactions root, a receipts root, and a state root. Each is the root of a Merkle-Patricia trie, and they are hashed with Keccak-256 rather than SHA-256.
The most important difference is the state root. It commits not to the block's transactions but to the entire world state after the block runs — every account balance and every byte of contract storage, folded into one 32-byte hash. So an Ethereum block doesn't just prove which payments happened; it proves the exact state of the whole system, which is what makes light clients and smart contracts practical.
// An Ethereum header (post-Merge, abridged)
{
"number": 17000000,
"parentHash": "0x...", // the link backward — same idea as Bitcoin
"stateRoot": "0x...", // root of the entire world state
"transactionsRoot":"0x...", // root over this block's transactions
"receiptsRoot": "0x...", // root over execution receipts
"timestamp": 1681338455,
"difficulty": "0", // PoW retired at the Merge
"nonce": "0x0000000000000000", // now unused
"mixHash": "0x..." // now carries beacon-chain randomness (prevRandao)
}Be honest about the history: since the Merge in September 2022, Ethereum no longer mines, so its difficulty and nonce fields are frozen relics and mixHash was reassigned to deliver randomness from the consensus layer. But the two ideas that matter most — the header commits to the body, and parentHash chains each block to the one before — are identical to Bitcoin's. That shared skeleton is what 'blockchain' really names.