Block Header

A block header is the compact, 80-byte metadata component of a Bitcoin block that contains the essential cryptographic data linking it to the previous block and summarizing its contents. Its primary fields include the previous block hash, a Merkle root of all transactions, a timestamp, a nonce for Proof-of-Work, and the difficulty target. This structure allows any node to efficiently verify the chain's history without downloading every full block, enabling the security model of Nakamoto Consensus.

The cryptographic linkage is the header's most critical function. The previous block hash field creates an immutable chain, as altering any past block would change its hash, breaking the link to all subsequent blocks. The Merkle root provides a similar guarantee for the block's transactions; any change to a single transaction would alter this root, invalidating the header. This design enables Simplified Payment Verification (SPV), where lightweight clients can verify a transaction's inclusion by checking a Merkle path against a trusted block header.

For miners, the block header is the data structure they repeatedly hash during the Proof-of-Work (PoW) process. They modify the nonce and, in some protocols, the extraNonce via the coinbase transaction, to find a hash that meets the network's current difficulty target. The successful hash, which serves as the block's unique identifier, is then included as the previous block hash in the next block, extending the chain. This process makes reorganizing the blockchain computationally prohibitive.

While the 80-byte Bitcoin header is the canonical example, other consensus mechanisms use different header structures. Ethereum's block header, for instance, includes additional fields like a state root, receipts root, and logs bloom to support its account-based model and smart contract execution. However, the core principles of cryptographic linking (via parent hash), transaction summarization (via a root), and consensus-specific data remain universal across blockchain implementations.

A block header is the compact, 80-byte metadata section of a blockchain block that contains the cryptographic fingerprints and summary data necessary to validate the block's contents and link it to the chain. It acts as a unique identifier for the entire block, allowing nodes to efficiently verify the block's integrity and its position in the chronological sequence without processing every transaction. The header's fixed structure is fundamental to the proof-of-work consensus mechanism, as miners repeatedly hash this data to find a valid block.

The header contains several critical fields. The previous block hash is a cryptographic hash of the preceding block's header, creating the immutable chain. The merkle root is a single hash that cryptographically summarizes all transactions in the block. The timestamp, difficulty target, and nonce are essential for the mining process. This compact design enables Simplified Payment Verification (SPV) clients, like lightweight wallets, to verify transactions by checking headers and merkle proofs instead of storing the entire blockchain.

During mining, the header becomes the input for the hashing algorithm. Miners vary the nonce (and occasionally the timestamp and coinbase transaction) to generate different hash outputs, aiming to produce one below the network's difficulty target. This process, called hashing, secures the network. Once a valid hash is found, the header is broadcast, and other nodes can instantly verify the proof-of-work by hashing the provided header themselves and confirming it meets the required difficulty.

The block header's immutability is paramount. Changing any single transaction in the block would alter the merkle root, which in turn changes the block header's hash. This would break the link to the next block's previous block hash, invalidating the entire subsequent chain. This cryptographic interdependence is what makes blockchains tamper-evident. Forks occur when two valid blocks share the same previous block hash, but the chain with the most cumulative proof-of-work (the longest chain) is accepted by consensus.

Beyond Bitcoin, the block header concept is adapted in other protocols. Ethereum's header includes a state root and receipts root to summarize global state and transaction outcomes, supporting its smart contract platform. Understanding the header is key for developers working with blockchain data, as it is the primary structure queried by APIs for block information and is essential for implementing or analyzing consensus algorithms, network forks, and blockchain explorers.

The block header's core fields are fundamental to achieving distributed consensus. The previous block hash creates the immutable chain of blocks, while the Merkle root provides a cryptographic fingerprint of all transactions within the block. The timestamp and nonce (or other consensus-specific fields) are critical for Proof-of-Work or Proof-of-Stake validation. During block propagation, nodes primarily share and verify headers first, enabling rapid synchronization and integrity checks before downloading full block data.

In chain selection, often called the "fork choice rule," the block header is the unit of comparison. For Bitcoin's Nakamoto Consensus, the rule is "longest chain," meaning the valid chain with the greatest cumulative proof-of-work, calculated by summing the difficulty implied by each header. For Ethereum's Gasper protocol, the fork choice considers the attestations (votes) embedded in block headers to identify the canonical chain. Nodes use these rules to independently select the single valid history from competing forks.

Light clients and simplified payment verification (SPV) rely entirely on block headers. By downloading and verifying the header chain, they can cryptographically prove that a transaction is included in a block without storing the entire blockchain. This is possible through Merkle proofs that link a transaction to the Merkle root in the header. The header's compact size (typically 80 bytes for Bitcoin) makes this efficient, enabling trust-minimized verification for resource-constrained devices.