Startseite
» Nachrichten
»
Ethereum-Gasgebührenoptimierung: Wie Proto-Danksharding die L2-Transaktionskosten verändert hat
Ethereum-Gasgebührenoptimierung: Wie Proto-Danksharding die L2-Transaktionskosten verändert hat
Die größte Änderung für L2-Nutzer war nicht die generelle Senkung der Ethereum-Gasgebühren. Vielmehr handelte es sich um einen günstigeren, temporären Datenkanal für Rollups. Das Dencun-Upgrade von Ethereum aktivierte Proto-Danksharding über EIP-4844 am 13. März 2024. Rollups konnten nun Batches mithilfe von Blobs – temporären Datencontainern mit einem separaten Gebührenmarkt – veröffentlichen, anstatt sich ausschließlich auf permanent gespeicherte Calldata zu verlassen. Diese Änderung senkte einen wichtigen Kostenfaktor für L2-Server, die Blobs einführten, machte aber nicht jede L2-Transaktion jederzeit günstig.
Der aktuelle Kontext ist entscheidend. Das spätere Fusaka-Upgrade von Ethereum brachte PeerDAS im Dezember 2025 ins Mainnet und trieb damit die Roadmap zur Datenverfügbarkeit weiter voran, indem es eine effizientere Skalierung des Blob-Durchsatzes ermöglichte. Für die Nutzer bedeutet dies heute, dass die L2-Gebühren von mehr als nur einem einzigen „Gaspreis“ abhängen: Ein L2-Server muss für seine eigene Ausführung und für die Veröffentlichung von Daten oder Proofs auf Ethereum bezahlen, während die Nachfrage nach Blob-Speicherplatz und die Gebührenpolitik jedes einzelnen L2-Servers den Endpreis beeinflussen können.
Das Diagramm veranschaulicht den Weg, der das Posten von Blob-basierten Rollups kostengünstiger macht: L2-Batches werden in temporären Datencontainern gruppiert, bevor ihre Commitments dem Ethereum-Netzwerk zur Verfügung gestellt werden. Es handelt sich um eine erläuternde Benutzeroberfläche, nicht um ein Live-Gebühren-Dashboard.
Was hat sich mit dem Proto-Danksharding geändert?
Vor EIP-4844 wurden Transaktionsdaten bei Rollups üblicherweise als Calldata an Ethereum übermittelt. Calldata ist Teil der Transaktionseingabe von Ethereum und bleibt als Teil der Blockchain-Historie verfügbar. Diese Beständigkeit ist zwar wertvoll, macht die Daten aber für Rollups in großem Umfang teuer.
EIP-4844 führte einen neuen Transaktionstyp ein, die sogenannte Blob-Transaktion. Ein Blob enthält Daten, die dem Netzwerk für einen begrenzten Zeitraum zur Verfügung gestellt werden, anstatt von der Ethereum Virtual Machine ausgeführt oder wie Calldata dauerhaft gespeichert zu werden. Laut Ethereum.org sind Blob-Daten etwa 18 Tage (4096 Epochen) lang verfügbar, bevor sie gelöscht werden können. Dieses Zeitfenster ist auf die Anforderungen an die Datenverfügbarkeit bei Rollups zugeschnitten und nicht für die dauerhafte Speicherung von Dateien im allgemeinen Sinne gedacht.
Das Ergebnis ist ein veränderter ökonomischer Weg für Rollup-Daten. Die Rollup-Daten werden weiterhin auf Ethereum abgerechnet bzw. dort verankert, können aber eine speziell dafür entwickelte Datenverfügbarkeitsressource nutzen, anstatt nur um die übliche L1-Ausführungs- und Aufrufdatenkapazität zu konkurrieren. Lesen Sie die Dencun-FAQ von Ethereum für eine offizielle Übersicht des Upgrades und die EIP-4844-Spezifikation für das Transaktions- und Gebührendesign.
Der entscheidende Mechanismus: Blob-Gebühren sind von normalen Gasgebühren getrennt.
„Gas“ wird oft so verwendet, als wäre es eine einzelne Zahl. Nach EIP-4844 kann diese Kurzform jedoch verschleiern, wofür ein Rollup bezahlt. Blob-Transaktionen enthalten neben den üblichen Ethereum-Ausführungsgebührenfeldern eine separate maximale Gebühr für Blob-Gas. Das Protokoll verwaltet eine unabhängige Blob-Basisgebühr, die sich nach der Blob-Nutzung richtet, anstatt Blobs ausschließlich über den normalen L1-Gasmarkt zu bepreisen.
Kostenkomponente
Wofür es sich bezahlt
Warum das für einen L2-Benutzer relevant sein sollte
L2-Ausführungsgebühr
Berechnung und Verarbeitung der Transaktion des Benutzers im Rahmen der Zusammenfassung.
Sie kann ansteigen, wenn die jeweilige L2-Instanz ausgelastet ist, selbst wenn die Ethereum-Blob-Gebühren niedrig sind.
L1-Datenverfügbarkeitskosten
Veröffentlichung von Rollup-Batches oder Proofs auf Ethereum.
Blobs können diese Eingabe im Verhältnis zu Anrufdaten reduzieren, wenn die Rollup-Funktion sie verwendet.
Blob-Gebühr
Der dedizierte Gebührenmarkt für Blob-Speicherplatz.
Es variiert mit dem Blob-Bedarf und ist nicht identisch mit dem L1-Ausführungsgas.
Rollup-Betreiberrichtlinie
Wie ein Sequenzer Transaktionen bündelt, Kosten weitergibt und Gemeinkosten berechnet.
Zwei L2-Server können unter gleichen Ethereum-Bedingungen unterschiedliche Benutzergebühren anzeigen.
EIP-4844 trennt die Preisgestaltung für Blob-Gas bewusst. Die Spezifikation beschreibt Blob-Gas als unabhängig von normalem Gas, mit eigenem Zielwert und eigener Anpassungsregel. Daher lässt sich aus einer Meldung über niedrige L1-Gaspreise nicht automatisch ableiten, wie viel eine L2-Transaktion kosten wird, und ein plötzlicher Anstieg der Blob-Nachfrage kann sich auf Rollups auswirken, selbst wenn die normale L1-Aktivität gering erscheint.
Wie sich dadurch L2-Transaktionen in der Praxis verändert haben
Rollups können Daten wirtschaftlicher veröffentlichen.
Rollups führen zahlreiche Nutzertransaktionen außerhalb des Ethereum-Mainnets aus und veröffentlichen anschließend ausreichend Informationen auf Ethereum, damit der Status des Rollups gemäß seiner Architektur verifiziert oder angefochten werden kann. Vor der Einführung von Blobs waren permanente Aufrufdaten ein wesentlicher Bestandteil dieser Prozesse. Blobs bieten Rollups eine kostengünstigere Möglichkeit, Daten zu veröffentlichen, die lange genug für die Sicherheit des Systems verfügbar sein müssen, aber nicht in der permanenten Ausführungshistorie jedes Knotens gespeichert werden müssen.
Bei einer L2-Architektur, die Blobs unterstützt, können die Einsparungen an die Nutzer weitergegeben, in einem Gebührenmodell verbucht oder teilweise durch andere Kosten kompensiert werden. Zeitpunkt und Umfang der Einsparungen sind daher implementierungsabhängig. Ethereum.org weist ausdrücklich darauf hin, dass die Rollup-Anbieter die Entscheidung zwischen Calldata und Blobs in der Regel basierend auf der Blob-Speichernachfrage treffen und dass die individuellen Unterstützungszeiträume und Gebührenstrukturen variieren können.
Die Gebühren reagierten empfindlicher auf die Stapelverarbeitung und die Dateneffizienz.
Ein Rollup fasst in der Regel viele Nutzeraktionen zu einem Batch zusammen, bevor sie auf L1 veröffentlicht werden. Durch die Verteilung der L1-Datenkosten auf mehr Transaktionen kann der Anteil pro Nutzer sinken, während datenintensive Aktionen einen größeren Anteil beanspruchen können. Die Details variieren je nach Rollup-Architektur, Komprimierungsmethode und Sequenzierungsrichtlinie. Ein einfacher Token-Transfer, ein Smart-Contract-Aufruf mit umfangreichen Call-Daten und die Erstellung eines NFTs können daher auf demselben L2 sehr unterschiedliche Gebühren verursachen.
Proto-Danksharding beseitigt diesen Zielkonflikt nicht. Es senkt zwar die Kosten der Datenverfügbarkeitsschicht bei Verwendung von Blobs, beseitigt aber weder die L2-Berechnung noch die Komplexität von Smart Contracts oder die Kosten knapper Datenressourcen bei Überlastung.
Was Proto-Danksharding nicht verändert hat
Es führte nicht direkt zu günstigeren Mainnet-Transaktionen. Laut den Dencun-FAQs zielt EIP-4844 primär auf L2-Gebühren ab. Jegliche Auswirkungen auf die Mainnet-Gebühren sind indirekt und hängen von der Akzeptanz und der Nachfrage ab.
Dadurch wurde der Blob-Speicherplatz nicht unbegrenzt. Die Blob-Kapazität ist begrenzt, und Rollups können Anrufdaten verwenden, wenn Blob-Speicherplatz gefragt oder nicht zu akzeptablen Kosten verfügbar ist.
Es wurde nicht erzwungen, dass jede L2-Instanz Blobs auf dieselbe Weise verwendet. Der Sequenzer- oder Rollup-Operator verwaltet im Allgemeinen die Datenübermittlung und die Batch-Verarbeitung.
Dadurch wurden Blobs nicht in dauerhaften Speicher umgewandelt. Der Inhalt von Blobs ist temporär; Anwendungen, die dauerhafte Daten benötigen, müssen ein geeignetes Speicherkonzept verwenden.
Es wurden keine Bridge-, Swap-, Protokoll- oder Wallet-Gebühren entfernt. Der angezeigte Gesamtbetrag kann neben der Basis-Transaktionsgebühr der Schicht 2 mehrere weitere Kostenebenen enthalten.
Warum der Fahrplan nach Dencun weiterhin relevant ist: PeerDAS
Proto-Danksharding war bewusst als Brücke zu einer skalierbareren Datenverfügbarkeit gedacht und nicht als endgültige Form des Shardings. EIP-4844 führte das Blob-Transaktionsformat und einen separaten Gebührenmarkt ein, wobei die anfängliche Kapazität konservativ gehalten wurde. Im Dezember 2025 stellte Fusaka PeerDAS (EIP-7594) vor, ein Verfahren zur Datenverfügbarkeitsprüfung, das es Knoten ermöglicht, die Verfügbarkeit durch Stichproben zu überprüfen, anstatt dass jeder Knoten alle Blob-Daten herunterlädt.
Dies ist wichtig, da ein höherer Blob-Durchsatz mehr Rollup-Daten ermöglicht, ohne dass jeder Knoten die volle Last tragen muss. Die grundlegende Regel für den Benutzer bleibt unverändert: Die L2-Gebühr ist weiterhin dynamisch. Die technische Verbesserung kann die Kapazität erhöhen und den Druck verringern, stellt aber keine Garantie für einen Festpreis dar. Den bestätigten Umfang dieses Upgrades finden Sie in der Ankündigung der Ethereum Foundation zum Fusaka-Mainnet und in der offiziellen PeerDAS-Übersicht .
Ein praktischer Workflow zur Gebührenoptimierung für L2-Nutzer
Bei einer typischen Wallet-Transaktion können Sie keinen Blob direkt auswählen; der Rollup-Prozess entscheidet, wie die Batches verbucht werden. Sie können jedoch vermeidbare Kosten reduzieren und eine für die Transaktion passende Route wählen.
Ermitteln Sie das tatsächliche Netzwerk. Prüfen Sie, ob die App das Ethereum-Mainnet, einen bestimmten Rollup oder eine andere Blockchain nutzt. „Ethereum-kompatibel“ bedeutet nicht, dass sie vom Ethereum-Blob-Speicherplatz profitiert.
Bitte lesen Sie die Gebührenaufschlüsselung sorgfältig durch, bevor Sie bestätigen. Beachten Sie, dass die L2-Netzwerkgebühr nicht mit Anwendungs-, Brücken-, Swap- oder Protokollgebühren identisch ist.
Vergleichen Sie dieselbe Aktion auf den unterstützten Layer-2-Plattformen. Nutzen Sie ausschließlich die offizielle Netzwerkunterstützung der App und deren aktuellen Wallet-Kurs. Eine niedrigere Gebühr ist nur dann sinnvoll, wenn Ziel, Liquidität, Sicherheitsannahmen und Auszahlungspfad zu Ihrem Anwendungsfall passen.
Vermeiden Sie unnötige datenintensive Anfragen. Mehrfache Genehmigungen, wiederholte Versuche und komplexe Vertragsinteraktionen können teurer sein als eine einfache Überweisung. Konsolidieren Sie Aktionen nur dann, wenn dadurch kein größeres Sicherheits- oder Ausführungsrisiko entsteht.
Versuchen Sie nach einer Verzögerung nicht einfach blindlings erneut. Prüfen Sie zuerst den Transaktionsstatus. Eine Ersatz- oder Duplikattransaktion kann eine weitere Belastung oder eine unbeabsichtigte Folgeaktion auslösen.
Halten Sie einen kleinen Puffer des nativen Gasvermögens auf der L2-Schnittstelle bereit. Wenn nach dem Bridging oder Swapping das Gas ausgeht, kann dies eine zusätzliche Überweisung erzwingen und die Transaktion verzögern.
Verwenden Sie offizielle Analysetools und Dokumentationen. Überprüfen Sie Vertragsadressen, Bridge-Schritte und Netzwerkeinstellungen vor der Unterzeichnung. Eine „günstige“ Transaktion, die an das falsche Netzwerk gesendet wird, ist keine Optimierung.
Wenn eine niedrigere angezeigte Gebühr nicht die bessere Wahl ist
Die Gebührenoptimierung ist situationsabhängig. Ein kostengünstiger L2-Tarif kann für häufige, unterstützte Aktionen wie Anwendungsinteraktionen innerhalb desselben Ökosystems geeignet sein. Er ist hingegen ungeeignet, wenn Sie unmittelbar danach erneut eine Bridge benötigen, die App das Zielnetzwerk nicht unterstützt oder Liquiditäts- und Auszahlungsmodalitäten höhere Kosten und Risiken als die anfängliche Gebührenersparnis mit sich bringen.
Beispielsweise kann die Übertragung von Vermögenswerten auf eine kostengünstige L2-Plattform für einen kleinen Swap ineffizient sein, wenn die Kosten für die Bridge, Genehmigungen und Rückübertragung höher sind als die Kosten für die Transaktion dort, wo sich die Vermögenswerte bereits befinden. Umgekehrt kann ein Nutzer, der viele unterstützte Transaktionen innerhalb eines einzigen L2-Ökosystems durchführt, von niedrigen wiederkehrenden Ausführungs- und Datenkosten profitieren. Vergleichen Sie den gesamten Transaktionspfad, nicht nur das erste Gasangebot.
Wie Entwickler die Änderung interpretieren sollten
Für Rollup-Teams verschiebt sich durch Blobs das Optimierungsziel von „Minimierung der permanenten Anrufdaten um jeden Preis“ hin zu „effizienter Nutzung der Datenverfügbarkeit bei gleichzeitiger Verwaltung eines separaten Blob-Gebührenmarktes“. Dies umfasst Komprimierung, Batch-Bildung, Ausweichverhalten bei steigenden Blob-Gebühren und transparente Gebührenabrechnung für Nutzer. Anwendungen sollten vermeiden, allein aufgrund von EIP-4844 eine dauerhafte Gebührenreduzierung zu beanspruchen, da Nachfrage, Rollup-Implementierung und zukünftige Protokollaktualisierungen weiterhin variabel sind.
Für Anwendungsentwickler auf einer L2-Knotenebene ist das Transaktionsdesign weiterhin relevant. Durch die Reduzierung unnötiger Speicherschreibvorgänge, Calldata, Vertragsaufrufe und fehlgeschlagener Ausführungen lassen sich die Ausführungskosten für den Benutzer senken. Hierbei handelt es sich um komplementäre Optimierungen: Proto-Danksharding reduziert primär die Datenübermittlung auf der L1-Knotenebene, während effiziente Verträge die auf der L2-Knotenebene selbst ausgeführten Arbeiten optimieren.
Fazit
Proto-Danksharding veränderte die L2-Ökonomie, indem es Rollups eine temporäre, separat bepreiste Datenleitung zur Verfügung stellte. Daher konnten viele Blob-fähige Rollups nach Dencun einen wesentlichen Teil der Abrechnungskosten reduzieren. Die spätere Einführung von PeerDAS verbesserte die Kapazität im Rahmen desselben Plans, doch keines der beiden Upgrades führt zu statischen Gebühren oder garantiert, dass jede L2-Verbindung für jede Aufgabe günstiger ist als das Mainnet.
Für Nutzer liegt die optimale Lösung darin, das richtige Netzwerk für den gesamten Transaktionspfad auszuwählen, die tatsächlichen Gebühren zu prüfen, redundante Smart Contracts zu vermeiden und ausreichend Gas für das verwendete Netzwerk vorzuhalten. Für Entwickler gilt die wichtige Erkenntnis, Blob-Verfügbarkeit, Blob-Gebühren, Batching und L2-Ausführung als zwar zusammenhängende, aber dennoch unterschiedliche Bestandteile des Kostenmodells zu betrachten.