März 2024 hat die Layer-2-Ökonomie für immer umgekrempelt. Vor Dencun haben Rollups wie Arbitrum oder Optimism die Budgets der Teams verbrannt, um Calldata in das Mainnet zu drücken. Ethereum-Smart-Contracts haben dieses Byte-Array für immer in den globalen State geschrieben und jeden Validator gezwungen, es ewig zu speichern. Das hat bis zu neunzig Prozent der Kosten für L2-Nutzer verschlungen.
EIP-4844 hat dieses Schema aufgebrochen, indem es Transaktionen des dritten Typs und Blobs eingeführt hat. Doch hinter den schönen Zahlen einer 10- bis 50-fachen Gebührensenkung verbirgt sich eine Menge technischer Nuancen, über die Marketer meist schweigen.
Wie ein Blob auf Speicher- und Konsensebene aufgebaut ist
Ein Blob ist nicht einfach nur eine Datei, die an die Blockchain gesendet wird. Es ist ein isoliertes Daten-Array von exakt 131.072 Bytes (128 KB), das parallel zur EVM-Ausführung existiert. Smart Contracts auf Ethereum können den Inhalt eines Blobs innerhalb eines CALL- oder STATICCALL-Aufrufs nicht lesen. Sie haben nur Zugriff auf einen einzigen Bytecode – den speziellen BLOBHASH-Opcode, der die Version und den Commitment-Hash zurückgibt.
- Blockgröße: Der Zielwert liegt bei 3 Blobs (~384 KB), das Maximum in der Spitze bei 6 Blobs (~768 KB).
- Lebensdauer: Etwa 4096 Epochen (ca. 18 Tage), danach bereinigen die Konsensknoten die Daten von ihren Festplatten.
- Mempool-Isolierung: Blobs laufen nicht im gewöhnlichen Execution-Mempool. Sie haben einen eigenen Pool auf Konsens-Client-Ebene (P2P Blob Pool), was die Haupttransaktionswarteschlangen vor Überlastung schützt.
Parameter | Klassisches Calldata | EIP-4844 Blob (Type 3)
Wo die Daten liegen: Im permanenten EVM-State | Im temporären P2P-Konsenspool
Speicherzeit: Für immer | ~18 Tage
Zugriff aus der EVM: Direkt (über Bytereading) | Indirekt (nur über Hash und KZG)
Preisfindung: Geteiltes Execution-Gas | Unabhängiger Blob-Gas-Markt (EIP-1559)
Unauffällige Features und architektonische Fallstricke von Proto-Danksharding
Die wenigsten achten darauf, wie die Blob-Gas-Preisfindung funktioniert. Im Gegensatz zu Standard-Gas, das bei jedem DeFi-Hauch springt, wird der Blob-Markt von einem unabhängigen Korrekturalgorithmus gesteuert. Wenn Rollups die Slots über die zielsetzenden drei Blobs hinaus vollschreiben, fängt der Preis an, exponentiell zu steigen. Bleiben die Slots leer, fällt er auf das Minimum zurück. In der Praxis führt das zu einer Situation, in der das Senden eines Blobs zu ruhigen Zeiten winzige Bruchteile eines Cents kostet, bei einem plötzlichen Netzwerk-Ansturm der Preis jedoch Hunderte Male schneller als in der Execution-Schicht nach oben schießen kann.
Ein weiterer feiner Punkt ist die kryptografische Verifizierung über KZG-Commitments (Kate-Zaverucha-Goldberg). Validatoren müssen nicht alle 128 KB herunterladen, um die Korrektheit der Daten sicherzustellen. Es reicht völlig aus, ein 48-Byte-Polynom zu prüfen. Das senkt die CPU-Anforderungen für Validatoren, verlagert jedoch die gesamte Last auf den Netzwerkkanal.
Wohin mit „unbequemen“ Daten in der Praxis
Die temporäre Natur von Blobs macht sie zum idealen Container für Daten, die keine ewige Buchhaltung benötigen, aber eine kryptografische Unveränderlichkeit über ein kurzes Validierungsfenster erfordern:
- Oracle-Dumps und Rohmetriken: Zwischen-Daten-Arrays, die vor der Aggregation in den Smart Contract von Providern signiert werden.
- L3-State-Snapshots und Spielwelten: Delta-Zustandsänderungen, bei denen es ausreicht, die Korrektheit für die letzte Woche zu bestätigen.
- Backend-Audit-Logs: Transaktionspakete oder Belege, die öffentlich verifizierbar sein müssen, aber nach einem Monat ihren operativen Wert verlieren.
Lasten über Python-Skripte mit web3.py in einen Blob zu werfen erfordert das separate Verpacken von Bytes in Polynome und die Generierung eines versionierten Hashes mit dem Präfix 0x01. Eine falsche Berechnung von maxFeePerBlobGas zum Zeitpunkt des Absendens garantiert, dass die Transaktion im Mempool hängen bleibt.
Theorie und Ökonomie sind klar, aber wie sieht die Arbeit mit Blobs auf Code-Ebene aus? Ein Standardaufruf von send_transaction führt zu einem Fehler, da Transaktionen des dritten Typs die manuelle Vorbereitung von KZG-Commitments, das Generieren von Proofs und die Berechnung eines separaten Gaslimits erfordern.
Senden einer Type-3-Transaktion in Python
Unten ist ein funktionierendes Muster zum Senden eines Blobs unter Verwendung aktueller Bibliotheken für die Arbeit mit einem Node (Geth oder Reth) dargestellt, der das Dencun-Upgrade unterstützt:
import os
from eth_account import Account
from web3 import Web3
w3 = Web3(Web3.HTTPProvider("http://127.0.0.1:8545"))
key = os.environ["OPERATOR_KEY"]
acct = Account.from_key(key)
FE_COUNT, FE_PAYLOAD = 4096, 31 # 31 Bytes Daten pro Feldelement
def encode_blob(data: bytes) -> bytes:
data = len(data).to_bytes(4, "big") + data
if len(data) > FE_COUNT * FE_PAYLOAD:
raise ValueError("Payload passt nicht in einen einzigen Blob")
data = data.ljust(FE_COUNT * FE_PAYLOAD, b"\x00")
# Höchstes Byte jedes Elements = 0, damit der Wert < BLS-Modul ist
return b"".join(b"\x00" + data[i:i + FE_PAYLOAD]
for i in range(0, len(data), FE_PAYLOAD))
blob = encode_blob(b"EXMON Infrastructure DA Payload: batch #98412")
# Aktueller Blob-Gas-Preis mit Puffer für Anstiege
blob_base_fee = int(w3.provider.make_request("eth_blobBaseFee", [])["result"], 16)
base_fee = w3.eth.get_block("latest")["baseFeePerGas"]
tx = {
"type": 3,
"chainId": w3.eth.chain_id,
"nonce": w3.eth.get_transaction_count(acct.address),
"gas": 21000,
"maxPriorityFeePerGas": w3.to_wei(1, "gwei"),
"maxFeePerGas": base_fee * 2 + w3.to_wei(1, "gwei"),
"maxFeePerBlobGas": max(blob_base_fee * 2, w3.to_wei(1, "gwei")),
"to": acct.address, # Kein Kontrakt-Create: bei Blob-Tx ist `to` obligatorisch
"value": 0,
"data": b"",
}
# ckzg berechnet Commitment, Proofs und Versioned Hash; Sidecar wird in die Raw Tx eingebettet
signed = Account.sign_transaction(tx, key, blobs=[blob])
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print(f"Blob-Tx gesendet: {tx_hash.to_0x_hex()}")Wenn die Volatilität von maxFeePerBlobGas nicht berücksichtigt wird, bleibt die Transaktion in Momenten hoher Rollup-Auslastung im Konsens-Mempool hängen, bis sich der Markt abkühlt.
Das Problem der Archiv-Nodes: Wohin wandern die Daten nach 18 Tagen?
Die größte Falle beim Entwurf einer Blob-Architektur ist mit deren Löschung verbunden. Konsens-Clients speichern Blob-Inhalte für mindestens 4096 Epochen (ca. 18 Tage) und löschen sie danach. Die Transaktion selbst und das KZG-Commitment bleiben für immer in der Blockchain, aber der Inhalt des Blobs kann darüber nicht wiederhergestellt werden. Wird nach einem Monat auf die Blob-Daten zugegriffen, gibt ein Standard-Node einen Fehler zurück.
Teams, die Produkte auf Basis von EIP-4844 entwickeln, müssen dieses Problem auf einem von drei Wegen lösen:
- Eigene Archiv-Scraper: Bereitstellung von Hintergrunddiensten, die Blobs im Moment ihres Erscheinens aus dem P2P-Netzwerk abziehen und in Cold Storage ablegen (S3-kompatible Buckets).
- Dezentrale Archive: Nutzung von Netzwerken wie Celestia, Avail oder The Graph für die langfristige Data-Availability-Speicherung.
- Verzicht auf tiefe Historie: Speicherung lokaler Indizes nur für das aktive Zwei-Wochen-Fenster, wobei ältere Aggregate komprimiert verworfen werden.
EXMON-Praxis: Speicheroptimierung
In der EXMON-Infrastruktur nutzen wir temporäre Blob-Bereiche, um schwere intermediäre Transaktionslogs, Dienst-Dumps und Verifikations-Snapshots auszulagern.
Das erlaubt es, gleich zwei Probleme auf einmal zu lösen:
- Budgeteinsparung: Die Kosten für die Datenveröffentlichung sind im Vergleich zu alten Methoden über Calldata um Größenordnungen gesunken.
- Blockchain-Sauberkeit: Der globale Netzwerkstatus wird nicht mit Müll zugestellt, der bereits nach einer Woche seine Relevanz verliert, während gleichzeitig die hundertprozentige kryptografische Prüfbarkeit im Lebenszyklusintervall der Daten erhalten bleibt.
