---
title: "Disponibilità dei dati"
description: "Guida orientata alla verifica di pubblicazione, reperibilità, commitment, validità, finalità, campionamento, conservazione, archivi, derivazione dei rollup e recupero eseguibile."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Disponibilità dei dati
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Disponibilità dei dati significa che dati sufficienti specificati dal protocollo vengono pubblicati e sono reperibili nella finestra richiesta, affinché i partecipanti previsti possano verificare, derivare o ricostruire lo stato rilevante. L’oggetto richiesto può essere costituito da input delle transazioni, differenze di stato, share codificate o altro formato di batch definito; non equivale alla disponibilità di sito web, endpoint RPC o API del progetto.
Quattro affermazioni vanno separate. La disponibilità riguarda la pubblicazione tempestiva ai fruitori del protocollo. La reperibilità riguarda la capacità di una parte specifica di recuperare i byte ora o in futuro. La validità riguarda il rispetto delle regole o dei vincoli della prova da parte della transizione di stato. La finalità riguarda la possibilità che il consenso sostituisca ancora il commitment durante il normale funzionamento. Commitment vincolante, prova KZG, prova di validità o inclusione finalizzata non dimostrano da soli tutte e quattro le affermazioni; disponibilità temporanea non significa archiviazione permanente.
## Come funziona
1. Definire l’affermazione prima di misurarla: batch, blob, namespace o oggetto codificato esatti; protocollo e versione; fruitore previsto; operazione richiesta di derivazione, verifica o uscita; finestre di disponibilità, contestazione e recupero. Dati completi significa dati sufficienti secondo quel protocollo, non una copia indefinita di ogni transazione.
2. Fissare percorso ed evidenze di pubblicazione: chain di settlement, chain DA dedicata, calldata, sidecar del blob, commitment esterno o certificato del comitato; identificatori di blocco, slot e batch; codifica e compressione; commitment; contratto o bridge che lo utilizza. La pubblicazione in un luogo non prova che un altro verificatore la controlli.
3. Testare separatamente legame e ricostruzione. Recuperare i byte senza API del progetto, verificarne hash, KZG o altro commitment e riferimento di inclusione, convalidare framing e codifica a cancellazione, decodificare il batch e riprodurre gli input necessari alla derivazione dello stato. Un commitment valido senza byte non è ricostruzione riuscita.
4. Mappare il modello di accettazione. Registrare se i full node scaricano l’oggetto, i light node campionano share autenticate, i validatori hanno obblighi di custodia o un comitato DA firma un certificato a soglia. Dichiarare ipotesi di campionamento, cancellazione, indipendenza dei peer, soglia, stake, chiavi ed eclipse e cosa verifichi davvero il contratto di settlement o bridge.
5. Tracciare stati e tempistiche distinti: inviato, incluso, disponibile nella finestra del protocollo, reperibile da client indipendenti, decodificato o derivato, valido in esecuzione, sicuro, finalizzato e archiviato. Una prova di validità può attestare computazione vincolata mentre i dati per derivazione o funzionamento indipendente restano indisponibili.
6. Misurare conservazione, bootstrap ed economia. Registrare minimo di servizio del protocollo, pruning, fornitori di archivi e snapshot, requisiti dei nuovi nodi, byte grezzi e codificati, overhead, prezzo unitario, costi di prova e transazione, limiti di capacità, sussidi e costi di fallback. La reperibilità a lungo termine è una dipendenza aggiuntiva dopo la scadenza della DA temporanea.
7. Provare i guasti. Testare withholding, servizio selettivo, campioni correlati o soggetti a eclipse, perdita del comitato, arresto o fork DA, riorganizzazione del settlement, frame mancanti, perdita dell’archivio, censura del sequencer e picchi di commissioni. Verificare arresto sicuro, inclusione forzata, nuovo tentativo, fallback, ricostruzione e uscita con software, dati e gas effettivi, quindi conservare commitment, ricevute e prove di archivio indipendenti.
## Esempi svolti
- **Unità corrette del costo dei dati.** Un batch contiene `400,000 bytes`, copre `2,000 transactions` e costa `$0.00002 per byte`. La tariffa DA è `400,000 * $0.00002 = $8 per batch`, ossia `$8 / 2,000 = $0.004 per transaction`. Se il prezzo unitario aumenta di dieci volte a `$0.00020 per byte`, il costo diventa `$80 per batch` e `$0.040 per transaction`, non `$0.04 per batch`. Esecuzione, prova, overhead di transazione, archiviazione e margine sono esclusi.
- **La finestra di servizio del protocollo non promette un archivio.** La finestra minima di richiesta EIP-4844 è `4,096 epochs`; con `32 slots per epoch` e `12 seconds per slot`, equivale a `4,096 * 32 * 12 = 1,572,864 seconds`, ossia `1,572,864 / 86,400 = 18.2044444444 days`. È un minimo di protocollo in questo modello, non garanzia che un fornitore conservi per sempre uno specifico blob.
- **Probabilità di campionamento stilizzata.** Si supponga, soltanto per un modello didattico, che un attaccante nasconda `50%` delle share estese campionate uniformemente e che `30` campioni autenticati siano indipendenti e con reinserimento. La probabilità che tutti evitino la regione nascosta è `0.5^30 = 0.0000000009313225746`, quindi la probabilità di rilevamento è `99.9999999069%`. Non è una garanzia di servizio di PeerDAS attivo o altra rete; peer correlati, bias, parametri di codifica e attacchi adattivi cambiano il risultato.
- **La soglia del comitato non equivale alla reperibilità attuale.** Un ipotetico comitato DA richiede firme `5-of-7`. Se tre membri non sono disponibili, ne restano `4`, quindi non è possibile formare un nuovo certificato a soglia. Un vecchio certificato con `5 signatures` prova che la soglia ha attestato secondo le proprie regole; non prova che un utente possa recuperare ora i byte, che l’esecuzione sia valida o il settlement finalizzato.
## Rischi
- Ispezionare chain, batch, blob, namespace o versione di protocollo errati.
- Confondere commitment o certificato con i byte sottostanti.
- Trattare il recupero corrente da un endpoint come disponibilità dell’intero protocollo.
- Trattare la disponibilità dei dati come prova di validità dell’esecuzione.
- Trattare disponibilità o validità come finalità del consenso.
- Fare riferimento a blocco di settlement obsoleto, non sicuro o riorganizzato.
- Perdere la finestra di conservazione prima di recuperare i dati.
- Dipendere da un archivio, snapshot, indexer o API del progetto.
- Accettare framing, compressione o codifica a cancellazione malformati.
- Non verificare hash, KZG o altro commitment.
- Campionare troppo poche share per il modello di minaccia dichiarato.
- Presumere indipendenti campioni, peer o gruppi di custodia correlati.
- Subire attacchi eclipse, selezione distorta dei peer o servizio selettivo.
- Usare parametri di cancellazione o soglie di ricostruzione incompatibili col verificatore.
- Dipendere da comitato DA colluso o indisponibile.
- Lasciare che contratto di bridge o settlement accetti un oggetto più debole del previsto.
- Perdere dati per withholding o censura del sequencer o frame del batch mancanti.
- Incontrare arresto, fork, riorganizzazione o upgrade client incompatibile di DA.
- Scoprire che inclusione forzata, fallback, recupero o uscita non sono eseguibili.
- Sottostimare capacità, picchi di commissioni, overhead, costi di archivio o fine dei sussidi.
## Errori comuni
- Una prova di validità elimina la necessità di disponibilità dei dati.
- Un commitment o una prova KZG dimostrano che tutti i byte erano reperibili.
- L’inclusione finalizzata significa che i dati restano reperibili permanentemente.
- Le etichette on-chain, blob, DA dedicata o campionamento forniscono automaticamente la stessa sicurezza.
- Più campioni o costi minori dimostrano da soli la superiorità di un design DA.
## Argomenti correlati
- [Blockchain modulare](/it/crypto/modular-blockchain/)
- [Rollup](/it/crypto/rollup/)
- [ZK Rollup](/it/crypto/zk-rollup/)
## Fonti
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultato: 2026-08-12)
- [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org (consultato: 2026-08-12)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-12)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consultato: 2026-08-12)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (consultato: 2026-08-12)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (consultato: 2026-08-12)
- [Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities](https://arxiv.org/abs/1809.09044) - arXiv (consultato: 2026-08-12)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (consultato: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/data-availability/index.mdx