Dalla domanda all’ipotesi

Ogni indagine inizia con una domanda, e la qualità della domanda limita la qualità della risposta. I dati on-chain sono così vasti e interconnessi che un analista che parte da una spiegazione preferita può quasi sempre trovare transazioni che sembrano confermarla. Questa lezione mostra come trasformare una richiesta vaga in una domanda analitica a cui sia possibile rispondere, come definirne l’ambito e come confrontare diverse spiegazioni, invece di costruire un caso a sostegno di una sola.

Dalla richiesta alla domanda analitica

Le richieste raramente arrivano in una forma utilizzabile. «Scopri chi c’è dietro questo wallet» o «Stiamo ricevendo fondi provenienti da un attacco informatico?» descrivono una preoccupazione, non una domanda a cui i dati possano rispondere. Una buona domanda analitica è:

• Specific: nomina gli asset, gli indirizzi o gli eventi a cui si riferisce.
• Delimitata: ha un limite temporale, un numero massimo di passaggi o un limite di impegno.
• A cui è possibile rispondere: i dati che l’analista può ottenere legalmente potrebbero, in linea di principio, risolverla.
• Rilevante per una decisione: la risposta cambia ciò che farà il richiedente (congelare, segnalare, pubblicare, chiudere il fascicolo).
• Neutrale: non presuppone la risposta.

Si noti che la prima riformulazione elimina «chi». Di solito, l’identità reale di una persona privata non è determinabile dai soli dati della blockchain e spesso non è ciò di cui il richiedente ha bisogno; ciò che gli serve è conoscere il tipo di entità e i servizi presso cui esistono registrazioni off-chain (si veda la lezione Seguire il valore attraverso exchange e servizi e la lezione Protezione dei dati, etica e divulgazione responsabile per capire perché l’identità va trattata con cautela).

È utile anche classificare la domanda. Le domande descrittive chiedono che cosa è successo (dove sono finiti i fondi?). Le domande esplicative chiedono perché o di chi si tratta (è un servizio o un individuo?). Le domande estimative riguardano qualcosa che non è direttamente osservabile o che non è ancora accaduto (i fondi rimanenti raggiungeranno un exchange?). Ogni tipo richiede una risposta diversa e una diversa dichiarazione del livello di confidenza, come spiega la lezione Confidenza, incertezza e linguaggio.

Definire l’ambito di blockchain, asset e intervalli temporali

Prima di eseguire anche una sola query, scrivete una breve dichiarazione dell’ambito nel fascicolo del caso. Questo protegge l’analista dall’espansione incontrollata dell’ambito e chiarisce al lettore i limiti di ogni risultato.

Esprimete gli intervalli temporali sia come altezze dei blocchi sia come date UTC. Gli intervalli di blocchi sono esatti e riproducibili, mentre i timestamp presentano le cautele descritte nella lezione Blocchi e header come dati.

I limiti di profondità sono importanti perché la tracciatura cresce rapidamente. Se ogni indirizzo invia fondi a tre altri indirizzi in media, già cinque passaggi producono 3^5 = 243 percorsi e dieci passaggi ne producono più di 59.000. Una regola che impone di fermarsi ai servizi di custodia non è pigrizia: oltre un hot wallet, i movimenti on-chain non appartengono più al proprietario originario.

Una query rapida per dimensionare l’indagine permette di capire se l’ambito è realistico prima di impegnarsi:

-- Dimensionare l'ambito: attività degli indirizzi di partenza nell'intervallo di blocchi
SELECT
  COUNT(*)                     AS transfers,
  COUNT(DISTINCT counterparty) AS counterparties,
  MIN(block_number)            AS first_block,
  MAX(block_number)            AS last_block
FROM (
  SELECT block_number, to_address AS counterparty FROM token_transfers
  WHERE from_address IN ('0xa1b2…9f', '0xe7c1…44ad')
    AND block_number BETWEEN 24790112 AND 24812000
  UNION ALL
  SELECT block_number, from_address FROM token_transfers
  WHERE to_address IN ('0xa1b2…9f', '0xe7c1…44ad')
    AND block_number BETWEEN 24790112 AND 24812000
) t;

La query interna raccoglie i trasferimenti in entrambe le direzioni; quella esterna li conta, insieme alle controparti distinte. Il filtro sui blocchi si trova all’interno di ciascun ramo, così il motore può escludere le partizioni non pertinenti (si veda la lezione Prestazioni, costi e riproducibilità). Se il risultato è di 40 controparti, l’ambito è gestibile; se è di 40.000, probabilmente uno degli indirizzi di partenza appartiene a un servizio e la domanda va ripensata.

Formulare ipotesi concorrenti

Un’ipotesi è una spiegazione verificabile di ciò che mostrano i dati. La disciplina consiste nel formularne diverse prima di valutarne una qualsiasi e nell’includere anche la spiegazione più banale e innocua.

Consideriamo uno schema comune: un indirizzo Bitcoin bc1q…m4x2 riceve 38 piccoli pagamenti da 38 indirizzi diversi nell’arco di sei giorni, poi li spende tutti in un’unica transazione con due output. Almeno tre spiegazioni sono compatibili:

