Answers>Learn about indexing & blockchain data>How to access historical blockchain data
Como acessar dados históricos da blockchain
// Tags
historical blockchain dataarchive data
TL;DR: Accessing historical blockchain data requires either an archive node (which stores every state snapshot from genesis) or a data backfilling tool that retrieves and stores past blocks in a queryable database. Standard full nodes only retain the most recent 128 blocks of state data and prune everything older, so querying a wallet's balance from six months ago on a full node will fail. The two main approaches are archive node RPC access for point-in-time state queries and streaming backfills for building comprehensive historical databases.
A Explicação Simples
Blockchains record every transaction that has ever occurred, but that does not mean every piece of historical data is easily accessible. The distinction lies between transaction data and state data. Transaction data (the record of who sent what to whom, which contracts were called, which events were emitted) is permanent and available in every block. State data (the balances, storage values, and contract states at any given moment) is a different story.
Full nodes, which are the standard nodes most RPC providers operate, store the complete history of blocks and transactions but only maintain the current state and a rolling window of recent state snapshots (typically the last 128 blocks on Ethereum, roughly 25 minutes). They prune older state data to conserve storage. This means a full node can tell you what transactions happened in block 15,000,000, but it cannot tell you what a wallet's balance was at block 15,000,000 unless that block falls within the recent retention window.
When your application sends an RPC call like "eth_getBalance" with a historical block number to a full node, the node returns a "missing trie node" error because the state data for that block has been pruned. This is the most common surprise developers encounter when first working with historical data. The blockchain "remembers" everything in the sense that all transactions are recorded, but recovering the state at an arbitrary point in history requires special infrastructure.
Qual é a diferença entre um nó completo e um nó de arquivo?
The fastest way to understand historical data access is to compare the two node types most providers run. A full node keeps the complete history of blocks and transactions but prunes old state, while an archive node keeps every historical state snapshot. If you only need recent data, a full node is cheaper and faster, but point-in-time historical state queries require an archive node. For a deeper breakdown, see our guide on full node vs archive node and the overview of what a blockchain node is.
Capacidade
Nó completo
Nó de arquivo
Retenção estatal
Últimos ~128 blocos (cerca de 25 minutos na rede Ethereum)
Todos os estados, desde o início até ao mais recente
Espaço ocupado pelo armazenamento
Cerca de 1 TB na Ethereum
12 TB ou mais na Ethereum
Consultas sobre o estado histórico
Falha com um erro de nó em falta na árvore trie
Retorna o estado em qualquer altura de bloco
Custos de funcionamento
Mais baixo
Significativamente mais elevado
Ideal para
Saldos atuais e atividade recente
Auditorias, declarações fiscais, análise forense, análise de dados
Archive Nodes for Point-in-Time Queries
Archive nodes solve the state pruning problem by retaining every state snapshot from the genesis block forward. An Ethereum archive node stores 12TB+ of data compared to roughly 1TB for a full node, making it significantly more expensive to run and maintain. But it enables a critical capability: querying the exact state of any account, contract, or storage slot at any historical block height.
Isto é essencial para uma série de casos de utilização. A auditoria financeira exige a reconstrução dos saldos das contas em datas específicas. A declaração fiscal precisa de determinar o valor dos ativos detidos no final do ano. A análise forense rastreia o flow fundos através das transições de estado históricas. A depuração de contratos inteligentes utiliza o estado histórico para reproduzir e analisar erros ou vulnerabilidades passadas. A análise de protocolos DeFi calcula o TVL, o APY e outras métricas históricas, consultando os estados dos pools em alturas de bloco passadas.
Running your own archive node is resource-intensive. The initial sync takes weeks, storage costs are high, and the node requires ongoing maintenance, client updates, and monitoring. Most teams access archive data through infrastructure providers rather than running their own nodes. When evaluating providers, the key consideration is whether archive access is included in your plan or charged as a premium add-on, and whether the provider supports archive data across all the chains your application needs.
How far back can you query historical blockchain data?
With an archive node you can query the state of any account, contract, or storage slot all the way back to the genesis block. Transaction and event data is available from every block even on a standard full node, but historical balances and contract storage are only recoverable from an archive node. This distinction matters when you decide whether you need point-in-time state or a full record of past activity, a tradeoff we cover in real-time vs historical blockchain data. If your queries keep failing, it is usually because the request reached a full node, which is why understanding how RPC requests work helps you route them correctly.
Preenchimento contínuo de bases de dados históricas
Archive nodes answer point-in-time state queries, but many historical data use cases require something different: a complete, queryable database of past blocks, transactions, event logs, and traces. Building a blockchain analytics dashboard, a token transfer history API, or a comprehensive block explorer requires processing and storing historical block data in a structured database, not just querying an archive node on demand.
A abordagem tradicional para criar esta base de dados consiste em escrever um script que percorra os blocos um a um, recupere os dados de cada bloco através de RPC, descodifique as transações e os registos e insira os resultados na sua base de dados. Isto funciona, mas é extremamente lento e frágil em grande escala. Preencher o histórico completo Ethereum(mais de 20 milhões de blocos) através de chamadas RPC sequenciais pode demorar semanas ou meses. O script tem de lidar com a limitação de taxa, falhas de ligação, tempos de espera dos nós, novas tentativas e ordenação dos blocos. Se o script falhar a meio do processo, é necessária uma lógica para retomar a partir do ponto em que parou, sem criar lacunas ou duplicados nos dados.
As ferramentas de preenchimento retroativo baseadas em «push» resolvem estes problemas operacionais, ao gerir a complexidade da infraestrutura do lado do fornecedor. Basta especificar um intervalo de blocos, selecionar os conjuntos de dados necessários (blocos, transações, recibos, rastreios, registos), aplicar filtros (opcionalmente) e o sistema envia os dados para o seu destino com entrega garantida, ordenação correta e nova tentativa automática em caso de falha. Assim que o preenchimento histórico estiver concluído, o mesmo pipeline pode passar para a transmissão em tempo real, de modo a manter a sua base de dados atualizada à medida que novos blocos são produzidos.
Quanto tempo demora o preenchimento de dados históricos?
O tempo de preenchimento depende da cadeia, do intervalo de blocos e dos conjuntos de dados solicitados. Um script sequencial que recupera blocos um de cada vez através do RPC padrão pode demorar semanas ou meses a cobrir 20 milhões de blocos, e tem de gerir por si próprio as tentativas de repetição, a ordenação e a retoma. Os preenchimentos geridos baseados em envio em massa paralelizam o trabalho e podem ser concluídos até sete vezes mais rapidamente, com estimativas de custo e conclusão apresentadas antes de iniciar. A largura de banda da sua infraestrutura RPC subjacente é o principal fator limitante para qualquer abordagem «faça você mesmo».
Outros métodos para dados históricos
O Graph e outros protocolos de indexação fornecem dados históricos pré-indexados para contratos inteligentes específicos através de subgráficos. Se alguém já tiver implementado um subgráfico para o protocolo do qual precisa de dados (como o Uniswap, o Aave ou o Lido), pode consultar os dados históricos através da respetiva API GraphQL sem ter de criar o seu próprio pipeline. A limitação é que os subgráficos são específicos de cada contrato e de cada esquema, pelo que só é possível consultar o que o autor do subgráfico decidiu indexar.
Third-party data providers like Dune Analytics, Flipside Crypto, and Nansen maintain comprehensive historical databases across major chains and expose them through SQL interfaces or APIs. These are convenient for analytics and research but introduce dependency on a third party's data freshness, accuracy, and availability. For production applications that need to own their data pipeline, building on top of raw blockchain data (via archive nodes or backfill streams) provides more control and reliability.
Os exploradores e as APIs específicas de cada cadeia (como a API do Etherscan) oferecem outra forma de aceder a dados históricos, mas, normalmente, impõem limites de taxa rigorosos nos planos gratuitos e podem não proporcionar a granularidade ou a exaustividade que as aplicações de produção exigem.
Which method should you use to access historical blockchain data?
There is no single best method: the right choice depends on whether you need point-in-time state, a full queryable database, or pre-aggregated analytics. The table below summarizes the main options. If your goal is efficient repeated access rather than one-off lookups, compare RPC vs indexing and review what blockchain indexing is before committing, since querying blockchain data at scale is harder than it first appears.
Método
Ideal para
Principal limitação
Nó de arquivo RPC
Estado num momento específico em qualquer bloco
Não é uma base de dados em massa
Preenchimento por streaming
Criação de uma base de dados completa e pesquisável
Requer um destino para armazenar os dados
Protocolos de indexação e subgrafos
Dados históricos específicos do contrato
Limitado ao que foi indexado
APIs de dados de terceiros
Análise e investigação
Dependência de um fornecedor
APIs do explorador de blocos
Pesquisas rápidas
Limites de taxa rigorosos e granularidade limitada
Como Quicknode acesso a dados históricos
Quicknode includes archive node access across all plans, eliminating the need to manage or pay separately for archive infrastructure. Every Quicknode RPC endpoint can serve historical state queries at any block height, from the genesis block to the latest. Quicknode's QRoute technology automatically routes historical state requests to archive nodes and current-state requests to full nodes, delivering both through a single endpoint URL with no configuration required.
Para a criação de bases de dados históricas, Quicknode Streams fornece modelos de preenchimento retroativo com um clique que lhe permitem preencher a sua base de dados com o histórico completo da cadeia em mais de 20 redes. Basta selecionar a cadeia, o tipo de conjunto de dados (blocos, transações, recibos, rastreios ou combinações «tudo-em-um») e o destino (PostgreSQL, Snowflake, Amazon S3, Azure Storage, webhooks), e Streams os dados com entrega garantida, ordenação correta dos blocos e lógica de repetição integrada. As estimativas de custo e tempo de conclusão são apresentadas antes de iniciar, proporcionando-lhe total transparência. Os preenchimentos retroativos sincronizam-se até sete vezes mais rapidamente do que os scripts tradicionais baseados em RPC e, uma vez concluídos, o mesmo Stream pode continuar em mode em tempo real mode manter a sua base de dados atualizada.
Historical blockchain data is any record of past on-chain activity, including blocks, transactions, event logs, traces, and the state (balances and contract storage) at a given block height. Transaction data is permanent on every node, but historical state requires an archive node or a stored backfill.
Por que é que a função eth_getBalance falha com blocos antigos?
Um nó completo padrão elimina os estados anteriores a, aproximadamente, os últimos 128 blocos, pelo que uma chamada histórica ao `eth_getBalance` devolve um erro de nó trie em falta. A consulta a um nó de arquivo, que conserva todos os instantâneos do estado, resolve o erro.
Preciso de um nó de arquivo para aceder a dados históricos?
You need archive access for point-in-time state queries at arbitrary block heights. If you only need historical transactions and event logs, you can read them from full nodes or store them in your own database through a backfill.
What is a blockchain data backfill?
Um preenchimento retroativo recupera um intervalo de blocos anteriores e os respetivos conjuntos de dados, carregando-os numa base de dados ou num destino de armazenamento. Os preenchimentos retroativos baseados em «push» tratam da ordenação, das tentativas de repetição e da entrega garantida, podendo depois passar para a transmissão em tempo real assim que se atualizarem.
Qual é a capacidade de armazenamento de um nó Ethereum ?
Um nó Ethereum armazena cerca de 12 TB ou mais, em comparação com cerca de 1 TB num nó completo. O espaço de armazenamento adicional contém todos os instantâneos históricos do estado, razão pela qual a infraestrutura de arquivo tem custos de funcionamento mais elevados.
