Zum Inhalt springen
Financial Context Wiki

Blobspace

Ein prüfungsorientierter Leitfaden zu Ethereum-Blobspace, codierter und nutzbarer Kapazität, PeerDAS-Sampling und -Custody, temporärer Aufbewahrung, Rollup-Derivation und aktuellen forkabhängigen Limits.

Aktualisiert

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

Direkte Antwort

Blobspace ist Ethereums begrenzte, temporäre Datenverfügbarkeitskapazität für Blobs, die neben Blöcken committed werden. Er ist weder EVM-Ausführungs-Blockspace noch Contract Storage, dauerhaftes Dateisystem oder Token. Eine Typ-3-Transaktion enthält versionierte Hashes; authentifizierte Blob-Daten werden über Sidecars der Consensus Layer oder PeerDAS-Datenspalten übertragen. Die EVM kann einen versionierten Hash abfragen und eine Punktöffnung prüfen, aber die Blob-Payload nicht direkt lesen.

PeerDAS erweitert Blobs mittels Erasure Coding, teilt die erweiterte Matrix in 128 columns und lässt Nodes Teilmengen verwahren und samplen, statt von jedem Node den Download jedes vollständigen Blobs zu verlangen. Das ermöglicht eine probabilistische lokale Verfügbarkeitsbeurteilung, beweist aber weder Rollup-Ausführungsvalidität noch Ethereum-Finalität, Bridge-Sicherheit oder dauerhafte Abrufbarkeit. Die Kapazität ist forkabhängig. Am 2026-08-13 zielt das Ethereum-Mainnet nach Fusaka BPO2 auf 14 blobs per block und erlaubt höchstens 21; jede Blob-Transaktion ist auf 6 blobs begrenzt.

Funktionsweise

  1. Fixiere Netzwerk, Block oder Slot, aktiven Fork und Blob-Parameter-Only-Zeitplan sowie Rollup und Derivationsversion. Historische 3/6, Pectra-6/9, aktuelle 14/21, Testnet- und künftige Parameter sind nicht austauschbar.
  2. Identifiziere das Veröffentlichungsobjekt: Typ-3-Transaktion, versionierte Hashes, KZG-Commitments und -Proofs, Blob-Indizes, L1-Origin und ob das Rollup tatsächlich Ethereum-Blobs statt Calldata oder alternativer DA nutzte. Ein Commitment bindet Daten, beweist allein aber nicht deren Verfügbarkeit.
  3. Trenne die Einheiten. Ein Blob umfasst 4,096 field elements * 32 bytes = 131,072 encoded bytes; freie Payload verwendet meist 31 bytes je Feldelement beziehungsweise 126,976 usable bytes. Kompression, Framing, Padding, Blob-Gas, erasure-erweiterte Cells und Anwendungsbytes sind unterschiedliche Größen.
  4. Prüfe die Zeitplanlimits. Das Ziel steuert die Preisrückkopplung, ist aber keine reservierte Kapazität. Das Blockmaximum ist eine Konsensobergrenze, nicht der erwartete Durchsatz. Das PeerDAS-Limit 6 blobs per transaction unterscheidet sich vom aktuellen Maximum 21 blobs per block.
  5. Prüfe den Verfügbarkeitspfad. PeerDAS verwendet eindimensionale Erasure-Erweiterung, authentifizierte Cells und Columns, Gossip und Peer Requests. Ein Node sampelt unter aktuellen Parametern mindestens 8 columns und hat Custody-Pflichten; mindestens 64 of 128 columns ermöglichen die Rekonstruktion der erweiterten Matrix.
  6. Verfolge getrennte Zustände: Commitment aufgenommen, Datenspalten bezogen und geprüft, lokale DA-Prüfung bestanden, L1-Block safe oder finalized, Rollup-Batch decodiert und abgeleitet, Mindestbereitstellungsfenster aktiv und unabhängiges Archiv getestet. Verfügbarkeit impliziert keinen späteren Zustand.
  7. Simuliere fehlende Columns, Eclipse oder Partition, verzögerte Ausbreitung, L1-Reorganisation, Zeitplan- oder Client-Abweichung, Rollup-Formatupgrade und Archivverlust. Rufe benötigte Daten vor Ablauf des Protokollfensters ab, rekonstruiere und sichere sie; nutze für Batcher- und Nutzerkosten das separate Blob-Gebührenthema.

