Preservação de evidências on-chain

Uma blockchain mantém seu histórico, mas quase tudo o que um investigador usa para ler esse histórico pode mudar. Os exploradores reformulam páginas e renomeiam endereços, as ferramentas de análise atualizam suas atribuições, sites e publicações em fóruns desaparecem, e os blocos mais recentes ainda podem ser substituídos. Preservar evidências on-chain significa fixar cada uma dessas visualizações em um momento conhecido, para que um revisor, anos depois, possa verificar exatamente o que você viu e confirmar isso diretamente na própria cadeia.

O que realmente precisa ser preservado

O livro-razão bruto é a única parte de um caso que raramente precisa ser recuperada: depois que um bloco é finalizado, qualquer nó honesto retornará os mesmos dados. O que precisa ser preservado é o contexto ao redor dele. A tabela lista os itens mais comuns.

Trate os dados brutos como evidência e todo o resto como uma visualização datada deles. Se uma captura de tela do explorador e o nó discordarem, prevalece o nó, e a divergência deve constar em suas anotações.

Vincular cada fato a um bloco

Um txid identifica uma transação, mas, por si só, não fixa onde essa transação se encontra na cadeia que você examinou. Registre, para cada transação em que se basear:

• cadeia e rede (rede principal do Bitcoin, ID de cadeia 1 do Ethereum, uma L2 identificada pelo nome e seu ID de cadeia);
• txid e, para cadeias com modelo baseado em contas, o índice de log de qualquer evento em que você se basear;
• altura e hash do bloco;
• confirmações ou estado de finalização no momento da captura;
• a fonte: seu próprio nó e a versão de seu cliente, ou uma API pública identificada pelo nome;
• horário de recuperação em UTC e o arquivo em que os dados brutos foram salvos, com seu hash SHA-256.

{
  "fact_id": "F-012",
  "chain": "bitcoin-mainnet",
  "txid": "4f3a…c21e",
  "block_height": 966204,
  "block_hash": "0000…3b9e",
  "confirmations_at_capture": 4828,
  "source": "nó próprio, cliente v30.x",
  "cross_check": "API pública do explorador, recuperada em 2026-10-14T10:05Z, campos correspondem",
  "retrieved_utc": "2026-10-14T09:42:10Z",
  "raw_file": "raw/4f3a_c21e.json",
  "raw_file_sha256": "0072…33a9"
}

Este registro vincula um fato usado no relatório (F-012) à transação, ao bloco e à fonte exatos, bem como a um arquivo bruto salvo cujo hash pode ser verificado. Os resumos criptográficos foram abreviados para impressão; o registro real contém todos os 64 caracteres hexadecimais. A linha de verificação cruzada registra que uma segunda fonte independente forneceu os mesmos valores. A aula do IDFE-BA Qualidade, normalização e proveniência dos dados apresenta um registro semelhante para conjuntos de dados inteiros; o acréscimo forense é que cada fato citado em um relatório pode ser rastreado até um desses registros.

Reorganizações e finalização

Os dados capturados perto do topo da cadeia podem ser desfeitos por uma reorganização, na qual os nós mudam para um ramo concorrente e blocos recentes ficam obsoletos. A aula do IDFE-BA Blocos e cabeçalhos como dados explica a mecânica. Para as evidências, as regras são simples:

1. Não preserve como final aquilo que ainda não foi finalizado. No Bitcoin, seis confirmações são a convenção comum, e as evidências de um relatório devem estar bem além disso. No Ethereum, use blocos no ponto de verificação finalized ou abaixo dele, normalmente cerca de 13 minutos atrás do topo.
2. Registre o estado no momento da captura. Se precisou capturar os dados antes, por exemplo, para documentar um roubo enquanto ele acontece, marque o registro como provisório.
3. Verifique novamente os registros provisórios quando forem finalizados: recupere a transação novamente, confirme que ela está em um bloco com o mesmo hash e registre a verificação. Se o hash do bloco tiver mudado, a transação pode ter sido movida ou ter desaparecido, e tudo o que se baseia nela precisa ser revisado.
4. As L2 exigem uma segunda verificação. Os próprios blocos de um rollup podem parecer finalizados em segundos, mas a garantia mais forte só vem quando o lote que os contém é finalizado na cadeia-base; além disso, os saques de rollups otimistas têm um período de contestação. Registre em qual nível de finalização você se baseou.

A documentação em tempo real ainda é valiosa: uma captura antecipada mostra o que estava visível e quando. Ela simplesmente precisa ser identificada pelo que é.

Verificar com uma segunda fonte

Uma única fonte pode estar errada: um explorador pode decodificar um token incorretamente, mostrar um saldo desatualizado ou associar um rótulo errado. Antes de um extrato se tornar evidência, compare-o com uma fonte independente, idealmente seu próprio nó com um público, ou dois provedores sem relação entre si. A consulta abaixo pressupõe que o examinador carregou em evidence_facts os fatos citados no relatório e, em node_check, um extrato atualizado de uma segunda fonte.

-- Fatos cujo txid está ausente ou aparece em um bloco diferente na segunda fonte
SELECT f.fact_id, f.txid, f.block_hash AS cited_block, n.block_hash AS check_block
FROM evidence_facts f
LEFT JOIN node_check n ON n.txid = f.txid
WHERE n.txid IS NULL
   OR n.block_hash <> f.block_hash
   OR n.value_sats <> f.value_sats;   -- para cadeias EVM, compare o valor em wei e o log_index

