EVM-Memory vs. EVM-Storage: Der Unterschied erklärt

Definition

Die Ethereum Virtual Machine (EVM) ist die Laufzeitumgebung für Smart Contracts auf der Ethereum-Blockchain. Sie ist eine zentrale Komponente, die den Code dezentraler Anwendungen ausführt. Innerhalb dieser Umgebung verwalten Smart Contracts Daten mithilfe verschiedener Speichermechanismen, hauptsächlich Memory und Storage. Das Verständnis des Unterschieds zwischen diesen beiden ist grundlegend für jeden, der verstehen möchte, wie Smart Contracts funktionieren, wie sie Ressourcen verbrauchen und wie ihr Zustand aufrechterhalten wird.

EVM-Memory bezeichnet einen temporären, flüchtigen Datenspeicher, der von Smart Contracts während der Ausführung eines einzelnen Funktionsaufrufs verwendet wird. Daten, die hier gespeichert werden, sind nicht persistent und werden gelöscht, sobald die Funktionsausführung abgeschlossen ist.

EVM-Storage bezeichnet einen permanenten, persistenten Datenspeicher auf der Blockchain, in dem die Zustandsvariablen eines Smart Contracts abgelegt werden. Daten im Storage bleiben unbegrenzt erhalten und sind Teil des globalen Zustands des Ethereum-Netzwerks.

Kernaussage

Der grundlegende Unterschied zwischen EVM-Memory und EVM-Storage liegt in ihrer Persistenz und ihren Kosten. Memory ist ein transienter Arbeitsbereich, vergleichbar mit dem RAM eines Computers, der für die kurzfristige Datenverarbeitung innerhalb einer Transaktion genutzt wird. Dies macht ihn relativ kostengünstig, aber nicht persistent. Storage hingegen ist die permanente Datenbank des Contracts, vergleichbar mit einer Festplatte, in der alle kritischen Zustandsvariablen gespeichert werden. Das Schreiben in Storage ist erheblich teurer, gewährleistet aber die Langlebigkeit der Daten über Transaktionen hinweg. Diese Unterscheidung bestimmt, wie Entwickler ihre Smart Contracts strukturieren und den Gasverbrauch steuern.

Mechanik

Die internen Funktionsweisen von EVM-Memory und Storage sind unterschiedlich und für ihre jeweiligen Zwecke optimiert.

EVM-Memory ist ein byte-adressierbares lineares Array, das erweitert werden kann. Es ist in 32-Byte-Slots organisiert. Wenn eine Smart-Contract-Funktion aufgerufen wird, wird ein frischer, leerer Speicherbereich zugewiesen. Daten können mithilfe spezifischer EVM-Opcodes (z.B. MSTORE, MLOAD) in den Speicher geschrieben und daraus gelesen werden. Die Kosten für die Nutzung von Memory sind dynamisch; sie beginnen relativ niedrig, steigen aber quadratisch an, je mehr Speicherplatz beansprucht wird, was die zugrunde liegenden Rechenressourcen widerspiegelt. Diese quadratische Skalierung ermutigt Entwickler, Memory effizient und nur für die Daten zu nutzen, die für den aktuellen Vorgang wirklich benötigt werden. Memory wird typischerweise für Zwischenberechnungen, die Speicherung von Funktionsargumenten (insbesondere für interne Aufrufe) und die Vorbereitung von Daten für Rückgabewerte oder Event-Emissionen verwendet. Variablen, die in Solidity mit dem Schlüsselwort memory deklariert werden, werden hier gespeichert.

