Strumenti, riproducibilità e validazione

Quasi ogni tracciamento di criptovalute è prodotto mediante software, spesso proprietario, in rapida evoluzione e basato su scelte metodologiche predefinite. Il tribunale non deve necessariamente fidarsi dello strumento, ma deve potersi fidare del risultato. Tale fiducia deriva dalla dimostrazione che i fatti possono essere ricavati nuovamente dai dati grezzi della blockchain, che lo strumento è stato testato per il compito previsto, che ogni impostazione, versione e fonte delle etichette è stata registrata e che un'altra persona, eseguendo le stesse query sugli stessi dati, ottiene le stesse righe. Le pratiche che rendono economiche le query (ambiti circoscritti, intervalli fissati, versioni esplicite) sono le stesse che le rendono riproducibili.

Il panorama degli strumenti

I nomi dei prodotti non sono importanti; conta ciò che ciascuna categoria apporta agli elementi probatori.

La maggior parte delle unità utilizza più strumenti contemporaneamente: una piattaforma per esplorare e generare piste investigative, un nodo e query proprie per accertare i fatti, e una relazione basata su entrambi. L'architettura dei dati è trattata nella lezione 2.7.

Fatti, trasformazioni e interpretazioni

Ogni output di uno strumento combina tre livelli. I fatti sono dati grezzi della blockchain: txid, output, importi, blocchi. Le trasformazioni deterministiche convertono i dati grezzi in una forma leggibile: conversione delle unità, decodifica degli eventi, tracce di esecuzione. Le interpretazioni aggiungono valutazioni: cluster, etichette, identificazioni del resto, risultati di allocazione.

Uno strumento può sbagliare a ciascun livello. Può interpretare erroneamente i dati (il numero di decimali di un token, un trasferimento interno omesso, una riorganizzazione gestita in modo errato), avere una copertura insufficiente (un token non indicizzato, una blockchain non supportata, dati in ritardo rispetto alla punta della catena) oppure applicare impostazioni predefinite che l'esaminatore non ha mai scelto (un'euristica del resto attivata, un metodo di allocazione preimpostato). La regola operativa è questa: ogni fatto contenuto in una relazione forense deve essere riconducibile a dati grezzi che una terza parte possa verificare sul proprio nodo, e ogni interpretazione deve indicare il metodo e le impostazioni utilizzati. Una schermata di una vista a grafo illustra, ma non dimostra. Occorre conservare le esportazioni sottostanti.

Rieseguire un tracciamento a partire dai dati grezzi

Prima di riportare un tracciamento nella relazione, occorre ricavarlo nuovamente al di fuori dello strumento che lo ha prodotto:

1. esportare il percorso dello strumento come tabella dei passaggi: txid, riferimento all'output o al log, altezza del blocco, importo in unità di base;
2. ricavare nuovamente gli stessi campi dal proprio nodo o da un data warehouse riconciliato con un nodo;
3. confrontarli campo per campo;
4. ricalcolare le allocazioni con un proprio script secondo il metodo dichiarato;
5. registrare le differenze e il modo in cui ciascuna è stata risolta.

-- Confronta i passaggi esportati dallo strumento con i valori ricavati nuovamente dal nostro nodo
SELECT t.hop_id, t.txid, t.out_ref,
       t.amount_base  AS tool_amount,   n.amount_base  AS node_amount,
       t.block_height AS tool_height,   n.block_height AS node_height,
       CASE
         WHEN n.txid IS NULL THEN 'NOT FOUND ON NODE'
         WHEN t.amount_base <> n.amount_base
           OR t.block_height <> n.block_height THEN 'MISMATCH'
         ELSE 'OK'
       END AS check_result
FROM tool_hops t
LEFT JOIN node_hops n ON n.txid = t.txid AND n.out_ref = t.out_ref
ORDER BY t.hop_id;

