kevinferron.comKevin Ferron

T9 · Blockchain · Computed in your browser

Reading an explorer page

This site’s own block and transaction pages, built from a committed snapshot, with every field tagged and a recompute button wherever the chain can prove it.

An explorer page mixes values copied from the chain, values it computed from them, and values it added from elsewhere. Read a page knowing which is which.

The key, used on every row

  • Headerin the block header, which the block hash commits to
  • Transactionin the transaction the sender signed, or the receipt the node made by running it
  • Derivedcomputed from those by arithmetic or hashing: you can redo it
  • Off-chainadded by the explorer or someone else: the chain does not hold it

Block 26,255,759

Built from the committed snapshot, fetched 2026-10-23. Open any row.

Read it yourself

These four requests return what the panels above were built from. Send them to your own node, or any endpoint you trust, as JSON-RPC over HTTP POST. Then hash the header and compare.

  • The block (header fields, transaction hashes only)

    {"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x190a18f",false]}
  • Its parent, for the base fee

    {"jsonrpc":"2.0","id":2,"method":"eth_getBlockByNumber","params":["0x190a18e",false]}
  • The transaction

    {"jsonrpc":"2.0","id":3,"method":"eth_getTransactionByHash","params":["0x09a42b694a7c6af85d289c8ee503e8e1e1109e1487d9b3b51650e17343d345a5"]}
  • Its receipt

    {"jsonrpc":"2.0","id":4,"method":"eth_getTransactionReceipt","params":["0x09a42b694a7c6af85d289c8ee503e8e1e1109e1487d9b3b51650e17343d345a5"]}

Fetched once from a public Ethereum node on 2026-10-23 and committed to this site; nothing is fetched while you read, and this site’s checks recompute every hash in it.

Every field on an explorer page comes from one of four places, and the colour on each row says which. Green fields are in the block header, which the block’s hash commits to. Blue ones are in the transaction the sender signed or the receipt the node made by running it. Amber ones are computed from those by arithmetic or hashing, so you can redo them. Magenta ones are the explorer’s own additions: the chain does not hold them. Open any row for what it means, where it comes from and the node call that returns it.

A block’s hash is not a field in the block. Every node computes it as the Keccak-256 hash of the header’s encoding, and the Recompute button does exactly that to the committed header. The transaction hash is the same: the hash of the transaction’s encoded bytes. For a typed transaction those bytes are the type number followed by the payload.

The base fee in a header is set by the block before it. The target is half the gas limit. If the parent used exactly the target, the fee stays; if more, it rises by the parent’s fee times the excess over the target, divided by the target and by 8, and by at least one wei; if less, it falls by the same expression for the shortfall. The Recompute button on Base fee per gas does that with the committed parent and checks it against this block’s header. Fees are shown in wei, the smallest unit, and never converted to a currency.

What the sender paid is derived: the gas used times the effective gas price, which is the base fee plus the smaller of the sender’s tip cap and the room under their fee cap. Burnt fees for the block are its gas used times its base fee. The gas limit and the other block figures are as of the snapshot date, and the page shows them only from the committed block.

The “tokens transferred” list is built by reading logs. A log records which contract wrote it, a first topic that is the hash of the event’s signature, any indexed arguments as further topics, and the rest as data. For a standard fungible-token Transfer, the two indexed addresses are the sender and receiver and the data is the amount. The explorer cannot know a transfer happened, only that this contract said so: any contract can write any log. Amounts here are raw units; the token’s name and decimals are separate lookups, which is why those slots are magenta and empty.

The extra-data field holds up to 32 bytes the block’s builder chose to write. It is in the header, so it is certain that the block carried it, and nobody checks what it says. Read it as text only with the button; the text is whatever was written. The fee recipient and every address on these pages are shown shortened and unlabelled: nothing on chain says who owns an address.

A transaction’s status is in the receipt. A failed transaction is still in its block, and it still paid for the gas it used. The block tags latest, safe and finalized, in the strip under the transaction, say how settled a block is: latest is the most recent block, and finalized is one that validators have voted to finalise, with two consecutive checkpoints backed by two-thirds of the staked ether. This block was at or behind finalized when it was fetched.

Where the data comes from: the Ethereum block, its parent, one transaction and its receipt were fetched once, on 2026-10-23, from a public node endpoint, and committed to this site; nothing is fetched while you read. The transaction was chosen because the token transfer it logs runs between two contracts (the sender of any transaction is always an account). The Bitcoin tab uses a testnet3 block from Bitcoin Core’s test data. The numbers recompute when this site is checked, so none of it depends on trusting where it came from.

Exercise

Recompute a block hash and its base fee from your own node.

  1. Call eth_getBlockByNumber for a recent block and for its parent, with the second argument false.
  2. RLP-encode the header fields in order, hash the result with Keccak-256 and compare it with the block’s hash.
  3. Write the EIP-1559 base-fee rule from the parent’s gas used, gas limit and base fee, and check it against the block’s baseFeePerGas.

