Euristiche del modello account

Le blockchain basate su account, come Ethereum, non offrono all’analista nessuno dei due strumenti principali di Bitcoin: ogni transazione ha esattamente un mittente e i saldi restano nello stesso account, quindi non ci sono input spesi congiuntamente né output di resto. Gli utenti possono comunque creare tutti gli indirizzi che vogliono, e molti lo fanno. Il clustering su queste blockchain si basa sui comportamenti relativi a servizi, token e contratti, e le prove sono più deboli e meno convalidate rispetto alle blockchain UTXO.

Cosa cambia nel modello account

Su una blockchain basata su account, un singolo indirizzo spesso contiene l’intera cronologia di un utente: ogni indirizzo è quindi più ricco di informazioni, ma non esiste una regola integrata per collegarlo a un altro. Victor (2020, "Euristiche di clustering degli indirizzi per Ethereum") ha proposto tre euristiche: riutilizzo degli indirizzi di deposito, partecipazione multipla agli airdrop (più indirizzi che reclamano ciascuno un airdrop di token e poi trasferiscono i token a un unico indirizzo comune) e auto-autorizzazione tramite approvazioni dei token. Ha rilevato che, nei primi quattro anni di Ethereum, queste euristiche hanno raggruppato il 17,9% di tutti gli account esterni attivi (EOA). L’articolo ammette chiaramente che non esisteva una ground truth con cui misurarne l’accuratezza. Uno studio open source successivo sulla privacy di Ethereum e Tornado Cash (Wu et al., 2022) ha applicato la più efficace delle tre, il riutilizzo degli indirizzi di deposito, e ha rilevato 26 milioni di EOA raggruppati in 2,5 milioni di cluster; confrontando i risultati con 1.028 cluster ricavati dai record dei servizi di naming, il richiamo è stato del 39,4%. Sono i dati meglio documentati disponibili e mostrano che la maggior parte dei collegamenti non viene individuata e che la precisione è in gran parte non misurata.

Le euristiche seguenti sono elencate, all’incirca, dalla più efficace alla meno efficace.

Riutilizzo degli indirizzi di deposito

Molti exchange custodial assegnano a ciascun cliente un indirizzo di deposito univoco e trasferiscono periodicamente il suo saldo a un hot wallet (vedi la lezione Seguire il valore attraverso exchange e servizi). Se due EOA inviano entrambi fondi allo stesso indirizzo di deposito, è probabile che vengano accreditati sullo stesso account cliente e che quindi siano probabilmente controllati dalla stessa persona o organizzazione. Questa è l’euristica di Victor basata sugli indirizzi di deposito, ed è la regola più efficace del modello account.

Gli indirizzi di deposito non sono etichettati sulla blockchain, quindi devono essere dedotti: un indirizzo che riceve fondi e poco dopo inoltra quasi lo stesso importo a un wallet exchange noto.

-- Indirizzi di deposito candidati e mittenti che collegano
WITH forwards AS (
  SELECT t_in.to_address   AS deposit_addr,
         t_in.from_address AS sender
  FROM transfers t_in
  JOIN transfers t_out
    ON t_out.from_address = t_in.to_address
   AND t_out.block_number BETWEEN t_in.block_number
                              AND t_in.block_number + 2000
  JOIN labels hw
    ON hw.address = t_out.to_address AND hw.category = 'exchange_hot_wallet'
  LEFT JOIN labels svc
    ON svc.address = t_in.from_address
  WHERE svc.address IS NULL          -- i mittenti non devono essere servizi noti
)
SELECT deposit_addr, COUNT(DISTINCT sender) AS linked_senders
FROM forwards
GROUP BY deposit_addr
HAVING COUNT(DISTINCT sender) >= 2;

