EIP-1153 erklärt: Transient Storage, TLOAD, TSTORE und Smart-Contract-Risiken
Ethereum-Smart-Contracts müssen häufig Informationen nur während einer einzigen Transaktion behalten. Für solche kurzlebigen Werte gab es lange keine eigene speicherähnliche Lösung. EIP-1153 führt mit TLOAD und TSTORE einen temporären Speicherbereich ein, der nach jeder Transaktion automatisch verworfen wird. Das kann bestimmte Vertragsabläufe günstiger machen, schafft aber auch neue Fehlerquellen. Dieser Leitfaden erklärt die technische Logik, die wirtschaftliche Bedeutung und die Sicherheitsgrenzen ohne Renditeversprechen.
Was ist EIP-1153?
EIP-1153 ist ein Ethereum-Protokollstandard für sogenannten Transient Storage. Anders als gewöhnlicher persistenter Contract Storage existiert dieser Speicher nur während der Ausführung einer Transaktion. Innerhalb derselben Transaktion können mehrere Aufrufebenen eines Contracts auf den Wert zugreifen. Sobald die Transaktion abgeschlossen ist, ist der temporäre Zustand verschwunden. Das ist weder eine neue Kryptowährung noch ein Tokenstandard. Es handelt sich um eine Änderung der Ausführungsumgebung Ethereum Virtual Machine, kurz EVM.
Ein Beispiel: Ein DeFi-Contract führt mehrere interne Aktionen aus und benötigt währenddessen eine Sperre gegen unerwünschte Wiedereintritte. Diese Sperre muss nicht dauerhaft in der Blockchain verbleiben. Der Vertrag kann sie zu Beginn setzen, während weiterer interner Aufrufe abfragen und am Ende automatisch verlieren. Entscheidend ist die Abgrenzung: Ein temporärer Speicherwert ist nicht automatisch eine sichere Zugriffskontrolle. Der Code muss die Bedingungen korrekt definieren.
TLOAD und TSTORE: Die beiden neuen Opcodes
TLOAD mit Opcode 0x5c liest einen 32-Byte-Wert aus einem transienten Slot. TSTORE mit Opcode 0x5d schreibt einen 32-Byte-Wert in einen solchen Slot. Die Slot-Adressierung ähnelt SLOAD und SSTORE, den herkömmlichen Operationen für persistenten Storage. Der wesentliche Unterschied liegt in der Lebensdauer. Transient gespeicherte Werte werden weder als dauerhafter Zustand geladen noch am Ende der Transaktion in den persistenten Zustand geschrieben.
Laut EIP-1153 kostet TLOAD 100 Gas und TSTORE ebenfalls 100 Gas unter den in der Spezifikation beschriebenen Regeln. Diese Zahlen sind Opcode-Kosten, keine garantierten Gesamtgebühren für eine reale Transaktion. Hinzu kommen beispielsweise Berechnungen, Aufrufkosten, Datenübertragung und weitere EVM-Operationen. Ausserdem können sich Gebührenpreise zwischen Netzwerken und Zeitpunkten deutlich unterscheiden.
Transient Storage, Memory und Storage im Vergleich
Memory ist ein flüchtiger Arbeitsbereich einer konkreten Ausführungsumgebung. Persistenter Storage hält Vertragszustand über Transaktionen hinweg. Transient Storage liegt funktional dazwischen: Er wird für die gesamte Transaktion bereitgestellt und ist innerhalb des zugehörigen Contract-Kontexts über mehrere Aufrufe nutzbar. Dadurch eignet er sich für kurzlebige Koordination zwischen Call Frames, für die reines Memory nicht dieselbe gemeinsame Sicht bietet.
Der Ausdruck temporär darf nicht mit privat oder unsichtbar verwechselt werden. Transient Storage ist nicht als Verschlüsselung gedacht. Ein öffentlicher Blockchain-Aufruf lässt sich unter Umständen simulieren und sein Verhalten analysieren. Sensible Informationen gehören nicht allein deshalb in TSTORE, weil die Daten am Ende nicht dauerhaft als Contract Storage zurückbleiben. Auch Ereignisse, Calldata und andere Spuren können unabhängig davon bestehen.
Warum ist die Lebensdauer einer Transaktion so wichtig?
Eine Ethereum-Transaktion kann viele verschachtelte Aufrufe auslösen: Wallet, Router, Token-Contract und weitere Protokolle kommunizieren miteinander. Ein einzelner Aufruf kann einen weiteren Contract ansprechen, der wiederum zurück in den ursprünglichen Contract springt. Genau hier entstehen anspruchsvolle Sicherheitsfragen. Kurzlebige Werte müssen über mehrere Aufrufe hinweg konsistent bleiben, dürfen aber nach der Transaktion keine unerwarteten Nebenwirkungen verursachen.
Transient Storage beginnt für jede neue Transaktion wieder ohne die Werte aus der vorherigen Transaktion. Ein Entwickler darf daher niemals annehmen, dass eine mit TSTORE gespeicherte Freigabe am nächsten Tag oder in einem späteren Block noch vorhanden ist. Für dauerhafte Guthaben, Eigentumsrechte oder Token-Balances bleibt persistenter Storage beziehungsweise eine andere geeignete dauerhafte Zustandsverwaltung erforderlich.
Praxisbeispiel: Reentrancy Guard
Ein Reentrancy Guard soll verhindern, dass ein bestimmter geschützter Funktionsablauf während seiner Ausführung unerlaubt erneut betreten wird. Der Contract setzt dafür vor einer kritischen Aktion einen Sperrwert. Bei einem erneuten Aufruf prüft der Contract diesen Wert und bricht ab, falls die Sperre noch aktiv ist. Mit TSTORE lässt sich eine solche Sperre innerhalb derselben Transaktion setzen, mit TLOAD lesen und bei Bedarf wieder aufheben.
Das Design erfordert besondere Sorgfalt: Soll ein weiterer Aufruf innerhalb derselben Transaktion ausdrücklich erlaubt sein, muss die Sperrlogik dies berücksichtigen. Eine zu grobe Sperre kann legitime zusammengesetzte Transaktionen blockieren. Eine zu lockere Sperre kann Angriffe ermöglichen. Ein Reentrancy Guard ersetzt ausserdem weder die Checks-Effects-Interactions-Regel noch eine vollständige Prüfung externer Aufrufe und wirtschaftlicher Invarianten.
Weitere Hintergründe bietet unser bestehender Fachartikel zu Reentrancy-Angriffen: https://www.auswandernschweiz.ch/post/reentrancy-angriffe-smart-contract-defi-sicherheit
Werbung: Bitcoin mit Relai kaufen
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Der Code lautet AUSWANDERNSCHWEIZ. Relai ist keine Kaufplattform für die in diesem Fachartikel erläuterten Smart-Contract-Funktionen oder Altcoins.
Gasgebühren richtig berechnen
Ein vereinfachtes Rechenbeispiel zeigt den Unterschied zwischen Gasmenge und Kosten. Angenommen, eine Implementierung spart bei einem bestimmten Ablauf insgesamt 4'000 Gas. Bei einem hypothetischen effektiven Gaspreis von 20 Gwei entspricht das 4'000 × 20 × 10⁻⁹ ETH = 0,00008 ETH. Bei einem rein beispielhaften ETH-Kurs von 2'000 CHF wären das 0,16 CHF. Diese Rechnung ist keine aktuelle Kurs- oder Gebührenangabe, sondern eine Illustration der Einheiten.
Die tatsächliche Ersparnis ist nicht pauschal 4'000 Gas. Sie hängt von der konkreten bisherigen Implementierung, der Anzahl Lese- und Schreibvorgänge, den Storage-Refund-Regeln und dem übrigen Ablauf ab. Bei einem Contract, der kaum temporäre Zustände nutzt, kann die Änderung wirtschaftlich irrelevant sein. Ein seriöser Vergleich verwendet reproduzierbare Tests mit derselben EVM-Konfiguration und denselben Eingaben.
Was passiert bei Reverts und fehlgeschlagenen Aufrufen?
EIP-1153 definiert, dass Änderungen am transienten Zustand zurückgesetzt werden, wenn der zugehörige Ausführungsrahmen revertiert. Auch Schreibvorgänge aus verschachtelten Aufrufen können von dieser Rückabwicklung betroffen sein. Dadurch ähnelt das Fehlerverhalten dem persistenten Storage innerhalb einer Transaktion. Wer nur auf den automatisch gelöschten Zustand am Transaktionsende schaut, übersieht diese wichtige Eigenschaft.
Beispiel: Ein Contract setzt eine temporäre Freigabe und ruft eine andere Funktion auf. Scheitert der relevante Aufruf mit Revert, können die innerhalb dieses Rahmens vorgenommenen Änderungen zurückgerollt werden. Fängt ein übergeordneter Contract einen Fehler ab und setzt seine Ausführung fort, muss die Anwendung den tatsächlichen verbleibenden Zustand korrekt behandeln. Sicherheitsannahmen sollten anhand konkreter Call Trees getestet werden.
CALL, DELEGATECALL und STATICCALL
Der Eigentümer des transienten Speichers hängt vom Aufrufkontext ab. Bei CALL und STATICCALL gehört der Speicher dem aufgerufenen Contract. Bei DELEGATECALL und CALLCODE ist er dem aufrufenden Contract-Kontext zugeordnet. Das ist besonders relevant für Proxies und modulare Wallets. Ein Entwickler, der Bibliothekscode über DELEGATECALL ausführt, muss daher auf mögliche Überschneidungen von transienten Slot-Schlüsseln achten.
TSTORE ist in einem statischen Aufruf nicht erlaubt und führt dort zu einer Ausnahme. TLOAD kann dagegen in einem statischen Kontext verwendet werden. Diese Unterscheidung verhindert, dass schreibende Zustandsänderungen unter den Regeln eines statischen Aufrufs durchgeführt werden. Sie ersetzt aber keine umfassende Prüfung der übrigen Zugriffsrechte.
Temporäre Token-Freigaben und DeFi-Anwendungen
Die EIP nennt temporäre ERC-20-Freigaben als potenziellen Anwendungsfall. Ein Contract könnte eine Erlaubnis auf die aktuelle Transaktion begrenzen, statt sie langfristig zu speichern. Ob dies für einen bestimmten Token tatsächlich implementiert ist, muss anhand seines Codes und seiner Schnittstellen geprüft werden. EIP-1153 führt nicht automatisch ein allgemeines Token-Freigabesystem für sämtliche ERC-20-Token ein.
Nicht zu verwechseln ist diese technische Idee mit ERC-2612 Permit: Dort geht es um signaturbasierte Allowances. Auch EIP-712 strukturiert Signaturdaten, während EIP-1153 den Lebenszyklus eines Speicherbereichs regelt. Die Standards können in einem grösseren System gemeinsam vorkommen, lösen aber unterschiedliche Probleme.
Proxies, Smart Wallets und Account Abstraction
Modulare Wallet-Systeme können mehrere interne Komponenten und unterschiedliche Ausführungswege kombinieren. Transient Storage kann dort als kurzlebiger Kommunikationskanal dienen. Besonders sorgfältig muss jedoch geklärt werden, ob zwei Module dieselben Slots verwenden, wie Berechtigungen geprüft werden und was bei verschachtelten Aufrufen passiert. Eine fehlerhafte Namespace-Strategie kann zu unvorhergesehenen Interaktionen führen.
Account Abstraction und Smart-Contract-Signaturen sind davon getrennte Konzepte. ERC-1271 beschreibt die Prüfung von Signaturen durch Smart-Contract-Wallets; ERC-4337 und EIP-7702 betreffen andere Teile des Wallet-Ausführungsmodells. Transient Storage macht eine Wallet nicht automatisch sicherer oder benutzerfreundlicher. Sicherheit entsteht aus dem Zusammenspiel geprüfter Implementierungen und korrekter Autorisierung.
Welche Sicherheitsrisiken entstehen durch Transient Storage?
Die grösste Gefahr liegt nicht in einem neuen handelbaren Vermögenswert, sondern in falschen Annahmen über Zustandsgrenzen. Ein Contract könnte irrtümlich annehmen, eine temporäre Sperre sei nach einem internen Aufruf bereits verschwunden, obwohl die Transaktion weiterläuft. Umgekehrt könnte er davon ausgehen, dass eine Berechtigung über die Transaktion hinaus besteht. Beides kann zu Funktionsfehlern führen.
Weitere Risiken betreffen die Reihenfolge von Aufrufen, die Wiederverwendung von Slots, fehlerhafte Revert-Behandlung, externe Callbacks und Proxy-Kontexte. Besonders kritisch sind Contracts, die Guthaben bewegen oder Sicherheiten verwalten. Hier kann ein kleiner Implementierungsfehler wirtschaftliche Schäden verursachen, obwohl die verwendeten Opcodes formal korrekt funktionieren.
Für Nutzer bedeutet das: Prüfe vor der Interaktion mit einem DeFi-Protokoll dessen Sicherheitsdokumentation, Audits, Upgrade-Rechte und Notfallmechanismen. Audits reduzieren Risiken, garantieren aber keine Fehlerfreiheit. Bei Krypto-Investitionen kommen unabhängig von EIP-1153 Marktvolatilität, Liquiditätsprobleme, Betrug und das Risiko eines Totalverlusts hinzu.
Woran erkennst Du eine seriöse Implementierung?
Ein seriöses Projekt sollte erklären können, warum es temporären Speicher benötigt und wie dessen Lebensdauer getestet wird. Wichtig sind Tests mit mehreren verschachtelten Aufrufen, Rückabwicklungen, Proxy-Delegation und unerwarteten Callbacks. Sicherheitsprüfungen sollten sowohl den normalen Ablauf als auch bewusst fehlerhafte und bösartige Interaktionen abdecken.
Auch die unterstützte EVM-Version muss stimmen. Eine Implementierung, die TLOAD und TSTORE voraussetzt, kann nicht ohne Weiteres auf jedem EVM-kompatiblen Netzwerk oder jeder historischen Fork-Konfiguration funktionieren. Die Kompatibilität ist eine Eigenschaft der tatsächlich eingesetzten Ausführungsumgebung und nicht allein des Marketingbegriffs EVM-kompatibel.
Werbung: Bitcoin mit Relai kaufen
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Gutscheincode: AUSWANDERNSCHWEIZ. Die Werbung ist unabhängig vom technischen Thema dieses Artikels.
Bedeutung für Anleger und die Schweizer Krypto-Praxis
EIP-1153 ist ein Infrastrukturstandard. Er begründet weder einen eigenen Tokenpreis noch eine direkte Rendite. Ein günstigerer Ausführungsweg kann die Nutzung eines Protokolls wirtschaftlich beeinflussen, aber ein theoretischer Effizienzgewinn lässt sich nicht automatisch in höhere Erträge für Tokenhalter übersetzen. Geschäftsmodell, Wettbewerb, Sicherheitsniveau und Nachfrage bleiben separate Faktoren.
Für Personen in der Schweiz sind insbesondere Verwahrung, Gegenparteirisiken und die steuerliche Behandlung tatsächlicher Kryptowerte relevant. Ein technischer Opcode löst keine Steuerpflicht aus. Entstehen jedoch Erträge, Transaktionen oder Vermögenspositionen, sind die konkreten Umstände nach den geltenden Regeln zu beurteilen. Für individuelle Fragen sind aktuelle Informationen der ESTV und gegebenenfalls fachliche Beratung sinnvoll.
FAQ: Häufige Fragen zu EIP-1153
Speichert TSTORE Daten dauerhaft?
Nein. Transient Storage wird nach der Transaktion verworfen. Innerhalb derselben Transaktion kann er jedoch über mehrere passende Aufrufe hinweg zugänglich sein.
Ist TLOAD dasselbe wie SLOAD?
Nein. Beide lesen einen Slot, aber TLOAD liest transienten Zustand, während SLOAD auf persistenten Contract Storage zugreift. Lebensdauer und Gasregeln unterscheiden sich.
Sind Smart Contracts durch EIP-1153 automatisch sicher?
Nein. Die Opcodes ermöglichen neue Implementierungsmuster, aber Sicherheitsgarantien hängen vom gesamten Contract-Design ab. Insbesondere Reentrancy, Autorisierung und Reverts müssen weiterhin geprüft werden.
Kann ich EIP-1153 als Coin kaufen?
Nein. EIP-1153 ist ein Ethereum-Verbesserungsvorschlag und kein eigenständiger Coin oder handelbarer Token.
Spart jeder Nutzer damit Gebühren?
Nein. Nur wenn ein Contract die Funktionen tatsächlich nutzt und dadurch Gas einspart, kann ein Kostenvorteil entstehen. Der Marktpreis pro Gas und weitere Gebührenbestandteile bleiben entscheidend.
Fazit
EIP-1153 erweitert Ethereum um einen Speicherbereich, dessen Werte genau für die Dauer einer Transaktion bestehen. Mit TLOAD und TSTORE lassen sich bestimmte kurzlebige Zustände effizienter koordinieren, etwa Reentrancy-Sperren oder interne Abläufe modularer Smart Contracts. Der Nutzen ist technisch konkret, aber nicht pauschal: Ob eine Anwendung günstiger oder sicherer wird, muss ihr Code zeigen. Für Anleger ist die Unterscheidung zwischen Infrastrukturverbesserung und spekulativem Tokenwert besonders wichtig.
Dieser Beitrag dient der allgemeinen Information und ist keine individuelle Anlage-, Rechts- oder Steuerberatung. Kryptowährungen und DeFi-Anwendungen können zu erheblichen Verlusten bis zum Totalverlust führen.
Kommentare