Zum Inhalt springen
Financial Context Wiki

Risiken eines Datenverfügbarkeitskomitees (DAC)

Prüfungsorientierter Leitfaden zu DAC-Attestierungen, q-von-n-Annahmeregeln, tatsächlichem Datenbesitz und -abruf, korrelierten Ausfallbereichen, Schlüsselrotation, Aufbewahrung, Rückfallverfahren und Ausstiegsrisiken.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Ein Datenverfügbarkeitskomitee ist eine begrenzte Gruppe von Mitgliedern, deren Signaturen oder Attestierungen die Protokollregel zur Annahme einer Behauptung über die Verfügbarkeit externer Daten erfüllen können. Das Zertifikat belegt nur, dass der konfigurierte Schlüsselsatz und Schwellenwert ein bestimmtes signiertes Objekt nach diesen Regeln akzeptiert haben. Es beweist nicht unabhängig, dass jeder Unterzeichner sämtliche Bytes abgerufen, dauerhaft gespeichert, aktuell bereitgestellt, die Ausführung validiert oder die Abwicklung finalisiert hat.

Sicherheit und Lebendigkeit sind verschieden. Akzeptiert der Vertrag q-of-n Signaturen, kann die Kontrolle über q gültige Schlüssel die Annahmeregel für ein nicht verfügbares Objekt erfüllen, sofern keine weitere Prüfung dies verhindert. Mit weniger als q willigen und erreichbaren Unterzeichnern entsteht normalerweise kein neues Zertifikat; Aktualisierungen stoppen oder nutzen ein dokumentiertes Rückfallverfahren. Die tatsächliche Wiederherstellung hängt zudem von ehrlichen Prüfungen vor der Signatur, unabhängigen Kopien, Aufbewahrung, Bereitstellungskapazität, Schlüssel- und Governancehistorie sowie ausführbarer Rekonstruktions- und Ausstiegssoftware ab.

Funktionsweise

  1. Deployment festlegen: Chain, Protokollmodus und -version, Abwicklungs- und Verfügbarkeitsprüfverträge, Batch und Datenobjekt, Kodierung, Commitment, Schlüsselsatz, Schwelle q, Mitgliederzahl n, Pflichtunterzeichner, Aktivierung, Ablauf, Widerruf und Governancebefugnis.
  2. Exakte signierte Aussage und Annahmelogik rekonstruieren. Domain, Chain- und Vertragsbindung, Batch-ID, Commitment oder State Root, Ablauf, Unterzeichner-Bitmap oder Aggregation, Replay-Schutz und tatsächliche Schwellenberechnung des Vertrags prüfen. Mitgliederlogo oder API-Antwort sind keine Annahmeregel.
  3. Von jedem Mitglied verlangen, vor der Signatur das vollständige Objekt abzurufen, Commitment und Kodierung zu prüfen, es zu dekodieren und die für unabhängige Zustandsableitung oder Nutzerausstieg erforderlichen Daten aufzubewahren. Dokumentieren, was attestiert wird und ob das Protokoll die Durchführung dieser Prüfungen beweisen kann.
  4. Unabhängige Ausfallbereiche abbilden, statt Namen zu zählen. Rechtsträger, wirtschaftliche Kontrolle, Cloud-Konten und -Regionen, DNS und Netzwerk, Software und Datenbanken, Schlüsselverwahrung, Speicher, Betrieb und Rechtsordnung ermitteln. Spiegel oder Endpunkte hinter einer gemeinsamen Steuerung sind keine unabhängigen Mitglieder.
  5. Besitz und Abruf testen. Aktuelle und historische Batches ohne Betreiber-API von mehreren Mitgliedern abrufen, Hashes und Roots prüfen, Zustand oder Auszahlungsnachweis rekonstruieren, Aufbewahrung und Datenübertragung messen und Zertifikatserstellung, aktuellen Abruf, Ausführungsgültigkeit, Konsensfinalität und Archivbeständigkeit trennen.
  6. Lebenszyklus und Wiederherstellung erproben: Mitglieder- und Schlüsselrotation, historische Schlüsselsätze, Ablauf und Widerruf, Verfügbarkeit unterhalb der Schwelle, kompromittierte Schwellenschlüssel, selektive Bereitstellung, Betreiberausfall, Rückfall auf vollständige Daten, Einfrier- oder Escape-Modus, erzwungene Aufnahme, unabhängige Archive sowie tatsächlicher Gas- und Zeitbedarf des Ausstiegs.
  7. Akzeptierte Unterzeichner-Bitmaps, Zertifikatsverzögerung, Abrufserfolg, Byte-Integrität, Speicheralter, Änderungen von Schlüsselsatz und Schwelle, Upgrades, Pausen und Rückfallkapazität überwachen. Zertifikate, Daten und Vertragszustand archivieren und das Engagement nicht erhöhen, wenn Zertifikate angenommen werden, unabhängiger Abruf oder Wiederherstellung aber nicht mehr funktionieren.

