Layer 2, sidechain e bridge come fonti di dati

Una quota considerevole dell'attività sulle reti di tipo Ethereum si svolge ormai su chain layer 2 e sidechain, anziché sulla chain di base. I fondi si spostano tra i layer attraverso i bridge, e ogni layer ha i propri blocchi, il proprio explorer e il proprio chain ID. Un analista che segue i fondi solo sul layer 1 li vede scomparire in un contratto bridge; chi capisce come i layer registrano depositi, prelievi e messaggi può seguirli nel passaggio e indicare quanto sia certa ogni connessione.

Una mappa del territorio

Per le prove, la distinzione importante riguarda dove risiedono i dati e chi potrebbe riscriverli. In linea di principio, la cronologia di un rollup può essere ricostruita da L1; quella di una sidechain è affidabile solo quanto i suoi validatori.

Sequencer e finalità su L2

La maggior parte dei rollup ha un unico sequencer che ordina le transazioni e produce rapidamente blocchi L2 (in genere ogni 2 secondi sulle chain OP Stack, e più rapidamente su alcune altre). Gli utenti ricevono dal sequencer una conferma «soft» entro pochi secondi; la transazione viene ancorata quando il sequencer pubblica il batch su L1 e considerata regolata quando quel blocco L1 raggiunge la finalità. La maggior parte dei rollup consente inoltre agli utenti di forzare l'invio di una transazione tramite L1 se il sequencer la censura.

Per l'analisi, questo crea una finalità a più livelli. I nodi OP Stack espongono le teste unsafe (solo sequencer), safe (derivate dai dati pubblicati su L1) e finalized (derivate da blocchi L1 finalizzati); i tag safe e finalized funzionano nelle chiamate JSON-RPC standard. Crea i dataset a partire da blocchi L2 safe o finalized, come faresti su L1 (vedi la lezione Blocchi e header come dati). Si sono verificate interruzioni dei sequencer su diversi rollup e la testa unsafe può essere riorganizzata.

Disponibilità dei dati: dove leggere i dati L2

Nella pratica, gli analisti leggono i dati L2 da nodi L2, explorer e data warehouse, proprio come su L1, con le stesse ricevute, gli stessi log e le stesse tracce. La copia su L1 è importante per la verifica e per comprendere i costi:

• Fino a marzo 2024, i rollup pubblicavano i batch come call data L1, conservati per sempre.
• Dall'upgrade Dencun (13 marzo 2024), la maggior parte li pubblica come blob (EIP-4844). I nodi di consenso L1 conservano i dati dei blob per 4.096 epoche, circa 18 giorni, poi li eliminano; nella transazione L1 rimane solo un hash con versione. Per ricostruire la vecchia cronologia L2 da L1 serve quindi un archivio dei blob.
• Alcuni rollup ZK pubblicano differenze di stato anziché transazioni, quindi la copia su L1 prova i saldi ma non elenca ogni trasferimento.

Per ogni dataset L2, registra il chain ID, l'intervallo di blocchi L2, il nodo o provider e, se pertinente, il blocco L1 che lo ha ancorato.

Da L1 a L2: depositi e messaggi

Un deposito trasferisce valore o un messaggio da L1 a L2. Sulle chain OP Stack, un utente (o il contratto bridge standard che agisce per suo conto) chiama su L1 OptimismPortal, che emette TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData). I nodi L2 leggono questi eventi e creano una transazione di deposito di tipo 0x7E all'inizio di un blocco L2 successivo. Un nodo OP Stack restituisce la transazione nel formato seguente:

{
  "type": "0x7e",
  "sourceHash": "0x3c9e…a0d4",
  "from": "0xA1b2…9F",
  "to": "0xA1b2…9F",
  "mint": "0x6f05b59d3b20000",
  "value": "0x6f05b59d3b20000",
  "gas": "0x186a0",
  "input": "0x"
}

Una transazione di deposito non ha una firma: la sua autorità deriva dall'evento L1. mint è l'ETH creato su L2 (qui 0,5 ETH), corrispondente all'ETH bloccato nel portal su L1. sourceHash identifica univocamente l'origine L1 ed è calcolato a partire dall'hash del blocco L1 e dall'indice del log dell'evento; per questo è la chiave di join esatta tra l'evento L1 e la transazione L2. In un data warehouse che memorizza il tipo come intero, queste righe hanno tipo 126.

Arbitrum usa i retryable ticket: una chiamata L1 a createRetryableTicket sul contratto Inbox crea un ticket che normalmente viene riscattato automaticamente su L2. Se il riscatto automatico non riesce, il ticket resta in attesa per un massimo di una settimana, durante la quale può essere riscattato manualmente; un analista potrebbe quindi osservare un deposito su L1 il cui effetto su L2 si verifica giorni dopo.

