The analyst's view of a blockchain

Every on-chain finding rests on data that someone retrieved, decoded and interpreted. An analyst who cannot say which node produced the data, which software decoded it and whose labels were applied cannot defend a finding when a colleague, an auditor or a court asks how it was reached. This lesson maps where blockchain data comes from and what each layer adds, so that you choose sources deliberately and can reproduce your own results.

Three layers of blockchain data

Blockchain data comes in three layers, each built on the one below.

Raw node data is the ground truth: every honest full node that follows the same chain returns the same bytes for the same block hash. Decoded data is only as reliable as the decoder: an address derived from a script, or a token amount derived from an event, depends on the decoder knowing the script type or the contract's interface (its ABI). Enriched data adds judgment: prices come from a chosen market, labels from a chosen source, clusters from chosen heuristics.

The higher the layer, the more useful the data and the more assumptions it carries. A working rule: every claim in a report must be traceable down to raw data, and every assumption added on the way up must be written down.

Full nodes, archive nodes and what they can answer

A full node downloads and validates every block. What it can answer depends on what it keeps and indexes.

• Bitcoin Core keeps all blocks unless pruning is enabled and returns any block by hash or height. To look up an arbitrary confirmed transaction by txid it needs the optional transaction index (txindex=1); without it, it finds only mempool transactions or transactions in a block you name. Bitcoin Core has no address index: it cannot list the history of an address. Address lookups need a separate indexer (open-source examples include Electrs, Fulcrum and Esplora).
• Ethereum execution clients (Geth, Nethermind, Besu, Erigon, Reth) keep blocks, transactions and receipts, but a default full node keeps the state (balances, contract storage) only for recent blocks. Geth's default path-based storage, for example, keeps one full copy of the state on disk for the block 128 blocks behind the head, plus in-memory changes for the newer blocks, so it can answer state queries for roughly the latest 128 blocks only. Asking such a node for a balance as of a block from last year fails. An archive node keeps historical state for every block and is needed for historical balance queries, contract calls against old blocks and most tracing of old transactions.

History itself is also shrinking on default nodes. Since July 2025 all major Ethereum execution clients support partial history expiry under EIP-4444: a node can drop block bodies and receipts from before the Merge (September 2022) while keeping every header. A node configured that way cannot serve a 2019 receipt. Analysts who need early history must use a node that keeps it or a published history archive.

RPC providers and indexers

Running nodes costs disk, time and maintenance, so most analysts use one of two shortcuts.

RPC providers run nodes and expose the standard interfaces (Bitcoin Core RPC, Ethereum JSON-RPC) over the internet. They are convenient, but you inherit their configuration (full or archive, which client, which methods are enabled), their rate limits and their errors. The lesson Node APIs and data access covers how to use and check them.

Indexers read node data continuously and write it into a database shaped for queries: one row per transaction, output, log or trace. Some index everything (the ETL pipelines that feed public datasets); others index one protocol (a subgraph that tracks a single lending market). Indexers answer questions a node cannot answer quickly, such as "every Transfer event involving this address over five years," but they add a dependency: their decoding logic, their handling of reorganizations and their freshness.

Block explorers versus data warehouses

A block explorer is an indexer with a web interface. It is the right tool for a first look: confirm that a transaction exists, check its status, read its decoded events. It is the wrong tool to rely on alone, for three reasons. Its decoding and labeling methods are rarely documented to the level a report needs. Its views change over time, so a label added this year appears on transactions from years ago. And explorers disagree with each other on derived figures such as "internal transactions," token balances or the address shown for a non-standard script.

A data warehouse (a columnar database holding indexed chain data) is the right tool for questions about many transactions: totals, time series, every counterparty of a cluster. Its tables are only as good as the ETL that filled them, so warehouse results are checked against a node for a sample of rows. The lesson The analytics data stack compares warehouse options.

A sound workflow combines the three: an explorer for orientation, a warehouse for scale and a node to verify the specific transactions a finding depends on.

A worked example: one question, three answers

An analyst is asked how much ETH the address 0xA1b2…9F received in March 2025. Three sources give three numbers:

• An explorer's transaction list totals 41.20 ETH.
• A warehouse query on the transactions table totals 41.20 ETH.
• A warehouse query that adds value moved by internal calls, from the traces table, totals 53.70 ETH.

None of the sources is wrong. The first two count only top-level transactions in which the address was the to field. The extra 12.50 ETH arrived through contract calls, here a withdrawal from a smart-contract wallet, which appears only in traces. A fourth answer would appear if wrapped ETH (WETH) were included: WETH is a token and shows up only in event logs. A careless fifth answer would count value from calls that reverted, which traces also record but which moved nothing.

The point is not that one number is right. The question must be pinned to a data definition: which layer, which tables, which block range, which asset. "53.70 ETH received as native value in blocks X to Y, including successful internal transfers and excluding WETH" is an answer another analyst can reproduce.

Reproducibility as the analyst's first duty

Reproducibility means that another competent analyst, given your notes, obtains the same result. Blockchain data makes this unusually achievable, because the raw layer is public and does not change once final. What breaks reproducibility is everything around it:

• Moving targets. "Latest" changes every few seconds. Anchor every query to a block height and record that block's hash.
• Unrecorded sources. Note the node or provider, the client and its version, and the dataset and table version.
• Unrecorded transformations. Keep the exact query or script, including filters and unit conversions.
• Mutable labels. Record each label's source and the date you read it; labels get revised.
• Unfinalized data. Recent blocks can be replaced; see the lesson Blocks and headers as data.

Treat these as habits, not paperwork. A finding that rests on "the explorer said so last Tuesday" cannot be checked; a finding that rests on a named block hash, a saved query and a recorded client version can be checked by anyone with a node. The lesson Data quality, normalization and provenance turns these points into a provenance record you can attach to every dataset.

Exam focus: the three data layers (raw, decoded, enriched or labeled) and the assumptions each adds; what a Bitcoin full node can answer, the role of txindex and the absence of an address index; Ethereum full versus archive nodes and why historical state needs an archive node; partial history expiry (EIP-4444) and pre-Merge data; strengths and weaknesses of RPC providers, indexers, explorers and warehouses; why native, internal and token transfers give different totals; and anchoring every query to a block height and hash for reproducibility.