A blockchain ledger has a seemingly simple but critical question: when many people jointly maintain the same ledger, how does everyone know ‘which page we have reached’? Without a unified sequential reference, each participant may have a different view of transaction order, and the final ledger state cannot reach consensus.

Block Height exists precisely to solve this problem. It gives each block a linear position number, allowing all participants to use the same standard to identify ‘this is the nth block on the chain.’ But this numbering mechanism also has its boundaries—especially when the chain forks. This article starts with ‘why order is needed,’ then explains what block height is, how it is produced, how it is used for transaction confirmation, and why the same height does not necessarily correspond to the same block.

Why a Blockchain Needs an Order

A blockchain is not a database maintained by a single institution. It is jointly maintained by multiple nodes distributed across the network, with no ‘administrator’ responsible for deciding where the next record is written or when to turn the page.

This means all participants must agree on transaction order. Transaction order directly affects the final ledger state. For example, whether the same balance is first transferred to A or first to B produces a completely different result. If nodes have no consensus on order, the balances, contract states, and account histories they calculate will be inconsistent, and the entire chain will lose its foundation of trust.

A block is the unit in which transactions are packaged. Each block contains a batch of transactions, and blocks are connected in order to form a chain. Numbering blocks is essentially numbering each page of the ledger—with page numbers, everyone can know where the current record has reached, what the before-and-after relationships are, and which page a specific record is on.

Without a stable block order, nodes cannot agree on which chain is currently valid.

An analogy can help: suppose there is a ledger jointly maintained by multiple people, and everyone can record transactions on it. If the ledger has no page numbers and everyone records separately, it quickly becomes impossible to determine who came first and which record is ‘the latest.’ With page numbers, everyone can point to the same page and say ‘this is page 100,’ greatly reducing coordination costs. Of course, a real blockchain is more complex than a ledger—ledger page numbers usually do not have two different ‘page 100s,’ while a blockchain can indeed have this situation during a fork, as explained later.

What Block Height Is: Numbering Starting from the Genesis Block

Block height is a linear number for a block’s position on the chain. It answers the question: which block is this on the chain?

The Genesis Block Is the Starting Point of Numbering

Every blockchain has a Genesis Block, the first block created on the chain. In mainstream blockchains such as Bitcoin and Ethereum, the genesis block height is usually set to 0. Each subsequent new block has a height one greater than the previous block.

For example, Bitcoin’s genesis block height is 0, the first block immediately after it has height 1, the second has height 2, and so on. So the genesis block itself is not ‘height 1’—it is starting point 0, and subsequent blocks increase from 1.

Note: different blockchains may not have exactly the same convention for genesis block height. This article describes common practice on mainstream chains; for a specific chain, its protocol documentation should be authoritative.

Height Can Represent the Length of the Chain

If the genesis block height is 0, then the total number of blocks on the chain (i.e., chain length) equals the latest block height plus 1. For example, if the current latest block height is 999, there are 1000 blocks on the chain (from height 0 to height 999).

Height Only Represents Position, Not Content

This is where beginners most easily get confused: block height only tells you the position on the chain, not what is in the block.

To uniquely determine the content of a specific block, you need the Block Hash. A block hash is a fingerprint calculated from the block’s content; different block content produces different hash values. The same height may have different hashes; if the hash is the same, the block content is identical.

You can think of height as ‘which page’ and hash as ‘the unique fingerprint of what is written on that page.’ The two answer completely different questions.

How Height Is Produced and Grows

Now that we understand what height is, the next natural question is: who numbers the blocks? Who decides the rules?

Answer: No central institution assigns block heights. Height is not a number uniformly issued by an administrator; it is a natural result of the blockchain’s chain structure.

New Blocks Extend the Chain by Referencing the Parent Block

Each new block includes the hash of the previous block as a reference. This reference relationship links blocks one after another, forming a chain. When a new block is accepted by nodes in the network, its height naturally becomes the parent block’s height plus 1.

For example, if the previous block’s height is 500, then a newly produced valid block that references it has height 501. No one needs to approve or assign this number—it is a direct consequence of the chain structure.

Nodes Judge Validity According to Consensus Rules

Although height is not centrally assigned, not just any block can be accepted. Nodes verify whether a new block is legal according to consensus rules: whether the parent block it references is valid, whether transactions in the block are legal, and whether it meets other protocol requirements of that chain. Only blocks that pass verification are accepted by nodes and extend the chain.

Whether a chain uses Proof of Work (PoW) or Proof of Stake (PoS), the numbering logic for block height is built on the same foundation: a new block references the previous block and thereby obtains the position of ‘parent block height plus 1.’ The specific consensus process does not affect the basic rules of height numbering; this article does not go into the details of consensus algorithms.

Block Height in Transaction Confirmation: Why We Say ‘3 Blocks Have Passed’

The place where ordinary people most easily encounter block height in practice is transaction confirmation. When you hear ‘this transaction has 6 confirmations,’ the calculation behind it is actually based on block height.

How to Calculate the Number of Confirmations

After a transaction is packaged into a block, the height of its block is fixed. Suppose:

• The transaction is packaged into a block at height N.
• The current latest block height on the chain is M.

Then the number of confirmations this transaction usually receives equals:

M – N + 1

Why add 1? Because the block containing the transaction itself also counts as one confirmation. That is, the block containing the transaction plus every block extending after it together make up the confirmation count.

A Numerical Example