La left join conserva ogni passaggio riportato dallo strumento, perciò un passaggio assente dai dati del nodo compare come "NOT FOUND ON NODE" anziché scomparire. Gli importi vengono confrontati come numeri interi in unità di base, quindi un errore nel numero di decimali si manifesta come una discrepanza pari a una potenza di dieci. La query verifica soltanto i fatti; la concordanza non dice nulla sulla correttezza delle etichette o delle identificazioni del resto effettuate dallo strumento.

Validare gli strumenti

Le norme per i laboratori richiedono che sia dimostrata l'idoneità allo scopo dei metodi e degli strumenti che li implementano. ISO/IEC 17025 richiede ai laboratori di validare i metodi non normalizzati, i metodi sviluppati dal laboratorio e i metodi normalizzati utilizzati al di fuori del loro ambito previsto o altrimenti modificati (punto 7.2.2). ISO/IEC 27041 fornisce indicazioni per garantire che i metodi investigativi siano idonei e adeguati. Il sistema qualità che inquadra questi aspetti è trattato nella lezione 8.3; qui l'attenzione è rivolta agli strumenti.

Il documento SWGDE Requisiti minimi per il collaudo degli strumenti utilizzati nell'informatica forense e nelle analisi forensi multimediali (documento 18-Q-001, versione 2.1, marzo 2024) descrive tre strategie di test, tutte applicabili agli strumenti per blockchain: test su dataset noti (input con un risultato noto), test comparativi (almeno due strumenti, verificati per accertarne la coerenza) e test empirici (output verificato rispetto ad altri dati). Richiede registrazioni dei test che indichino finalità e ambito, esecutore, data, procedura, dataset e risultati attesi, risultati con anomalie e limitazioni riscontrate, e raccomanda di testare nuovamente gli strumenti interni al primo utilizzo e dopo ogni revisione, nonché gli strumenti di ricerca dopo aggiornamenti rilevanti. Il programma NIST Computer Forensics Tool Testing (CFTT) offre un modello per strutturare i test: è orientato alle funzionalità e prevede la stesura, prima dei test, di una specifica di requisiti, asserzioni e casi di test per ciascuna funzione dello strumento.

Un piano di test pratico elenca ogni funzione di uno strumento per blockchain e le associa un risultato noto:

Le transazioni di test controllate sono particolarmente preziose perché l'unità conosce la situazione reale relativa a titolarità e resto. Tutto ciò che emerge confluisce in un registro delle limitazioni note, che gli esaminatori leggono prima di fare affidamento sullo strumento e che è disponibile per la divulgazione alle parti.

Query economiche e ripetibili

Le tabelle dell'intera cronologia arrivano a miliardi di righe, e la stessa domanda può costare pochi centesimi e richiedere pochi secondi, oppure comportare un costo significativo e richiedere un'ora.

Come i motori leggono i dati. I data warehouse memorizzano i dati per colonna, quindi una query legge soltanto le colonne che specifica; SELECT * legge anche i voluminosi calldata, e i costi a scansione sono proporzionali ai byte letti. Le tabelle di grandi dimensioni sono partizionate, di solito per giorno del timestamp del blocco o per intervallo di blocchi, e un filtro sulla colonna di partizionamento consente al motore di saltare intere partizioni (esclusione delle partizioni). LIMIT 10 non rende meno costosa una scansione nella maggior parte dei data warehouse, e un filtro su una colonna non usata per il partizionamento, come to_address, non esclude alcuna partizione. Prima di interrogare l'intera cronologia, verificare i byte o le partizioni mediante un'esecuzione di prova o EXPLAIN. Per dare un'idea della scala, Ethereum produce circa 7.200 blocchi al giorno (uno per slot di 12 secondi), quindi una settimana corrisponde a circa 50.000 blocchi; Bitcoin ne produce circa 144.

Intervalli di blocchi e finestre temporali. Gli analisti ragionano in termini di altezze dei blocchi; le tabelle sono partizionate per tempo. Leggere la piccola tabella blocks per individuare i timestamp che coprono l'intervallo, quindi filtrare la tabella grande in base a entrambi: timestamp letterali estesi a giorni interi sulla colonna di partizionamento grezza e intervallo esatto dei blocchi. Una finestra fornita tramite una join o una sottoquery, oppure una colonna racchiusa in una funzione come CAST(block_timestamp AS DATE), può disabilitare l'esclusione delle partizioni su alcuni motori.

