Components of a Blockchain and the Block Structure

1.4 — Components of Blockchain, Block in Blockchain

Recall first. From §1.2–1.3 you know a block header holds a Merkle root and links to the previous block by hash. Name the two things that let a block be (a) tamper-evident and (b) chained to its predecessor. Then read.

Reference-book anchor

Primary reference: Blockchain Technology, Chapter 1, §§1.4–1.5 and Chapter 4, §§4.4.2/4.4.4.1 — converted Markdown lines 689–830 and 2688–2800.¹

The book’s anchor covers nodes, ledgers, wallets, nonces, hashes, mining, consensus, the block’s fields, and Bitcoin’s header/PoW example. The exact 80-byte header is retained as Bitcoin-specific rather than presented as a universal blockchain layout.

The big picture: layers of a blockchain

A blockchain system has recurring components. Learn them as a stack — each layer depends on the one below:

┌─────────────────────────────────────────────┐
│  Application layer   (smart contracts, apps) │  ← Modules III–VI
├─────────────────────────────────────────────┤
│  Consensus layer    (who appends next block) │  ← §1.6
├─────────────────────────────────────────────┤
│  Network layer      (peer-to-peer gossip)    │
├─────────────────────────────────────────────┤
│  Data layer         (blocks, hashes, Merkle) │  ← this note
└─────────────────────────────────────────────┘

This note focuses on the data layer — what a block actually is — then lists the other recurring components at a high level.

Anatomy of a block

A block has two conceptual parts: the header (metadata used to identify and validate the block) and the body (the transactions or state updates). The fixed 80-byte layout below is Bitcoin-specific; other blockchain protocols can use different fields, sizes, and commitments.

Block header (80 bytes in Bitcoin)

In Bitcoin, the block hash = SHA256d(header). Because the header includes prev_block, each Bitcoin block is chained to its parent; because it includes merkle_root, it commits to its transactions. Other protocols can hash and structure blocks differently.²³

Block body

The body is the list of transactions in the order they were paired into the Merkle tree. In Bitcoin, the coinbase transaction (the miner’s reward) is always first; other protocols may have different first-record or reward rules.³

Three identifiers to keep separate

A block hash is not a replacement for the block body: a verifier still needs the body to inspect transactions, while the hash provides a compact integrity handle.

The genesis block is the boundary case: it has no ordinary predecessor, so its previous-block field is defined by the protocol rather than pointing to an earlier block.

Why only the header is hashed for PoW

In Bitcoin, only the 80-byte header is hashed during mining. This is deliberate:

• Adding transactions changes only the Merkle root inside the header — you don’t re-hash the whole block.
• The nonce lives in the header, so miners can try nonces without touching transaction data.
• It keeps mining I/O cheap (small, fixed data) no matter how many transactions are in the block.³

Refresher — what “hashing the header” means. The miner repeatedly sets nonce = 0,1,2,…, computes SHA256d(header), and checks whether the result is below the target. Finding a valid nonce is the proof-of-work (see §1.6).

The chain property, made concrete

Block N-1:  hash = H(header_{N-1})
Block N:    prev_block = hash_{N-1},  hash_N = H(header_N)
Block N+1:  prev_block = hash_N

If an attacker alters a transaction in Block N:

1. merkle_root in header_N changes → hash_N changes.
2. Block N+1’s prev_block no longer matches → the break is visible.
3. To hide it, the attacker must recompute Block N and every block after it (re-do all the PoW). That is the “proof-of-work makes rewriting expensive” guarantee.²

What a full node checks before accepting a block

A simplified validation sequence is:

1. Check the header format, timestamp, target, and proof-of-work.
2. Check that the previous-block reference points to a known valid chain tip or candidate ancestor.
3. Recompute the Merkle root from the supplied transactions.
4. Validate each transaction, including signatures, inputs, outputs, and double-spend rules.
5. Apply the consensus rule for chain selection or finality, then relay or store the block.

A valid hash is therefore necessary but not sufficient. A miner can produce a correctly shaped header for a block whose transactions violate the protocol; full nodes reject the invalid block.

Other recurring components (mental inventory)

You’ll meet wallets, transactions, and consensus in depth in Modules II and §1.6. Here, just fix the data-layer picture.

Worked example — spot the break

Given this chain, an attacker changes Tx2 in Block 2. Which block hashes must be recomputed for the attack to succeed fully?

Block1 (hash h1) → Block2 (prev=h1, hash h2, merkle=m2) → Block3 (prev=h2, hash h3)

Answer: Changing Tx2 changes m2, so h2 changes. Now Block3’s prev_block (=h2) is wrong, so h3 must also change. The attacker must re-mine Block2 and Block3 (and everything after). They cannot quietly edit one block.

Exercise

In Bitcoin, the header is 80 bytes but the block hash is 32 bytes. (a) Which is larger — a block’s header or its full body? (b) Why does Bitcoin store only the 32-byte hash as the block identifier rather than the whole block?

Exam lens

Draw and label: previous-block hash → header fields → block hash, with Merkle root in the header and the transaction list in the body. State that the exact field layout shown is Bitcoin-specific.

Five-mark answer pattern: define header and body, explain prev_block and merkle_root, list the Bitcoin header fields, describe how a changed transaction propagates through the Merkle root and descendant links, then explain why node validation is still required.

Common traps:

• The Merkle root is not the block hash.
• The block hash is not the whole block.
• A nonce is not the only field a miner can vary, although it is the obvious dedicated search field.
• “Immutable” does not mean a node accepts every block forever; invalid blocks can be rejected and valid histories can reorganize under some consensus protocols.

Rapid revision

• Can I name the six Bitcoin header fields and their roles?
• Can I distinguish txid, Merkle root, and block hash?
• Can I trace one changed transaction through the root, block hash, and next block’s link?
• Can I explain why proof-of-work does not replace transaction validation?

Key takeaways

• In Bitcoin, a block = header (80 B, hashed for PoW) + body (transactions); other protocols can structure blocks differently.
• The header carries prev_block (the chain link) and merkle_root (commitment to transactions).
• In Bitcoin, only the header is hashed for mining — efficient and modular.
• Changing any transaction forces recomputation of that block and all descendants.
• Higher layers (consensus, network, application) sit on top of this data layer.

Sources