Wie speichert ein Smart Contract Daten und was ist der Unterschied zwischen Speicher, Speicher und Anrufdaten?

Wie Smart Contracts Daten auf der Blockchain speichern

1. Smart Contracts auf Blockchain-Plattformen wie Ethereum nutzen ein dezentrales Ledger, um Zustandsänderungen aufrechtzuerhalten und Daten dauerhaft zu speichern. Jedes Mal, wenn eine Vertragsfunktion eine Variable ändert, wird diese Änderung auf allen Knoten im Netzwerk aufgezeichnet. Dies sorgt für Transparenz und Unveränderlichkeit. Die in einem Smart Contract gespeicherten Daten bleiben über einzelne Transaktionen hinaus bestehen und bleiben zugänglich, solange der Vertrag besteht.

2. Die Datenspeicherung in Smart Contracts erfolgt über Variablen, die auf Vertragsebene deklariert werden. Diese Variablen werden im sogenannten „Speicher“ gespeichert, der Teil der Ethereum Virtual Machine (EVM)-Architektur ist. Jeder Vertrag verfügt über einen eigenen dedizierten Speicherplatz, der aufgrund der Gaskosten dauerhaft und kostspielig zu ändern ist. Wenn eine Transaktion eine Statusvariable aktualisiert, validieren Miner die Änderung und schreiben sie in den Statusversuch der Blockchain.

3. Die EVM behandelt den Speicher als großen Schlüsselwertspeicher, bei dem jeder Steckplatz 32 Byte fasst. Variablen werden effizient gepackt, um den Platzbedarf zu minimieren. Beispielsweise können mehrere boolesche Werte in einem einzigen Slot gespeichert werden. Entwickler müssen bei der Deklaration von Variablen vorsichtig sein, da ineffizientes Packen den Gasverbrauch erhöht.

4. Für das Lesen aus dem Speicher und das Schreiben in den Speicher fallen unterschiedliche Gaskosten an. Schreibvorgänge kosten deutlich mehr als Lesevorgänge, und das Initialisieren eines Werts ungleich Null ist teurer als das Setzen auf Null. Sobald Daten geschrieben wurden, können sie nicht vollständig gelöscht werden. Stattdessen wird durch das Festlegen eines Werts auf Null etwas Gas zurückerstattet, was Entwicklern einen Anreiz gibt, ungenutzte Daten zu bereinigen.

Unterschiede zwischen Speicher, Speicher und Anrufdaten

1. Speicher bezieht sich auf den permanenten Datenbereich, der einem Vertrag zugeordnet ist und in dem Zustandsvariablen gespeichert werden. Es ist über Funktionsaufrufe und Transaktionen hinweg persistent. Alle außerhalb von Funktionen deklarierten Variablen – wie z. B. „uint balance“ oder „mapping(address => bool)“-Whitelist – befinden sich standardmäßig im Speicher. Der Zugriff auf den Speicher ist aufgrund seiner Permanenz und globalen Replikation langsam und kostspielig.

2. Speicher ist ein temporärer Speicherplatz, der zum Speichern von Daten während der Funktionsausführung verwendet wird. Es wird nach Beendigung des Funktionsaufrufs gelöscht und ist ideal für lokale Variablen und komplexe Typen wie Arrays oder Strukturen, die innerhalb einer Funktion verwendet werden. Im Gegensatz zu Speicher ist der Zugriff auf Speicher günstiger, die Daten werden jedoch zwischen Aufrufen nicht gespeichert. Zeichenfolgen, dynamische Arrays und Funktionsargumente befinden sich häufig hier, sofern nicht ausdrücklich etwas anderes zugewiesen wird.

3. Calldata ist ein spezieller schreibgeschützter Bereich, in dem Funktionsargumente gespeichert werden, insbesondere für externe Funktionsaufrufe. Es vermeidet das Kopieren von Daten in den Speicher und macht es für große Eingaben wie Byte-Arrays, die an öffentliche oder externe Funktionen übergeben werden, effizient. Da Aufrufdaten nicht geändert werden können, ist sie nur für Eingabeparameter geeignet, die während der Ausführung nicht geändert werden müssen.

