EIP-2930 erklärt: Ethereum Access Lists, Gasgebühren und Risiken
Einleitung
Ethereum-Transaktionen können nicht nur Ether verschicken, sondern auch komplexe Programme ausführen. Dabei liest die Ethereum Virtual Machine Daten aus Konten und Speicherbereichen. EIP-2930 ermöglicht es, bestimmte Konten und Speicherpositionen bereits vor der Ausführung einer Transaktion anzukündigen. Diese sogenannten Access Lists beeinflussen die Gasabrechnung. Sie garantieren aber weder eine erfolgreiche Transaktion noch automatisch tiefere Gebühren. Dieser Fachartikel erklärt den technischen Mechanismus, die Grenzen und die Bedeutung für Nutzer von DeFi-Anwendungen.
Was ist EIP-2930?
EIP-2930 ist ein Ethereum Improvement Proposal mit dem Titel Optional Access Lists. Es definiert eine Transaktionsform, die eine Liste von Ethereum-Adressen und den zugehörigen Speicherpositionen mitführen kann. Der neue Transaktionstyp hat die Kennung 0x01. Er baut auf dem typisierten Transaktionsrahmen von EIP-2718 und den Regeln für kalte und warme Zustandszugriffe von EIP-2929 auf. Eine Access List ist keine Zugriffsberechtigung: Sie verbietet nicht, andere Speicherpositionen zu lesen oder andere Verträge aufzurufen. Sie bestimmt vielmehr, welche Einträge beim Start als bereits aufgewärmt gelten.
Warum Ethereum kalte und warme Zugriffe unterscheidet
Der Ethereum-Zustand enthält Konten, Smart-Contract-Code und zahlreiche Speicherwerte. Ein erster Zugriff auf bestimmte Daten kann für einen Client aufwendiger sein als ein weiterer Zugriff innerhalb derselben Transaktion. EIP-2929 berücksichtigt diese Unterscheidung bei der Gasabrechnung. Ein noch nicht berücksichtigter Speicherzugriff ist kalt, während ein bereits berücksichtigter Zugriff warm ist. Der Begriff warm bezeichnet einen Abrechnungszustand innerhalb der Transaktion, keine Zusicherung, dass die Daten physisch im Arbeitsspeicher eines jeden Nodes liegen. EIP-2930 erlaubt es, diesen warmen Zustand für bestimmte Einträge im Voraus zu erwerben.
Aufbau einer Access List
Eine Access List besteht aus Einträgen mit einer 20 Byte langen Ethereum-Adresse und einer Liste von 32 Byte langen Storage Keys. Ein Storage Key bezeichnet einen Speicherplatz innerhalb eines bestimmten Smart Contracts. Dieselbe numerische Speicherposition kann bei zwei Verträgen ganz unterschiedliche Inhalte besitzen. Deshalb reicht die Position allein nicht aus: Adresse und Storage Key bilden gemeinsam die relevante Zuordnung. Auch eine Adresse ohne zusätzliche Speicherpositionen ist zulässig. Das Format ist Bestandteil der signierten Transaktionsdaten und kann nicht nachträglich geändert werden, ohne die Signatur ungültig zu machen.
Welche Gaspreise schreibt der Standard vor?
Die EIP-2930-Spezifikation definiert 2'400 Gas für jede angegebene Adresse und 1'900 Gas für jeden angegebenen Storage Key. Diese Beträge werden zu Beginn der Ausführung zusätzlich berechnet. Ein vorab berücksichtigter Storage Key kann anschliessend mit dem warmen SLOAD-Preis von 100 Gas gelesen werden. Der kalte SLOAD-Zuschlag nach EIP-2929 beträgt dagegen 2'100 Gas für den ersten Zugriff. Entscheidend ist deshalb die Differenz zwischen dem Preis der Vorankündigung und den Kosten des sonst kalten Zugriffs. Gas ist eine Recheneinheit; der Geldbetrag ergibt sich erst zusammen mit dem tatsächlich gezahlten Preis pro Gas.
Rechenbeispiel für einen Storage Key
Angenommen, eine Transaktion greift erstmals auf einen bestimmten Storage Key eines ansonsten bereits warmen Vertrags zu. Ohne Vorankündigung werden für diesen ersten SLOAD 2'100 Gas berechnet. Mit Access List fallen 1'900 Gas für den Schlüssel und 100 Gas für den warmen Lesezugriff an, zusammen 2'000 Gas. Die rechnerische Differenz beträgt 100 Gas. Diese Ersparnis gilt nur für die hier isoliert betrachtete Konstellation. Eine Access List kann durch zusätzliche Adresskosten, nicht verwendete Einträge und andere Ausführungspfade insgesamt auch teurer werden.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Code: AUSWANDERNSCHWEIZ. Relai verkauft Bitcoin, keine Altcoins.
Rechenbeispiel für eine Adresse
Für einen ansonsten kalten Kontozugriff ist nach EIP-2929 ein Gaspreis von 2'600 vorgesehen. Wird die Adresse über die Access List aufgewärmt, fallen zunächst 2'400 Gas an; ein entsprechender warmer Zugriff kostet anschliessend 100 Gas. Das ergibt im einfachen Beispiel 2'500 statt 2'600 Gas, also ebenfalls 100 Gas Unterschied. Ein tatsächlicher Smart-Contract-Aufruf kann zahlreiche weitere Operationen und Speicherzugriffe auslösen. Deshalb lässt sich aus dieser isolierten Rechnung weder eine konkrete Transaktionsgebühr noch ein pauschaler Prozentsatz an Einsparungen ableiten.
Warum mehr Einträge nicht automatisch besser sind
Die Vorabkosten entstehen für die angegebenen Einträge unabhängig davon, ob der Ausführungspfad sie später tatsächlich nutzt. Wer eine lange Liste mit unnötigen Adressen oder Speicherpositionen signiert, kann Gas bezahlen, ohne davon zu profitieren. Auch doppelt aufgeführte Einträge sind laut Spezifikation nicht grundsätzlich verboten, verursachen aber zusätzliche Kosten. Eine gute Access List ist deshalb möglichst präzise. Die Herausforderung besteht darin, vor der endgültigen Ausführung zu wissen, welcher Zustand tatsächlich benötigt wird. Das ist bei dynamischen Smart Contracts und wechselnden Marktbedingungen nicht immer zuverlässig möglich.
Warum Simulationen fehlschlagen können
Wallets und Infrastrukturprogramme können Transaktionen simulieren, um die voraussichtlichen Zugriffe zu erkennen. Zwischen Simulation und Aufnahme in einen Block können sich jedoch Smart-Contract-Zustände verändern. Ein Liquiditätspool erhält möglicherweise neue Einlagen, ein Oracle liefert einen neuen Wert oder ein anderer Nutzer handelt vorher. Dadurch kann der reale Ausführungspfad von der Simulation abweichen. Die vorab erzeugte Liste ist dann unter Umständen unvollständig oder enthält überflüssige Einträge. EIP-2930 erlaubt weiterhin Zugriffe ausserhalb der Liste, sodass eine unvollständige Liste nicht allein deshalb eine Transaktion ungültig macht.
Access Lists und DeFi
DeFi-Protokolle lesen häufig mehrere Konten, Token-Salden, Pool-Reserven und Vertragsvariablen. Eine Access List kann die Kosten bestimmter vorhersehbarer Zugriffe verändern. Die eigentlichen wirtschaftlichen Risiken verschwinden dadurch nicht. Ein Swap kann wegen Slippage, unzureichender Liquidität oder einer veränderten Pool-Situation ungünstiger ausfallen. Ein Kredit kann liquidiert werden, wenn Sicherheiten nicht mehr ausreichen. Eine fehlerhafte Smart-Contract-Implementierung kann Gelder gefährden. Die Access List ist ein Werkzeug für die Ausführungskosten und nicht für die wirtschaftliche Sicherheit des Geschäfts.
Access Lists und Wallet-Sicherheit
Eine Access List ist weder eine Freigabeliste vertrauenswürdiger Empfänger noch eine Zugriffskontrolle für Deine Wallet. Sie sagt nichts darüber aus, ob eine Vertragsadresse seriös ist. Ein betrügerischer Smart Contract kann ebenfalls in einer Access List stehen. Entscheidend bleiben die tatsächlich signierten Transaktionsdaten, Token-Genehmigungen und die überprüfte Vertragslogik. Achte bei Wallet-Anfragen auf das Netzwerk, die Zieladresse, die angeforderte Aktion und mögliche unbegrenzte Token-Freigaben. Die Existenz einer Access List ist kein Qualitäts- oder Sicherheitsmerkmal.
Unterschied zu EIP-1559
EIP-2930 und EIP-1559 betreffen unterschiedliche Aspekte einer Transaktion. EIP-2930 beschreibt den typisierten Transaktionstyp 1 mit optionaler Access List und einem Gaspreisfeld. EIP-1559 führte einen weiteren Transaktionstyp und das System mit maximaler Gebühr und Prioritätsgebühr ein. Auch neuere Transaktionstypen können Access Lists enthalten. Die konkrete ETH-Gebühr hängt nicht nur von der Gasmenge, sondern auch vom Preis pro Gas und den jeweils geltenden Netzwerkregeln ab. Wer nur die Access List optimiert, hat deshalb noch nicht die gesamte Gebührenstrategie optimiert.
Technische Grenzen und wirtschaftliche Risiken
Die Effizienz einer Access List hängt vom tatsächlichen Ausführungspfad ab. Wenn die erwarteten Speicherzugriffe ausbleiben, können die Vorabkosten die Einsparungen übersteigen. Fehlerhafte oder unvollständige Simulationen führen nicht automatisch zu einem Sicherheitsproblem, können aber die Kostenrechnung verschlechtern. Unabhängig davon bestehen die allgemeinen Risiken von Kryptowährungen: starke Kursschwankungen bis zum Totalverlust, Phishing, kompromittierte Private Keys, Smart-Contract-Fehler und Betrug. Bei Bridge-Anwendungen kommen zusätzliche Vertrauensannahmen und mögliche Schwachstellen der Cross-Chain-Infrastruktur hinzu.
Für wen ist EIP-2930 relevant?
Für die meisten Privatanleger ist es nicht erforderlich, Access Lists manuell zusammenzustellen. Die Funktion ist besonders für Wallet-Entwickler, Infrastrukturbetreiber und Entwickler komplexer Smart Contracts interessant. Wer Ethereum-Transaktionen analysiert, sollte wissen, dass die angegebene Gasmenge nicht allein die ausgeführten Rechenoperationen abbildet. Vorabkosten für Access Lists können Bestandteil der Gesamtabrechnung sein. Wer selbst eine Access List erstellt, sollte den Effekt unter realistischen Bedingungen testen und nicht allein anhand einer theoretischen Einzeloperation entscheiden.
Fazit
EIP-2930 macht bestimmte Zustandszugriffe innerhalb von Ethereum-Transaktionen im Voraus deklarierbar. Der Vorteil besteht in einer anderen, teilweise günstigeren Abrechnung vorhersehbarer Konten- und Speicherzugriffe. Der Standard verhindert aber keine Zugriffe ausserhalb der Liste und garantiert weder tiefere Gesamtkosten noch sichere Smart Contracts. Für eine sachliche Bewertung sind die Vorabkosten, der tatsächliche Ausführungspfad und der jeweils verwendete Transaktionstyp gemeinsam zu betrachten. Der technische Nutzen ist real, aber kontextabhängig.
Quellen und weiterführende Literatur
Buterin, V. und Swende, M.: EIP-2930 – Optional Access Lists. https://eips.ethereum.org/EIPS/eip-2930 . Ethereum Improvement Proposals: EIP-2929 – Gas cost increases for state access opcodes. https://eips.ethereum.org/EIPS/eip-2929 . Ethereum Improvement Proposals: EIP-2718 – Typed Transaction Envelope. https://eips.ethereum.org/EIPS/eip-2718 . Ethereum Improvement Proposals: EIP-1559 – Fee market change for ETH 1.0 chain. https://eips.ethereum.org/EIPS/eip-1559 . Heimbach et al.: Dissecting the EIP-2930 Optional Access Lists. https://arxiv.org/abs/2312.06574 .
Welche Einträge bereits ohne Access List warm sind
Bei der Gasabrechnung beginnt eine Transaktion nicht mit einer vollkommen leeren Menge warmer Adressen. Bestimmte Konten, darunter der Absender und das Transaktionsziel, werden durch die Regeln des Protokolls bereits berücksichtigt. Ausserdem können weitere besondere Adressen abhängig von der Protokollversion dazugehören. Eine zusätzliche Vorankündigung bereits warmer Einträge kann deshalb keinen vergleichbaren Nutzen bringen. Wer die Wirtschaftlichkeit einer Liste beurteilt, muss den Anfangszustand der Zugriffsmenge kennen. Der einfache Vergleich von 2'400 mit 2'600 Gas ist nur für tatsächlich kalte Adressen sinnvoll. Andernfalls kann die Liste eine reine Zusatzbelastung darstellen. Eine Simulation sollte deshalb mit den korrekten Regeln des Zielnetzwerks erfolgen.
Warum die Reihenfolge der Zugriffe eine Rolle spielt
Die Gasberechnung ist pfadabhängig. Wird ein Storage Key erstmals gelesen, unterscheidet sich seine Abrechnung von späteren Lesezugriffen auf denselben Key. Der spätere Zugriff ist bereits warm, selbst wenn keine Access List verwendet wurde. Bei einem mehrfachen Zugriff lässt sich daher nicht für jede Wiederholung dieselbe Ersparnis ansetzen. Der wesentliche Effekt entsteht beim ersten relevanten Kontakt mit einem zuvor kalten Eintrag. Wer die Einsparung mit der Zahl aller Leseoperationen multipliziert, überschätzt den Nutzen. Auch interne Aufrufe zwischen Verträgen können den Zustand der Zugriffsmenge beeinflussen. Für eine verlässliche Berechnung muss die gesamte Ausführung nachvollzogen werden, nicht nur eine einzelne Zeile Smart-Contract-Code.
Ein Beispiel mit mehreren Storage Keys
Stell Dir vor, eine Transaktion liest erstmals drei verschiedene Speicherpositionen eines bereits warmen Vertrags. Ohne Access List kosten diese ersten drei kalten SLOAD-Zugriffe zusammen 6'300 Gas. Werden genau diese drei Schlüssel vorab angekündigt, entstehen 5'700 Gas Vorabkosten und 300 Gas für die drei warmen Lesezugriffe, zusammen 6'000 Gas. In diesem idealisierten Beispiel beträgt die Differenz 300 Gas. Werden dagegen vier Schlüssel angekündigt, aber nur drei genutzt, steigen die Vorabkosten auf 7'600 Gas und die drei Lesezugriffe kosten zusätzlich 300 Gas. Die Liste wäre dann im Vergleich deutlich teurer. Das Beispiel zeigt, warum Genauigkeit wichtiger ist als Listenlänge.
Umrechnung von Gas in ETH
Die Gasmenge ist nicht mit dem Geldbetrag gleichzusetzen. Als rein hypothetische Rechnung nehmen wir einen effektiven Preis von 20 Gwei pro Gas an. Eine Einsparung von 300 Gas entspricht dann 6'000 Gwei oder 0,000006 ETH. Bei einem anderen Gaspreis ändert sich der ETH-Betrag proportional. Diese Zahlen sind ein mathematisches Beispiel und keine Aussage über aktuelle Netzwerkgebühren. Auch der Marktwert in CHF oder EUR hängt vom jeweiligen ETH-Kurs ab. Wer Transaktionen vergleicht, sollte dieselbe Ausführung, denselben Zustand und dieselben Gebührenannahmen zugrunde legen. Andernfalls können scheinbare Ersparnisse schlicht aus verschiedenen Marktbedingungen stammen.
Was bedeutet Transaktionstyp 1?
Der Standard definiert eine typisierte Transaktion mit der Kennung 0x01. Das Datenformat enthält unter anderem Chain ID, Nonce, Gaspreis, Gaslimit, Empfänger, Wert, Transaktionsdaten, Access List und Signaturbestandteile. Die Kennung ist Teil des signierten Formats. Dadurch kann eine Signatur nicht einfach als Freigabe für einen anderen Transaktionstyp interpretiert werden. EIP-2718 schafft den allgemeinen Rahmen, in dem unterschiedliche Transaktionsformate nebeneinander existieren können. Typ 1 ist deshalb nicht mit jeder Ethereum-Transaktion gleichzusetzen. Spätere Standards ergänzten andere Typen und Gebührenmechanismen. Bei der Analyse einer konkreten Transaktion lohnt sich ein Blick auf deren Typ, bevor man die Gebührenfelder interpretiert.
Signaturen und Chain ID
Die Chain ID gehört zu den Transaktionsdaten und dient der Zuordnung zu einem Netzwerk. Eine korrekt erzeugte Signatur bindet die relevanten Daten, einschliesslich der Access List, an die Transaktion. Änderungen an einem Speicherkey, einer Adresse oder an anderen signierten Feldern führen dazu, dass die ursprüngliche Signatur nicht mehr zur veränderten Transaktion passt. Das ist wichtig, weil die Access List Auswirkungen auf die Kosten hat. Allerdings ist die Signatur keine Garantie für einen wirtschaftlich sinnvollen oder ungefährlichen Vertragsaufruf. Wer eine Transaktion autorisiert, bestätigt möglicherweise zugleich einen riskanten Token-Transfer oder eine Genehmigung. Die kryptografische Integrität und die wirtschaftliche Vertrauenswürdigkeit sind getrennt zu beurteilen.
Wie Entwickler eine Liste testen
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Code: AUSWANDERNSCHWEIZ. Relai verkauft Bitcoin, keine Altcoins.
Entwickler können eine geplante Transaktion zunächst gegen einen konkreten Ethereum-Zustand simulieren und dabei beobachten, welche Konten und Speicherpositionen berührt werden. Anschliessend lässt sich eine Access List ableiten und die geschätzte Gasmenge erneut berechnen. Sinnvoll ist ein Vergleich zwischen einer Ausführung mit und ohne Liste bei möglichst identischem Zustand. Wiederholte Tests mit unterschiedlichen Zuständen können zeigen, wie stabil die Ergebnisse sind. Wenn eine Anwendung dynamische Pfade nutzt, sollte nicht allein die günstigste Simulation massgeblich sein. Ebenso wichtig ist, wie stark die tatsächlichen Kosten bei abweichenden Zuständen steigen können. Die Entscheidung über eine Liste ist somit eine Frage von Messung und Robustheit.
Warum eine Access List keine Berechtigungsliste ist
Der englische Ausdruck Access List wird in anderen IT-Systemen häufig für Regeln verwendet, die den Zugriff auf Ressourcen erlauben oder verweigern. Bei EIP-2930 bedeutet er etwas anderes. Die Liste enthält geplante Zustandszugriffe für die Gasabrechnung. Ein nicht gelisteter Vertrag darf weiterhin aufgerufen werden, wenn die Transaktion und die Smart-Contract-Logik das zulassen. Ebenso wird ein gelisteter Vertrag dadurch nicht automatisch vertrauenswürdig. Diese Unterscheidung ist gerade für Einsteiger wichtig, weil die Bezeichnung ein falsches Sicherheitsgefühl vermitteln kann. Für Wallet-Berechtigungen, Token-Allowances und den Schutz privater Schlüssel gelten eigenständige Mechanismen, die durch EIP-2930 nicht ersetzt werden.
Welche Risiken bestehen bei automatischer Optimierung?
Eine Wallet oder ein Dienstleister kann versuchen, Access Lists automatisch zu erzeugen. Dabei entsteht eine zusätzliche Abhängigkeit von der Qualität der Simulation und von der verwendeten Infrastruktur. Eine fehlerhafte Prognose muss die Transaktion nicht verhindern, kann aber ihre Gasmenge erhöhen. Bei zeitkritischen DeFi-Aktionen kann eine verzögerte oder ungenaue Schätzung die Planung erschweren. Nutzer sollten deshalb nicht davon ausgehen, dass ein als optimiert bezeichnetes Transaktionsformat unter allen Bedingungen günstiger ist. Transparente Werkzeuge sollten die Annahmen offenlegen und möglichst einen Vergleich mit der Variante ohne Access List ermöglichen. Das gilt besonders dann, wenn sich der Zustand der beteiligten Smart Contracts schnell verändert.
Forschung zu tatsächlichen Einsparungen
Die wissenschaftliche Untersuchung Dissecting the EIP-2930 Optional Access Lists analysierte reale Ethereum-Transaktionen und zeigte, dass die Qualität der Listen eine wesentliche Rolle spielt. Die Autoren untersuchten sowohl mögliche Einsparungen als auch fehlerhafte oder ineffiziente Listen. Solche historischen Messungen sind hilfreich, um die praktische Bedeutung des Standards einzuordnen. Sie dürfen aber nicht ohne Weiteres als aktuelle Netzwerkstatistik oder Garantie für künftige Einsparungen verstanden werden. Ethereum entwickelt sich weiter, Gebührenbedingungen ändern sich und Wallets passen ihre Implementierungen an. Für aktuelle Aussagen wären neue, methodisch nachvollziehbare Daten erforderlich. Die technische Grundregel bleibt jedoch: Nur tatsächlich hilfreiche Einträge können die Vorabkosten rechtfertigen.
Vergleich mit anderen Ethereum-Verbesserungen
EIP-2930 beschäftigt sich mit dem Vorabkennzeichnen von Zustandszugriffen. EIP-712 regelt dagegen die strukturierte Signatur von Daten, EIP-1153 den temporären Speicher innerhalb einer Transaktion, EIP-2935 die Verfügbarkeit bestimmter historischer Blockhashes und EIP-4788 die Bereitstellung von Beacon-Block-Roots für Smart Contracts. Die Nummern können ähnlich aussehen, die Funktionen sind jedoch grundverschieden. Für Leser ist diese Abgrenzung wichtig, weil die Standards nicht beliebig austauschbar sind. Eine Verbesserung bei der Datensignatur verändert nicht automatisch die Kosten kalter Speicherzugriffe. Ebenso macht ein neuer Systemvertrag eine Access List nicht überflüssig. Jeder Standard sollte anhand seines eigenen technischen Problems beurteilt werden.
Bedeutung für Nutzer in der Schweiz
Für Nutzer mit Wohnsitz in der Schweiz gelten bei der Bewertung von Ethereum-Transaktionen dieselben technischen Protokollregeln wie für andere Teilnehmer desselben Netzwerks. Die steuerliche Behandlung von Kryptowährungen ist dagegen eine gesonderte Frage und hängt von den individuellen Umständen sowie der jeweils anwendbaren Praxis ab. Eine Einsparung bei Gasgebühren ist nicht automatisch ein steuerlich relevanter Gewinn und sollte nicht mit einem Kursgewinn verwechselt werden. Wer umfangreiche DeFi-Aktivitäten dokumentiert, sollte Transaktionsbelege, Gebühren und den jeweiligen Kontext nachvollziehbar aufbewahren. Dieser Artikel erläutert Technik und Risiken, nicht die individuelle steuerliche Einordnung oder Anlageentscheidung.
FAQ: Muss ich Access Lists selbst erstellen?
Nein. Für gewöhnliche Nutzer ist eine manuelle Erstellung normalerweise nicht erforderlich. Wallets und Entwicklerwerkzeuge können die technischen Details übernehmen. Ob eine solche Optimierung angeboten wird und wie gut sie funktioniert, hängt vom jeweiligen Werkzeug ab. Bei einer Transaktion solltest Du vor allem prüfen, was Du signierst, welche Werte bewegt werden und welche Vertragsberechtigungen entstehen. Die Access List ist lediglich ein zusätzlicher Bestandteil der Ausführungs- und Gebührenlogik. Wenn Du die Kosten eines komplexen Smart-Contract-Aufrufs verstehen willst, kann ein technischer Transaktionsbericht hilfreicher sein als der Versuch, einzelne Speicherkeys manuell zusammenzustellen.
FAQ: Kann eine falsche Access List mein Geld verlieren lassen?
Eine unvollständige Access List allein verbietet keine weiteren Zustandszugriffe und ist daher nicht gleichbedeutend mit einer fehlgeschlagenen Transaktion. Eine ineffiziente Liste kann allerdings zusätzliche Gasgebühren verursachen. Der eigentliche Verlust von Token oder Ether kann aus dem ausgeführten Smart Contract, einer falschen Zieladresse, einer schädlichen Freigabe, einem kompromittierten Schlüssel oder wirtschaftlichen Risiken der Anwendung entstehen. Deshalb sollten Gasoptimierung und Sicherheitsprüfung getrennt stattfinden. Auch eine technisch korrekt ausgeführte Transaktion kann finanziell nachteilig sein. Prüfe insbesondere bei DeFi-Anwendungen die Vertragsadresse, die beabsichtigte Aktion und die möglichen Folgen vor der Signatur.
FAQ: Spart EIP-2930 immer Gas?
Nein. Die Vorankündigung verursacht selbst Gas und lohnt sich nur, wenn die Einsparungen bei tatsächlich genutzten Zustandszugriffen diese Kosten mindestens ausgleichen. Bei überflüssigen Einträgen kann die Transaktion teurer werden. Zudem sind manche Adressen schon ohne Access List warm, sodass eine zusätzliche Aufnahme keinen Vorteil bietet. Der Vergleich muss die gesamte Transaktion und ihren tatsächlichen Zustand berücksichtigen. Ein pauschales Versprechen über eine bestimmte prozentuale Ersparnis wäre deshalb irreführend. Gerade bei stark dynamischen Smart Contracts ist die Genauigkeit einer vorherigen Simulation begrenzt.
Kommentare