EIP-8374-Entwurf: Adressen und Speicherschlüssel sollen nach einem Revert warm bleiben
Victoria Shinder2 Min. LesezeitEin neuer Entwurf, EIP-8374 „Persist Warm Access Sets Across Reverts“, ist am 15. Oktober 2026 vom Bot des Repositorys in die Ethereum-EIPs übernommen worden. Der Vorschlag von Dragan Rakita gehört zum Core Standards Track und setzt einen Hard Fork voraus; sein Status ist Draft, diskutiert wird auf Ethereum Magicians.
Was sich ändert. Seit EIP-2929 führt die EVM zwei für die Transaktion geltende Mengen, accessed_addresses und accessed_storage_keys, anhand derer entschieden wird, ob ein Zugriff zum kalten oder zum warmen Preis abgerechnet wird. Bricht ein Call-Frame mit Revert oder einem Ausnahmefehler ab, werden beide Mengen auf den Stand vor dem Aufruf zurückgesetzt. EIP-8374 streicht dieses Zurücksetzen: Ist eine Adresse oder ein Speicherschlüssel einmal aufgenommen, bleibt er für den Rest der Transaktion warm, egal was danach geschieht. Auch Einträge aus Unteraufrufen eines Frames bleiben erhalten.
Warum. Der Entwurf argumentiert, die Unterscheidung von warm und kalt solle die tatsächlichen Kosten des Clients für das Laden von Zustand abbilden, und diese fielen beim ersten Lesen aus der Datenbank an. Ein Revert mache Zustandsänderungen rückgängig, entlade aber keine Daten, die im Cache des Clients liegen bleiben; einen zweiten Zugriff nach einem Revert kalt abzurechnen, bepreise also Arbeit, die nicht stattfindet. Hinzu komme ein Vorteil für Implementierungen: Die Zugriffsmengen werden zu reinen Anhängelisten und müssen nicht mehr am Zustandsjournal und an der Checkpoint- und Revert-Mechanik teilnehmen. Eine verworfene Alternative – das Zurücksetzen beibehalten, wiederholte kalte Zugriffe aber rabattieren – würde laut Autor eine dritte Preisstufe ohne Nutzen schaffen.
Die genaue Regel. Die kalte Gebühr muss vor der Aufnahme eines Eintrags bezahlt werden; reicht das Gas dafür nicht, wird der Eintrag nicht aufgenommen. Ist sie bezahlt, bleibt der Eintrag, auch wenn eine spätere Gebühr oder Prüfung in derselben Operation scheitert. Die Testfälle des Entwurfs machen das konkret: Liest Frame B per DELEGATECALL kalt einen Slot aus dem Speicher von A und bricht dann mit Revert ab, zahlt A beim nächsten Laden dieses Slots den warmen Preis; geht B das Gas aus, bevor eine kalte Gebühr bezahlt ist, zahlt A weiterhin kalt. Zustandsänderungen eines abgebrochenen Frames bleiben rückgängig gemacht – nur die Einträge der Zugriffsmengen bleiben bestehen.
Kompatibilität und Sicherheit. Nach dem Fork werden manche bisher kalt abgerechneten Zugriffe warm, Transaktionen werden also günstiger oder kosten gleich viel; keine wird teurer. Verträge, die sich auf exakte Gaskosten von Zugriffen nach einem Revert verlassen, können einen anderen Verbrauch sehen. Zur Sicherheit räumt der Entwurf ein, dass eine Transaktion Einträge in einem Frame, der dann abbricht, aufwärmen und später günstig nutzen könnte. Neu sei das nicht: Eine Zugriffsliste nach EIP-2930 ändere den Status beliebiger Adressen und Schlüssel bereits vor der Ausführung, und in beiden Fällen werde die kalte Gebühr je Eintrag einmal bezahlt.
Quelle: EIP-8374 in der am 15. Oktober 2026 übernommenen Fassung — https://github.com/ethereum/EIPs/commit/6c6c83f427bb2f22b