Layer 2, catene laterali e altre chain

Molti percorsi si allontanano da Ethereum e Bitcoin e conducono a rollup, catene laterali, Tron o Solana, dove il modello dei dati, i timestamp, le regole di finalità e gli strumenti disponibili sono tutti diversi. Un esaminatore che applica a queste chain le abitudini maturate con Ethereum interpreterà male i movimenti dei token, collocherà gli eventi nel momento sbagliato e non individuerà gli operatori che conservano i dati. Questa lezione esamina cosa aggiunge ciascuna famiglia al quadro probatorio e come lavorare su una chain che i tuoi strumenti supportano appena.

Depositi e prelievi dai rollup come prove

I meccanismi sono descritti nella lezione IDFE-BA Layer 2, catene laterali e bridge come fonti di dati. Ecco gli aspetti forensi.

I depositi da L1 a L2 sono collegamenti deterministici. Sulle chain OP Stack, il portale L1 emette TransactionDeposited e la L2 crea una transazione di deposito senza firma (tipo 0x7E), il cui sourceHash viene calcolato a partire dall'hash del blocco L1 e dall'indice del log: una chiave di collegamento esatta. Poiché la transazione L2 non ha firma, l'autorità e l'attribuzione derivano dal mittente L1. Su Arbitrum, un ticket retryable che non riesce a essere riscattato automaticamente può restare in attesa fino a una settimana, quindi un deposito L1 può produrre il suo effetto L2 giorni dopo. Quando un contratto L1 invia il messaggio, il suo indirizzo L2 viene sottoposto ad alias (con l'aggiunta di 0x1111…1111); cerca l'alias, non l'indirizzo originale.

I prelievi canonici dai rollup optimistic vengono avviati su L2 e completati su L1 dopo un periodo di contestazione che su molte chain dura circa una settimana. Sulle chain OP Stack si articolano in tre passaggi (avvio su L2, prova su L1, finalizzazione su L1) collegati da un hash del prelievo; Arbitrum non prevede un passaggio separato di prova. Questo ritardo rappresenta un'opportunità investigativa: non appena l'avvio è visibile, conosci il destinatario L1 e il momento più vicino in cui i fondi possono arrivare, con giorni di anticipo. Se il destinatario è un indirizzo di deposito di un exchange, è possibile avvisare l'exchange prima che arrivino i fondi (vedi la lezione Opzioni di congelamento e sequestro). Due avvertenze: l'indirizzo che prova o finalizza è spesso un relayer, non il proprietario; inoltre, i periodi di contestazione variano da una chain all'altra e cambiano con l'evoluzione dei sistemi di prova, quindi annota il parametro in vigore alla data interessata, consultando la documentazione della chain.

Poiché una settimana è un periodo lungo, spesso i responsabili escono dai rollup attraverso bridge di liquidità, che pagano su L1 utilizzando i fondi di un relayer e sostituiscono il collegamento canonico con il proprio ID di deposito del bridge (vedi la lezione Bridge: lock-and-mint, burn-and-release e bridge di liquidità).

Dati del sequencer e dei batch

La maggior parte dei rollup ha un unico sequencer che ordina le transazioni, assegna timestamp L2 entro i limiti imposti dal protocollo e pubblica batch su L1. Questo comporta tre conseguenze per le prove:

• La finalità è stratificata. Una transazione confermata solo dal sequencer può ancora essere riorganizzata; una derivata da dati pubblicati su L1 è più sicura; una derivata da blocchi L1 finalizzati è definitiva. Annota quale head hai consultato e la transazione L1 che ha ancorato il batch.
• La copia su L1 scade in parte. Dal 13 marzo 2024, la maggior parte dei rollup pubblica i batch come blob, che i nodi di consenso eliminano dopo circa 18 giorni; su L1 rimane solo un hash versionato. Se devi dimostrare che la cronologia L2 può essere ricostruita indipendentemente dai nodi della L2, conserva i dati dei blob entro tale finestra oppure indica l'archivio di blob su cui ti sei basato (vedi la lezione Conservazione delle prove on-chain).
• Il sequencer è un operatore. I sequencer sono solitamente gestiti da una società o da una fondazione che riceve le transazioni tramite i propri endpoint RPC. La registrazione dei metadati di invio, come gli indirizzi IP, e la durata della loro conservazione dipendono dalle relative policy; il sequencer è un possibile destinatario di una richiesta precisa, come qualsiasi fornitore di servizi. Lo stesso vale per gli altri provider RPC utilizzati dal wallet del soggetto.

Catene laterali e app-chain

L'affidabilità della cronologia di una catena laterale dipende dalla sua serie di validatori. Una chain con pochi validatori può essere bloccata, aggiornata o, nel peggiore dei casi, controllata da chi detiene la maggioranza delle chiavi: nel furto di Ronin del marzo 2022, cinque delle nove chiavi dei validatori sono state usate per firmare prelievi dal bridge. Ai fini probatori, annota il consenso e le regole di finalità della chain in vigore al momento, la serie di validatori se pubblicata e se ti sei basato sull'unico explorer della chain o su un nodo gestito da te. I bridge verso le catene laterali sono solitamente firmati dai validatori, perciò un collegamento del bridge «deterministico» è deterministico solo nei limiti della fiducia riposta in quei validatori; specificalo nel rapporto.

Flussi di Tron e USDT

Tron veicola una quota rilevante degli USDT in circolazione e ricorre continuamente nei casi di truffe, operazioni OTC e conversione in denaro contante. La sua macchina virtuale è compatibile con EVM, quindi i trasferimenti TRC-20 emettono lo stesso evento Transfer dei trasferimenti ERC-20 (vedi la lezione IDFE-BA Altri modelli di chain che gli analisti incontrano). I blocchi arrivano circa ogni tre secondi. Ecco gli aspetti rilevanti nei casi:

• Formati degli indirizzi. Gli indirizzi T… sono codifiche Base58Check di un byte di prefisso 0x41 più un corpo di 20 byte. Converti gli indirizzi in esadecimale per collegarli agli strumenti EVM e includi l'identificativo della chain in ogni riga, perché gli stessi 20 byte su Ethereum corrispondono a un account diverso.
• Pagatori delle commissioni. I trasferimenti consumano banda ed energia, che possono essere delegate o noleggiate. L'account che ha pagato con le proprie risorse potrebbe essere un servizio di noleggio, non il mittente, e non costituisce prova di controllo.
• Attivazione. Un nuovo indirizzo in genere diventa attivo quando riceve TRX per la prima volta. Il mittente che lo attiva, spesso un prelievo da un exchange o un servizio di noleggio, è un indizio utile.
• Congelamenti da parte dell'emittente. Il contratto USDT consente all'emittente di congelare un indirizzo, emettendo AddedBlackList, e in seguito di bruciare il saldo congelato, emettendo DestroyedBlackFunds. Prima di descrivere come disponibili i fondi che stai tracciando, controlla se sono stati congelati e quando.

-- USDT su Tron ricevuti dagli indirizzi del soggetto, con eventuali congelamenti dell'emittente sul destinatario
SELECT t.txid, t.block_time, t.to_hex, t.amount_raw / 1e6 AS usdt,
       f.block_time AS frozen_at
FROM trc20_transfers t
LEFT JOIN usdt_freeze_events f
  ON f.target_hex = t.to_hex AND f.event_name = 'AddedBlackList'
WHERE t.token_contract = 'TR7N…Lj6t'          -- Contratto USDT su Tron (troncato)
  AND t.to_hex IN ('41a3c9…7e10', '41f08b…22c4') -- Indirizzi del soggetto in formato esadecimale
  AND t.block_time >= TIMESTAMP '2026-06-16 00:00:00'
ORDER BY t.block_time;

La query elenca i trasferimenti USDT ricevuti dagli indirizzi del soggetto, converte l'importo grezzo usando le 6 cifre decimali del token e associa l'ora di qualsiasi evento di congelamento che indichi il destinatario. La LEFT JOIN mantiene gli indirizzi non congelati, per i quali frozen_at è vuoto. I nomi delle tabelle e delle colonne dipendono dal dataset; prima di eseguire la query, occorre calcolare e verificare la forma esadecimale di ciascun indirizzo.

Solana e altri modelli di account

Il modello di Solana è illustrato nella lezione IDFE-BA Altri modelli di chain che gli analisti incontrano. Aspetti forensi:

• Account di token, non wallet. I token si spostano tra account di token; associa ciascuno al suo proprietario al momento del trasferimento, perché la proprietà può essere riassegnata.
• Identificativi e tempo. Una transazione è identificata dalla sua prima firma; si trova in uno slot e blockTime è un orario Unix stimato. Annota sia lo slot sia l'orario.
• Cronologia. Molti nodi RPC conservano solo la cronologia recente; per la cronologia completa occorrono nodi d'archivio o provider. Indica la fonte e ripeti la query su un campione utilizzando una seconda fonte.
• Differenze di saldo. I saldi precedenti e successivi nelle metadati della transazione mostrano l'effetto netto di chiamate complesse ai programmi in modo più affidabile rispetto alla decodifica di ogni istruzione interna.
• Pagatori delle commissioni. Come su Tron, il pagatore delle commissioni può essere un servizio o un relayer.

Le chain Cosmos collegate da IBC offrono una chiave esatta per il collegamento cross-chain (porta di origine, canale e sequenza del pacchetto), che rende i trasferimenti IBC collegamenti deterministici.

Confronto tra le famiglie:

Per ogni passaggio, annota la chiave di collegamento, l'altezza del blocco, l'orario UTC, lo stato di finalità e la fonte dei dati.

Chain senza strumenti adeguati

Prima o poi, un percorso raggiunge una chain che i tuoi strumenti non riescono a decodificare. Segui una lista di controllo prestabilita e annota ogni passaggio:

1. Leggi la documentazione: modello dei dati, formato degli indirizzi, identificativi, timestamp e finalità, facendo riferimento a una versione datata.
2. Recupera i dati da due fonti: preferibilmente dal tuo nodo; altrimenti, da due explorer o API indipendenti. Salva le risposte grezze e calcolane l'hash (vedi la lezione Calcolo dell'hash, registrazione e catena di custodia).
3. Convalida usando dati noti: ricalcola un saldo che puoi verificare e decodifica una transazione di cui conosci già il significato, come un deposito su un exchange di cui possiedi i registri.
4. Decodifica con prudenza: riporta solo i campi che hai convalidato e indica gli altri come non interpretati.
5. Sfrutta i punti di entrata e di uscita: il bridge o l'exchange attraverso cui i fondi sono entrati e usciti dalla chain solitamente conserva dati migliori di quelli mostrati dall'explorer della chain.
6. Dichiara i limiti: fonte unica, decodificatore non convalidato, cronologia mancante. Un limite dichiarato chiaramente è difendibile; uno nascosto no (vedi la lezione Strumenti, riproducibilità e convalida).

Focus sull'esame: depositi OP Stack e sourceHash come chiave di collegamento, con attribuzione tramite il mittente L1; ritardi dei retryable di Arbitrum e alias degli indirizzi; prelievi canonici (tre passaggi sulle chain OP Stack) e periodo di contestazione come tempo utile per avvisare un exchange; relayer che fungono da dimostratori e finalizzatori; finalità stratificata, eliminazione dei blob dopo circa 18 giorni e conservazione dei dati dei batch; sequencer e provider RPC come possibili detentori di dati; fiducia nei validatori delle catene laterali; conversione degli indirizzi Tron, pagatori delle risorse, attivazione ed eventi di congelamento USDT; account di token, firme, slot e cronologia d'archivio di Solana; chiavi dei pacchetti IBC; lista di controllo per le chain senza strumenti adeguati.