---
title: "Blobspace"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Blobspace
> 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
- [Blob-Gebühren und Rollup-Kosten](/de/crypto/blob-fee-rollup-cost/)
- [Data Availability Sampling](/de/crypto/data-availability-sampling/)
- [Rollup](/de/crypto/rollup/)
## Quellen
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [EIP-7840: Add blob schedule to EL config files](https://eips.ethereum.org/EIPS/eip-7840) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [EIP-7892: Blob Parameter Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [Checkpoint #8: Jan 2026](https://blog.ethereum.org/2026/01/20/checkpoint-8) - Ethereum Foundation Blog (abgerufen: 2026-08-13)
- [Fulu -- Data Availability Sampling Core](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/das-core.md) - Ethereum Consensus Specifications (abgerufen: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (abgerufen: 2026-08-13)
- [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/blobspace/index.mdx