Sources

  1. ethereum.org: block explorers Block explorers (ethereum.org). page updated 2026-03-02.

    Read 2026-10-23: The field lists for block, transaction, account and token pages. The page names explorers; none is used here

    • The fields block, transaction, account and token pages show
  2. Explorer indexer docs Indexer architecture overview (documentation of an open-source block explorer). undated.

    Read 2026-10-23: Realtime and catch-up indexers; off-chain integrations for prices, verification and labels

    • Off-chain integrations: an explorer adds prices, verification and labels
  3. Ethereum yellow paper Ethereum: A Secure Decentralised Generalised Transaction Ledger (Gavin Wood). Shanghai version efc5f9a, 2025-02-04. Its section 4.4 lists 17 header fields; the blob, beacon-root and requests-hash fields are not in it.

    Read 2026-10-23: Section 3 (KEC is Keccak-256, not the final SHA-3), 4.4 (17 header fields, through baseFeePerGas and withdrawalsRoot), 4.4.1 (receipts and logs), Appendix B (RLP, titles)

    • Section 4.4: parentHash is the Keccak-256 hash of the parent’s header
    • Section 4.4.1: a log carries the address of the contract that logged it
    • Section 4.4: the header’s extraData and beneficiary
  4. EIP-2718 Typed Transaction Envelope (M. Zoltu). created 2020-06-13; Final.

    Read 2026-10-23: a transaction is TransactionType || TransactionPayload or a legacy transaction; the type is a number from 0 to 0x7f; the transactions trie holds those bytes

    • A transaction is the type followed by its payload; the type is a number from 0 to 0x7f
  5. EIP-1559 Fee market change for ETH 1.0 chain (V. Buterin, E. Conner, R. Dudley, M. Slipper, I. Norden, A. Bakhta). created 2019-04-13; Final.

    Read 2026-10-23: the constants (denominator 8, elasticity 2), the base-fee reference code, the Backwards compatibility note that the base fee is one additional item at the end of the header, the type-2 payload and signature, the effective gas price and the burn

    • The type-2 payload and what it contains
    • The base-fee reference code, the constants and the burn
    • The priority fee and effective gas price rules, and the burn
    • The base-fee reference code
  6. ERC-20 Token Standard (F. Vogelsteller, V. Buterin). created 2015-11-19; Final.

    Read 2026-10-23: Methods and events; the Transfer event; the optional name, symbol and decimals

    • The Transfer event
  7. Solidity: ABI specification Contract ABI Specification (Solidity docs, latest). read 2026-10-23.

    Read 2026-10-23: Function selectors and canonical signatures, static types in 32-byte words, events: topics[0] and indexed arguments

    • Events: topics[0] is the hash of the signature, indexed arguments follow in topics, the rest in data
  8. Solidity: introduction to smart contracts Introduction to Smart Contracts (Solidity docs, latest). read 2026-10-23.

    Read 2026-10-23: Logs and events; gas used before a revert is not refunded

    • Gas used before a revert is not refunded
  9. ethereum.org: JSON-RPC JSON-RPC API (ethereum.org). page updated 2026-06-28.

    Read 2026-10-23: Block tags (latest, safe, finalized), hex encoding of quantities and data, the methods an explorer calls, receipt fields

    • The block tags latest, safe and finalized
    • eth_getBlockByNumber and hex encoding
  10. ethereum.org: transactions Transactions (ethereum.org). page updated 2026-10-07.

    Read 2026-10-23: The transaction’s fields and types, the lifecycle (pending, included, safe, finalized), 21,000 gas for a plain transfer

    • The transaction lifecycle
  11. ethereum.org: proof of stake Proof-of-stake (ethereum.org). page updated 2026-10-07.

    Read 2026-10-23: 12-second slots, 32-slot epochs, finality when two consecutive checkpoints gather votes from two-thirds of the staked ether

    • Finality
  12. Bitcoin Core, blockfilters.json src/test/data/blockfilters.json, the BIP 158 test vectors, Bitcoin Core (MIT). tag v32.0, commit 465dde27. These are testnet3 blocks.

    Read 2026-10-23: each vector’s block height, block hash and full block bytes; the first 80 bytes of each are the header used here

    • The vectors’ block heights, block hashes and full block bytes
  13. ethereum.org: nodes and clients Nodes and clients (ethereum.org). page updated 2026-07-13.

    Read 2026-10-23: Execution and consensus clients; why run your own node

    • Running your own node

Everything here is paraphrased from the sources, not quoted at length, and every claim is attributed to one. Each entry says which parts of the source were read, and whether the build or the plan read them. Anything illustrative is labelled as such. Where a source is silent or could not be read, the page leaves the fact out.