Archiviazione e sincronizzazione registri distribuiti: come i dati si conservano, si replicano e si verificano

Nel mondo delle blockchain, molti associano la parola blockchain a una grande log o registri condivisi. Ma la sfida reale è: come far convergere migliaia di macchine mutuamente distrutte verso una storia identica e uno stato coerente, senza un coordinatore centrale? A livello più basso, ogni nodo partecipante memorizza una sequenza di blocchi contenenti transazioni ordinate e state root — una Merkle root che vincola lo stato del sistema a una determinata altezza. L’innovazione non è la log append-only in sé; i log esistono da sempre. È la garanzia che ogni nodo onesto finisca con lo stesso log e lo stesso stato deterministico derivato da esso.

Monolithic Replication: Everyone Runs Everything

Nei ledger di prima e seconda generazione (Bitcoin, Ethereum pre Danksharding, l’attuale design di Solana), la replicazione è estremamente semplice: nodi completi scaricano ed eseguono ogni transazione dall’inizio. Questo offre garanzie di sicurezza molto forti — ogni nodo può verificare autonomamente l’intera storia — ma scala con difficoltà.

Un nodo Bitcoin completo oggi archivia circa 650 GB di blocchi e circa 6 GB di UTXO. Un nodo Ethereum archive supera i 14 TB perché conserva stati storici. Il fattore di replicazione è sostanzialmente pari al numero di nodi completi (decine di migliaia per Bitcoin, diverse migliaia per Ethereum mainnet). Incentivi economici (ricompense di mining, yield di staking) mantengono un numero sufficiente di operatori che eseguono software così pesante.

La Move to Modular Replication

A partire dal 2021–2022, l’industria ha accettato che la replica monolitica non possa sostenere throughput a scala globale. Progetti come Celestia, la roadmap Danksharding di Ethereum, Avail, Near DA e Polygon Avail convergono sull’idea che il consenso e la disponibilità dei dati (DA) possano essere separati dall’esecuzione.

In una pila modulare:

– Lo strato di consenso + disponibilità dei dati (DA) ordina le transazioni e garantisce che i dati del blocco restino disponibili per circa una o due settimane.

– Gli ambienti di esecuzione (EVM rollup, SVM rollup, VM personalizzate) elaborano le transazioni off-chain e pubblicano prove di frode o di validità compatte più differenze di stato sullo strato DA.

– I nodi completi sul DA scaricano comunque tutto, ma ce ne sono molti di meno.

– I nodi rollup completi scaricano solo i dati rilevanti per la propria catena.

Questo riduce drasticamente l’onere di replicazione per la maggior parte dei partecipanti, senza compromettere le garanzie crittografiche.

Data Availability Sampling (DAS)

La svolta che rende praticabile il DA modulare è il DAS, introdotto dal lavoro LazyLedger di Mustafa Al-Bassam e adottato da Celestia. DAS permette ai light client di verificare la disponibilità dei dati senza dover scaricare l’intero blocco.

Ecco come funziona nella pratica:

Celestia, mainnet lanciata nell’ottobre 2023, raggiunge blocchi di ~10–20 MiB utilizzando Reed-Solomon 2D e DAS. I light client hanno bisogno di circa 1–2 Mbps di banda sostenuta per rimanere al passo — compatibile con i dispositivi mobili.

State Synchronization Mechanics

Anche con il DAS risolto, i nodi devono comunque raggiungere uno stato identico. Tre approcci distintivi dominano oggi:

Fast sync / snapshot sync — la maggior parte dei nodi Ethereum ed EVM-compatibili non eseguono più dall’inizio. Scaricano uno stato recente root attendibile ( tramite checkpoint manuale o maggioranza onesta ), poi recuperano prove Merkle per account e slot di storage che interessano. Questa tecnica riduce da settimane a ore il tempo di sincronizzazione.

Parallel block propagation — la propagazione dei blocchi in parallelo. L’esempio di Solana con Turbine e l’approccio di Arweave con Blockweave spezzano i blocchi in shreds e li diffondono in modo rapido, permettendo a decine di migliaia di validatori di riceverli in pochi millisecondi.

