Block ID

Overview

Most blockchains derive a block identifier from cryptographically encoded block data. In Bitcoin, the block header hash identifies the block and binds fields such as the previous block hash and Merkle root. Ethereum APIs expose a block hash together with the parent hash, block number, transaction root, state root, and receipt root. Other protocols can use signed headers or composite identifiers, so the exact calculation is network-specific.

Block ID is more precise than block number. Two Competing Chain branches can contain different blocks at the same height, and a reorganization can replace the block previously associated with a number. Applications that store only “transaction confirmed at block 100” may fail to detect the replacement. Storing the actual identifier allows software to verify that the same block remains in the Canonical Chain.

An identifier can be valid for a noncanonical, stale, or maliciously supplied block. Light clients and payment systems must verify parent links, consensus evidence, and the node’s current chain view. The hash also does not make the complete block data available. A service can provide a genuine block ID while omitting transactions or returning an incomplete interpretation. Verification requires the relevant header, proofs, or full data under the protocol’s rules.

Operational records should pair every transaction inclusion with block ID, block number, timestamp, and confirmation or finality state. When an API returns a null block hash for pending data, systems should not invent a stable reference. After a reorganization, the old block ID should remain in audit history with a noncanonical status. This preserves evidence of what the system observed and why a previous settlement decision may have changed.