A perspectiva do analista sobre uma blockchain

Toda constatação on-chain se baseia em dados que alguém recuperou, decodificou e interpretou. Um analista que não consegue dizer qual nó produziu os dados, qual software os decodificou e de quem são os rótulos aplicados não consegue defender uma constatação quando um colega, auditor ou tribunal pergunta como ela foi alcançada. Esta aula mapeia de onde vêm os dados da blockchain e o que cada camada acrescenta, para que você escolha as fontes deliberadamente e possa reproduzir seus próprios resultados.

Três camadas de dados da blockchain

Os dados da blockchain vêm em três camadas, cada uma construída sobre a camada abaixo.

Os dados brutos do nó são a verdade fundamental: todo nó completo honesto que segue a mesma cadeia retorna os mesmos bytes para o mesmo hash de bloco. Os dados decodificados são tão confiáveis quanto o decodificador: um endereço derivado de um script ou um valor de token derivado de um evento depende de o decodificador conhecer o tipo de script ou a interface do contrato (seu ABI). Os dados enriquecidos acrescentam julgamento: os preços vêm de um mercado escolhido, os rótulos vêm de uma fonte escolhida e os clusters vêm de heurísticas escolhidas.

Quanto mais alta a camada, mais úteis são os dados e mais pressupostos eles carregam. Uma regra prática: toda afirmação em um relatório deve poder ser rastreada até os dados brutos, e todo pressuposto acrescentado no caminho até as camadas superiores deve ser documentado.

Nós completos, nós de arquivo e o que podem responder

Um nó completo baixa e valida todos os blocos. O que ele pode responder depende do que mantém e indexa.

• Bitcoin Core mantém todos os blocos, a menos que a poda esteja habilitada, e retorna qualquer bloco por hash ou altura. Para consultar uma transação confirmada arbitrária por txid, precisa do índice de transações opcional (txindex=1); sem ele, encontra apenas transações do mempool ou transações em um bloco que você especificar. O Bitcoin Core não tem índice de endereços: não consegue listar o histórico de um endereço. As consultas por endereço precisam de um indexador separado (exemplos de código aberto incluem Electrs, Fulcrum e Esplora).
• Os clientes de execução do Ethereum (Geth, Nethermind, Besu, Erigon, Reth) mantêm blocos, transações e recibos, mas um nó completo padrão mantém o estado (saldos, armazenamento de contratos) apenas para os blocos recentes. Por exemplo, o armazenamento padrão baseado em caminhos do Geth mantém uma cópia completa do estado em disco para o bloco que está 128 blocos atrás da ponta da cadeia, além das alterações em memória para os blocos mais recentes; assim, consegue responder a consultas de estado apenas para aproximadamente os últimos 128 blocos. Se você pedir a esse nó um saldo referente a um bloco do ano passado, a consulta falhará. Um nó de arquivo mantém o estado histórico de todos os blocos e é necessário para consultar saldos históricos, fazer chamadas a contratos com referência a blocos antigos e realizar a maioria dos rastreamentos de transações antigas.

O próprio histórico também está diminuindo nos nós padrão. Desde julho de 2025, todos os principais clientes de execução do Ethereum oferecem suporte à expiração parcial do histórico conforme a EIP-4444: um nó pode descartar corpos de blocos e recibos anteriores à Fusão (setembro de 2022), mantendo todos os cabeçalhos. Um nó configurado dessa forma não pode fornecer um recibo de 2019. Analistas que precisam do histórico antigo devem usar um nó que o mantenha ou um arquivo histórico publicado.

Provedores de RPC e indexadores

Manter nós custa espaço em disco, tempo e manutenção, então a maioria dos analistas usa um de dois atalhos.

Provedores de RPC operam nós e expõem as interfaces padrão (RPC do Bitcoin Core, JSON-RPC do Ethereum) pela internet. São convenientes, mas você fica sujeito à configuração deles (completo ou de arquivo, qual cliente, quais métodos estão habilitados), aos limites de requisições e aos erros. A aula APIs de nós e acesso a dados aborda como usá-los e verificá-los.

Indexadores leem continuamente os dados dos nós e os gravam em um banco de dados estruturado para consultas: uma linha por transação, saída, log ou rastreamento. Alguns indexam tudo (os pipelines de ETL que alimentam conjuntos de dados públicos); outros indexam um protocolo (um subgrafo que acompanha um único mercado de empréstimos). Os indexadores respondem a perguntas que um nó não consegue responder rapidamente, como "todos os eventos Transfer envolvendo este endereço ao longo de cinco anos", mas acrescentam uma dependência: a lógica de decodificação, o tratamento de reorganizações e a atualização dos dados.