State expiry and re-execution — i rollup come Arbitrum e Optimism garantiscono la disponibilità dei dati per 1–14 giorni. Dopo la finestra di challenge, vecchi stati vengono eliminati. Se servono prove storiche, si ri-esegue dallo stato conservato, scambiando archiviazione per ricomputazione occasionale.

Real-World Example 1 — Ethereum Danksharding (in progress)

Il Danksharding in via di sviluppo introdurrà le “blob-carrying transactions”. Invece di uno stato permanente, i rollup allegano blob di grandi dimensioni (fino a ~2 MB) che restano disponibili per circa 18 giorni (periodo di sfide di 4096 slot). I nodi scaricano i blob, i validatori attestano di averli visti e gli impegni KZG permettono a chiunque di verificarne l’inclusione.

Dopo la finestra, i blob vengono eliminati, ma lo stato root rimane per sempre nella beacon chain. Questo è il primo passo verso la separazione del modello monolitico di Ethereum.

Real-World Example 2 — Celestia + Rollups

Celestia è passata a blocchi inizialmente di 8 MiB nel 2023 e ha mirato a 64 MiB entro il 2025. I rollup come Dymension e Saga pubblicano i propri state root e le prove di frode su Celestia. Un rollup Dymension full node scarica circa 100–500 MB di dati storici, invece dell’intera storia multi-terabyte di Celestia. I light client verificano tutto tramite DAS e Namespaced Merkle Trees (NMT), che permettono di provare che i dati di un rollup siano stati inclusi sotto il proprio namespace.

Cross-Chain State Replication

Quando asset o messaggi si spostano tra ledger, una porzione di stato deve essere replicata tra chain. Tre pattern predominanti:

– Lock-and-mint bridges (es. Wormhole, LayerZero) — osservatori riportano header e prove Merkle.

– Light-client relayers (IBC, Polygon AggLayer, Near Rainbow) — nodi completi della chain A eseguono un light client di chain B all’interno della loro VM e viceversa.

– Shared sequencing + asynchronous state roots (Espresso, Astria) — più rollup concordano sull’ordinamento tramite un servizio comune, eliminando i tradizionali ponti.

Ogni approccio replica solo lo stato minimo necessario — tipicamente percorsi Merkle da un header a un evento specifico — piuttosto che intere catene.

Trade-offs No One Talks About Publicly

Una replica archivistica completa offre la massima resistenza alla censura e decentralizzazione, ma quasi nessun utente al dettaglio gestisce un archivio. La maggior parte delle metriche di decentralizzazione ora conta validatori segnati o light client, non replicatori indipendenti dello stato.

Gli strati di disponibilità dei dati riducono richieste hardware in modo significativo, ma aprono una nuova superficie di attacco: attacchi di withholding dei dati. Se i dati del blocco scompaiono prima che le prove siano finalizzate, la catena può arrestarsi. Per questo le soglie di fiducia del DAS sono impostate per essere estremamente alte (spesso 99.99% di certezza statistica).

Chiave di lettura e implicazioni pratiche

La tecnologia della disponibilità dei dati e della modularità non è fine a sé stessa: cambia radicalmente il modello di scalabilità e di governance delle blockchain. Per le startup e i progetti che costruiscono su DA, significa poter progettare environment di esecuzione dedicati, ottimizzando costi, tempi di sviluppo e affidabilità. Per gli investitori, significa nuove opportunità di finanziamento orientate a soluzioni di data availability e a esecuzioni modulari, piuttosto che a reti monolitiche tradizionali.

Conclusioni e prospettive

La transizione dalla replica monolitica a una modularità con DAS sta già permettendo a blockchain di scalare in modo più efficiente, mantenendo la verificabilità crittografica. Nei prossimi anni vedremo crescere una selezione di strati DA ad alta capacità sotto numerosi ambienti di esecuzione specializzati. La replicazione dello stato avverrà in modo selettivo, sincronizzato in modo probabilistico e verificato crittograficamente — una visione molto più complessa ma anche molto più potente rispetto al modello originale di un database condiviso immutabile.

Questa nuance è ciò che effettivamente consente al sistema di funzionare su larga scala.

Fonte di riferimento