Many people have an intuitive image of a blockchain block as “a container holding a lot of transactions.” This is not wrong, but it is incomplete. If we see a block only as a list of transactions, it becomes hard to explain why blockchains are tamper-resistant, why nodes can quickly verify data consistency, and why blocks on different chains look so different.
This article answers a very specific question: what parts make up a block, what function does each part serve, and why “a block is more than transactions.”
Breaking a Block Down: Block Header and Transaction List
To understand the internal structure of a block, we can start with an everyday analogy: imagine the blockchain as a ledger, and each block as one page in that ledger. At the top of the page is header information, such as the date, the number of the previous page, and a summary of the page’s contents; below that header is the actual record of entries.
A real block has a similar two-layer structure:
- Block header: stores metadata and is responsible for linking, verification, and consensus.
- Transaction list: stores the user operations or state-change requests that the block actually records.
Here, “metadata” is not the transactions themselves but information about the block. It answers: which page comes before this one? What do the transactions on this page look like as a whole? When was this page assembled? Does it comply with the network’s consensus rules?
This “metadata + content” structure is the key to understanding what is inside a block. The block header is like an ID card and connector; the transaction list is the actual body of the ledger.
It should be noted that this analogy has clear limitations. A ledger does not automatically lock its pages to one another through cryptography, whereas a blockchain’s hash links are cryptographically strong bindings that do not rely on manual checking. The analogy helps build an intuition for the two-layer structure, but it cannot replace the explanation of the mechanisms that follows.
The Block Header: This Page’s ID Card and Connector
Block headers usually contain several key fields. Below, using Bitcoin’s block header structure as an example, we show a simplified view. This is not a universal template for all blockchains, but it helps us see what each block header field does.
A simplified Bitcoin block header usually contains:
- version number
- previous block hash
- Merkle root
- timestamp
- difficulty target
- nonce
These fields may look scattered, but they can be understood in three functional groups: linking, verification, and consensus.
Parent Hash: Pointing the Current Block to the Previous Block
The previous block hash records the hash value of the previous block. A hash function can map arbitrary data to a fixed-length fingerprint; the same data produces the same fingerprint, and if the data changes, the fingerprint changes.
The role of the previous block hash is to let the current block “remember” the fingerprint of the previous block. In this way, each block points to the one before it, forming a chain from back to front. If the contents of the previous block are changed, its hash changes, and the previous block hash recorded in the current block no longer matches. This chained reference is one of the foundations of blockchain tamper resistance.
Merkle Root: Compressing a Set of Transactions into One Fingerprint
The block header does not directly list all transactions; instead, it contains a Merkle root. A Merkle root is a single root hash obtained by hashing the transaction list layer by layer through a specific structure.
Its key role is: to represent the entire set of transactions with one small fingerprint. If any transaction in the transaction list changes, the Merkle root changes accordingly. This allows the block header to bind the integrity of the transaction list without storing every transaction again in the header.
Here we do not need to go deep into the full construction of a Merkle tree or how proofs are generated. To understand the internal structure of a block, we only need to know that the Merkle root is the “summary representative” of the transaction list in the block header.
Timestamp, Difficulty, and Nonce: Serving Consensus
The timestamp records the approximate time when the block was assembled, but different chains have different validation rules for time precision and acceptable ranges. We cannot treat one chain’s rules as a universal standard.
In Proof-of-Work (PoW) chains such as Bitcoin, the block header also contains a difficulty target and a nonce. Miners need to find a nonce such that the hash of the block header satisfies the current difficulty target. The nonce is essentially a variable that miners can try repeatedly, while the difficulty target defines “how hard it must be to qualify.” These two fields serve mining proof and consensus validation, not the recording of user transactions.
Emphasis: nonce and difficulty target are designs under a specific consensus mechanism. Chains using other consensus mechanisms may have completely different fields. For example, after Ethereum moved to Proof of Stake (PoS), its block structure changed. It no longer relies on traditional nonce mining as Bitcoin does, and its block header also contains a state root, transaction root, receipts root, and gas-related fields. Ethereum’s specific fields evolve with protocol versions; for accurate details, consult its protocol documentation.
Here we mention the state root only as background: some chains need to put a summary of on-chain state into the block header to verify state consistency. The specific construction of the state tree is beyond the scope of this article.
The Transaction List: The Batch of Events a Block Actually Records
The transaction list is the content part of a block. Transactions represent operations initiated by users, such as transfers, smart contract calls, or, more generally, requests to change on-chain state.
A block usually packages multiple transactions rather than giving each transaction its own block. The benefit is throughput efficiency: packing multiple operations onto one page is more economical than making a separate page for each operation. Different chains may define transaction content, ordering, and execution differently, but “a block contains a set of transactions” is common practice on most chains.
The transaction list and block header are bound through the Merkle root. Imagine a simplified scenario: a block packages three transactions, Tx1, Tx2, and Tx3. After layer-by-layer hashing, they produce a Merkle root, denoted R. This R is written into the block header. If any one of the transactions is changed, the recomputed root becomes R’, which does not match the R recorded in the block header.
This explains why the block header, although it is not the transaction content, can help the network verify that the transaction list has not been tampered with.
How the Block Hash Binds Transactions and the Chain Together
Now we can answer a key question: why does changing one transaction in a block cause problems for the chain that follows?
This requires understanding the relationship among three roles: the block hash, the Merkle root, and the parent hash.
The Block Hash Is a Hash of the Block Header
On chains such as Bitcoin, the block hash is usually an identifier obtained by hashing the block header, not by directly hashing the transaction list. This detail matters because it determines that transactions affect the block hash indirectly.
The transaction list is first compressed into a fingerprint through the Merkle root and written into the block header; then the entire block header is hashed to produce the block hash. So a change in transactions first changes the Merkle root, then changes the block hash. The causal direction is: transactions → Merkle root → block header → block hash.
If the causal direction is reversed—if someone thinks “the block hash is calculated directly from transaction content”—then the roles of other fields in the block header are omitted, and the chained relationship of the parent hash cannot be explained accurately.
The Parent Hash Makes Chained Tamper Resistance Work
Each block’s header records the hash of the previous block. Suppose an attacker modifies a transaction in block 9. This transaction change causes that block’s Merkle root to change, which in turn causes the block hash of block 9 to change. The parent hash recorded in block 10’s header is the original hash of block 9, and it now no longer matches. For block 10 to remain valid, the attacker must modify block 10’s parent hash, which changes block 10’s hash, which then affects block 11, and so on.
This is the effect of chained binding: the earlier the modification, the more subsequent blocks must be recalculated.
Immutability Is Computational, Not Absolute
Here we need to correct a common but overly absolute claim: blockchain content is “absolutely immutable.”
A more accurate statement is: tampering will break the matching of parent hashes and Merkle roots in subsequent blocks, so it is easily detected by nodes; however, under some consensus mechanisms, if an attacker controls enough hash power, chain reorganization can still occur. Therefore, blockchain immutability is more accurately computationally and probabilistically difficult to tamper with, not logically absolutely impossible to change. Understanding this point is necessary for having reasonable expectations about blockchain security boundaries.
Different Blockchains, Different Block Contents
A common misunderstanding is that all blockchains have the same block structure. In reality, block fields can differ greatly across chains.
Bitcoin and Ethereum, for example, have different block header fields. Bitcoin’s block header is relatively lean, containing fields such as version number, previous block hash, Merkle root, timestamp, difficulty target, and nonce. Ethereum’s block header contains a parent hash, state root, transaction root, receipts root, gas-related fields, timestamp, and so on; after the Merge upgrade, its block structure changed and it no longer relies on traditional PoW nonce.
Even when chains share a similar concept of “block header + transaction list,” they may define transaction ordering, execution, and state recording differently. Some chains may use different data structures, but most still keep a similar two-layer division.
To understand a particular chain’s block structure accurately, consult that chain’s protocol documentation rather than treating one chain’s field list as a universal template for all blockchains.
Quick Review: A Complete Mental Model of a Block
At this point, we can condense the internal structure of a block into a model worth remembering:
- Block = block header + transaction list. A block is not simply a collection of transactions.
- The block header is metadata, responsible for linking to the previous block, binding transaction integrity, and participating in consensus validation.
- The transaction list is content, recording user operations or state-change requests; a block usually packages multiple transactions.
- The Merkle root connects the transaction list and the block header; any transaction change changes the Merkle root and therefore indirectly changes the block hash.
- The parent hash connects the current block and the previous block, making tampering easy to expose and forming a chained tamper-resistant structure.
- The block hash is usually a hash of the block header; transactions affect the block hash indirectly through the Merkle root.
- Specific fields vary by chain, especially between PoW and PoS chains; one chain’s design cannot be treated as the universal structure of all blockchains.
If you remember only one sentence: the block header handles “linking and verification,” the transaction list handles “recording content,” and the Merkle root and parent hash bind these two layers and the entire chain together. Once you understand this structure, when you see block explorer pages for different chains, you can distinguish which fields are metadata and which are actual transactions, and you will no longer mistake a block for merely a transaction list.