EVM-Storage ist ein persistenter Key-Value-Speicher, bei dem sowohl Schlüssel als auch Werte 32 Bytes (256 Bit) groß sind. Er ist Teil des globalen Zustands der Ethereum-Blockchain. Jeder Smart Contract verfügt über einen eigenen dedizierten Speicherplatz, im Wesentlichen eine Zuordnung von 256-Bit-Speicher-Slots zu 256-Bit-Werten. Das Schreiben in Storage (mithilfe des SSTORE-Opcodes) ist die teuerste Operation in der EVM, da es die Änderung des Blockchain-Zustands beinhaltet, der über alle Netzwerkknoten hinweg verbreitet und dauerhaft gespeichert werden muss. Das Lesen aus Storage (mithilfe des SLOAD-Opcodes) ist deutlich günstiger als das Schreiben, aber immer noch teurer als Memory-Operationen. Zustandsvariablen, die in Solidity ohne explizite Datenlokation deklariert werden, werden standardmäßig im Storage gespeichert. Komplexe Datenstrukturen wie Mappings und dynamische Arrays befinden sich ebenfalls im Storage, wobei ihre Elemente spezifische, deterministisch berechnete Speicher-Slots belegen. Die hohen Kosten für Storage-Schreibvorgänge sind eine bewusste Designentscheidung, um ein effizientes Contract-Design zu fördern und eine Überladung der Blockchain zu verhindern.

Die EVM verwendet auch den Stack für sehr kleine, temporäre Werte während der Opcode-Ausführung und Calldata als schreibgeschützten, temporären Bereich für externe Funktionsargumente. Calldata ähnelt Memory in seiner temporären Natur, kann aber vom Contract selbst nicht beschrieben werden, was es noch günstiger für die Übergabe externer Argumente macht.

Trading-Relevanz

Obwohl die Unterscheidung zwischen EVM-Memory und Storage rein technisch erscheinen mag, hat sie erhebliche indirekte Auswirkungen auf Trader und Teilnehmer im Krypto-Ökosystem. Die Effizienz von Smart Contracts, die stark von ihrer Memory- und Storage-Nutzung beeinflusst wird, wirkt sich direkt auf Transaktionskosten, Netzwerküberlastung und letztendlich auf die Rentabilität und Sicherheit dezentraler Anwendungen (dApps) aus.

Hohe Gaskosten, die oft durch ineffiziente Storage-Schreibvorgänge verursacht werden, können bestimmte Trading-Strategien oder dApp-Interaktionen unwirtschaftlich machen. Beispielsweise könnte ein Arbitrage-Bot, der auf schnelle, kostengünstige Transaktionen angewiesen ist, seine Rentabilität schwinden sehen, wenn die zugrunde liegenden DEX-Smart-Contracts ineffizient gestaltet sind und zu höheren Transaktionsgebühren führen. Ebenso werden Nutzer, die mit DeFi-Protokollen für Kreditvergabe, -aufnahme oder Yield Farming interagieren, unterschiedliche Transaktionskosten erfahren, je nachdem, wie gut die Contract-Entwickler ihre Storage-Operationen optimiert haben. Projekte, die Gas-Effizienz priorisieren, indem sie unnötige Storage-Schreibvorgänge minimieren und Memory oder Calldata angemessen nutzen, können eine kostengünstigere und benutzerfreundlichere Erfahrung bieten, potenziell mehr Nutzer und Liquidität anziehen. Diese Effizienz kann ein Wettbewerbsvorteil in der überfüllten DeFi-Landschaft sein.

Darüber hinaus kann das Verständnis dieser Mechanismen Einblicke in die Sicherheit und Robustheit eines Smart Contracts geben. Contracts, die kritische Daten im Storage verwalten, müssen dies sorgfältig tun, um Schwachstellen wie Storage-Kollisionen oder unerwartete Zustandsänderungen zu verhindern. Trader, die ein neues DeFi-Protokoll oder NFT-Projekt bewerten, könnten die Gas-Effizienz und architektonische Solidität des zugrunde liegenden Contracts als Indikatoren für dessen langfristige Nachhaltigkeit und Sicherheit betrachten. Ein Contract mit übermäßigen Storage-Operationen könnte auf potenzielle Skalierbarkeitsprobleme oder höhere Betriebskosten für seine Nutzer hinweisen, was sich auf seine Akzeptanz und den Wert der zugehörigen Token auswirken könnte.

