Die Einführung mehrdimensionaler Gas-Modelle in Ethereum löst die enge Kopplung von knappen Ressourcen wie Speicherwachstum und Calldata an reine Rechenoperationen. Gleichzeitig stellt sie das Protokoll vor neue Kompatibilitäts- und Sicherheitsherausforderungen, etwa den sogenannten Overflow-Buffer, der bestehende Smart Contracts vor abrupten Transaktionsabbrüchen schützen soll. Im Folgenden wird erläutert, wie die EIPs 7999, 7706 und 7825 diese Probleme adressieren und welche Auswirkungen sie auf Entwickler, Nutzer und das Netzwerk haben.

Überblick über die neuen Gas-Modelle

Die drei zentralen Verbesserungsvorschläge – EIP-7999, EIP-7706 und EIP-7825 – bauen aufeinander auf und verändern die Art und Weise, wie Gebühren in Ethereum berechnet und begrenzt werden. Während EIP-7999 ein einheitliches maxfee -Budget einführt, erweitert EIP-7706 das Modell um drei orthogonale Ressourcen-Dimensionen und EIP-7825 legt eine feste Obergrenze für das Ausführungsgas fest.

EIP-7999 – Einheitliches Max-Fee-Budget

• Kernaussage: Transaktionen deklarieren ein aggregiertes Gebührenbudget („maxfee“) anstelle separater Höchstgebühren für jede Ressourcendimension (Execution, Blobs, State, Calldata).
• Motivation: Vermeidung von Transaktionsabbrüchen durch Basistarif-Schwankungen einzelner Sub-Dimensionen und Vereinfachung der Mempool-Validierung.
• Entwurfsdatum: 4. August 2025 (EIP-7999-Entwurf).
• Autoren: Anders Elowsson, Vitalik Buterin, Maria Silva.
• Stärkung des Artikels: Erläutert die technische Grundlage von Elowssons Argument für einheitliche Budgets im Vergleich zu Buterins vektorbasiertem Ansatz.

Durch die Aggregation wird das finanzielle Exposure des Nutzers auf ein einzelnes Budget reduziert. Das System wandelt bei der Transaktionsaufnahme die einzelnen Ressourcen-Limits in ein gemeinsames maxfee um, wodurch die Gefahr von Fehlinvestitionen aufgrund dynamischer Base-Fees minimiert wird.

EIP-7706 – Dreidimensionale Gasarchitektur

• Kernaussage: Trennung der Gebührenmessung in drei orthogonale Dimensionen: Execution Gas, Blob Gas (EIP-4844) und Calldata Gas.
• Einführung: 13. Mai 2024 (EIP-7706-Spezifikation).
• Dimensionen: Execution, Calldata, Blobs (insgesamt 3).
• Motivation: Entkoppelung datenintensiver Transaktionen von teuren Rechenzyklen durch dynamische Base-Fees nach dem EIP-1559-Prinzip.
• Stärkung des Artikels: Liefert die formale Begründung für Vitalik Buterins Vorschlag, Overflow-Gas als weitere eigenständige Vektordimension zu modellieren.

Die vektorbasierte Struktur ermöglicht es, jede Ressource mit einem eigenen Basistarif zu bepreisen, wodurch Preisverzerrungen zwischen Daten-Rollups und rechenintensiven Contracts reduziert werden.

EIP-7825 – Deterministische Ausführungsobergrenze

• Kernaussage: Obergrenze von 2^24 Gas (≈ 16,78 Millionen Gas) pro Einzeltransaktion.
• Einführung: 6. Juli 2025 im Rahmen des Fusaka-Upgrades.
• Ziel: Minimierung von DoS-Risiken bei steigenden Block-Gaslimits und Beschleunigung von Zero-Knowledge-Beweisen sowie paralleler Ausführung.
• Stärkung des Artikels: Ordnet den Kommentar von MATOBOYCRYPTO65 zu expliziten Gas-Counters für EIP-7825 technisch präzise ein.

Durch die feste Obergrenze wird die Planung von Ressourcen-verbrauch deterministischer, was insbesondere für zk-Rollups und parallele EVM-Ausführungen von Bedeutung ist.

Vergleich der Gas-Budget-Modelle

Im Diskurs werden drei Grundmodelle unterschieden:

• Aggregate (A): Ein gemeinsamer Gas-Budget-Pool mit festem relativen Gas-Schedule, finanziert konservativ zum höchsten relevanten Base-Fee.
• Subfee (S): Ein gemeinsamer Budget-Pool mit fließendem relativen Gas-Schedule; Nutzer geben separate Ressourcen-Limits an, die bei Aufnahme in ein aggregiertes Budget umgerechnet werden.
• Multidimensional (M): Separate Budgets für jede Ressource mit festen Gas-Kosten in jeweiligen Einheiten.

