Wie lese ich Speichervariablen aus einem Smart Contract?

Verständnis des Speicherlayouts in Ethereum Smart Contracts

1. Jeder auf Ethereum bereitgestellte Smart Contract behält seinen Zustand in persistenten Speicherslots bei, die jeweils 32 Byte breit sind und ab Slot 0 sequentiell indiziert werden.

2. Der Compiler weist Speicherorte basierend auf der Deklarationsreihenfolge der Zustandsvariablen zu und berücksichtigt dabei die Typgröße und Packregeln für Effizienz.

3. Strukturen, Arrays und Zuordnungen führen zu Komplexität: Dynamische Arrays speichern die Länge in ihrem Slot und die Daten an einem durch keccak256 berechneten Offset; Zuordnungen verwenden keccak256(Schlüssel, Steckplatz), um Speicherpositionen abzuleiten.

4. Solidity-Versionen vor 0.8.0 ermöglichten eine engere Packung über Variablengrenzen hinweg, während neuere Versionen eine strengere Ausrichtung erzwingen, was sich auf die Genauigkeit der manuellen Slot-Berechnung auswirkt.

5. Die Vertragsvererbung beeinflusst das Layout – Variablen aus Basisverträgen belegen die unteren Plätze, gefolgt von Variablen aus abgeleiteten Verträgen in linearer Reihenfolge.

Direktes On-Chain-Lesen über eth_getStorageAt

1. Die JSON-RPC-Methode eth_getStorageAt ruft rohe 32-Byte-Werte aus einem bestimmten Speichersteckplatz unter Verwendung der Vertragsadresse, des Steckplatzindex und der Blockkennung ab.

2. Slot-Indizes müssen manuell berechnet oder aus Kompilierungsartefakten wie dem von Solidity generierten Speicherlayout-JSON extrahiert werden, das in den Metadaten- oder Build-Info-Dateien des Vertrags zu finden ist.

3. Tools wie Hardhat-Storage-Layout oder Slither-Print-Storage automatisieren die Slot-Zuordnung durch Parsen von AST und Bytecode und reduzieren so menschliche Fehler.

4. Bei Abfragen mit Infura- oder Alchemy-Endpunkten gelten Ratenbegrenzungen und Archivierungsknotenanforderungen – insbesondere für historische Slot-Werte vor Vertrags-Upgrades oder Selbstzerstörung.

5. Hex-codierte Antworten erfordern eine Dekodierung: uint256-Werte werden links aufgefüllt angezeigt, Adressen werden in den letzten 20 Bytes rechtsbündig ausgerichtet und boolesche Werte werden 0x01 oder 0x00 zugeordnet.

Komplexe Typen manuell dekodieren

1. Bei statischen Arrays belegt jedes Element einen Slot, wenn es passt; andernfalls laufen die Elemente gemäß den Standardausrichtungsregeln in aufeinanderfolgende Slots über.

2. Dynamische Array-Daten beginnen bei keccak256(slot), wobei die ersten 32 Bytes die Array-Länge enthalten und nachfolgende Slots Elemente fortlaufend speichern, beginnend bei keccak256(slot)+1.

3. Zuordnungen erfordern eine Neuberechnung von keccak256 für jeden Schlüssel: Für die Zuordnung (Adresse => uint256) öffentlicher Guthaben lautet der Steckplatz für die Adresse 0xAbc… keccak256(abi.encodePacked(0xAbc..., Slot_index)).

4. Verschachtelte Strukturen erhöhen die Komplexität – zum Beispiel erfordert eine Zuordnung zu einer Struktur zunächst die Berechnung des Zuordnungsslots und dann die Anwendung von Strukturfeldoffsets relativ zu dieser Basis.

5. Offsets innerhalb von Strukturen folgen den gleichen Regeln wie Variablen der obersten Ebene: uint128 + uint128 werden in einen Slot gepackt, aber das Hinzufügen von uint256 erzwingt aufgrund von Ausrichtungsbeschränkungen einen neuen Slot.

Verwendung von Gießerei und Guss für die praktische Inspektion

1. Der Cast- Speicherbefehl akzeptiert eine Vertragsadresse und eine Steckplatznummer und ruft automatisch Werte ab und dekodiert sie optional, wenn ABI oder Layout bereitgestellt wird.

2. Mit --watch überwacht cast Speicheränderungen über Blöcke hinweg, was nützlich ist, um Wiedereintritts- oder Flash-Loan-Nebenwirkungen in Echtzeit zu beobachten.

3. Die Forge-Inspektion von Foundry gibt das vollständige Speicherlayout aus, einschließlich Variablennamen, Typen, Steckplatznummern und Byte-Offsets – eine manuelle ABI-Analyse ist nicht erforderlich.

4. Wenn der Quellcode nicht verfügbar ist, ist ein Reverse Engineering erforderlich: Die Analyse von SSTORE-Opcodes in Transaktionsspuren zeigt, welche Slots wann geschrieben wurden.

5. Benutzerdefinierte Skripte, die web3.py oder ethers.js nutzen, können mehrere Slots stapelweise abfragen, Ausgaben als Tabellen formatieren und Querverweise mit bekannten Proxy-Mustern wie Transparent oder UUPS erstellen.

Häufig gestellte Fragen

F: Kann ich Speicher aus einem Vertrag lesen, ohne dessen Quellcode zu kennen? A: Ja – mithilfe von Bytecode-Analyse, Opcode-Tracing oder Heuristiken wie gängigen Slot-Mustern für OpenZeppelin-Proxys oder ERC-20-Balancen. Allerdings bleibt die Interpretation ohne Kontext mehrdeutig.

F: Warum gibt eth_getStorageAt Null für einen Wert ungleich Null zurück, von dem ich weiß, dass er existiert? A: Zu den möglichen Ursachen gehören die Abfrage des falschen Slots, die Verwendung einer veralteten Blocknummer, die Ausrichtung auf einen Proxy ohne Weiterleitung an die Implementierung oder das Lesen von nicht initialisiertem Speicher (der standardmäßig Null ist).

F: Kosten Speicherablesungen Gas, wenn sie außerhalb der Kette durchgeführt werden? A: Nein – eth_getStorageAt ist ein kostenloser RPC-Aufruf. Gaskosten fallen nur für On-Chain-Lesevorgänge an, die innerhalb von Transaktionen oder Ansichtsfunktionen ausgeführt werden.

F: Ist es sicher, sich auf Speichersteckplatznummern in allen Compilerversionen zu verlassen? A: Nicht garantiert – Soliditätsaktualisierungen können die Layoutalgorithmen verändern. Überprüfen Sie immer anhand der genauen Compilerversion und Optimierungseinstellungen, die während der Bereitstellung verwendet wurden.