Estrarre una sola volta. Recuperare ogni trasferimento che coinvolge gli indirizzi del caso nell'intervallo di blocchi del caso mediante un'unica query ben filtrata, salvarlo come piccola tabella o file Parquet e proseguire le elaborazioni localmente. La scansione costosa viene eseguita una sola volta, e l'estrazione funge anche da istantanea fissa degli elementi probatori.

Il campionamento è adatto all'esplorazione di una tabella o al test della logica, mai al calcolo dei totali, al tracciamento o all'analisi di eventi rari: il valore on-chain è concentrato in pochi trasferimenti di importo elevato che un campione dell'1% solitamente non include. Il campionamento dello storage (TABLESAMPLE SYSTEM) restituisce righe raggruppate e, su alcuni motori, un campione diverso a ogni esecuzione. Un filtro derivato dall'hash, come gli hash delle transazioni che terminano in 00, conserva circa 1 riga su 256 (0,39%), sempre le stesse a ogni esecuzione, anche se non rende meno costosa la scansione.

Caricamenti incrementali. I processi di monitoraggio dovrebbero elaborare soltanto i nuovi blocchi, ma i blocchi recenti possono essere soggetti a riorganizzazione, e un processo che si limita ad aggiungere dati conserva righe provenienti da blocchi che non esistono più. Ogni esecuzione dovrebbe eliminare e ricaricare un intervallo retrospettivo (ad esempio, a partire dal blocco più alto caricato meno 64) fino all'ultimo blocco finalizzato, in un'unica transazione del database, così che una nuova esecuzione produca la stessa tabella: il processo è idempotente. La finalità di Ethereum viene normalmente raggiunta dopo circa due epoche, ossia circa 13 minuti; su Bitcoin, un intervallo retrospettivo di almeno sei blocchi è una convenzione comune.

Registrare versioni, impostazioni e fonti delle etichette

Un risultato è riproducibile quando un'altra persona, o lo stesso analista un anno dopo, può eseguire la medesima query sugli stessi dati e ottenere le stesse righe. Ciò richiede un ambito fissato (intervalli di blocchi, mai CURRENT_DATE o "ultimi 30 giorni"); SQL mantenuto sotto controllo di versione e citato mediante commit; output deterministico, ordinato in base a una chiave completa, ad esempio numero del blocco seguito dall'indice del log, senza funzioni approssimative nei valori riportati; e versioni dei dati registrate per l'istantanea del dataset e per gli input modificabili, come le tabelle delle etichette e dei prezzi. Ogni esecuzione analitica riceve quindi una registrazione, conservata nel fascicolo del caso:

{
  "run_id": "CF-2026-0142-R07",
  "started_utc": "2026-03-05T08:40:12Z",
  "tool": {"category": "investigation platform", "version": "8.4.1", "data_through_block": 939336},
  "node": {"client": "Bitcoin Core", "version": "29.0", "tip_height": 939388},
  "settings": {"allocation": "haircut", "hop_limit": 6, "change_heuristic": "on",
               "stop_at": "labeled custodial services"},
  "labels_used": [
    {"address": "bc1q…dx7e", "label": "Exchange K deposit", "source": "platform cluster 4471",
     "basis": "co-swept with known deposits", "retrieved_utc": "2026-03-05T08:52:40Z"}
  ],
  "queries": [{"file": "rederive_hops.sql", "commit": "9c41e2a", "blocks": [938940, 939050]}],
  "exports": [{"file": "R07_hops.csv", "sha256": "3b1f…9e02"}],
  "examiner": "EX-07"
}