4. Das Schlüsselwort „location“ in Solidity – wie „storage“, „memory“ oder „calldata“ – muss angegeben werden, wenn es um Referenztypen wie Arrays, Strings und Strukturen geht. Missbrauch kann zu unnötigem Kopieren, erhöhten Benzingebühren oder Laufzeitfehlern führen. Wenn Sie beispielsweise ein großes Array an eine Funktion übergeben, ohne Calldata zu verwenden, wird es unnötigerweise in den Speicher geladen, was den Rechenaufwand erhöht.

Auswirkungen auf den Datenstandort im Funktionsdesign

1. Beim Entwerfen von Funktionen wirkt sich die Wahl des richtigen Datenspeicherorts sowohl auf die Leistung als auch auf die Kosten aus. Externe Funktionen, die große Nutzlasten akzeptieren, sollten Parameter als Aufrufdaten deklarieren, um eine Speicherzuweisung zu vermeiden. Diese Optimierung reduziert den Gasverbrauch und verbessert die Skalierbarkeit, insbesondere für Verträge, die Massenvorgänge wie Token-Transfers oder Batch-Registrierungen abwickeln.

2. Interne und private Funktionen können keine Aufrufdaten verwenden, da sie nicht extern aufgerufen werden. Stattdessen verlassen sie sich auf Arbeitsspeicher oder Speicher, je nachdem, ob die Daten bestehen bleiben müssen. Lokale Berechnungen mit temporären Strukturen profitieren von der Speichergeschwindigkeit und vermeiden gleichzeitig die hohen Kosten für Speicherschreibvorgänge.

3. Eine falsche Zuweisung von Referenztypen kann zu unbeabsichtigtem Verhalten führen. Wenn Sie eine lokale Variable als Speicher deklarieren und sie einer Statusvariablen zuweisen, wird ein Alias ​​​​anstelle einer Kopie erstellt. Das Ändern der lokalen Variablen führt direkt zu einer Änderung des ursprünglichen Zustands, was in manchen Fällen wünschenswert sein kann, aber gefährlich ist, wenn es unbeabsichtigt erfolgt.

4. Komplexe Vorgänge wie Sortieren oder Filtern sollten auf Speicherkopien angewendet werden, sofern keine direkte Zustandsmanipulation erforderlich ist. Das Erstellen eines Speicher-Snapshots eines Speicher-Arrays ermöglicht eine sichere Transformation, ohne dass das Risiko inkonsistenter Zustandsänderungen während der Ausführung besteht. Nach der Verarbeitung können die Ergebnisse bei Bedarf zurück in den Speicher geschrieben werden.

Häufig gestellte Fragen

Was passiert, wenn ich versuche, Daten in den Anrufdaten zu ändern? Der Versuch, Daten in calldata zu ändern, führt zu einem Kompilierungsfehler. Calldata ist ausschließlich schreibgeschützt und dient dazu, Eingabeparameter für externe Funktionsaufrufe zu speichern, ohne dass während der Ausführung Mutationen zugelassen werden.

Können andere Funktionen in derselben Transaktion auf Speicherdaten zugreifen? Nein, der Speicher ist auf die ausführende Funktion beschränkt. Selbst innerhalb derselben Transaktion erhält jeder Funktionsaufruf seinen eigenen neuen Speicherplatz. Allerdings sind Zustandsänderungen, die während eines Funktionsaufrufs am Speicher vorgenommen werden, für nachfolgende Aufrufe in derselben Transaktion sichtbar.

Warum kann ich einen Wert nicht direkt aus dem Speicher zurückgeben, ohne ihn in den Speicher zu kopieren? Wenn komplexe Typen wie Arrays oder Strings zurückgegeben werden, verlangt die EVM, dass diese im Speicher abgelegt werden, bevor sie in die Antwort aufgenommen werden. Der Speicher kann für Rückgabewerte nicht direkt serialisiert werden. Daher ist eine temporäre Kopie im Speicher erforderlich, auch wenn die Quelle eine Zustandsvariable ist.

Gibt es eine Grenze für die Datenmenge, die ich in calldata speichern kann? Während in der EVM-Spezifikation keine feste Größenbeschränkung definiert ist, ergeben sich praktische Einschränkungen aus Blockgasgrenzen. Übermäßig große Anrufdaten können dazu führen, dass Transaktionen zu teuer werden, um sie in einen Block aufzunehmen, wodurch die nutzbare Größe basierend auf den aktuellen Netzwerkbedingungen und Gaspreisen effektiv eingeschränkt wird.