Transaktion
Eine Transaktionsart, die in EIP-4844 von Ethereum eingeführt wurde und darauf abzielt, Transaktionsgebühren durch die separate Speicherung von Daten-Blobs vom Haupttransaktionsdatensatz zu reduzieren.
Blob-Transaktionen, eingeführt durch das Ethereum Improvement Proposal (EIP) 4844 (auch bekannt als Proto-Danksharding), stellen eine bedeutende architektonische Veränderung dar, die darauf abzielt, Transaktionsgebühren zu senken, insbesondere für Layer-2-Skalierungslösungen. Im Gegensatz zu herkömmlichen Ethereum-Transaktionen, die Daten direkt in den Calldata der Haupttransaktion einbetten, verwenden Blob-Transaktionen eine separate, wenn auch immer noch On-Chain-Datenstruktur namens 'Blobs'. Diese Blobs sind kostengünstiger zu posten und unterliegen anderen Gaslimits und Preismechanismen als reguläre Transaktionsdaten. Die Hauptmotivation ist die Senkung der Kosten für die Datenverfügbarkeit für Rollups. Rollups bündeln Transaktionen Off-Chain und posten eine komprimierte Zusammenfassung oder einen Nachweis auf der Haupt-Ethereum-Kette (Layer 1). Die Kosten für das Posten dieser Daten auf Layer 1 sind ein großes Hindernis. EIP-4844 führt einen neuen Transaktionstyp ein, der es Rollups ermöglicht, größere Datenmengen kostengünstiger zu posten, indem sie in diese Blobs aufgeteilt werden. Diese Blobs werden nicht direkt von der Ethereum Virtual Machine (EVM) verarbeitet, sondern über ein KZG (Kalai-Shen-Goldwasser) Polynomial Commitment Scheme zugesichert. Diese Zusicherung ist im Block-Header enthalten und gewährleistet die Datenverfügbarkeit, ohne dass jeder Knoten die vollständigen Blob-Daten herunterladen und auf Dauer speichern muss. Diese Trennung und spezialisierte Handhabung reduzieren die Gaskosten für die Datenverfügbarkeit erheblich, machen Rollups wirtschaftlich rentabler und verbessern so die allgemeine Skalierbarkeit von Ethereum.
graph LR
Center["Transaktion"]:::main
Pre_digital_signature["digital-signature"]:::pre --> Center
click Pre_digital_signature "/terms/digital-signature"
Pre_private_key["private-key"]:::pre --> Center
click Pre_private_key "/terms/private-key"
Rel_block["block"]:::related -.-> Center
click Rel_block "/terms/block"
Rel_smart_contract["smart-contract"]:::related -.-> Center
click Rel_smart_contract "/terms/smart-contract"
Rel_data_availability["data-availability"]:::related -.-> Center
click Rel_data_availability "/terms/data-availability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Erkläre es wie einem 5-Jährigen
Stellen Sie sich vor, Sie versenden ein großes Paket (Ihre Transaktion), bei dem Sie früher viel dafür bezahlen mussten, das gesamte Verpackungsmaterial mit hineinzulegen. Blob-Transaktionen ermöglichen es Ihnen, das Verpackungsmaterial separat und viel günstiger zu versenden, wodurch Ihre gesamten Lieferkosten erheblich sinken.
🤓 Expert Deep Dive
EIP-4844 verändert die Datenverfügbarkeitsstrategie von Ethereum grundlegend, indem es 'Blobs' und KZG-Zusicherungen einführt. Blobs sind zusammenhängende Datenblöcke, die an einen Block angehängt sind, mit einer maximalen Größe und einem separaten Gaslimit, das sich von Calldata unterscheidet. Entscheidend ist, dass Blobs nicht direkt von der EVM-Vertragslogik zugänglich sind; ihr Hauptzweck ist die Verifizierung der Datenverfügbarkeit. Die Zusicherung der Blob-Daten erfolgt mittels KZG-Polynomial-Zusicherungen, wobei die Blob-Daten die Koeffizienten eines Polynoms darstellen und die Zusicherung ein Punkt auf einer elliptischen Kurve ist. Dies ermöglicht eine effiziente Erzeugung und Verifizierung von Nachweisen. Knoten müssen Blob-Daten für einen begrenzten Zeitraum (z. B. ca. 4096 Blöcke oder ca. 27 Stunden) zur Verifizierung herunterladen, danach können sie sie löschen, was den State Bloat reduziert. Die Gaskosten für das Posten von Blobs sind deutlich niedriger als bei Calldata und berechnen sich nach der Blob-Größe und einem separaten 'Blob-Gaspreis'. Dieser Mechanismus ist ein Vorläufer für das vollständige Danksharding, bei dem der Blob-Speicherplatz erweitert und auf mehrere Shards verteilt wird. Zu den Kompromissen gehören die Komplexität des KZG-Zusicherungsschemas und die temporäre Speicheranforderung für Knoten, aber der Hauptvorteil ist eine erhebliche Reduzierung der Kosten für das Posten von Rollup-Daten.