Zum Inhalt springen
Financial Context Wiki

Data Availability Sampling (DAS)

Prüfungsorientierter Leitfaden zu probabilistischem Data Availability Sampling, Erasure Coding, Commitments, PeerDAS, Custody, Peer-Unabhängigkeit und Rekonstruktionsgrenzen.

Aktualisiert

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

Direkte Antwort

Data Availability Sampling ermöglicht einem Node, eine protokolldefinierte Teilmenge authentifizierter, per Erasure Coding erweiterter Dateneinheiten anzufordern und probabilistisch lokal zu beurteilen, ob das per Commitment gebundene Objekt ausreichend veröffentlicht wurde, um rekonstruierbar zu sein. Der Node lädt nicht das vollständige Objekt. Ein erfolgreicher Sample erhöht das Vertrauen nur unter den angegebenen Annahmen zu Kodierung, Rekonstruktionsschwelle, Auswahl, Peer-Vielfalt, Frist und Angreifermodell.

Ein KZG- oder Cell Proof bindet die zurückgegebene Einheit an ein Commitment; er beweist nicht, dass genügend weitere Einheiten existieren. Ein lokaler Sampling-Erfolg beweist nicht automatisch netzweite Rekonstruktion, Ausführungsgültigkeit, Konsensfinalität, Rollup-Abwicklung, Nutzerausstieg oder dauerhafte Archivierung. PeerDAS ist ein konkretes Ethereum-Design mit versionsspezifischen Columns, Cells, Custody Groups, Netzwerk- und Fork-Choice-Regeln.

Funktionsweise

  1. Objekt und Spezifikation festlegen: Chain, Netzwerk, Fork, Client und Revision; Slot, Block Root und Blob Commitments; ursprüngliche und erweiterte Dimensionen; Definitionen von Cell, Row, Column und Custody Group; lokale Verfügbarkeitsentscheidung.
  2. Kodierung und Rekonstruktion prüfen: Erweiterungsalgorithmus, Commitment, originale und kodierte Einheiten, Mindestzahl zur Wiederherstellung und Ablehnung fehlerhafter Erweiterungen. Sampling ist nur aussagekräftig, wenn genügendes Zurückhalten zur Verhinderung der Rekonstruktion einen erkennbaren Bereich erzeugt.
  3. Grundgesamtheit und Verfahren definieren: Population, zurückgehaltene Menge, Samplezahl, Auswahl mit oder ohne Zurücklegen, Zufallsquelle, Eindeutigkeit, Custody, Peers, Timeout, Wiederholung und Deduplizierung. Deterministische Custody und zufällige Samples sind unterschiedliche Evidenz.
  4. Wahrscheinlichkeitsmodell vor der Rechnung angeben. Für festen Anteil f und s unabhängige gleichverteilte Samples mit Zurücklegen gilt P_miss = (1 - f)^s. Ohne Zurücklegen ist das Verhältnis von Kombinationen zu verwenden. Korrelierte Peers, verzerrter Zufall, Eclipse, adaptive Bereitstellung und Wiederholungsselektion entkräften das einfache Modell.
  5. Innerhalb der Frist von vielfältigen Peers abrufen. Kanonischen Header, Blob-Inklusion, Commitment, Index, KZG Cell Proof und Bytes prüfen; fehlende, ungültige und verspätete Antworten getrennt erfassen. Dieselbe Column erneut abzufragen ist keine neue unabhängige Evidenz.
  6. Lokale Availability- und Fork-Choice-Regeln des Protokolls anwenden; Netzverbreitung und Rekonstruktion, Gültigkeit, sichere und finalisierte Zustände, Aufbewahrung und Archiv getrennt erfassen. Einen lokalen Erfolg nicht über die Protokollgarantie hinaus verallgemeinern.
  7. Withholding, fehlerhafte Kodierung, ungültige Proofs, Eclipse- und Sybil-Angriffe, selektive Bereitstellung, korrelierte Samples, Partitionen, Timeouts, Pruning, Parameteränderungen, Reorganisationen und Client-Abweichungen erproben. Tatsächlich rekonstruieren und Anfragen, Antworten, Proofs und Versionen aufbewahren.