Durchgerechnete Beispiele

  • Schwellenlebendigkeit und -sicherheit sind nicht gleich. In einem beispielhaften 5-of-7-Komitee lassen zwei ausgefallene Mitglieder 5 Unterzeichner übrig; ein neues Zertifikat ist noch möglich. Bei drei Ausfällen bleiben 4, somit gilt 4 < 5 und die Zertifikatserstellung stoppt, sofern kein dokumentierter Rückfall greift. Umgekehrt kann die Kontrolle über 5 akzeptierte Schlüssel die Schwellenregel erfüllen; aktuellen Datenabruf oder Ausführungsgültigkeit beweist das Zertifikat dennoch nicht.
  • Unabhängiges Verfügbarkeitsmodell. Nur als IID-Lehrmodell sei jedes der 7 Mitglieder unabhängig mit Wahrscheinlichkeit 0.95 verfügbar und ein Zertifikat benötige mindestens 5. Dann gilt P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570; die modellierte Stillstandswahrscheinlichkeit beträgt 1 - 0.9962429570 = 0.0037570430. Gemeinsame Cloud-, Software-, Betreiber-, Rechts- oder Schlüsselabhängigkeiten machen diese Binomialschätzung ungültig.
  • Speicherkopien und Bereitstellung sind getrennt. Ein Batch umfasst 120 MB. Sieben vollständige unabhängige Kopien würden 120 * 7 = 840 MB speichern; persistieren ihn tatsächlich nur drei Mitglieder, sind es 120 * 3 = 360 MB, selbst wenn fünf Schlüssel signierten. Die einmalige Bereitstellung an 100 clients überträgt 120 * 100 = 12,000 MB; die Signaturzahl ist weder Kopienzahl noch Maß für Übertragungskapazität.
  • Rekonstruktionsschwelle. Ein Beispielobjekt enthält 1,024 records, aufgeteilt in 16 chunks mit je 64 records; die festgelegte Wiederherstellungsschwelle beträgt 12 chunks. Elf Fragmente legen 11 * 64 = 704 records offen, doch 11 < 12; nach dieser Regel ist keine Rekonstruktion möglich. Ein gültiges Komiteezertifikat ersetzt weder ein fehlendes Fragment noch ändert es die Schwelle.

Risiken

  • Falsche Chain, Vertrag, Deployment, Batch oder Protokollversion prüfen.
  • Signierte Aussage, Domain, Commitment oder Ablauf falsch rekonstruieren.
  • Replay über Chains, Verträge, Versionen oder historische Schlüsselsätze akzeptieren.
  • Ungültigen, veralteten, abgelaufenen oder widerrufenen Schlüsselsatz verwenden.
  • q, n, Pflichtunterzeichner, Bitmaps oder aggregierte Signaturen falsch lesen.
  • Implementierungsfehler bei Unterzeichner oder Vertragsprüfung ausnutzen.
  • Vor vollständigem Abruf, Integritätsprüfung und Speicherung signieren.
  • Teilweise, fehlerhafte oder falsch kodierte Daten akzeptieren.
  • Sicherheit durch Kompromittierung oder Kollusion der Schwellenschlüssel verlieren.
  • Lebendigkeit verlieren, weil weniger als die Schwelle signieren können.
  • Korrelierte Rechtsträger, Clouds, Regionen oder Betreiber als unabhängig zählen.
  • Gemeinsame DNS-, TLS-, Software-, Datenbank- oder Speichersteuerung nutzen.
  • Eclipse-Angriffen, selektiver Bereitstellung oder privatem Gateway ausgesetzt sein.
  • Daten nach Signatur oder vor Ende des Ausstiegsfensters löschen oder beschneiden.
  • Historischen Abruf durch Mitgliederwechsel oder Schlüsselrotation unterbrechen.
  • Governance Mitglieder ersetzen, Schwelle senken oder Verzögerung umgehen lassen.
  • Auf veraltetes, unsicheres oder reorganisiertes Abwicklungs-Commitment verweisen.
  • Gültigkeitsnachweis oder finalisierten Root mit aktuellem Datenabruf gleichsetzen.
  • Feststellen, dass Rückfall, Einfrieren, Zwangsaufnahme oder Ausstieg nicht ausführbar sind.
  • Speicher-, Übertragungs-, Wiederherstellungs-, Rückfall-, Gebühren- oder Kapazitätskosten unterschätzen.

Häufige Irrtümer

  • Mehr Komiteemitglieder bedeuten automatisch mehr unabhängige Ausfallbereiche.
  • q Signaturen beweisen, dass q dauerhafte Vollkopien öffentlich abrufbar sind.
  • Ein Gültigkeitsnachweis beseitigt die Notwendigkeit, DAC-Datenverfügbarkeit zu prüfen.
  • Ein altes gültiges Zertifikat garantiert aktuellen Abruf und dauerhaftes Archiv.
  • Ein ehrliches oder offizielles Mitglied garantiert jedem Nutzer jederzeitigen Ausstieg.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...