---
title: "Campionamento della disponibilità dei dati (DAS)"
description: "Guida orientata alla verifica di campionamento probabilistico, erasure coding, commitment, PeerDAS, custody, indipendenza dei peer e limiti di ricostruzione."
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.
# Campionamento della disponibilità dei dati (DAS)
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Il Data Availability Sampling consente a un nodo di richiedere un sottoinsieme definito dal protocollo di unità autenticate e sottoposte a erasure coding, formulando un giudizio probabilistico locale sulla sufficiente pubblicazione dell'oggetto vincolato dal commitment. Il nodo non scarica l'intero oggetto. Un campione riuscito aumenta la fiducia solo rispetto a codifica, soglia di ricostruzione, selezione, diversità dei peer, tempi e modello avversario dichiarati.
Una prova KZG o di cella lega l'unità restituita a un commitment; non dimostra l'esistenza di sufficienti altre unità. Un esito locale positivo non prova automaticamente ricostruzione globale, validità dell'esecuzione, finalità, settlement del rollup, uscita o archivio permanente. PeerDAS è uno specifico design Ethereum con colonne, celle, gruppi di custody, rete e fork choice dipendenti dalla versione.
## Come funziona
1. Fissare oggetto e specifica: chain, rete, fork, client e revisione; slot, block root e commitment dei blob; dimensioni originali ed estese; definizioni di cella, riga, colonna e gruppo di custody; decisione locale richiesta.
2. Verificare codifica e ricostruzione: algoritmo di estensione, commitment, unità originali e codificate, minimo recuperabile e rifiuto delle estensioni malformate. Il campionamento ha senso solo se nascondere abbastanza unità da bloccare la ricostruzione crea una regione rilevabile.
3. Definire universo e procedura: popolazione, insieme nascosto, numero di campioni, selezione con o senza reinserimento, casualità, unicità, custody, peer, timeout, tentativi e deduplicazione. Custody deterministica e campionamento casuale sono prove diverse.
4. Dichiarare il modello prima del calcolo. Per frazione fissa `f` e `s` campioni uniformi indipendenti con reinserimento, `P_miss = (1 - f)^s`. Senza reinserimento si usa il rapporto fra combinazioni. Peer correlati, casualità distorta, eclipse, servizio adattivo e selezione dei retry invalidano il modello semplice.
5. Recuperare da peer diversi entro la scadenza. Verificare header canonico, inclusione del blob, commitment, indice, prova KZG e byte; registrare separatamente risposte mancanti, non valide e tardive. Ripetere una colonna non fornisce nuova prova indipendente.
6. Applicare le regole locali di availability e fork choice; registrare separatamente propagazione e ricostruzione di rete, validità, stati safe e finalized, retention e archivio. Non estendere un esito locale oltre la garanzia del protocollo.
7. Simulare withholding, codifica errata, prove non valide, attacchi eclipse e Sybil, servizio selettivo, campioni correlati, partizioni, timeout, pruning, modifiche dei parametri, riorganizzazioni e disaccordo fra client. Ricostruire davvero e conservare richieste, risposte, prove e versioni.
## Esempi svolti
- **Campionamento indipendente con reinserimento.** In un modello didattico viene nascosto `50%` e il nodo esegue `30` campioni uniformi indipendenti. La probabilità di mancato rilevamento è `0.5^30 = 0.0000000009313225746`; quella di rilevamento è `99.9999999069%`. Non è una garanzia operativa di PeerDAS.
- **Obiettivo probabilistico.** Con `25%` nascosto e massimo `0.000001`, servono `ceil(log(0.000001) / log(0.75)) = 49` campioni. Con `48`, `0.75^48 = 0.0000010067940558701114` resta sopra l'obiettivo; con `49`, vale `0.75^49 = 0.0000007550955419025835`.
- **Senza reinserimento.** Su `128` colonne, `64` sono disponibili e `64` nascoste. Estraendo `8` colonne distinte, la probabilità di evitare quelle nascoste è `C(64,8) / C(128,8) = 0.0030958642767920487`; il rilevamento è `99.6904135723%`. Differisce da `0.5^8 = 0.00390625`.
- **Snapshot Fulu.** Nella specifica verificata il `2026-08-12`, `NUMBER_OF_COLUMNS = 128`, `SAMPLES_PER_SLOT = 8`, `NUMBER_OF_CUSTODY_GROUPS = 128` e `CUSTODY_REQUIREMENT = 4`. Le quote minime sono `8 / 128 = 6.25%` e `4 / 128 = 3.125%`. Se il nodo custodisce `12` gruppi e usa il maggiore fra `8` e `12`, richiede `12 / 128 = 9.375%`. Sono parametri versionati.
## Rischi
- Campionare chain, rete, fork, slot, blocco o oggetto errati.
- Fidarsi di header obsoleto, non canonico o riorganizzato.
- Usare dati con estensione di erasure coding errata.
- Accettare prova KZG, di cella o inclusione non valida.
- Confondere autenticità del commitment e disponibilità.
- Raccogliere troppo pochi campioni per il modello di minaccia.
- Scambiare formule con e senza reinserimento.
- Usare casualità distorta, prevedibile o manipolabile.
- Contare duplicati o retry come campioni indipendenti.
- Campionare peer, subnet o gruppi di custody correlati.
- Subire isolamento eclipse o Sybil.
- Consentire servizio selettivo o adattivo dopo la scelta.
- Scambiare timeout, congestione o guasto client per withholding.
- Confondere custody deterministica e campionamento casuale.
- Assumere una quota nascosta incompatibile con la soglia.
- Fallire la ricostruzione per limiti di CPU, memoria, banda o software.
- Subire guasti di gossip, request-response, subnet o cross-seeding.
- Estrapolare un esito locale alla disponibilità globale.
- Confondere DAS con validità, finalità, settlement o uscita.
- Ignorare modifiche a retention, archivio, fallback, fork, blob o parametri.
## Errori comuni
- Un campione riuscito prova la disponibilità dell'intero oggetto.
- Una prova KZG o di cella è da sola prova di disponibilità.
- Più richieste forniscono sempre prove indipendenti.
- DAS valida l'esecuzione e rende finale la chain.
- I dati disponibili ora resteranno archiviati per sempre.
## Argomenti correlati
- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Light client](/it/crypto/light-client/)
- [Rete peer-to-peer](/it/crypto/peer-to-peer-network/)
## Fonti
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultato: 2026-08-12)
- [PeerDAS](https://ethereum.org/roadmap/fusaka/peerdas/) - Ethereum.org (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)
- [Fulu -- Data Availability Sampling Core](https://ethereum.github.io/consensus-specs/specs/fulu/das-core/) - Ethereum Consensus Specs (consultato: 2026-08-12)
- [Fulu -- Networking](https://ethereum.github.io/consensus-specs/specs/fulu/p2p-interface/) - Ethereum Consensus Specs (consultato: 2026-08-12)
- [Fulu -- Fork Choice](https://ethereum.github.io/consensus-specs/specs/fulu/fork-choice/) - Ethereum Consensus Specs (consultato: 2026-08-12)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (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)
Source: https://wiki.fcontext.com/it/crypto/data-availability-sampling/index.mdx