---
title: "Rischio del comitato per la disponibilità dei dati (DAC)"
description: "Guida orientata alla verifica di attestazioni DAC, regole di accettazione q-su-n, possesso e recupero effettivi dei dati, domini di guasto correlati, rotazione delle chiavi, conservazione, fallback e rischio di uscita."
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.

# Rischio del comitato per la disponibilità dei dati (DAC)

> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

<a id="answer"></a>

## Risposta diretta

Un comitato per la disponibilità dei dati è un insieme circoscritto di membri le cui firme o attestazioni possono soddisfare la regola con cui un protocollo accetta una dichiarazione di disponibilità di dati offchain. Il certificato prova soltanto che il keyset e la soglia configurati hanno accettato uno specifico oggetto firmato secondo quelle regole. Non prova autonomamente che ogni firmatario abbia scaricato tutti i byte, ne abbia conservato una copia durevole, li renda disponibili ora, abbia validato l'esecuzione o abbia reso definitivo il settlement.

Safety e liveness sono distinte. Se il contratto accetta firme `q-of-n`, il controllo di `q` chiavi valide può soddisfare la regola per un oggetto indisponibile, salvo un controllo ulteriore. Con meno di `q` firmatari disponibili e consenzienti, di norma non si forma un nuovo certificato: gli aggiornamenti si arrestano o usano un fallback documentato. Il recupero effettivo dipende anche da verifiche oneste prima della firma, copie indipendenti, conservazione, capacità di servizio, storia delle chiavi e della governance e software eseguibile per ricostruzione e uscita.

<a id="mechanism"></a>

## Come funziona

1. Identificare il deployment: chain, modalità e versione del protocollo, contratti di settlement e verifica della disponibilità, batch e oggetto dati, codifica, commitment, keyset, soglia `q`, numero di membri `n`, firmatari obbligatori, attivazione, scadenza, revoca e autorità di governance.
2. Ricostruire esattamente dichiarazione firmata e logica di accettazione. Verificare dominio, legame con chain e contratto, ID del batch, commitment o state root, scadenza, bitmap o aggregazione dei firmatari, protezione dal replay e calcolo effettivo della soglia nel contratto. Logo di un membro o risposta API non costituiscono la regola.
3. Esigere che ogni membro scarichi l'oggetto completo prima di firmare, ne verifichi commitment e codifica, lo decodifichi e conservi i dati necessari alla derivazione indipendente dello stato o all'uscita degli utenti. Registrare cosa attestano i membri e se il protocollo può provare l'esecuzione di tali controlli.
4. Mappare domini di guasto indipendenti, non limitarsi a contare i nomi. Individuare entità giuridiche, controllo effettivo, account e regioni cloud, DNS e rete, software e database, custodia delle chiavi, storage, operazioni e giurisdizione. Mirror o endpoint dietro lo stesso piano di controllo non sono membri indipendenti.
5. Testare possesso e recupero. Scaricare batch recenti e storici da più membri senza l'API dell'operatore, verificare hash e root, ricostruire lo stato o una prova di prelievo, misurare conservazione ed egress e distinguere produzione del certificato, reperibilità attuale, validità dell'esecuzione, finalità del consenso e durata dell'archivio.
6. Esercitare ciclo di vita e recupero: rotazione di membri e chiavi, keyset storici, scadenza e revoca, disponibilità sotto soglia, compromissione delle chiavi, servizio selettivo, indisponibilità dell'operatore, fallback sui dati completi, modalità freeze o escape, inclusione forzata, archivi indipendenti e gas e tempo effettivi necessari all'uscita.
7. Monitorare bitmap accettate, ritardo dei certificati, successo del recupero, integrità dei byte, età dello storage, modifiche di keyset e soglia, upgrade, pause e capacità di fallback. Archiviare certificati, dati e stato dei contratti e non aumentare l'esposizione quando i certificati vengono accettati ma recupero indipendente o ripristino non funzionano più.

<a id="example"></a>

## Esempi svolti