Entrambe le famiglie applicano l'aliasing degli indirizzi. Quando un contratto L1 invia un messaggio a L2, il suo indirizzo su L2 viene traslato aggiungendo 0x1111000000000000000000000000000000001111, così non può impersonare un contratto L2 con lo stesso indirizzo. Un messaggio dal contratto L1 0x5d3a…7c10 arriva quindi su L2 da 0x6e4b…8d21. Gli EOA non vengono aliasati. Un analista che cerca su L2 l'indirizzo del contratto L1 non troverà nulla: deve cercare l'alias.

Da L2 a L1: prelievi

Un prelievo canonico è un processo in più fasi che si svolge su due chain e dura diversi giorni. Sulle chain OP Stack:

1. Avvio su L2: l'utente chiama il predeploy L2ToL1MessagePasser all'indirizzo 0x4200…0016 (direttamente o tramite il bridge L2), che emette MessagePassed con un hash del prelievo.
2. Prova su L1: una volta che lo stato L2 contenente quel messaggio è stato proposto su L1, chiunque può inviare una prova a OptimismPortal, che emette WithdrawalProven(bytes32 indexed withdrawalHash, address indexed from, address indexed to).
3. Finalizzazione su L1: dopo la finestra di contestazione, chiunque può inviare la chiamata di finalizzazione; il portal emette WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success) e rilascia i fondi.

Su Arbitrum, il lato L2 chiama il precompile ArbSys (indirizzo 100, 0x…0064) con sendTxToL1 e, circa una settimana dopo, il messaggio viene eseguito su L1 tramite executeTransaction del contratto Outbox.

L'hash del prelievo collega tutte e tre le fasi. Due insidie: chi invia la prova o finalizza può essere chiunque, spesso un relayer, e non è necessariamente il proprietario; inoltre, le finestre di contestazione variano da una chain all'altra e cambiano con l'evoluzione dei sistemi di prova (alcune chain le hanno accorciate con sistemi di prova più recenti), quindi verifica quali parametri erano in vigore al momento. Poiché una settimana è un periodo lungo, molti utenti escono invece tramite bridge di terze parti o fornitori di liquidità, che pagano su L1 usando i propri fondi e interrompono il collegamento canonico; il confronto di questi flussi è trattato nella lezione Tracciamento cross-chain.

Chain ID e identità tra i layer

Ogni chain EVM ha un chain ID (EIP-155), restituito da eth_chainId e incorporato nelle transazioni firmate:

Indicizza ogni tabella usando insieme chain ID e indirizzo, mai solo l'indirizzo. La stessa chiave privata controlla lo stesso indirizzo EOA su ogni chain EVM, rendendo semplice l'identificazione cross-chain degli EOA. I contratti sono diversi: un indirizzo può ospitare un contratto su una chain e nulla, o il contratto di qualcun altro, su un'altra. Nel giugno 2022, circa 20 milioni di token OP furono inviati a un indirizzo su Optimism presso il quale esisteva solo su Ethereum il multisig del destinatario previsto; prima che il proprietario potesse implementarlo lì, un aggressore implementò a quell'indirizzo su Optimism un multisig diverso e si appropriò dei token. Lo stesso indirizzo non implica lo stesso proprietario, a meno che il codice e il deployment non siano verificati su ciascuna chain.

Un conteggio giornaliero dei depositi OP Stack mostra il filtro standard:

-- Depositi giornalieri da L1 a L2 su una chain OP Stack (tipo deposito 0x7E = 126)
SELECT
  CAST(block_timestamp AS DATE)     AS day,
  COUNT(*)                          AS deposits,
  SUM(mint) / 1e18                  AS eth_minted
FROM transactions
WHERE chain_id = 8453
  AND tx_type = 126
  AND block_timestamp >= TIMESTAMP '2026-01-01 00:00:00'
GROUP BY 1
ORDER BY 1;

La query filtra una sola chain e le transazioni di deposito, poi somma l'ETH creato. I nomi delle colonne variano tra i dataset (type o transaction_type; mint potrebbe non essere presente) e i tipi di timestamp differiscono in base al motore; controlla lo schema prima di considerare attendibile uno zero.

Focus sull'esame: differenze tra rollup ottimistici, rollup ZK e sidechain, e dove risiedono i dati di ciascuno; sequencer e teste unsafe, safe e finalized; blob dal marzo 2024 e la loro conservazione di circa 18 giorni; depositi OP Stack (TransactionDeposited, tipo 0x7E, mint, sourceHash come chiave di join) e retryable ticket di Arbitrum; aliasing degli indirizzi dei contratti L1 tramite l'aggiunta di 0x1111…1111; le fasi di avvio, prova e finalizzazione di un prelievo OP Stack e l'hash del prelievo che le collega; perché chi finalizza non è necessariamente il proprietario; chain ID, indicizzazione dei dati tramite chain ID più indirizzo e perché lo stesso indirizzo di contratto su due chain non implica lo stesso proprietario.