Euristiche del modello basato su account

Le blockchain basate su account, come Ethereum, non offrono all'analista nessuno dei due strumenti fondamentali di Bitcoin: ogni transazione ha esattamente un mittente e i saldi rimangono nello stesso account, quindi non esistono input spesi congiuntamente né output di resto. Gli utenti possono comunque creare tutti gli indirizzi che desiderano, e molti lo fanno. Il raggruppamento in cluster su queste blockchain si basa sui comportamenti relativi a servizi, token e contratti, e le evidenze sono più deboli e meno validate rispetto a quelle delle blockchain UTXO.

Che cosa cambia nel modello basato su account

Su una blockchain basata su account, un singolo indirizzo contiene spesso l'intera cronologia di un utente: ciò rende ogni indirizzo più ricco di informazioni, ma non fornisce alcuna regola intrinseca per collegarlo a un altro. Victor (2020, "Euristiche di raggruppamento degli indirizzi per Ethereum") ha proposto tre euristiche: il riutilizzo degli indirizzi di deposito, la partecipazione multipla agli airdrop (più indirizzi che richiedono ciascuno un airdrop di token e poi inoltrano i token a un unico indirizzo comune) e l'autoautorizzazione tramite approvazioni di token. Ha riscontrato che, nei primi quattro anni di Ethereum, queste euristiche hanno raggruppato in cluster il 17,9% di tutti gli account a proprietà esterna (EOA) attivi. L'articolo dichiara apertamente che non erano disponibili dati di riferimento certi con cui misurarne l'accuratezza. Un successivo studio open source sulla privacy di Ethereum e Tornado Cash (Wu et al., 2022) ha applicato la più solida delle tre, il riutilizzo degli indirizzi di deposito, e ha individuato 26 milioni di EOA raggruppati in 2,5 milioni di cluster; verificato rispetto a 1.028 cluster ricavati da record di servizi di denominazione, il suo richiamo era del 39,4%. Questi sono i dati meglio documentati disponibili e mostrano che la maggior parte dei collegamenti non viene individuata e che la precisione rimane in gran parte non misurata.

Le euristiche riportate di seguito sono elencate approssimativamente dalla più solida alla più debole.

Riutilizzo degli indirizzi di deposito

Molti exchange custodial assegnano a ciascun cliente un indirizzo di deposito univoco e ne trasferiscono integralmente il saldo a un hot wallet a intervalli regolari (si veda la lezione Tracciamento attraverso exchange e servizi di custodia). Se due EOA inviano entrambi fondi allo stesso indirizzo di deposito, probabilmente gli importi vengono accreditati sullo stesso account cliente e, pertanto, i due EOA sono probabilmente controllati dalla stessa persona od organizzazione. Questa è l'euristica degli indirizzi di deposito di Victor ed è la più produttiva tra le regole del modello basato su account.

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