La query abbina ogni trasferimento in entrata a un trasferimento in uscita dallo stesso indirizzo verso un hot wallet exchange etichettato, entro 2.000 blocchi; esclude i mittenti che sono a loro volta servizi noti e mantiene gli indirizzi di deposito utilizzati da almeno due mittenti. Una versione destinata alla produzione verifica anche che l’importo inoltrato sia simile a quello ricevuto e che l’indirizzo inoltri fondi con regolarità nel tempo. La finestra di 2.000 blocchi è un’ipotesi da documentare, non uno standard.

Modalità di errore: una persona che versa fondi sull’account exchange di un amico o del datore di lavoro; processori di pagamento e desk over-the-counter che depositano per conto dei clienti; exchange che riassegnano o condividono gli indirizzi di deposito; e l’errore di classificare un normale indirizzo di inoltro come indirizzo di deposito.

Pattern di finanziamento del gas

Un EOA appena creato ha bisogno della valuta nativa per pagare il gas prima di poter fare qualsiasi cosa. Il suo primo trasferimento in entrata spesso proviene dallo stesso operatore; di conseguenza, molti EOA appena creati finanziati da un unico indirizzo in un breve intervallo, con importi simili e attività successiva simile, suggeriscono un controllo comune. I team che gestiscono gli airdrop usano questo pattern per individuare i partecipanti falsi, ed è un indizio utile nelle indagini sugli exploit (vedi la lezione Analizzare exploit e attacchi informatici).

Il punto debole è che chi fornisce i fondi è spesso un servizio. I wallet di prelievo degli exchange, i bridge e i faucet finanziano un numero enorme di utenti non correlati, quindi occorre verificare i finanziatori rispetto alle etichette dei servizi prima di tracciare qualsiasi collegamento. La sponsorizzazione del gas interrompe del tutto il collegamento: con ERC-4337, un paymaster può pagare le operazioni di un utente e, da EIP-7702 (attivato a maggio 2025), un EOA può delegare a del codice e far sì che uno sponsor invii e paghi le sue transazioni. La lezione Il modello account per gli analisti spiega perché il pagatore del gas e il firmatario sono questioni diverse.

Approvazioni dei token

Una chiamata approve di ERC-20 consente a uno spender di trasferire token dal saldo del proprietario ed emette un evento Approval:

{
  "address": "0x7d1a…c3E0",
  "topics": [
    "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
    "0x000000000000000000000000a1b2…009f",
    "0x000000000000000000000000c4d5…77e2"
  ],
  "data": "0x…ffffffff"
}

Il primo topic è l’hash della firma dell’evento Approval(address,address,uint256), il secondo è il proprietario, il terzo è lo spender e il campo data è l’importo autorizzato. La maggior parte delle approvazioni indica un contratto, ad esempio il router di un DEX. L’euristica di Victor dell’auto-autorizzazione collega un proprietario a uno spender quando quest’ultimo è un altro EOA, partendo dal presupposto che le persone raramente consentano all’indirizzo personale di uno sconosciuto di spendere i propri token.

La modalità di errore più grave è la frode. Il phishing delle approvazioni induce le vittime ad approvare un indirizzo controllato da un aggressore, e queste approvazioni appaiono identiche a quelle di auto-autorizzazione. Prima di stabilire un collegamento, controlla se lo spender ha svuotato il saldo del proprietario poco dopo; in tal caso, il collegamento è tra vittima e ladro, non tra un unico proprietario.

Collegamenti tramite il deployer dei contratti

Ogni contratto ha un creatore. Con CREATE, l’indirizzo del nuovo contratto deriva dall’indirizzo e dal nonce del deployer; con CREATE2 (EIP-1014), dal contratto che esegue il deploy, da un salt e dall’hash del codice di inizializzazione. I contratti distribuiti dallo stesso EOA spesso appartengono allo stesso team, e il deployer di un contratto di exploit è di solito un nodo chiave nel cluster dell’aggressore.