Risiken

Der Missbrauch oder das Missverständnis von EVM-Memory und Storage birgt mehrere Risiken, die von wirtschaftlichen Ineffizienzen bis hin zu kritischen Sicherheitslücken reichen.

Ein primäres Risiko ist der übermäßige Gasverbrauch. Eine ineffiziente Nutzung von Storage, insbesondere häufige oder unnötige Schreibvorgänge, kann zu unerschwinglich hohen Transaktionsgebühren führen. Jede SSTORE-Operation, die einen Storage-Slot von Null auf einen Nicht-Null-Wert ändert, kostet 20.000 Gas, während das Ändern eines Nicht-Null-Wertes 5.000 Gas kostet. Das Löschen eines Storage-Slots bietet eine Gas-Rückerstattung, die jedoch oft nicht ausreicht, um die anfänglichen Schreibkosten auszugleichen. Entwickler, die es versäumen, ihre Storage-Nutzung zu optimieren, können dApps erstellen, die für Nutzer zu teuer sind, was die Akzeptanz behindert und potenziell zu einer "Abwärtsspirale" führen kann, bei der hohe Kosten Nutzer abschrecken. Dies ist besonders kritisch für Anwendungen, die viele Zustandsänderungen erfordern, wie komplexe DeFi-Protokolle oder Gaming-dApps.

Ein weiteres erhebliches Risiko sind Sicherheitslücken. Eine falsche Handhabung von Datenlokationen kann zu subtilen, aber gefährlichen Fehlern führen. Wenn ein Entwickler beispielsweise versehentlich eine memory-Referenz verwendet, wo eine storage-Referenz beabsichtigt war, oder umgekehrt, kann dies dazu führen, dass Daten nicht persistent gespeichert werden, oder schlimmer noch, zu unbeabsichtigten Änderungen an Zustandsvariablen. Storage-Kollisionen, bei denen verschiedene Variablen oder Datenstrukturen aufgrund falscher Packung oder Zeigerarithmetik versehentlich denselben Storage-Slot belegen, können zu Datenkorruption oder unbefugtem Zugriff führen. Obwohl Solidity vieles davon abstrahiert, ist ein tiefes Verständnis für Audits und sichere Entwicklung unerlässlich. Reentrancy-Angriffe, obwohl sie primär mit externen Aufrufen zusammenhängen, können verschärft werden, wenn Zustandsvariablen im Storage nicht korrekt aktualisiert werden, bevor externe Aufrufe getätigt werden.

Schließlich gibt es Skalierbarkeits- und Netzwerkgesundheitsrisiken. Jedes Byte, das in Storage geschrieben wird, trägt zur Gesamtgröße des Ethereum-Blockchain-Zustands bei. Ein größerer Zustand erfordert mehr Ressourcen für Full Nodes, um ihn zu speichern, zu synchronisieren und zu validieren, was potenziell die Dezentralisierung und Netzwerkleistung beeinträchtigt. Ineffiziente Storage-Nutzung über Tausende von dApps kann zu einer Überladung der Blockchain führen, was es für neue Nodes schwieriger macht, dem Netzwerk beizutreten und es aufrechtzuerhalten. Dies ist ein langfristiges Anliegen für die Nachhaltigkeit von Ethereum.

Geschichte und Beispiele

Die Unterscheidung zwischen temporärer und permanenter Datenspeicherung ist ein Eckpfeiler der Computerarchitektur lange bevor die Blockchain aufkam. In der traditionellen Informatik spiegelt dies den Unterschied zwischen RAM (Random Access Memory) für transiente Operationen und Festplatten (HDD/SSD) für persistente Datenspeicherung wider. Die Ethereum Virtual Machine, die als globaler, dezentraler Computer konzipiert wurde, übernahm ein ähnliches Paradigma, um ihren einzigartigen Zustand zu verwalten.

