Wie schreibe ich gaseffizienten und optimierten Soliditätscode?

Gasverbrauchsmuster verstehen

1. Jeder Vorgang in der Ethereum Virtual Machine verbraucht eine bestimmte Menge an Gas, von der einfachen Arithmetik bis hin zu Speicherschreibvorgängen.

2. Die Speicherzuweisung und die dynamische Größenänderung des Arrays führen im Vergleich zu Strukturen mit fester Größe zu unverhältnismäßig hohen Gaskosten.

3. Externe Funktionsaufrufe verursachen Overhead aufgrund der Nachrichtenübermittlung, des Stapelkopierens und des EVM-Kontextwechsels.

4. SLOAD- und SSTORE-Vorgänge gehören nach wie vor zu den teuersten Anweisungen, insbesondere wenn Speicherslots wiederholt geändert werden.

5. Schleifeniterationen erhöhen den Gasverbrauch exponentiell, wenn sie Speicherlese- oder -schreibvorgänge ohne ordnungsgemäße Überprüfung der Grenzen enthalten.

Optimierung des Lagerlayouts

1. Das Packen mehrerer kleiner Variablen in einen einzigen 256-Bit-Speichersteckplatz reduziert SSTORE-Aufrufe und spart Gas bei der Bereitstellung und Laufzeit.

2. Das Deklarieren von Zustandsvariablen in absteigender Reihenfolge der Größe – uint256 vor uint128 vor uint64 – ermöglicht eine engere Packung und vermeidet implizite Fülllücken.

3. Durch die Verwendung von unveränderlichen Konstanten, die einmal im Konstruktor initialisiert werden, entfallen Speicherschreibvorgänge nach der Bereitstellung vollständig.

4. Durch das Ersetzen der zahlbaren Adresse durch eine einfache Adresse , an der keine Übertragungen stattfinden, wird unnötiger Aufwand für die Typkonvertierung vermieden.

5. Das Vermeiden von Strukturen mit Feldern unterschiedlicher Größe ohne Berücksichtigung der Ausrichtung führt zu Platzverschwendung und erhöhtem Gas pro Zugang.

Minimierung der Laufzeitberechnung

1. Die Berechnung von Schleifengrenzen außerhalb der Kette oder deren Zwischenspeicherung im Speicher verhindert wiederholte Speichersuchen innerhalb von Iterationen.

2. Durch die Verwendung von ungeprüftem { ... } für die Arithmetik, bei der ein Überlauf mathematisch unmöglich ist, werden Sicherheitsüberprüfungen übersprungen und die Gasmenge pro Vorgang um bis zu 40 % reduziert.

3. Durch die Bevorzugung von require() gegenüber Assert() wird ein früherer Ausfall mit geringeren Gaskosten bei ungültigen Eingaben gewährleistet.

4. Durch die Verlagerung komplexer Logik in Bibliotheken und die Verwendung von Delegatecall wird die Duplizierung von Bytecode über Verträge hinweg vermieden.

5. Das manuelle Einbinden kleiner Hilfsfunktionen kann den Aufrufaufwand reduzieren, obwohl Compiler-Optimierungen dies bei höheren Optimierungsstufen möglicherweise automatisch handhaben.

Compiler- und Toolchain-Nutzung

1. Durch die Aktivierung des Solidity-Optimierers mit --optimize --optimize-runs=200 werden die Größe des bereitgestellten Bytecodes und die Laufzeitbelastung durch ständige Faltung und Neuordnung von Sprüngen erheblich reduziert.

2. Durch die Verwendung aktueller Compilerversionen wie 0.8.24 werden integrierte Prüfungen und aggressivere Inlining-Strategien freigeschaltet, die in älteren Versionen nicht verfügbar sind.

3. Die Analyse generierter Opcodes mit Tools wie solc --asm deckt versteckte Ineffizienzen wie redundante DUPs oder unnötige SWAPs auf.

4. Die Integration von Foundrys Forge Inspect hilft dabei, Speichersteckplatzkollisionen und unerwartete Speicherzuweisungen während des Tests zu erkennen.

5. Das Ausführen von Gas-Snapshots über den Forge-Test --gas-report macht Hotspots vor der Mainnet-Bereitstellung sichtbar.

Häufig gestellte Fragen

F: Entfallen für Anrufer durch die Verwendung der Ansichtsfunktionen sämtliche Gaskosten? A: Nein. Während Ansichtsfunktionen keinen Gas verbrauchen, wenn sie extern über RPC aufgerufen werden, kosten sie dennoch Gas, wenn sie intern von Nicht-View-Funktionen innerhalb derselben Transaktion aufgerufen werden.

F: Kann ich require(msg.sender == Owner) in der internen Logik sicher durch msg.sender == Owner ersetzen? A: Nicht sicher. Durch das Entfernen von require wird das explizite Zurücksetzen eliminiert, was zu stillen Fehlern oder unbeabsichtigtem Verhalten anstelle einer kontrollierten Fehlerbehandlung führt.

F: Ist es besser, Ereignisse auszugeben oder Daten in Zuordnungen für die Off-Chain-Indizierung zu speichern? A: Ereignisse sind günstiger als Speicherschreibvorgänge und für Indizierungszwecke ausreichend. Das Speichern identischer Daten sowohl in Ereignissen als auch in Zustandsvariablen verschwendet Gas ohne zusätzlichen Nutzen, es sei denn, es ist ein On-Chain-Zugriff erforderlich.

F: Warum reduziert das Löschen eines Array-Elements mit delete arr[i] nicht die Gesamtgaskosten des Vertrags? A: Das Schlüsselwort delete setzt nur den Wert zurück, verringert jedoch nicht die Array-Länge und gibt keine Speicherplätze frei. Dynamische Arrays behalten ihre Kapazität bei und für eine echte Bereinigung ist eine manuelle Verschiebung oder die Verwendung von Push/Pop-Mustern erforderlich.