BR Academy
Intro to Blockchain: How It Works and Why It Matters
0%
Exit course
Blocks, Hashes, and Cryptography·Lesson 5 of 25·12 min

Anatomy of a Block

The Concept

A block is made of two parts: a header and a body. Understanding this split is the key to everything that follows about why blockchains resist tampering.

The body holds the actual data — typically a list of transactions. This can be large: thousands of transactions in a single block.

The header is small and fixed-size, and it's the part that actually does the work of "chaining." A typical header contains:

  • Previous block hash — a cryptographic fingerprint (Module 2's next lesson) of the prior block's header. This is the literal "link" in blockchain — each block points backward to the one before it.
  • Timestamp — roughly when the block was created.
  • Nonce — a number miners adjust, in proof-of-work systems, to find a valid hash (Module 5 covers this in depth).
  • Merkle root — a single hash that summarizes every transaction in the body (the next lesson explains how this is built).

Here's the critical design choice: when a block gets hashed and linked to the next one, it's the header that gets hashed — not the full list of transactions directly. But because the header contains the Merkle root, and the Merkle root is derived from every transaction in the body, changing even one transaction in the body changes the Merkle root, which changes the header's hash, which breaks the link to the next block. The header is small and fast to hash repeatedly (useful for consensus, Module 5), while the Merkle root guarantees that the header still "represents" the entire body faithfully.

This is why altering old data is self-defeating: the forger would have to recompute the Merkle root, the header hash, and every subsequent block's header hash — a race against the rest of the network that, on an established chain, is computationally infeasible (Module 2's immutability lesson quantifies why).

Different networks add their own extra header fields on top of this basic set. Bitcoin's header includes a difficulty target (Module 5) that defines how hard the proof-of-work puzzle currently is. Ethereum's header includes a state root — a Merkle-style summary not just of this block's transactions, but of the entire current balance and smart-contract storage of the network — which is what lets a node verify account balances without replaying every transaction since the genesis block. The specific fields vary; the design principle doesn't: keep the header small and representative, put the bulk of the data in the body, and make the header depend on the body so the two can never drift apart undetected.

It's also worth noticing what's not in a typical header: there's no field for "miner's signature approving this specific transaction" or "bank authorization code." The header's job is purely structural — proving what came before and what this block contains — not vouching for any individual transaction's legitimacy. That job belongs to the signatures inside each transaction itself (Module 3 and Module 4 cover this), which the Merkle tree faithfully summarizes but doesn't evaluate.

One more distinction worth internalizing: a block's header size stays roughly constant over the life of a network, but the body's size grows with transaction demand, which is exactly why block size and block time become engineering and governance debates on real networks — a larger body means more transactions fit per block, but also means more data every node must download, store, and process to stay in sync. This header/body separation is what makes those trade-offs analyzable at all: you can reason about consensus speed almost entirely in terms of the small, fixed header, while reasoning about throughput and storage cost almost entirely in terms of the body — two separate engineering problems instead of one tangled one.

Worked Example

Open any public block explorer (for example, Etherscan for Ethereum or a Bitcoin explorer) and look at a confirmed block. You'll typically see fields labeled:

  • "Previous Hash" or "Parent Hash" → the previous block hash from the header.
  • "Timestamp" → the header's timestamp field.
  • "Transactions" (often a count, with a list below) → the body.
  • "Merkle Root" (sometimes hidden under "more details") → the header's Merkle root field.

Map each displayed field back to header vs. body: Previous Hash, Timestamp, and Merkle Root are header fields; the actual transaction list is the body. Notice that the explorer can show you thousands of transactions, but the header itself — the part that's hashed and linked — stays a fixed, small size no matter how many transactions the body holds.

Exercise

Sketch three consecutive blocks — in words or a simple diagram — labeled Block 100, Block 101, Block 102. For each, write a short header summary with a "prevHash" field. Draw (or describe) an arrow from Block 101's prevHash to Block 100's header hash, and from Block 102's prevHash to Block 101's header hash. Then answer in one sentence: if you changed one transaction inside Block 100's body, which other blocks' headers would need to be recomputed to keep the chain internally consistent?

As a final step, write one sentence explaining why it's the header — not the full transaction list — that gets hashed and linked to the next block, using the size and speed trade-off described in the Concept section.

Recap

  • A block is a header (small, fixed-size, creates the chain-link) plus a body (the actual transaction data).
  • The header's Merkle root ties it to every transaction in the body, so the two can't be tampered with independently.
  • This header/body split is the structural foundation for the immutability covered later in this module.

Resources

← A Brief History How Hashing Works →