Zum Inhalt springen
Financial Context Wiki

Datenverfügbarkeit

Ein verifikationsorientierter Leitfaden zu Datenpublikation, Abrufbarkeit, Commitments, Gültigkeit, Finalität, Sampling, Aufbewahrung, Archiven, Rollup-Ableitung und ausführbarer Wiederherstellung.

Aktualisiert

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

Direkte Antwort

Datenverfügbarkeit bedeutet, dass hinreichende protokollspezifische Daten innerhalb des erforderlichen Fensters publiziert und abrufbar sind, damit die vorgesehenen Teilnehmer den relevanten Zustand prüfen, ableiten oder rekonstruieren können. Das erforderliche Objekt kann aus Transaktionseingaben, Zustandsdifferenzen, codierten Shares oder einem anderen definierten Batch-Format bestehen; eine erreichbare Website, ein RPC-Endpunkt oder eine Projekt-API genügt nicht.

Vier Aussagen sind zu trennen. Verfügbarkeit betrifft die rechtzeitige Publikation für Protokollteilnehmer. Abrufbarkeit betrifft die Frage, ob eine bestimmte Partei Bytes jetzt oder später abrufen kann. Gültigkeit betrifft die Regel- oder Proof-Konformität einer Zustandsänderung. Finalität betrifft die Frage, ob der Konsens das Commitment im normalen Protokollbetrieb noch ersetzen kann. Bindendes Commitment, KZG-Proof, Validity Proof oder finalisierte Inklusion beweisen allein nicht alle vier Aussagen; temporäre Verfügbarkeit ist kein dauerhaftes Archiv.

Funktionsweise

  1. Aussage vor der Messung definieren: exaktes Batch-, Blob-, Namespace- oder codiertes Datenobjekt, Protokoll und Version, vorgesehener Nutzer, erforderliche Ableitungs-, Prüf- oder Ausstiegsaufgabe sowie Verfügbarkeits-, Anfechtungs- und Wiederherstellungsfenster. Vollständige Daten sind nach diesem Protokoll hinreichende Daten, nicht eine undefinierte Kopie jeder Transaktion.
  2. Publikationsweg und Nachweise fixieren: Settlement-Chain, dedizierte DA-Chain, Calldata, Blob-Sidecar, externes Commitment oder Komiteezertifikat; Block-, Slot- und Batch-Kennungen; Codierung und Kompression; Commitment; sowie konsumierender Vertrag oder Bridge. Publikation an einer Stelle beweist nicht, dass ein anderer Verifizierer sie prüft.
  3. Bindung und Rekonstruktion unabhängig testen. Bytes ohne Projekt-API abrufen, Hash, KZG oder anderes Commitment und Inklusionsreferenz prüfen, Framing und Erasure Coding validieren, Batch decodieren und für die Zustandsableitung benötigte Eingaben reproduzieren. Ein gültiges Commitment ohne Bytes ist keine erfolgreiche Rekonstruktion.
  4. Akzeptanzmodell abbilden. Festhalten, ob Full Nodes das Objekt herunterladen, Light Nodes authentifizierte Shares sampeln, Validatoren Custody-Pflichten haben oder ein DA-Komitee ein Schwellenwertzertifikat signiert. Sampling-, Erasure-, Peer-Unabhängigkeits-, Schwellenwert-, Stake-, Schlüssel- und Eclipse-Annahmen sowie das tatsächlich vom Settlement- oder Bridge-Vertrag geprüfte Objekt benennen.
  5. Getrennte Zustände und Zeitachsen verfolgen: eingereicht, inkludiert, im Protokollfenster verfügbar, durch unabhängige Clients abrufbar, decodiert oder abgeleitet, ausführungsgültig, safe, finalisiert und archiviert. Ein Validity Proof kann beschränkte Berechnung beweisen, obwohl Daten für unabhängige Ableitung oder Betrieb nicht verfügbar sind.
  6. Aufbewahrung, Bootstrapping und Wirtschaftlichkeit messen. Mindestbereitstellung des Protokolls, Pruning, Archiv- und Snapshot-Anbieter, Anforderungen neuer Nodes, Roh- und codierte Bytes, Overhead, Einheitspreis, Proof- und Transaktionskosten, Kapazitätslimits, Subventionen und Fallback-Kosten erfassen. Langfristiger Abruf ist nach Ablauf temporärer DA eine zusätzliche Abhängigkeit.
  7. Ausfälle proben. Withholding, selektive Bereitstellung, korrelierte oder eclipsed Samples, Komiteeverlust, DA-Stillstand oder Fork, Settlement-Reorganisation, fehlende Frames, Archivverlust, Sequencer-Zensur und Gebührenspitzen testen. Sicheren Halt, Forced Inclusion, Wiederholung, Fallback, Rekonstruktion und Ausstieg mit tatsächlicher Software, Daten und Gas verifizieren und Commitments, Belege sowie unabhängige Archivnachweise aufbewahren.

