Vai al contenuto
Financial Context Wiki

Campionamento della disponibilità dei dati (DAS)

Guida orientata alla verifica di campionamento probabilistico, erasure coding, commitment, PeerDAS, custody, indipendenza dei peer e limiti di ricostruzione.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...