Die Diskussion um Overflow-Gas zeigt, dass jede Modellvariante als „Overflow-Dimension“ eingesetzt werden kann:

• M+O A – Universal Overflow mit festen Gas-Kosten.
• M+O S – Subfee-Modell für Overflow.
• M+O M – Vektorisiertes Overflow, das unterschiedliche Ressourcen-Mixe zwischen Aufrufer und Aufgerufenen erlaubt.

Risiken und Gegenargumente

• Opcode-Preisschwankungen: Dynamische Änderungen der relativen Gaskosten (z. B. State vs. Computation) können Verträge mit fest kodierten Gas-Stipends (z. B. 2300 Gas für Transfers) zum Scheitern bringen.
• Fehlallokation durch Überbuchung im Universal-Overflow-Puffer: Eine zu günstige Tarifierung des Overflow-Puffers kann zu Ausnutzungen des Block-Speicherplatzes und Ungleichgewichten bei den Validierungszeiten führen.

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen Aggregate EVM Gas (A) und Subfee Accounting (S)?Modell A nutzt feste relative Gaskosten und berechnet das Gesamtbudget basierend auf dem höchsten Basistarif aller Ressourcen, was zu hohem Kapitalverbrauch führt. Modell S erlaubt dynamische relative Gaskosten, die sich an den jeweiligen Ressourcen-Basistarifen orientieren, und konvertiert diese bei der Transaktionsaufnahme in ein einheitliches Budget.Warum befürwortet Vitalik Buterin vektorisierte Gebührenlimits gegenüber EIP-7999?Buterin argumentiert, dass verschiedene Systemressourcen (z. B. Speicher vs. CPU) nicht fungibel sind. Nutzer sollten gezielt für knappe Ressourcen höhere Aufschläge zahlen können, ohne für weniger beanspruchte Ressourcen dieselbe Risikoprämie zu binden.

Praktische Implikationen für Smart Contracts und Kompatibilität

Die Umstellung auf ein einheitliches maxfee -Budget erfordert robuste Kompatibilitätsschichten. Bestehende Contracts, die über Opcodes wie GASLEFT eine skalare Gesamtressource erwarten, müssen mit dem Overflow-Buffer umgehen, der als zusätzliche Dimension fungiert. Diskussionen im Ethereum-Research-Forum (siehe INFO 2) zeigen, dass:

• Overflow kann als eigenständige Dimension behandelt werden, entweder mit 1:1-Verhältnis zu EVM-Gas oder mit einem fest codierten Preis-zu-1-Verhältnis.
• Ein Block-Level-Target für Overflow ist nicht zwingend nötig; die tatsächliche Ressourcennutzung sollte die Block-Limits und Base-Fees aktualisieren.
• Ein mehrstufiger Implementierungsplan (Phase 1 – Phase 3) wird von der Community empfohlen: zunächst Subfee-Markt mit separaten Limits und explizitem Execution-Gas-Counter (EIP-7825), danach optionaler Universal Overflow und langfristig vollständige multidimensionale EVM für neue Contracts.

Diese Schritte ermöglichen eine schrittweise Migration, bei der Legacy-Contracts weiter auf den bestehenden Mechanismen aufbauen, während neue Contracts von einer präziseren Ressourcen-Bepreisung profitieren.

Fazit

Die Kombination aus EIP-7999, EIP-7706 und EIP-7825 markiert einen entscheidenden Schritt hin zu einer flexibleren, ressourcensensiblen Gebührenstruktur in Ethereum. Durch ein einheitliches maxfee -Budget wird die Nutzer-Erfahrung vereinfacht, während die vektorisierten Dimensionen von EIP-7706 Preisverzerrungen zwischen Daten- und Rechen-Ressourcen reduzieren. Die feste Obergrenze von 2^24 Gas pro Transaktion (EIP-7825) sorgt für Sicherheit und Planbarkeit, insbesondere für Zero-Knowledge-Anwendungen. Gleichzeitig bleibt die Kompatibilität zu bestehenden Smart Contracts über den Overflow-Buffer gewährleistet. Die vorgeschlagenen Phasen für die Einführung zeigen, dass ein ausgewogener Übergang möglich ist – von der Optimierung der Finanzierungs-effizienz über die Einführung optionaler Overflow-Puffer bis hin zu einer langfristigen, vollständig multidimensionalen EVM-Architektur.