Rechenbeispiele

  • Byte-Einheiten eines Blobs. Die codierte Kapazität beträgt 4,096 * 32 = 131,072 bytes = 128 KiB. Allgemeine Payload beträgt 4,096 * 31 = 126,976 bytes = 124 KiB. Die Differenz sind 4,096 bytes oder 3.125% der codierten Kapazität; Kompression und Framing reduzieren die Anwendungspayload weiter.
  • Aktuelle Kapazität pro Block. Am Ziel gelten 14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB und 14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB. Am Maximum gelten 21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB und 21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB. Das sind datumsbezogene Mainnet-Blocklimits vor Kompression und Framing.
  • Transaktions- und Blocklimits. Eine Transaktion mit 6 blobs trägt 786,432 encoded bytes = 0.75 MiB und 761,856 usable bytes = 0.7265625 MiB. Ein maximaler 21-blob-Block benötigt mindestens 4 transactions, etwa 6 + 6 + 6 + 3; ein Zielblock mit 14-blob kann 6 + 6 + 2 enthalten. Keine Aufteilung reserviert Kapazität für ein Rollup.
  • Bereitstellungsfenster und nominales Volumen. 4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days. Bei nominal 7,200 slots per day und einem 14-blob-Ziel sind dies 100,800 blobs per day = 12.3046875 GiB per day codiertes und 11.920166015625 GiB per day allgemein nutzbares Volumen. Verpasste Slots und tatsächliche Inclusion ändern den Wert; das Fenster ist kein dauerhaftes Archivversprechen.

Risiken

  • Anwendung eines veralteten Forks oder Blob-Parameter-Only-Zeitplans.
  • Vermischung von Mainnet-, Testnet- oder Fremdnetzlimits.
  • Behandlung des Ziels als garantierte oder reservierte Kapazität.
  • Behandlung des Maximums als normalen erwarteten Durchsatz.
  • Verwechslung des Sechs-Blob-Transaktionslimits mit dem Blocklimit.
  • Vermischung codierter, nutzbarer, komprimierter, gerahmter und Blob-Gas-Einheiten.
  • Auslassung von Padding oder Rollup-Format-Overhead.
  • Bezeichnung von Calldata oder alternativer DA als Ethereum-Blobspace.
  • Akzeptanz eines versionierten Hashes, der nicht zum Blob-Commitment passt.
  • Deutung einer gültigen KZG-Öffnung als Verfügbarkeitsbeweis.
  • Gleichsetzung von Sampling mit lokalem Volldownload jedes Blobs.
  • Verwechslung von Datenverfügbarkeit und State-Transition-Validität.
  • Verwechslung lokaler DA-Prüfung mit L1- oder Rollup-Finalität.
  • Verlust von Columns durch Verzögerung, Eclipse, Partition oder korrelierte Peers.
  • Fehlende Rekonstruktion oder Peer-Antwort trotz nominaler Kapazität.
  • Verlust oder Neuordnung des Commitments durch L1-Reorganisation.
  • Ablauf des Mindestfensters vor Derivation oder Challenge.
  • Abhängigkeit von einem unerreichbaren, beschädigten oder unvollständigen Archiv.
  • Scheitern der Rollup-Derivation nach Kompressions- oder Protokollupgrade.
  • Annahme sicherer Bridges oder Exits allein wegen verfügbarer Blob-Daten.

Häufige Irrtümer

  • Blobspace ist dauerhafter Speicher, den Contracts wie Calldata lesen können.
  • Jedes Byte eines 128 KiB großen Blobs ist frei nutzbare Anwendungspayload.
  • Unter PeerDAS lädt jeder Ethereum-Node jeden vollständigen Blob und speichert ihn dauerhaft.
  • KZG-Commitment, erfolgreiches Sample oder finalisierte Inclusion beweisen korrekten Rollup-State und sichere Exits.
  • Mainnet-Kapazität bleibt dauerhaft auf 3/6, 6/9 oder dem aktuellen Zeitplan 14/21 fixiert.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...