Modalità di errore: factory pubbliche utilizzabili da chiunque (come creatore appare la factory, non l’utente), servizi di deploy, chiavi del deployer compromesse e codice open source copiato. Il bytecode identico mostra l’uso di codice condiviso, non un controllo condiviso.

Segnali temporali, nonce e di naming

Temporizzazione. Gli indirizzi gestiti dalla stessa persona o dallo stesso bot spesso presentano un pattern di attività giornaliero comune, agiscono negli stessi blocchi o si alternano secondo un ritmo fisso. Béres et al. (2020, "La blockchain ti osserva: profilazione e deanonimizzazione degli utenti di Ethereum") hanno utilizzato i profili degli orari di attività e le impostazioni delle commissioni come quasi-identificatori. Le impostazioni delle commissioni sono diventate molto meno distintive dopo EIP-1559 (agosto 2021), quando la maggior parte dei wallet ha iniziato a calcolare automaticamente le commissioni.

Nonce. Il nonce di un EOA conta le transazioni che ha inviato. Le sequenze dei nonce rivelano quanto è attivo un indirizzo e in quale ordine sono avvenute le sue azioni; diversi indirizzi con nonce che avanzano in sincronia, ognuno dei quali invia una transazione per turno secondo un ordine fisso, suggeriscono che un unico script li stia gestendo.

Servizi di naming. ENS collega i nomi agli indirizzi tramite record diretti (nome verso indirizzo) e, facoltativamente, record inversi (indirizzo verso nome principale). Un record inverso è impostato dal proprietario dell’indirizzo, quindi si tratta di un’autodichiarazione; conferma che il record diretto del nome punti allo stesso indirizzo. I nomi scadono e possono essere registrati di nuovo da qualcun altro, quindi annota il blocco in cui hai osservato il collegamento. Molti nomi sono personali; trattali come descritto nella lezione Attribuzione ed etichettatura.

Insidie specifiche delle blockchain basate su account

Non raggruppare mai in base al campo from delle transazioni inviate da infrastrutture condivise. Un bundler ERC-4337 invia una singola transazione contenente le operazioni di molti utenti non correlati; lo stesso fanno i relayer e i servizi di meta-transazioni. Collegare tutto ciò che un bundler o un relayer ha inviato significherebbe unire migliaia di utenti. Lo stesso vale per i contratti che custodiscono i fondi di molti utenti, come i pool DEX e i bridge.

I wallet di smart contract aggiungono un’ulteriore complicazione. Un wallet multisig basato su contratto è un unico indirizzo controllato da più EOA firmatari, il cui elenco è consultabile nello stato del contratto. I firmatari cooperano, ma possono essere persone diverse; considera il wallet come l’entità e i firmatari come parti correlate, non come un unico cluster.

Poiché ogni segnale del modello account è debole da solo, una prassi affidabile consiste nel richiedere due segnali indipendenti prima di tracciare un collegamento, ad esempio il finanziamento del gas da un indirizzo non associato a un servizio e una temporizzazione sincronizzata, e nel registrare entrambi nella tabella delle prove con il rispettivo livello di confidenza.

Focus sull'esame: perché le blockchain basate su account non hanno euristiche basate su input comuni e output di resto; le tre euristiche di Victor (riutilizzo degli indirizzi di deposito, partecipazione multipla agli airdrop, auto-autorizzazione) e perché la loro accuratezza è in gran parte non misurata (copertura del 17,9% senza ground truth, richiamo del 39,4% per il riutilizzo degli indirizzi di deposito); deduzione degli indirizzi di deposito dai trasferimenti verso hot wallet; finanziamento del gas e perché i finanziatori che sono servizi, i paymaster e gli sponsor EIP-7702 lo rendono inefficace; lettura di un log Approval e il falso positivo del phishing delle approvazioni; collegamenti tramite deployer con CREATE e CREATE2 e insidie delle factory; prove basate su temporizzazione, nonce ed ENS e i loro limiti; mai raggruppare in base all’indirizzo mittente di un bundler o di un relayer.