Suppose a transaction is packaged into a block at height 100. The current latest block height is 105.

Confirmations = 105 – 100 + 1 = 6.

This means that after the block containing the transaction, 5 new blocks have extended (heights 101, 102, 103, 104, 105), plus the block containing the transaction itself (height 100), for a total of 6 confirmations.

This calculation only holds on a single canonical chain without reorganization. If the chain undergoes a reorganization, the result may change; the reasons are explained later.

Meaning and Limits of Confirmation Count

The confirmation count indicates how many blocks have extended after the block containing the transaction. More confirmations usually mean that if an attacker wants to rewrite this history, they must pay a higher cost—because to replace or roll back the block containing the transaction, the attacker needs to recompute the work or consensus proof for that block and all blocks after it.

But it must be clear: this is probabilistic security, not an absolute guarantee. More confirmations increase the difficulty of reorganization, but no confirmation count guarantees ‘absolute irreversibility.’ Different blockchains have different security models and finality rules; some chains are designed so that once a block meets certain conditions it is considered final, while others rely on probability accumulation. This article does not go into the specific differences among chains’ finality mechanisms, but readers should remember: confirmation count is a risk reference, not an absolute mathematical promise.

Moreover, if a chain reorganization occurs, the block containing the transaction may be replaced, and the confirmation count may decrease or even drop to zero. This is why understanding block height requires also understanding that ‘the same height does not necessarily correspond to the same block.’

Does the Same Height Always Mean the Same Block?

This is the most easily misunderstood part of the block height concept. Many beginners naturally assume: if height is a unique number, then height 100 always points to the same block. This understanding is roughly true under normal circumstances, but not correct during forks and reorganizations.

During a Fork, Competing Blocks at the Same Height May Appear

A blockchain is a distributed system. Different nodes may almost simultaneously produce or receive different valid blocks; these blocks may reference the same parent block and therefore have the same height. For example, two participants almost simultaneously discover valid blocks at height H, and for a short time two blocks at height H exist in the network at the same time.

This does not violate consensus rules—they both reference valid parent blocks and contain legal transactions. At this point, different nodes may temporarily see different ‘latest blocks.’

The Network Eventually Converges on a Canonical Chain

Over time, nodes choose a canonical chain according to consensus rules. Usually, the rule selects the chain with the greatest cumulative work or one that meets specific finality conditions. Other competing blocks are orphaned and are not on the canonical chain.

But the key point is: before convergence, the same height may correspond to multiple candidate blocks. After convergence, a given height usually corresponds to only one block on the canonical chain, but this is not because height itself is unique; it is because the network has already chosen that chain.

Reorganization Changes the Block Corresponding to a Height

If the chain undergoes a reorganization, a block previously considered on the canonical chain may be replaced by another block. At that point, the block pointed to by a certain height has changed. Transactions previously packaged at that height may be repackaged into other blocks or return to a pending state.

Therefore, the same height does not mean the same block. Only a block hash can uniquely determine the content of a specific block. Height represents ‘position on the chain,’ and this position may be occupied by different blocks on different chains or at different times.

This point is crucial for understanding transaction confirmations and ‘rollbacks.’ When you see ‘6 confirmations,’ it means that on the current canonical chain, 5 new blocks have extended after the block containing the transaction. But if a reorganization occurs, this confirmation count may decrease, and the block containing the transaction may also change.

Where Block Height Actually Appears

Block height is not an abstract concept; it appears in many real products and development scenarios.

Block Explorers

Block explorers allow users to query blocks by height. Enter a height number, and the explorer jumps to the corresponding block’s detail page, showing on-chain data such as the block hash, included transactions, parent block information, and timestamp. This is the most intuitive way to query ‘height to block.’

Note that a block explorer displays data from the chain it sees. If a reorganization occurs, the same height may show different blocks in the explorer.

Wallets and On-Chain Services

Wallets and on-chain services can use block height to synchronize transaction status, display confirmation counts, or set checkpoints. For example, a wallet might record that ‘a certain transaction is in the block at height 100,’ and then update the displayed confirmation count as the latest height grows.

Developer APIs

Blockchain APIs commonly used by developers usually support querying blocks by height range or subscribing to height changes of new blocks. This allows developers to build applications such as block explorers, monitoring tools, and transaction status trackers.

Ordinary users do not necessarily need to actively memorize block heights, but understanding them helps make sense of confirmation status in wallets, data on block explorers, and news mentions that ‘a certain transaction was confirmed in a certain block.’

Summary

Block height is a positional number assigned to each block in order, starting from the genesis block. Mainstream blockchains usually set the genesis block height to 0, and each subsequent block adds 1 to its parent block’s height. This numbering is not assigned by a central institution; it is a natural result of the chain structure—a new block references its parent block and thereby obtains its position.

Height allows distributed participants to consistently identify the order on the chain, calculate transaction confirmations (current latest height minus the transaction’s block height plus 1), and locate blocks in block explorers and development scenarios.

But height only represents position, not content. The block hash is the unique fingerprint of block content. During forks and reorganizations, the same height may correspond to different competing blocks, so height alone cannot absolutely locate a unique block. Transaction confirmation counts provide a probabilistic security reference; more confirmations increase the difficulty of reorganization, but they are not an absolute guarantee of irreversibility.

Understanding block height is essentially understanding how blockchain uses simple linear numbering to establish a collaborative sequential reference in a distributed environment—and also understanding the boundaries of this reference in fork scenarios.