Conservare le prove on-chain

Una blockchain conserva la propria cronologia, ma quasi tutto ciò che un investigatore usa per consultarla può cambiare. Gli explorer riprogettano le pagine e rietichettano gli indirizzi, gli strumenti di analisi aggiornano le proprie attribuzioni, i siti web e i post nei forum scompaiono e i blocchi più recenti possono ancora essere sostituiti. Conservare le prove on-chain significa fissare ciascuna di queste viste in un momento noto, affinché un revisore, anche anni dopo, possa verificare esattamente ciò che hai visto e confrontarlo con la blockchain stessa.

Che cosa occorre conservare davvero

Il registro grezzo è l’unica parte di un caso che raramente occorre recuperare: una volta che un blocco è definitivo, qualsiasi nodo onesto restituirà gli stessi dati. Ciò che occorre conservare è il contesto che lo circonda. La tabella elenca gli elementi abituali.

Tratta i dati grezzi come prove e tutto il resto come una vista datata di essi. Se uno screenshot di un explorer e il nodo non concordano, prevale il nodo e la discrepanza va annotata.

Collegare ogni fatto a un blocco

Un txid identifica una transazione, ma da solo non fissa la posizione occupata da quella transazione nella catena esaminata. Per ogni transazione su cui fai affidamento, registra:

• catena e rete (Bitcoin mainnet, Ethereum chain ID 1, una L2 specifica e il relativo chain ID);
• txid e, per le catene basate su account, l’indice del log di qualsiasi evento su cui fai affidamento;
• altezza e hash del blocco;
• conferme o stato di finalità al momento dell’acquisizione;
• la fonte: il tuo nodo e la versione del relativo client, oppure un’API pubblica specifica;
• ora di recupero in UTC e file in cui sono stati salvati i dati grezzi, con il relativo 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": "own node, client v30.x",
  "cross_check": "public explorer API, retrieved 2026-10-14T10:05Z, fields match",
  "retrieved_utc": "2026-10-14T09:42:10Z",
  "raw_file": "raw/4f3a_c21e.json",
  "raw_file_sha256": "0072…33a9"
}

Questo record collega un fatto usato nel rapporto (F-012) alla transazione, al blocco e alla fonte esatti, nonché a un file grezzo salvato il cui hash può essere verificato. I digest sono abbreviati per la stampa; il record reale contiene tutti i 64 caratteri esadecimali. La riga di verifica incrociata registra che una seconda fonte indipendente ha fornito gli stessi valori. La lezione IDFE-BA Qualità, normalizzazione e provenienza dei dati presenta un record simile per interi insiemi di dati; l’aggiunta forense consiste nel poter ricondurre ogni fatto citato in un rapporto a uno di questi record.

Riorganizzazioni e finalità

I dati acquisiti in prossimità della punta della catena possono essere annullati da una riorganizzazione, in cui i nodi passano a un ramo concorrente e i blocchi recenti diventano obsoleti. La lezione IDFE-BA Blocchi e header come dati spiega i meccanismi. Per le prove, le regole sono semplici:

1. Non considerare definitivo ciò che non è definitivo. Su Bitcoin, sei conferme sono la convenzione comune, e le prove destinate a un rapporto dovrebbero essere ben oltre quella soglia. Su Ethereum, usa blocchi pari o precedenti al checkpoint finalized, normalmente circa 13 minuti dietro alla testa della catena.
2. Registra lo stato al momento dell’acquisizione. Se hai dovuto acquisire i dati in anticipo, per esempio per documentare un furto mentre è in corso, contrassegna il record come provvisorio.
3. Verifica nuovamente i record provvisori una volta che sono definitivi: recupera di nuovo la transazione, conferma che si trovi in un blocco con lo stesso hash e annota il controllo. Se l’hash del blocco è cambiato, la transazione potrebbe essersi spostata o essere scomparsa e occorre riesaminare tutto ciò che si basa su di essa.
4. Le Layer 2 richiedono un secondo controllo. I blocchi di un rollup possono sembrare definitivi nel giro di pochi secondi, ma la garanzia più forte arriva solo quando il batch che li contiene è definitivo sulla catena di base; inoltre, i prelievi dai rollup ottimistici prevedono un periodo di contestazione. Registra a quale livello di finalità ti sei affidato.

La documentazione in tempo reale resta preziosa: un’acquisizione anticipata mostra cosa era visibile e quando. Deve semplicemente essere etichettata per ciò che è.

Verificare con una seconda fonte

Una singola fonte può essere errata: un explorer può decodificare male un token, mostrare un saldo obsoleto o assegnare un’etichetta sbagliata. Prima che un estratto diventi una prova, confrontalo con una fonte indipendente, idealmente il tuo nodo con una fonte pubblica oppure due provider non correlati. La query seguente presuppone che l’esaminatore abbia caricato in evidence_facts i fatti citati nel rapporto e in node_check un nuovo estratto proveniente da una seconda fonte.

-- Fatti il cui txid manca o si trova in un blocco diverso nella seconda 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;   -- per le catene EVM confrontare il valore in wei e log_index