Durchgerechnete Beispiele

  • Unabhängiges Sampling mit Zurücklegen. In einem Lehrmodell werden 50% zurückgehalten und ein Node zieht 30 unabhängige gleichverteilte Samples. Die Nichtentdeckungswahrscheinlichkeit beträgt 0.5^30 = 0.0000000009313225746, die Entdeckungswahrscheinlichkeit 99.9999999069%. Das ist keine Live-Garantie für PeerDAS.
  • Zielwahrscheinlichkeit. Bei 25% zurückgehaltenen Einheiten und maximal 0.000001 sind ceil(log(0.000001) / log(0.75)) = 49 Samples nötig. Bei 48 ergibt sich 0.75^48 = 0.0000010067940558701114, noch über dem Ziel; bei 49 gilt 0.75^49 = 0.0000007550955419025835.
  • Ohne Zurücklegen. Von 128 Columns sind 64 abrufbar und 64 zurückgehalten. Bei 8 verschiedenen Samples ist die Wahrscheinlichkeit, alle zurückgehaltenen zu verfehlen, C(64,8) / C(128,8) = 0.0030958642767920487; die Entdeckungswahrscheinlichkeit ist 99.6904135723%. Dies unterscheidet sich von 0.5^8 = 0.00390625.
  • Fulu-Snapshot. In der am 2026-08-12 geprüften Spezifikation gelten NUMBER_OF_COLUMNS = 128, SAMPLES_PER_SLOT = 8, NUMBER_OF_CUSTODY_GROUPS = 128 und CUSTODY_REQUIREMENT = 4. Mindestanteile sind 8 / 128 = 6.25% und 4 / 128 = 3.125%. Verwahrt ein Node 12 Gruppen und gilt das Maximum aus 8 und 12, fordert er 12 / 128 = 9.375% an. Dies sind versionierte Parameter.

Risiken

  • Falsche Chain, Netzwerk, Fork, Slot, Block oder Datenobjekt sampeln.
  • Veraltetem, nicht kanonischem oder reorganisiertem Header vertrauen.
  • Fehlerhaft erweiterte Erasure-Code-Daten verwenden.
  • Ungültigen KZG-, Cell- oder Inklusionsnachweis akzeptieren.
  • Commitment-Authentizität mit Verfügbarkeit verwechseln.
  • Für das Bedrohungsmodell zu wenige Samples sammeln.
  • Formeln mit und ohne Zurücklegen vertauschen.
  • Verzerrten, vorhersehbaren oder manipulierbaren Zufall verwenden.
  • Duplikate oder Wiederholungen als unabhängige Samples zählen.
  • Korrelierte Peers, Subnetze oder Custody Groups sampeln.
  • Durch Eclipse- oder Sybil-Angriffe isoliert werden.
  • Selektive oder adaptive Bereitstellung nach Bekanntgabe der Samples zulassen.
  • Timeout, Überlastung oder Clientfehler als Withholding einstufen.
  • Deterministische Custody mit zufälligem Sampling verwechseln.
  • Einen zur Rekonstruktionsschwelle unpassenden Withholding-Anteil annehmen.
  • Wegen CPU-, Speicher-, Bandbreiten- oder Implementierungsgrenzen scheitern.
  • Gossip-, Request-Response-, Subnetz- oder Cross-Seeding-Ausfälle erleiden.
  • Lokalen Erfolg auf netzweite Verfügbarkeit extrapolieren.
  • DAS mit Gültigkeit, Finalität, Abwicklung oder Ausstieg verwechseln.
  • Änderungen bei Aufbewahrung, Archiv, Fallback, Fork, Blobplan oder Parametern übersehen.

Häufige Irrtümer

  • Ein erfolgreicher Sample beweist die Verfügbarkeit des vollständigen Objekts.
  • Ein KZG- oder Cell Proof ist selbst ein Verfügbarkeitsnachweis.
  • Mehr Anfragen liefern immer unabhängige Evidenz.
  • DAS validiert die Ausführung und finalisiert die Chain.
  • Jetzt verfügbare Daten bleiben dauerhaft archiviert.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...