Cada linha retornada indica um problema a resolver antes de o relatório ser enviado. Um txid ausente na segunda fonte geralmente indica um erro de digitação; o mesmo txid em um bloco diferente significa que o registro foi capturado em um ramo posteriormente substituído em uma reorganização; um valor diferente geralmente indica um erro de unidade ou de casas decimais. Um resultado vazio, com a consulta e ambas as fontes registradas, é por si só um registro útil da verificação.

Registrar instantâneos de rótulos e saídas de ferramentas

Os rótulos mudam com o tempo. Um endereço rotulado como processador de pagamentos neste ano pode ser rotulado como exchange no próximo, ou incorporado a um cluster maior. Se seu relatório disser que um depósito foi enviado para a «Exchange X», um revisor precisa conseguir ver o rótulo tal como era quando você se baseou nele. Exporte, para cada rótulo usado: o nome da entidade, o endereço ou cluster a que se aplica, a fonte (publicado pela própria entidade, registro de provedor, lista da comunidade, ferramenta de análise), a versão ou data da fonte e seu nível de confiança. A aula do IDFE-BA Atribuição e rotulagem aborda a classificação dos rótulos; aqui, o objetivo é congelá-los no tempo.

As saídas das ferramentas exigem o mesmo tratamento. Salve o arquivo nativo do projeto, caso a ferramenta tenha um, uma exportação legível (CSV ou JSON de nós e arestas) e uma imagem renderizada; registre também a versão da ferramenta, o método de rastreamento, os limites de saltos e outras configurações. Reexecutar o mesmo caso em uma versão posterior pode gerar um grafo diferente, e você precisará explicar a diferença. A aula Ferramentas, reprodutibilidade e validação aborda como conciliar ferramentas que discordam.

Arquivar evidências da web

Páginas externas à cadeia muitas vezes contêm a atribuição: um site fraudulento que lista endereços de depósito, uma publicação em fórum que oferece fundos roubados, os termos de uso de um serviço. O Protocolo de Berkeley sobre Investigações de Fontes Abertas Digitais, publicado em 2020 pelo Escritório de Direitos Humanos da ONU e pelo Centro de Direitos Humanos da UC Berkeley, estabelece como coletar e preservar esse material profissionalmente. Os métodos de captura são abordados na aula Metodologia OSINT. O registro de preservação deve incluir:

• um arquivo de arquivamento no formato WARC (ISO 28500:2017), que mantém o conteúdo da página e as respostas do servidor;
• uma captura de tela da página inteira, para leitura humana;
• a URL, o horário da captura em UTC, a ferramenta usada e se a captura era atribuível ou não;
• o hash SHA-256 de cada arquivo, calculado no momento da captura;
• quando for útil, uma cópia em um arquivo público da web como confirmação independente, nunca como a única cópia.

Para demonstrar que uma captura já existia em determinado momento, você pode obter um carimbo de data e hora confiável para seu hash (a RFC 3161 define um protocolo) ou ancorar o hash em uma transação de blockchain pública. OpenTimestamps é um exemplo de código aberto da segunda abordagem.

O pacote de evidências verificável novamente

Tudo isso se reúne em um pacote de evidências: uma pasta que permite a um revisor verificar cada fato sem precisar confiar em você.

CF-2026-041_onchain_v1/
  README.txt              como verificar novamente, fontes, versões de software
  manifest.sha256         uma linha SHA-256 por arquivo abaixo
  facts.json              registros dos fatos (F-001 ... F-088)
  raw/                    transações e blocos brutos do nó
  labels/labels_2026-10-12.json
  tool/trace_graph_export.json
  web/forum_post_capture.warc
  web/forum_post_capture.png

O manifesto lista o hash de cada arquivo; o hash do próprio manifesto (para esta versão, 4b91…199f) é registrado no diário do caso e no diário de evidências, de modo que um único valor proteja o pacote inteiro. O README explica como recuperar cada transação de qualquer nó, compará-la com raw/ e recalcular os hashes. Nunca edite um pacote depois de lacrá-lo: emita a versão 2 com um novo manifesto e registre o motivo. A aula Hashing, registro e cadeia de custódia aborda como o pacote é então transferido sob custódia.

Foco no exame: por que os dados brutos e finalizados da cadeia raramente precisam ser recuperados, ao contrário das páginas do explorador, dos rótulos, das saídas das ferramentas, das páginas da web e dos preços; os campos que vinculam um fato (cadeia, txid, índice de log, altura e hash do bloco, estado de finalização na captura, fonte e versão do cliente, horário UTC, hash do arquivo bruto); não tratar dados não finalizados como finais, marcar capturas provisórias e verificá-las novamente; a finalização do rollup em comparação com a da cadeia-base; verificação cruzada com uma fonte independente; exportação de instantâneos de rótulos e configurações de ferramentas; WARC, capturas de tela, hashes e carimbos de data e hora confiáveis para evidências da web conforme o Protocolo de Berkeley; o pacote de evidências, seu manifesto e o controle de versões em vez de editá-lo.