Exploradores de blocos versus data warehouses

Um explorador de blocos é um indexador com uma interface web. É a ferramenta certa para uma primeira análise: confirmar que uma transação existe, verificar seu status, ler seus eventos decodificados. É a ferramenta errada para usar como única fonte, por três motivos. Seus métodos de decodificação e rotulagem raramente são documentados no nível necessário para um relatório. Suas visualizações mudam com o tempo, então um rótulo acrescentado este ano aparece em transações de anos atrás. E os exploradores divergem entre si em valores derivados, como "transações internas", saldos de tokens ou o endereço exibido para um script não padrão.

Um data warehouse (um banco de dados colunar que contém dados indexados da cadeia) é a ferramenta certa para perguntas sobre muitas transações: totais, séries temporais, todas as contrapartes de um cluster. Suas tabelas são tão boas quanto o ETL que as preencheu, então os resultados do data warehouse são verificados contra um nó usando uma amostra de linhas. A aula A pilha de dados analíticos compara as opções de data warehouse.

Um fluxo de trabalho sólido combina os três: um explorador para orientação, um data warehouse para escala e um nó para verificar as transações específicas das quais uma constatação depende.

Um exemplo prático: uma pergunta, três respostas

Um analista recebe a pergunta de quanto ETH o endereço 0xA1b2…9F recebeu em março de 2025. Três fontes fornecem três números:

• A lista de transações de um explorador totaliza 41,20 ETH.
• Uma consulta ao data warehouse na tabela transactions totaliza 41,20 ETH.
• Uma consulta ao data warehouse que adiciona o valor movimentado por chamadas internas, a partir da tabela traces, totaliza 53,70 ETH.

Nenhuma das fontes está errada. As duas primeiras contam apenas transações de nível superior nas quais o endereço era o campo to. Os 12,50 ETH adicionais chegaram por meio de chamadas a contratos — neste caso, um saque de uma carteira de contrato inteligente — que aparece apenas nos rastreamentos. Uma quarta resposta surgiria se WETH fosse incluído: WETH é um token e aparece apenas em logs de eventos. Uma quinta resposta, descuidada, contaria o valor de chamadas que foram revertidas, que também são registradas nos rastreamentos, mas não movimentaram nada.

O ponto não é que um número esteja certo. A pergunta precisa ser definida com precisão: qual camada, quais tabelas, qual intervalo de blocos, qual ativo. "53,70 ETH recebidos como valor nativo nos blocos X a Y, incluindo transferências internas bem-sucedidas e excluindo WETH" é uma resposta que outro analista pode reproduzir.

Reprodutibilidade como primeiro dever do analista

Reprodutibilidade significa que outro analista competente obtém o mesmo resultado com base nas suas anotações. Os dados da blockchain tornam isso excepcionalmente viável, porque a camada bruta é pública e não muda depois de finalizada. O que prejudica a reprodutibilidade é tudo o que a cerca:

• Alvos móveis. "Mais recente" muda a cada poucos segundos. Vincule cada consulta a uma altura de bloco e registre o hash desse bloco.
• Fontes não registradas. Anote o nó ou provedor, o cliente e sua versão, e o conjunto de dados e a versão da tabela.
• Transformações não registradas. Guarde a consulta ou o script exato, incluindo filtros e conversões de unidades.
• Rótulos mutáveis. Registre a fonte de cada rótulo e a data em que você o consultou; os rótulos são revisados.
• Dados não finalizados. Blocos recentes podem ser substituídos; consulte a aula Blocos e cabeçalhos como dados.

Trate isso como hábitos, não como burocracia. Uma constatação baseada em "o explorador disse isso na terça-feira passada" não pode ser verificada; uma constatação baseada em um hash de bloco identificado, uma consulta salva e uma versão de cliente registrada pode ser verificada por qualquer pessoa com um nó. A aula Qualidade, normalização e proveniência de dados transforma esses pontos em um registro de proveniência que você pode anexar a cada conjunto de dados.

Foco no exame: as três camadas de dados (brutos, decodificados, enriquecidos ou rotulados) e os pressupostos que cada uma acrescenta; o que um nó completo de Bitcoin pode responder, a função de txindex e a ausência de um índice de endereços; nós completos e de arquivo do Ethereum e por que o estado histórico exige um nó de arquivo; expiração parcial do histórico (EIP-4444) e dados anteriores à Fusão; pontos fortes e fracos dos provedores de RPC, indexadores, exploradores e data warehouses; por que transferências nativas, internas e de tokens produzem totais diferentes; e a vinculação de cada consulta a uma altura e a um hash de bloco para garantir a reprodutibilidade.