Block Height
Number of blocks since genesis; position in the chain.
Block height is the numerical position of a block in a blockchain, usually measured from the genesis block at the beginning of the chain. Each accepted child block increases the height by one. Height provides a convenient reference for chain progress, but it does not uniquely identify a block or prove that the block is final.
Different conventions may count the genesis block as height zero, which is common, or describe chain length in a way that is one number higher. Documentation should clarify the convention. Two competing blocks can have the same height during a temporary fork, so a precise database record should include both block number and block hash.
Block height matters because blockchain time is organized by consensus events rather than only wall-clock timestamps. Software can request account state at a historical height, calculate how many blocks have followed a transaction, activate upgrades at a chosen block, or distribute rewards over defined ranges. Bitcoin halvings occur after a specified number of mined blocks, making the schedule predictable in height even though the exact calendar time varies.
Node operators compare local height with reliable peers or explorers to monitor synchronization. A node far behind may still be downloading or verifying history and should not serve time-sensitive application data. Matching tip heights are not sufficient by themselves because nodes could follow different hashes. Health checks should also examine peer connectivity, finalized or safe checkpoints, and whether new blocks continue arriving.
Height is not an exact clock. Block intervals vary under proof of work, and proof-of-stake networks may have missed slots or pauses. Estimating a date from average block time is useful for planning but not for deadlines requiring legal or operational precision. Smart contracts often use block numbers under protocol-specific assumptions, while applications should tolerate timing variation.
Confirmations are frequently calculated as the difference between the current canonical height and the transaction's block height, with conventions varying on whether inclusion counts as one. More confirmations generally lower reorganization risk, but the appropriate number depends on network security, consensus finality, transaction value, and threat model. Block height is best treated as a coordinate in chain history, supported by hashes and finality status when correctness matters.
Frequently asked questions
- No. Block height identifies position and shows chain progress, but finality comes from consensus rules. A recent block at a high height can still be reorganized. Applications should consider confirmations, finalized checkpoints, or other network-specific guarantees. Comparing heights also does not prove two nodes follow the same chain because competing blocks can share a height.
- Nodes may receive new blocks at different times, be syncing from history, lose connectivity, or follow competing chain tips. A small temporary difference is normal on many networks. A persistent gap can indicate a stalled node, wrong network, software problem, or chain fork. Compare peer count, synchronization status, block hash, and finalized height when diagnosing it.
- Use block height to reference an on-chain event, request historical state, measure confirmations, schedule protocol changes, or track node synchronization. Store the block hash with the height when records must survive reorganizations. Do not convert height to an exact wall-clock time using only average block intervals, because actual production can be early, late, or temporarily paused.