La registrazione fissa la versione dello strumento e l'altezza del blocco raggiunta dai suoi dati, che può essere in ritardo rispetto alla punta del nodo, nonché ogni impostazione che modifica i risultati. Ogni etichetta riporta fonte, fondamento e momento del recupero, perché le etichette cambiano. Per ogni esportazione viene calcolato un hash, così che un revisore possa confermare di aver riprodotto esattamente le stesse righe. Nella registrazione effettiva va inserito il nome reale dello strumento. La conservazione di questi file è trattata nelle lezioni 8.2 e 8.3.

Validare i dati rispetto a un nodo

I dataset vengono creati da software che possono presentare malfunzionamenti. Prima di inserire un valore in una relazione, verificarne un campione rispetto alla fonte (lezione 2.6): confrontare un saldo calcolato con eth_getBalance, oppure con balanceOf invocato tramite eth_call, allo stesso blocco; confrontare gli hash dei blocchi memorizzati con quelli del nodo (getblockhash su Bitcoin, eth_getBlockByNumber sulle blockchain EVM) per individuare righe provenienti da blocchi orfani; confrontare il numero di transazioni di ciascun blocco con le righe effettivamente caricate; e verificare la continuità.

-- Verifica della continuità: lacune nei numeri dei blocchi e collegamenti interrotti ai blocchi precedenti
SELECT number, prev_number, parent_hash, prev_hash
FROM (SELECT number, parent_hash,
             LAG(number) OVER (ORDER BY number) AS prev_number,
             LAG(hash)   OVER (ORDER BY number) AS prev_hash
      FROM blocks
      WHERE number BETWEEN 21100000 AND 21107199) AS s
WHERE number <> prev_number + 1          -- un blocco mancante
   OR parent_hash <> prev_hash;          -- un blocco di un'altra biforcazione

Ogni riga restituita indica un problema: un blocco mancante oppure un blocco memorizzato che non si collega al suo predecessore. Un risultato vuoto sull'intervallo di blocchi del caso, insieme a verifiche a campione concordanti, consente di dichiarare che i dati sono stati validati.

Quando gli strumenti non concordano

La discordanza tra strumenti è normale e utile: indica dove inizia l'interpretazione. Si consideri il percorso della lezione 3.2. Lo strumento A riporta che 0,90909091 BTC del riscatto sono arrivati a bc1q…dx7e e lo etichetta come indirizzo di deposito di Exchange K. Lo strumento B riporta 1,20000000 BTC e lascia l'indirizzo privo di etichetta. Occorre partire dal primo punto di divergenza e risalire ai dati grezzi:

Le cause comuni includono clustering diversi (uno strumento ha unito due cluster), diverse identificazioni del resto, fonti o date delle etichette diverse, impostazioni predefinite di allocazione diverse, trasferimenti interni o token mancanti e blocchi limite diversi. Registrare la discordanza, la causa e la risoluzione nel fascicolo del caso, senza mai risolverla scegliendo lo strumento che fornisce la risposta più conveniente. I consulenti tecnici della difesa esaminano spesso l'opacità degli strumenti e la provenienza delle etichette (lezione 8.4).

Focus sull'esame: categorie di strumenti e contributo di ciascuna agli elementi probatori; fatti, trasformazioni deterministiche e interpretazioni, e possibili errori degli strumenti a ciascun livello; perché i fatti riportati devono poter essere ricavati nuovamente dai dati grezzi e perché le schermate hanno soltanto funzione illustrativa; riesecuzione di un tracciamento e confronto delle esportazioni degli strumenti con i dati del nodo; ISO/IEC 17025, punto 7.2.2, e ISO/IEC 27041; le tre strategie di test di SWGDE, le registrazioni dei test e la ripetizione dei test; il modello NIST CFTT orientato alle funzionalità; test con risultato noto e registro delle limitazioni note; costi della lettura per colonne, esclusione delle partizioni con intervalli letterali e conversione degli intervalli di blocchi in finestre temporali; quando il campionamento è accettabile; caricamenti incrementali con intervallo retrospettivo per le riorganizzazioni fino alla punta finalizzata; elementi di una query riproducibile e campi di una registrazione di esecuzione; verifiche sul nodo di saldi, hash dei blocchi, conteggi e continuità; diagnosi e documentazione delle discordanze tra strumenti.