Durchgerechnete Beispiele

  • Korrekte Einheiten der Datenkosten. Ein Batch enthält 400,000 bytes, deckt 2,000 transactions ab und kostet $0.00002 per byte. Die DA-Datengebühr beträgt 400,000 * $0.00002 = $8 per batch oder $8 / 2,000 = $0.004 per transaction. Steigt der Einheitspreis auf das Zehnfache von $0.00020 per byte, entstehen $80 per batch und $0.040 per transaction, nicht $0.04 per batch. Ausführung, Proof, Transaktions-Overhead, Archivierung und Marge sind ausgeschlossen.
  • Das Protokollbereitstellungsfenster ist kein Archivversprechen. Das EIP-4844-Mindestanforderungsfenster beträgt 4,096 epochs; mit 32 slots per epoch und 12 seconds per slot sind das 4,096 * 32 * 12 = 1,572,864 seconds oder 1,572,864 / 86,400 = 18.2044444444 days. Es ist in diesem Modell ein Protokollminimum und keine Garantie, dass ein Anbieter einen bestimmten Blob dauerhaft speichert.
  • Stilisierte Sampling-Wahrscheinlichkeit. Nur als Spielzeugmodell angenommen, ein Angreifer hält 50% der gleichförmig gesampelten erweiterten Shares zurück und 30 authentifizierte Samples seien unabhängig mit Zurücklegen. Die Wahrscheinlichkeit, dass alle den zurückgehaltenen Bereich verfehlen, beträgt 0.5^30 = 0.0000000009313225746; die Erkennungswahrscheinlichkeit beträgt somit 99.9999999069%. Dies ist keine Servicegarantie für ein aktives PeerDAS oder anderes Netzwerk; korrelierte Peers, verzerrtes Sampling, Codierungsparameter und adaptive Angriffe verändern das Ergebnis.
  • Komiteeschwelle ist nicht aktuelle Abrufbarkeit. Ein hypothetisches DA-Komitee erfordert 5-of-7 Signaturen. Sind drei Mitglieder nicht verfügbar, verbleiben 4, sodass kein neues Schwellenwertzertifikat entstehen kann. Ein altes Zertifikat mit 5 signatures beweist, dass der Schwellenwert gemäß seinen Regeln attestierte; es beweist weder aktuellen Byte-Abruf durch einen Nutzer noch Ausführungsgültigkeit oder Settlement-Finalität.

Risiken

  • Falsche Chain, falsches Batch, Blob, Namespace oder Protokollversion prüfen.
  • Commitment oder Zertifikat mit den zugrunde liegenden Bytes verwechseln.
  • Aktuellen Abruf von einem Endpunkt als protokollweite Verfügbarkeit behandeln.
  • Datenverfügbarkeit als Beweis der Ausführungsgültigkeit behandeln.
  • Verfügbarkeit oder Gültigkeit als Konsensfinalität behandeln.
  • Veralteten, unsicheren oder reorganisierten Settlement-Block referenzieren.
  • Protokoll-Aufbewahrungsfenster vor dem Datenabruf verpassen.
  • Von einem Archiv, Snapshot, Indexer oder einer Projekt-API abhängen.
  • Fehlerhaftes Framing, Kompression oder Erasure Coding akzeptieren.
  • Hash, KZG oder anderes Commitment nicht prüfen.
  • Zu wenige Shares für das erklärte Bedrohungsmodell sampeln.
  • Korrelierte Samples, Peers oder Custody-Gruppen für unabhängig halten.
  • Eclipse-Angriffe, verzerrte Peer-Auswahl oder selektive Bereitstellung erleiden.
  • Mit dem Verifizierer inkonsistente Erasure-Parameter oder Rekonstruktionsschwellen nutzen.
  • Von einem kolludierenden oder nicht verfügbaren DA-Komitee abhängen.
  • Bridge- oder Settlement-Vertrag ein schwächeres Objekt akzeptieren lassen als erwartet.
  • Daten durch Sequencer-Withholding, Zensur oder fehlende Batch-Frames verlieren.
  • DA-Stillstand, Fork, Reorganisation oder inkompatibles Client-Upgrade erleben.
  • Feststellen, dass Forced Inclusion, Fallback, Wiederherstellung oder Ausstieg nicht ausführbar ist.
  • Kapazität, Gebührenspitzen, Overhead, Archivkosten oder Subventionsende unterschätzen.

Häufige Missverständnisse

  • Ein Validity Proof beseitigt den Bedarf an Datenverfügbarkeit.
  • Ein Commitment oder KZG-Proof beweist, dass sämtliche Bytes abrufbar waren.
  • Finalisierte Inklusion bedeutet, dass Daten dauerhaft abrufbar bleiben.
  • Onchain-, Blob-, Dedicated-DA- oder Sampling-Labels bieten automatisch dieselbe Sicherheit.
  • Mehr Samples oder geringere Kosten beweisen allein die Überlegenheit eines DA-Designs.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...