Als Ethereum konzipiert wurde, war die Notwendigkeit eines persistenten, global überprüfbaren Zustands für Smart Contracts von größter Bedeutung, damit sie als "unstoppable applications" funktionieren konnten. Dies führte zum Design von EVM-Storage als unveränderlichem Datensatz der Contract-Variablen, der sicherstellt, dass eine Zustandsänderung, sobald sie in der Blockchain festgeschrieben ist, für immer dort verbleibt. Gleichzeitig erforderte die Notwendigkeit einer effizienten, temporären Berechnung innerhalb einer einzelnen Transaktion EVM-Memory, wodurch Contracts komplexe Berechnungen durchführen konnten, ohne die prohibitiven Kosten des persistenten Speichers für Zwischenwerte zu verursachen. Dieser duale Ansatz gleicht die Notwendigkeit der Zustandspermanenz mit der rechnerischen Effizienz aus.

Beispiele für die EVM-Memory-Nutzung:

String-Manipulation: Wenn ein Contract Strings verketten oder Daten für ein Event-Log formatieren muss, verwendet er oft Memory, um den temporären String zu erstellen, bevor das Event emittiert oder der Wert zurückgegeben wird.
Dynamische Arrays in Funktionen: Wenn eine Funktion ein dynamisches Array als Argument erhält oder eines für die interne Verarbeitung erstellen muss, wird es typischerweise im Memory abgelegt. Zum Beispiel könnte eine Funktion, die eine Liste von Adressen sortiert, diese in ein Memory-Array laden, sortieren und dann die sortierte Liste zurückgeben.
Rückgabewerte: Komplexe Datenstrukturen, die von Funktionen zurückgegeben werden, werden oft im Memory konstruiert, bevor sie an den Aufrufer zurückgegeben werden.

Beispiele für die EVM-Storage-Nutzung:

Token-Guthaben: In einem ERC-20-Token-Contract speichert ein mapping(address => uint256) public balances; das permanente Guthaben jedes Nutzers. Dies ist ein klassisches Beispiel für Storage.
NFT-Besitz: Für einen ERC-721-NFT speichert ein mapping(uint256 => address) public ownerOf; welche Adresse eine bestimmte Token-ID besitzt. Diese Daten müssen über alle Transaktionen hinweg persistent sein.
DAO-Abstimmungsergebnisse: Ein Decentralized Autonomous Organization (DAO)-Contract würde Abstimmungsvorschläge, Mitgliederlisten und die Ergebnisse von Abstimmungen im Storage speichern, um deren Permanenz und Transparenz zu gewährleisten.
Contract-Eigentümer: Die Adresse des Contract-Eigentümers, oft als address public owner; gespeichert, ist eine Zustandsvariable, die im Storage liegt.

Diese Beispiele verdeutlichen, wie Entwickler bewusst zwischen Memory und Storage wählen, je nachdem, ob die Daten über die aktuelle Transaktion hinaus persistent sein müssen oder lediglich temporär für die Berechnung sind.

Häufige Missverständnisse

Die Unterscheidung zwischen EVM-Memory und Storage, obwohl grundlegend, ist oft eine Quelle der Verwirrung für Entwickler und Enthusiasten, was zu suboptimalen Contract-Designs oder Sicherheitslücken führt.

Ein weit verbreitetes Missverständnis ist die Unterschätzung des Gas-Kostenunterschieds. Viele neue Entwickler behandeln Memory und Storage als austauschbare Datenlokationen und verstehen nicht vollständig, dass das Schreiben in Storage um Größenordnungen teurer ist als das Schreiben in Memory. Dies kann zu Contracts führen, die unnötige Storage-Schreibvorgänge innerhalb von Schleifen oder für temporäre Daten durchführen, was zu exorbitanten Transaktionsgebühren führt. Zum Beispiel ist das Speichern eines Zwischenberechnungsergebnisses in einer Zustandsvariablen (Storage), obwohl es für die Dauer des Funktionsaufrufs vollständig im Memory hätte verarbeitet werden können, ein häufiger, kostspieliger Fehler.

