Ethereum Block Number: Reading Height, Hash, and State

An Ethereum block number specifies a block height. A block hash is derived from block data, while a timestamp describes the block’s time. These fields answer different questions, even when they appear together in the same record.

The distinction becomes useful when reading account state. A balance request needs more context than an address: its block parameter determines the requested height. Choosing an explicit number makes that selection visible, so a later reader can understand which height the request concerned.

Block number and block hash describe different things

For state queries, Ethereum’s JSON-RPC documentation describes the block parameter as determining the block height. A number therefore serves as a height selection. The block hash has a different relationship to the record: it is cryptographically derived from block data.

The documented JSON-RPC block object represents its hash as 32 bytes. There is an explicit exception for pending blocks, where the hash field is null. Keep that exception attached to the field definition rather than expecting every block-shaped response to contain a populated hash.

When reviewing a record, label the number and hash separately. A useful question beside the number is, which height was selected? Beside the hash, ask, which block hash did this response report? This keeps the two roles visible without turning a height into a promise of irreversible block identity.

The primary explanation of the hash’s relationship to block data is in Ethereum’s blocks documentation. Here, the purpose of that relationship is to distinguish the fields, rather than to provide a guide to confirmations or finality.

Why a timestamp differs from a height

The block object’s timestamp field reports the Unix timestamp for when the block was collated. It describes block time, rather than the height selected by a state query. It should also remain separate from a note recording when you retrieved the response.

Ethereum divides time into twelve-second slots. However, the documentation explains that slots can be empty when validators are offline when called to propose a block. Twelve-second slots consequently do not establish a twelve-second interval between every pair of produced blocks.

A limited deduction follows from those two premises: multiplying a block count by twelve seconds is not guaranteed to recover a block’s timestamp. This does not mean every interval differs, and it does not supply an alternative timestamp reconstruction formula. For a reading exercise about a particular block, keep its reported timestamp alongside its number instead of replacing one with a fixed-interval estimate.

Selecting a height for a state query

The block parameter accepts an integer block number encoded as a hexadecimal string. JSON-RPC quantities use compact hexadecimal encoding with a 0x prefix. In the hypothetical examples below, decimal height 1,024 is written as 0x400.

The tag latest instead selects the latest proposed block in the answering node’s context. Separately, eth_blockNumber returns the current block number the client is on. Treat that as a client-relative observation, rather than an independently established network-wide reading.

These definitions support another deduction: retaining an explicit integer parameter preserves the requested height across queries, whereas repeating latest repeats a relative selection. The conclusion concerns the request’s height. It does not guarantee immutable block identity, identical answers, or that two selected heights will produce different values.

The method descriptions and parameter conventions appear in Ethereum’s JSON-RPC documentation. That evidence establishes the selection mechanism; this explanation does not establish which historical heights a particular provider can serve.

Separate the block record from the state question

eth_getBlockByNumber returns information about a block selected by number. Use that method’s role to distinguish a request for the block record from a request for an account’s balance at a selected height.

eth_getBalance returns the balance of the account at the specified address. Its result belongs with both that address and the selected block parameter. It is not a general token-balance method, so the example here remains an account-balance reading exercise.

For contract queries, eth_call is also among the methods with a block parameter. It executes a message call without creating a transaction on the blockchain. That describes how the call is performed; it does not guarantee that an arbitrary call will return successfully.

For a related discussion of query context, see the published guide to Ethereum account nonce and transaction-count records. The focus here remains selecting and recording the height.

A hypothetical pair of query records

Imagine an educational worksheet for one stipulated network and Account A. Every value in this example is invented. No request was executed, and the worksheet is not a report of live account data.

  • Record A: method eth_getBalance; address Account A; block parameter 0x400, meaning decimal height 1,024; result left blank.
  • Record B: method eth_getBalance; address Account A; block parameter latest; result left blank.

Record A asks for the account balance with an explicit height selection. Record B asks with the latest proposed block selection. Leaving the results blank helps isolate the mechanism: the requests have different selection instructions before any numerical answer is considered.

Now stipulate a separate block-record entry for height 1,024, with spaces for the returned hash and timestamp. Keep those fields separate from the balance response. This organization connects the worksheet’s height, block record, and state question without treating the timestamp or hash as another spelling of the height.

If the worksheet is revisited, preserve the original parameters and record any new observation separately. The example does not assume that results must differ, that historical queries will be available, or that retaining a height guarantees an unchanged block identity.

A checklist for interpreting a recorded query

  1. Label the block number, block hash, and timestamp separately.
  2. Write down the method and the account or call inputs being examined.
  3. Preserve the exact integer block parameter or relative tag.
  4. When displaying a hexadecimal height in decimal, keep the correspondence clear.
  5. Distinguish a block-information response from a state-query response.
  6. Keep the requested height separate from claims about provider availability or immutable identity.

Educational material prepared with AI assistance. The worksheet is hypothetical and illustrates how to read query context.