Ogni riga restituita indica un problema da risolvere prima di inviare il rapporto. Un txid assente dalla seconda fonte di solito indica un errore di digitazione; lo stesso txid in un blocco diverso significa che il record è stato acquisito su un ramo poi sostituito da una riorganizzazione; un valore diverso indica di solito un errore di unità o di decimali. Un risultato vuoto, con la query e le due fonti registrate, costituisce di per sé un’utile prova della verifica.

Acquisire istantanee di etichette e output degli strumenti

Le etichette si deteriorano. Un indirizzo etichettato quest’anno come processore di pagamenti potrebbe essere rietichettato come exchange l’anno prossimo oppure unito a un cluster più grande. Se il tuo rapporto afferma che un deposito è stato inviato a «Exchange X», un revisore deve poter vedere l’etichetta così com’era quando ti sei basato su di essa. Per ogni etichetta usata, esporta il nome dell’entità, l’indirizzo o il cluster a cui si riferisce, la fonte (autopubblicata, record del provider, elenco della community, strumento di analisi), la versione o la data della fonte e il tuo livello di fiducia. La lezione IDFE-BA Attribuzione ed etichettatura spiega come valutare le etichette; qui l’obiettivo è congelarle.

Anche gli output degli strumenti vanno trattati allo stesso modo. Salva il file di progetto nativo, se lo strumento ne dispone, un’esportazione leggibile (CSV o JSON di nodi e archi) e un’immagine renderizzata; registra inoltre la versione dello strumento, il metodo di tracciamento, i limiti di hop e le altre impostazioni. Ripetere lo stesso caso con una versione successiva potrebbe produrre un grafo diverso, e dovrai spiegare la differenza. La lezione Strumenti, riproducibilità e convalida spiega come conciliare strumenti che non concordano.

Archiviare le prove web

Le pagine off-chain spesso forniscono l’attribuzione: un sito truffaldino che elenca indirizzi di deposito, un post in un forum che offre fondi rubati, i termini di utilizzo di un servizio. Il Berkeley Protocol on Digital Open Source Investigations, pubblicato nel 2020 dall’UN Human Rights Office e dall’Human Rights Center della UC Berkeley, definisce come raccogliere e conservare questo materiale in modo professionale. I metodi di acquisizione sono trattati nella lezione Metodologia OSINT. Il record di conservazione dovrebbe includere:

• un file di archivio in formato WARC (ISO 28500:2017), che conserva il contenuto della pagina e le risposte del server;
• uno screenshot dell’intera pagina, per la consultazione umana;
• l’URL, l’ora di acquisizione in UTC, lo strumento usato e l’indicazione se l’acquisizione fosse attribuibile o meno;
• l’hash SHA-256 di ogni file, calcolato al momento dell’acquisizione;
• se utile, una copia in un archivio web pubblico come corroborazione indipendente, mai come unica copia.

Per dimostrare che un’acquisizione esisteva entro un certo momento, puoi ottenere una marca temporale attendibile per il relativo hash (RFC 3161 definisce un protocollo) oppure ancorare l’hash in una transazione su una blockchain pubblica. OpenTimestamps è un esempio open source del secondo approccio.

Il pacchetto di prove riverificabile

Tutto questo confluisce in un pacchetto di prove: una cartella che consente a un revisore di verificare ogni fatto senza doversi fidare di te.

CF-2026-041_onchain_v1/
  README.txt              come riverificare, fonti, versioni del software
  manifest.sha256         una riga SHA-256 per ogni file elencato sotto
  facts.json              record dei fatti (F-001 ... F-088)
  raw/                    transazioni e blocchi grezzi dal nodo
  labels/labels_2026-10-12.json
  tool/trace_graph_export.json
  web/forum_post_capture.warc
  web/forum_post_capture.png

Il manifest elenca l’hash di ogni file; l’hash del manifest stesso (per questa versione, 4b91…199f) viene inserito nel registro del caso e nel registro delle prove, così un unico valore protegge l’intero pacchetto. Il README spiega come recuperare ogni transazione da qualsiasi nodo, confrontarla con raw/ e ricalcolare gli hash. Non modificare mai un pacchetto dopo averlo sigillato: crea la versione 2 con un nuovo manifest e registra il motivo. La lezione Hashing, registrazione e catena di custodia spiega come il pacchetto passa poi attraverso la catena di custodia.

Focus sull'esame: perché raramente occorre recuperare i dati grezzi definitivi della catena, mentre pagine degli explorer, etichette, output degli strumenti, pagine web e prezzi devono essere conservati; i campi che collegano un fatto al suo contesto (catena, txid, indice del log, altezza e hash del blocco, finalità al momento dell’acquisizione, fonte e versione del client, ora UTC, hash del file grezzo); non considerare definitivi i dati non finalizzati, contrassegnare le acquisizioni provvisorie e riverificarle; finalità del rollup rispetto a quella della catena di base; verifiche incrociate con una fonte indipendente; esportazione di istantanee delle etichette e delle impostazioni degli strumenti; WARC, screenshot, hash e marche temporali attendibili per le prove web secondo il Berkeley Protocol; pacchetto di prove, manifest e controllo delle versioni anziché modifiche al pacchetto.