- **Liveness e safety della soglia non coincidono.** In un comitato didattico `5-of-7`, due membri indisponibili lasciano `5` firmatari e consentono ancora un nuovo certificato; tre ne lasciano `4`, quindi `4 < 5` e la produzione si arresta senza fallback documentato. Viceversa, controllare `5` chiavi accettate soddisfa la soglia; il certificato non prova comunque reperibilità attuale dei byte o validità dell'esecuzione.
- **Modello di disponibilità indipendente.** Si supponga, soltanto come modello IID didattico, che ciascuno dei `7` membri sia disponibile indipendentemente con probabilità `0.95` e che servano almeno `5` firme. Allora `P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570`, quindi la probabilità modellata di arresto è `1 - 0.9962429570 = 0.0037570430`. Dipendenze comuni di cloud, software, operatore, legge o chiavi invalidano la stima binomiale.
- **Copie archiviate e servizio sono separati.** Un batch misura `120 MB`. Sette copie complete indipendenti occuperebbero `120 * 7 = 840 MB`; se solo tre membri lo conservano davvero, i byte archiviati sono `120 * 3 = 360 MB`, anche se hanno firmato cinque chiavi. Servire l'oggetto una volta a `100 clients` trasferisce `120 * 100 = 12,000 MB`: il numero di firme non è né il numero di copie né una misura della capacità di egress.
- **Soglia di ricostruzione.** Un oggetto didattico contiene `1,024 records`, divisi in `16 chunks` da `64 records`, con soglia di recupero dichiarata di `12 chunks`. Undici frammenti espongono `11 * 64 = 704 records`, ma `11 < 12`; secondo la regola l'oggetto non è ricostruibile. Un certificato valido non sostituisce un frammento mancante né modifica la soglia.

<a id="risks"></a>

## Rischi

- Esaminare chain, contratto, deployment, batch o versione errati.
- Ricostruire in modo errato dichiarazione firmata, dominio, commitment o scadenza.
- Accettare replay tra chain, contratti, versioni o keyset storici.
- Usare un keyset non valido, obsoleto, scaduto o revocato.
- Interpretare male `q`, `n`, firmatari obbligatori, bitmap o firme aggregate.
- Sfruttamento di bug nel firmatario o nella verifica del contratto.
- Firmare prima di scaricare, verificare e conservare tutti i dati.
- Accettare dati parziali, malformati o codificati in modo errato.
- Perdere safety per compromissione o collusione delle chiavi di soglia.
- Perdere liveness perché possono firmare meno membri della soglia.
- Contare come indipendenti entità, cloud, regioni od operatori correlati.
- Condividere piani di controllo DNS, TLS, software, database o storage.
- Subire attacchi eclipse, servizio selettivo o dipendenza da gateway privato.
- Eliminare o sottoporre a pruning i dati dopo la firma o prima della fine della finestra di uscita.
- Interrompere il recupero storico con avvicendamento dei membri o rotazione delle chiavi.
- Consentire alla governance di sostituire membri, ridurre la soglia o aggirare ritardi.
- Fare riferimento a un commitment di settlement obsoleto, non sicuro o riorganizzato.
- Scambiare una prova di validità o root finalizzata per reperibilità attuale.
- Scoprire che fallback, freeze, inclusione forzata o uscita non sono eseguibili.
- Sottostimare costi di storage, egress, recupero, fallback, commissioni o capacità.

<a id="misconceptions"></a>

## Errori comuni

- Più membri implicano automaticamente più domini di guasto indipendenti.
- `q` firme provano che esistono `q` copie complete durevoli e pubblicamente reperibili.
- Una prova di validità elimina la necessità di verificare la disponibilità dei dati DAC.
- Un vecchio certificato valido garantisce recupero attuale e archivio permanente.
- Un membro onesto o ufficiale garantisce che ogni utente possa sempre uscire.

<a id="related"></a>

## Argomenti correlati

- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Rollup](/it/crypto/rollup/)
- [Finalità](/it/crypto/finality/)

<a id="sources"></a>

## Fonti

- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultato: 2026-08-13)
- [Validium](https://ethereum.org/developers/docs/scaling/validium/) - Ethereum.org (consultato: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (consultato: 2026-08-13)
- [starkex-data-availability-committee](https://github.com/starkware-libs/starkex-data-availability-committee) - StarkWare Industries Ltd. (consultato: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultato: 2026-08-13)
- [SequencerInbox.sol](https://github.com/OffchainLabs/nitro-contracts/blob/main/src/bridge/SequencerInbox.sol) - Offchain Labs (consultato: 2026-08-13)

Source: https://wiki.fcontext.com/it/crypto/data-availability-committee-risk/index.mdx