A block is the fundamental unit of a blockchain. While the concept appears simple—a container for transactions—the internal structure of a block is carefully engineered to provide security, verifiability, and efficient data retrieval. Understanding block anatomy is essential for anyone analyzing on-chain data or building blockchain infrastructure.
High-Level Structure
Every block consists of two primary components:
- Block header: A compact data structure containing metadata about the block, including cryptographic commitments to the block's contents.
- Block body: The actual payload—typically a list of validated transactions.
The block header is what gets hashed to produce the block's identity (its block hash). The header is deliberately kept small so that light clients can download and verify headers without processing the full block body.
Block Header Fields
While specific fields vary by protocol, most blockchain block headers contain the following elements:
Previous Block Hash
The 256-bit hash of the parent block's header. This field is what creates the "chain" in blockchain. It establishes a strict ordering: block N explicitly references block N−1, which references block N−2, all the way back to the genesis block (block 0). Changing any historical block would alter its hash, breaking the reference in the next block and every block thereafter.
Block Number (Height)
An integer indicating the block's position in the chain. The genesis block is block 0 (or 1, depending on the protocol). Block number provides a simple way to reference a block's depth and is used in various protocol rules, such as difficulty adjustments and reward schedules.
Timestamp
A Unix timestamp recording when the block was produced. Timestamps in blockchain are not perfectly accurate. They are set by the block producer and only loosely validated by the network. Most protocols require that a block's timestamp be greater than the median of the previous several blocks and not too far in the future. Timestamps are used for difficulty adjustments and time-based protocol logic.
Transactions Root (Merkle Root)
A 256-bit hash representing the root of a Merkle tree constructed from all transactions in the block. This single hash cryptographically commits to every transaction. Changing, adding, or removing any transaction would alter the Merkle root, making the change detectable.
State Root (Ethereum)
Unique to account-model blockchains like Ethereum, the state root is the root hash of a Merkle Patricia Trie that encodes the entire world state after all transactions in the block have been executed. This includes every account's balance, nonce, contract code, and contract storage. The state root allows any node to verify the complete state of the system at any block height.
Receipts Root (Ethereum)
The root hash of a trie containing the receipts of all transactions in the block. Each receipt includes the transaction's status (success or failure), cumulative gas used, and event logs emitted by smart contracts. The receipts root enables efficient proof of transaction outcomes.
Nonce
In proof-of-work systems, the nonce is a 32-bit integer that miners iterate over to find a block hash that satisfies the difficulty target. The mining process is essentially: "find a nonce such that hash(header_with_nonce) < target." In post-Merge Ethereum (proof-of-stake), the nonce field is set to 0x0000000000000000 and is no longer functionally relevant.
Difficulty / Difficulty Target
In proof-of-work chains, this field specifies how difficult it is to mine a valid block. Higher difficulty means miners must find a hash with more leading zeros. Difficulty adjusts periodically to maintain a target block time (e.g., ~10 minutes for Bitcoin, ~12 seconds for pre-Merge Ethereum).
Gas Limit and Gas Used (Ethereum)
The gas limit is the maximum amount of gas that all transactions in the block can collectively consume. The gas used is the actual gas consumed. Block producers can adjust the gas limit within protocol-defined bounds, and this mechanism controls the block's computational capacity.
Comparison: Bitcoin vs. Ethereum Block Headers
| Field | Bitcoin | Ethereum |
|---|---|---|
| Version / Protocol | 4-byte version integer | N/A (protocol version implicit) |
| Previous Hash | Yes (32 bytes) | Yes (32 bytes) |
| Merkle Root | Transaction Merkle root | Transactions, State, Receipts roots |
| Timestamp | Yes (4 bytes) | Yes |
| Difficulty | Encoded as "bits" | Explicit difficulty field |
| Nonce | 4 bytes | 8 bytes (legacy PoW) |
| State Root | Not present | Yes (world state trie root) |
| Gas Limit / Used | Not applicable | Yes |
| Base Fee | Not applicable | Yes (post-EIP-1559) |
Block Body: The Transaction Payload
The block body contains the ordered list of transactions included in the block. Each transaction carries its own data (sender, recipient, value, calldata, signature, etc.), and the full set of transactions is what the Merkle root in the header commits to.
In Bitcoin, the first transaction in every block is the coinbase transaction—a special transaction with no inputs that creates new bitcoin and pays it to the miner. In Ethereum, there is no equivalent coinbase transaction; instead, block rewards and priority fees are credited directly to the block producer's account via protocol logic.
Uncle (Ommer) Blocks
In pre-Merge Ethereum, the block header included references to uncle blocks (also called ommer blocks). These are valid blocks that were mined at the same height as the canonical block but were not included in the main chain because another block was propagated first.
Ethereum's protocol rewarded uncle block producers (at a reduced rate) and the main block producer (for including the uncle reference). This mechanism served two purposes:
- Fairness: Miners who produced valid but non-canonical blocks still received partial compensation, reducing the advantage of well-connected mining pools.
- Security: Including uncle references increased the effective hash rate contributing to chain security.
After Ethereum's transition to proof-of-stake (The Merge, September 2022), uncle blocks are no longer relevant as the slot-based block proposal system eliminates competing block production.
Key Takeaways
- A block consists of a compact header (metadata and cryptographic commitments) and a body (transaction payload).
- The previous block hash in the header creates the chain's chronological integrity; the Merkle root commits to the transaction set.
- Ethereum blocks are significantly more complex than Bitcoin blocks, containing state roots, receipts roots, gas accounting, and (historically) uncle references.
- Block headers are designed to be small enough for light clients to process, while the body carries the full transaction data for full nodes.