Ein weiteres häufiges Missverständnis betrifft die Datensichtbarkeit und den Geltungsbereich. Entwickler gehen manchmal davon aus, dass im Memory gespeicherte Daten über verschiedene externe Funktionsaufrufe innerhalb derselben Transaktion zugänglich sind, was falsch ist. Memory wird bei jedem externen Funktionsaufruf zurückgesetzt. Während interne Aufrufe innerhalb desselben Contracts Memory teilen, erhalten externe Aufrufe (selbst an denselben Contract) einen frischen Memory-Bereich. Dies kann zu unerwartetem Verhalten führen, wenn ein Entwickler darauf vertraut, dass Memory-Daten zwischen externen Aufrufen persistent sind. Umgekehrt könnten einige fälschlicherweise annehmen, dass alle an eine Funktion übergebenen Daten, selbst externe Argumente (Calldata), automatisch in Memory kopiert und veränderbar sind, obwohl Calldata schreibgeschützt ist.

Darüber hinaus gibt es oft Verwirrung bezüglich der Standard-Datenlokationen von Solidity. In Solidity werden Werttypen standardmäßig kopiert. Referenztypen (wie structs, arrays, mappings) verhalten sich jedoch anders. Wenn ein Referenztyp aus Storage einer lokalen Variablen zugewiesen wird, ohne memory oder storage explizit anzugeben, wird standardmäßig Storage verwendet, wodurch eine Referenz erstellt wird. Wenn memory explizit verwendet wird, wird eine Kopie erstellt. Dieser subtile Unterschied kann zu unbeabsichtigten Änderungen von Zustandsvariablen oder unerwarteten Gaskosten führen, wenn eine Kopie erstellt wird, obwohl eine Referenz beabsichtigt war, oder umgekehrt. Das Verständnis, wann eine Kopie erstellt wird und wann eine Referenz beibehalten wird, ist entscheidend für eine effiziente und korrekte Contract-Logik.

Zusammenfassung

Die Architektur der Ethereum Virtual Machine basiert stark auf einer klaren Unterscheidung zwischen Memory und Storage, um Daten effizient und sicher zu verwalten. EVM-Memory dient als temporärer, flüchtiger Arbeitsbereich für Berechnungen innerhalb einer einzelnen Funktionsausführung, bietet relativ geringe Kosten, aber keine Persistenz. Es ist ideal für Zwischenwerte, Funktionsargumente und Rückgabedaten. Im Gegensatz dazu bietet EVM-Storage einen permanenten, persistenten Key-Value-Speicher auf der Blockchain, der für die Aufrechterhaltung des langfristigen Zustands von Smart Contracts unerlässlich ist. Obwohl das Schreiben in Storage erheblich teurer ist, ist seine Permanenz grundlegend für die unveränderliche Natur von Blockchain-Anwendungen.

Dieser grundlegende Unterschied hat tiefgreifende Auswirkungen auf die Entwicklung von Smart Contracts, die Gas-Optimierung und die Gesamtleistung von dApps. Entwickler müssen die geeignete Datenlokation sorgfältig wählen, um Transaktionskosten zu minimieren, die Contract-Sicherheit zu verbessern und zur Skalierbarkeit des Netzwerks beizutragen. Für Trader und Nutzer bietet das Verständnis dieser Mechanismen ein tieferes Verständnis der Transaktionskosten und der zugrunde liegenden Effizienz der dezentralen Anwendungen, mit denen sie interagieren. Letztendlich ist der umsichtige Einsatz von Memory und Storage ein Kennzeichen gut gestalteter, robuster und kostengünstiger Smart Contracts im Ethereum-Netzwerk.