Una blockchain può rendere disponibili i dati delle transazioni per consentirne la verifica, senza promettere di conservarli per sempre. Se in seguito non riusciamo a recuperare un vecchio dato, il problema potrebbe riguardare l’archivio, anche quando la pubblicazione iniziale è avvenuta correttamente.
La distinzione conta quando una rete presenta il proprio servizio come un livello di data availability. Prima di considerarlo un archivio permanente, conviene separare tre domande: i dati sono stati pubblicati, chi li conserva e come potremo recuperarli in futuro?
Tre domande diverse sui dati blockchain
| Concetto | La domanda a cui risponde |
|---|---|
| Disponibilità dei dati, o data availability (DA) | I dati necessari alla verifica sono stati pubblicati e resi accessibili secondo le regole del protocollo? |
| Conservazione storica | Chi mantiene i dati precedenti nel tempo? |
| Recuperabilità | È possibile ottenere in seguito proprio i dati che ci servono? |
Le tre funzioni sono collegate, ma una non assicura automaticamente le altre. Una copia conservata è utile se possiamo ottenerla. Allo stesso modo, una verifica positiva della disponibilità non promette una conservazione illimitata. Le FAQ di Celestia, in inglese, chiariscono proprio questo punto.
Perché un hash non sostituisce una copia
Un hash o un commitment crittografico può aiutare a controllare che i dati ricevuti corrispondano a un riferimento registrato. Non fornisce però i dati mancanti. Se un progetto mostra un commitment, serve comunque una fonte da cui ottenere i dati sottostanti.
La disponibilità non sostituisce neppure il controllo della validità delle transazioni. Avere gli elementi necessari e verificare che il calcolo rispetti le regole sono due requisiti distinti. La documentazione Ethereum sulla data availability spiega perché, in assenza degli input, non è possibile una verifica indipendente.
I blob di Ethereum: pubblicazione con durata limitata
Ethereum ha introdotto i blob con EIP-4844, implementata nell’aggiornamento Dencun. Un rollup può usarli per pubblicare dati delle transazioni. La conservazione prevista dal protocollo è limitata: non significa che ogni nodo manterrà quei dati indefinitamente. Il riferimento è la guida Ethereum alle strategie di archiviazione dei dati.
I blob sono anche diversi dallo spazio di memorizzazione ordinario degli smart contract. Il loro contenuto completo non è direttamente accessibile durante l’esecuzione nella EVM, mentre sono utilizzabili riferimenti a quel contenuto. La specifica EIP-4844 descrive questa scelta.
Immaginiamo di voler recuperare un vecchio gruppo di transazioni di un rollup che utilizzava i blob. Sapere che quei dati sono stati pubblicati non identifica il servizio che li fornirà oggi. Occorre verificare come il rollup gestisce il proprio archivio storico, senza dedurre una conservazione permanente dal solo utilizzo di Ethereum.
Celestia: verificare la disponibilità senza scaricare tutto
Celestia separa la disponibilità dei dati dall’esecuzione e dal livello di settlement, dove vengono verificati e consolidati i risultati delle transazioni. I suoi nodi leggeri utilizzano il data availability sampling (DAS): richiedono piccole porzioni casuali dei dati codificati di un blocco e controllano le prove che le accompagnano. Nelle condizioni previste dal sistema, i campioni ricevuti permettono di valutare la disponibilità senza che ogni nodo leggero scarichi il blocco intero. Il meccanismo è descritto nella panoramica del livello DA di Celestia.
Il campionamento non è un servizio di archiviazione. La documentazione Celestia su recuperabilità e pruning spiega che i nodi possono eliminare dati meno recenti. Applicazioni e rollup devono organizzare la conservazione della propria storia; l’accesso ai nodi di archivio pubblici non dovrebbe essere l’unica soluzione prevista.
Che cosa serve a un nuovo nodo
Supponiamo che un nuovo nodo di un rollup debba rielaborare i blocchi precedenti per ricostruirne la storia. Una verifica positiva della disponibilità eseguita in passato non gli consegna quei blocchi. Servono dati storici accessibili oppure un metodo di avvio adeguato e supportato. Anche il percorso di recupero deve quindi essere documentato.
Lo stato attuale non è tutta la storia
Lo stato descrive il sistema in un determinato momento: per esempio, i saldi e i dati degli smart contract. La cronologia delle transazioni registra invece i cambiamenti che hanno portato a quel risultato. Una fotografia dello stato attuale e un archivio completo delle transazioni hanno quindi scopi diversi.
È la differenza tra consultare il saldo di un conto e leggerne gli estratti: il saldo non mostra tutti i pagamenti precedenti. Allo stesso modo, una copia dello stato attuale di una blockchain non fornisce automaticamente ogni transazione storica o ogni stato passato. La documentazione Ethereum descrive le informazioni degli account e distingue nei blocchi lo stato dalle transazioni.
Le domande utili prima di affidarsi a un servizio dati
Quando leggi la documentazione di una rete o di un’applicazione, cerca tre risposte:
- Quali dati sono inclusi? Un commitment, un blocco completo, gli input delle transazioni e una copia dello stato non sono intercambiabili.
- Chi conserva la storia e per quanto tempo? Cerca responsabilità definite e una politica di conservazione esplicita.
- Come si recuperano i dati? Verifica il punto di accesso, le condizioni d’uso e le alternative se un fornitore smette di rispondere.
Una descrizione utile chiarisce sia il meccanismo di pubblicazione sia il successivo percorso di recupero. Per ripassare il termine, puoi consultare la voce Data Availability del glossario BlockChainDudes, in inglese.
Capire la garanzia dietro l’etichetta
Quando un progetto dichiara che i dati sono «disponibili», chiediti che cosa significhi per l’uso che vuoi farne. Verificare un nuovo blocco, mantenere un archivio e recuperare un vecchio dato sono lavori diversi. Capire chi svolge ciascuno di questi compiti aiuta a valutare che cosa puoi ottenere davvero e quali risposte mancano ancora. Se sviluppi un’applicazione, verifica chi è responsabile della conservazione dei dati storici e attraverso quale percorso l’applicazione potrà recuperarli.