• H1, sweep del servizio: bc1q…m4x2 è un indirizzo di deposito di un exchange e la spesa è lo sweep che l’exchange effettua verso un hot wallet.
• H2, consolidamento del proprietario: una persona o un’azienda consolida molte piccole quantità di bitcoin di sua proprietà mentre le commissioni sono basse.
• H3, consolidamento per riciclaggio: un ladro raccoglie gli output di precedenti catene a peeling prima di spostarli.

Chiedetevi «cos’altro potrebbe produrre questo schema?» finché non emergono più nuove risposte. Le ipotesi dovrebbero essere il più possibile mutuamente esclusive, così che le prove contrarie a una costituiscano prove a favore di un’altra.

Pregiudizi cognitivi che influenzano gli analisti on-chain

Richards Heuer, ex analista della CIA, sosteneva che i pregiudizi cognitivi si comportano come illusioni ottiche: conoscerli non li fa scomparire. Il rimedio è la struttura, non la forza di volontà.

Analisi delle ipotesi concorrenti (ACH)

L’analisi delle ipotesi concorrenti (ACH) è la tecnica strutturata descritta da Heuer in Psicologia dell’analisi d’intelligence (CIA Center for the Study of Intelligence, 1999). È un metodo derivato dalla pratica dell’intelligence, non uno standard giuridico, e funziona bene per le domande on-chain. La procedura di Heuer prevede otto passaggi:

1. Individuare le possibili ipotesi, idealmente coinvolgendo colleghi che interpretano il caso in modo diverso.
2. Elencare le prove e le argomentazioni significative, comprese le ipotesi assunte e l’assenza di prove attese.
3. Costruire una matrice con le ipotesi in alto e le prove a lato, indicando per ogni cella se l’elemento è coerente, incoerente o non applicabile.
4. Perfezionare la matrice: aggiungere le ipotesi emerse ed eliminare le prove che non consentono di distinguere le ipotesi.
5. Trarre conclusioni provvisorie cercando di confutare le ipotesi. Sopravvive l’ipotesi con il minor numero di incoerenze; il numero di elementi coerenti conta poco.
6. Analizzare quanto la conclusione sia sensibile a pochi elementi probatori critici.
7. Presentare la conclusione indicando la probabilità relativa di tutte le ipotesi, non solo di quella vincente.
8. Individuare traguardi: osservazioni future che dimostrerebbero che gli eventi stanno seguendo un corso diverso.

L’idea centrale è la capacità diagnostica. Le prove coerenti con ogni ipotesi, come «l’indirizzo ha ricevuto molti input», non indicano quale sia vera, indipendentemente da quante se ne raccolgano. Un solo elemento incoerente con due ipotesi può risolvere la questione.

Una matrice ACH con un esempio svolto

Torniamo a bc1q…m4x2. L’analista raccoglie cinque elementi:

• E1, 38 input nell’arco di sei giorni: coerente con tutte e tre. Non è diagnostico.
• E2, sette degli input sono riconducibili, entro tre passaggi, ai proventi dell’exploit: coerente con H1 (gli exchange ricevono fondi da chiunque) e H3, incoerente con H2 a meno che il «proprietario» non sia il ladro, nel qual caso si tratta di H3.
• E3, la transazione di spesa spende anche i fondi di altri 112 indirizzi che una fonte pubblica di etichette contrassegna come indirizzi di deposito di un exchange: coerente solo con H1, secondo la logica dell’euristica degli input comuni (si veda L’euristica della titolarità comune degli input).
• E4, l’output principale va a un indirizzo attivo da lungo tempo, contrassegnato come hot wallet di quell’exchange: coerente solo con H1.
• E5, la spesa ha pagato 2 sat/vB durante un fine settimana tranquillo: coerente con tutte e tre. Non è diagnostico.

H1 non presenta incoerenze; H2 e H3 ne presentano rispettivamente due o tre. Nel passaggio sulla sensibilità si chiede quindi quali elementi sostengano la conclusione: E3 ed E4, entrambi basati su un’unica fonte di etichette. Se tale fonte è errata, H1 crolla. Prima di riferire i risultati, l’analista verifica quindi l’etichetta in modo indipendente, per esempio confermando che lo schema di sweep si ripete su molti indirizzi di deposito. Il traguardo da monitorare: se bc1q…m4x2 dovesse mai inviare fondi a un indirizzo diverso dall’hot wallet noto dell’exchange, l’interpretazione come indirizzo di deposito si indebolirebbe e H1 meriterebbe un nuovo esame.

In pratica, i fondi sono probabilmente arrivati a un servizio di custodia, quindi il passo successivo è richiedere i registri attraverso una procedura legale, anziché proseguire con la tracciatura on-chain.

Focus sull’esame: le cinque qualità di una buona domanda analitica e come riformulare una richiesta vaga; domande descrittive, esplicative ed estimative; gli elementi di una dichiarazione dell’ambito, compresi gli intervalli espressi in altezze dei blocchi, i limiti di passaggi e le regole di arresto presso i servizi di custodia; perché la profondità della tracciatura cresce rapidamente (3^5 = 243 percorsi); formulare ipotesi concorrenti, includendone una innocua; pregiudizi comuni (di conferma, ancoraggio, da automazione, di chiusura prematura e di trascuratezza del tasso di base) e i relativi rimedi; i passaggi dell’ACH di Heuer, la classificazione in base alle incoerenze, la capacità diagnostica, l’analisi di sensibilità e i traguardi.