-- Possibili indirizzi di deposito e mittenti che collegano
WITH forwards AS (           -- transfers: una riga per movimento di ETH o token
  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 ciascun trasferimento in entrata a un trasferimento in uscita dallo stesso indirizzo verso un hot wallet di un exchange etichettato entro 2.000 blocchi, esclude i mittenti che sono essi stessi servizi noti e mantiene gli indirizzi di deposito utilizzati da almeno due mittenti. Una versione per l'uso operativo verifica anche che l'importo inoltrato sia prossimo a quello ricevuto e che l'indirizzo inoltri i fondi con regolarità nel tempo. La finestra di 2.000 blocchi è un'ipotesi da documentare, non uno standard.

Casi di errore: una persona che versa fondi sull'account di un amico o del datore di lavoro presso un exchange; processori di pagamento e operatori over-the-counter che effettuano depositi per conto dei clienti; exchange che riassegnano o condividono indirizzi di deposito; e l'errore di etichettare un normale indirizzo di inoltro come indirizzo di deposito.

Schemi di finanziamento del gas

Un nuovo EOA ha bisogno della valuta nativa per pagare il gas prima di poter compiere qualsiasi operazione. Il suo primo trasferimento in entrata proviene spesso dallo stesso operatore; pertanto, molti nuovi EOA finanziati da un unico indirizzo in un breve intervallo, con importi simili e attività successive analoghe, suggeriscono un controllo comune. I team che gestiscono gli airdrop utilizzano questo schema per individuare partecipanti fittizi, ed è una pista utile nelle indagini sugli exploit (si veda la lezione Analisi di exploit e attacchi informatici).

Il punto debole è che il finanziatore è spesso un servizio. I wallet di prelievo degli exchange, i bridge e i faucet finanziano un numero enorme di utenti non correlati, quindi è necessario verificare i finanziatori rispetto alle etichette dei servizi prima di stabilire 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 basato su account e la ricostruzione dei saldi spiega perché il soggetto che paga il gas e il firmatario siano due questioni distinte.

Approvazioni di token

Una chiamata ERC-20 approve consente a un soggetto autorizzato a spendere di trasferire token dal saldo del titolare 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 titolare, il terzo è il soggetto autorizzato a spendere e il campo data è l'importo autorizzato. La maggior parte delle approvazioni indica un contratto, ad esempio un router DEX. L'euristica di autoautorizzazione di Victor collega un titolare a un soggetto autorizzato a spendere quando quest'ultimo è un altro EOA, sulla base del ragionamento che raramente le persone consentono all'indirizzo personale di uno sconosciuto di spendere i propri token.

Il caso di errore più grave è la frode. Il phishing delle approvazioni induce le vittime ad approvare un indirizzo controllato da un attaccante e queste approvazioni appaiono esattamente come un'autoautorizzazione. Prima di stabilire un collegamento, verificare se il soggetto autorizzato a spendere abbia svuotato il saldo del titolare poco dopo; in tal caso, il collegamento è tra vittima e ladro, non indica un unico titolare.

Collegamenti tramite il deployer dei contratti

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

Casi di errore: contratti factory pubblici che chiunque può utilizzare (come creatore compare la factory, non l'utente), servizi di deployment, chiavi del deployer compromesse e codice open source copiato. Un bytecode identico dimostra la condivisione del codice, non del controllo.

Segnali temporali, nonce e denominazione

Distribuzione temporale. Gli indirizzi gestiti dalla stessa persona o dallo stesso bot condividono spesso uno schema di attività giornaliero, agiscono negli stessi blocchi o si alternano con un ritmo fisso. Béres et al. (2020, "La blockchain vi osserva: profilazione e deanonimizzazione degli utenti di Ethereum") hanno utilizzato profili basati sull'ora del giorno e 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 sia attivo un indirizzo e in quale ordine si siano svolte le sue azioni; più indirizzi i cui nonce avanzano in sincronia, ciascuno dei quali invia una transazione per ciclo in un ordine fisso, suggeriscono che siano gestiti da un unico script.

Servizi di denominazione. ENS collega i nomi agli indirizzi tramite record diretti (dal nome all'indirizzo) e record inversi facoltativi (dall'indirizzo al nome principale). Un record inverso viene impostato dal titolare dell'indirizzo, quindi costituisce un'autodichiarazione; verificare che il record diretto del nome rimandi allo stesso indirizzo. I nomi scadono e possono essere registrati nuovamente da qualcun altro, quindi occorre registrare il blocco in cui è stato osservato il collegamento. Molti nomi sono personali; trattarli come descritto nella lezione Dall'indirizzo all'entità alla persona: attribuzione ed etichettatura.

Insidie specifiche delle blockchain basate su account

Non raggruppare mai in cluster 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; i relayer e i servizi di meta-transazioni fanno lo stesso. Collegare tutto ciò che un bundler o un relayer ha inviato comporterebbe l'accorpamento di migliaia di utenti. Lo stesso vale per i contratti che detengono i fondi di molti utenti, come i pool DEX e i bridge.

I wallet basati su smart contract aggiungono un'ulteriore complicazione. Un wallet contrattuale multifirma è un unico indirizzo controllato da più EOA firmatari, il cui elenco può essere letto dallo stato del contratto. I firmatari collaborano, ma possono essere persone diverse; trattare il wallet come l'entità e i firmatari come parti correlate, non come un unico cluster.

Poiché ogni segnale del modello basato su account è debole se considerato isolatamente, una buona pratica consiste nel richiedere due segnali indipendenti prima di stabilire un collegamento, ad esempio il finanziamento del gas da un indirizzo che non appartiene a un servizio unito a una sincronizzazione temporale, e nel registrarli entrambi nella tabella delle evidenze, ciascuno con il proprio grado di solidità.

Focus sull'esame: perché le blockchain basate su account non dispongono delle euristiche degli input comuni e del resto; le tre euristiche di Victor (riutilizzo degli indirizzi di deposito, partecipazione multipla agli airdrop, autoautorizzazione) e perché la loro accuratezza sia in gran parte non misurata (copertura del 17,9% senza dati di riferimento certi, richiamo del 39,4% per il riutilizzo degli indirizzi di deposito); deduzione degli indirizzi di deposito dall'inoltro verso hot wallet; finanziamento del gas e perché i finanziatori che sono servizi, i paymaster e gli sponsor EIP-7702 interrompano il collegamento; lettura di un log Approval e falso positivo dovuto al phishing delle approvazioni; collegamenti tramite deployer con CREATE e CREATE2 e insidie delle factory; evidenze relative a distribuzione temporale, nonce ed ENS e relativi limiti; non raggruppare mai in cluster in base all'indirizzo mittente di un bundler o di un relayer.