Vai al contenuto
Financial Context Wiki

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

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.

Aggiornato

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

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.

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ù.

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.

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à.

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.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...