Comment lire les variables de stockage d’un contrat intelligent ?

Comprendre la disposition du stockage dans les contrats intelligents Ethereum

1. Chaque contrat intelligent déployé sur Ethereum conserve son état dans des emplacements de stockage persistants, chacun d'une largeur de 32 octets et indexés séquentiellement à partir de l'emplacement 0.

2. Le compilateur attribue des emplacements de stockage en fonction de l'ordre de déclaration des variables d'état, en respectant la taille du type et les règles de conditionnement pour plus d'efficacité.

3. Les structures, les tableaux et les mappages introduisent de la complexité : les tableaux dynamiques stockent la longueur dans leur emplacement et les données selon un décalage calculé par keccak256 ; les mappages utilisent keccak256(key, slot) pour dériver les positions de stockage.

4. Les versions Solidity antérieures à la 0.8.0 permettaient un regroupement plus serré au-delà des limites variables, tandis que les versions plus récentes imposent un alignement plus strict, affectant la précision du calcul manuel des emplacements.

5. L'héritage des contrats influence la disposition : les variables des contrats de base occupent des emplacements inférieurs, suivies par celles des contrats dérivés dans un ordre linéaire.

Lecture directe en chaîne via eth_getStorageAt

1. La méthode JSON-RPC eth_getStorageAt récupère les valeurs brutes de 32 octets d'un emplacement de stockage spécifique à l'aide de l'adresse du contrat, de l'index de l'emplacement et de l'identifiant de bloc.

2. Les indices d'emplacement doivent être calculés manuellement ou extraits d'artefacts de compilation tels que la disposition de stockage générée par Solidity JSON trouvée dans les métadonnées du contrat ou les fichiers d'informations de construction.

3. Des outils tels que hardhat-storage-layout ou slither-print-storage automatisent le mappage des emplacements en analysant l'AST et le bytecode, réduisant ainsi les erreurs humaines.

4. Lors d'une requête avec des points de terminaison Infura ou Alchemy, des limites de débit et des exigences en matière de nœuds d'archivage s'appliquent, en particulier pour les valeurs d'emplacement historiques avant les mises à niveau du contrat ou l'autodestruction.

5. Les réponses codées en hexadécimal nécessitent un décodage : les valeurs uint256 apparaissent remplies à gauche, les adresses sont alignées à droite dans les 20 derniers octets et les booléens correspondent à 0x01 ou 0x00.

Décoder manuellement les types complexes

1. Pour les tableaux statiques, chaque élément occupe un emplacement s'il convient ; sinon, les éléments se répandent dans des emplacements consécutifs en suivant les règles d'alignement standard.

2. Les données du tableau dynamique commencent à keccak256(slot), où les 32 premiers octets contiennent la longueur du tableau et les emplacements suivants stockent les éléments de manière contiguë en commençant à keccak256(slot)+1.

3. Les mappages nécessitent de recalculer keccak256 pour chaque clé : pour le mappage (adresse => uint256) des soldes publics , l'emplacement pour l'adresse 0xAbc… est keccak256 (abi.encodePacked (0xAbc..., slot_index)).

4. Les structures imbriquées aggravent la complexité : par exemple, un mappage vers une structure nécessite d'abord de calculer l'emplacement de mappage, puis d'appliquer des décalages de champ de structure par rapport à cette base.

5. Les décalages à l'intérieur des structures suivent les mêmes règles que les variables de niveau supérieur : uint128 + uint128 sont regroupés dans un seul emplacement, mais l'ajout d'un uint256 force un nouvel emplacement en raison de contraintes d'alignement.

Utiliser la fonderie et la fonte pour une inspection pratique

1. La commande cast storage accepte une adresse de contrat et un numéro d'emplacement, récupérant automatiquement et éventuellement décodant les valeurs si l'ABI ou la mise en page est fournie.

2. Avec --watch , cast surveille les changements de stockage à travers les blocs, ce qui est utile pour observer les effets secondaires de la réentrance ou du prêt flash en temps réel.

3. La forge de Foundry inspecte la disposition complète du stockage, y compris les noms de variables, les types, les numéros d'emplacement et les décalages d'octets - aucune analyse ABI manuelle n'est nécessaire.

4. Lorsque le code source n'est pas disponible, la rétro-ingénierie devient nécessaire : l'analyse des opcodes SSTORE dans les traces de transaction révèle quels emplacements ont été écrits et quand.

5. Les scripts personnalisés exploitant web3.py ou ethers.js peuvent interroger par lots plusieurs emplacements, formater les sorties sous forme de tableaux et effectuer des références croisées avec des modèles de proxy connus tels que Transparent ou UUPS.

Foire aux questions

Q : Puis-je lire le stockage d'un contrat sans connaître son code source ? R : Oui, en utilisant l'analyse du bytecode, le traçage des opcodes ou des heuristiques telles que les modèles d'emplacement courants pour les proxys OpenZeppelin ou les balances ERC-20. Cependant, l'interprétation reste ambiguë sans contexte.

Q : Pourquoi eth_getStorageAt renvoie-t-il zéro pour une valeur non nulle dont je sais qu'elle existe ? R : Les causes possibles incluent l'interrogation du mauvais emplacement, l'utilisation d'un numéro de bloc obsolète, le ciblage d'un proxy sans transfert vers l'implémentation ou la lecture de la mémoire non initialisée (qui est par défaut à zéro).

Q : Les lectures de stockage coûtent-elles de l’argent lorsqu’elles sont effectuées hors chaîne ? R : Non : eth_getStorageAt est un appel RPC gratuit. Les coûts de gaz s'appliquent uniquement aux lectures en chaîne exécutées dans le cadre de transactions ou de fonctions d'affichage.

Q : Est-il sûr de s'appuyer sur les numéros d'emplacement de stockage dans les versions du compilateur ? R : Non garanti : les mises à jour de solidité peuvent modifier les algorithmes de mise en page. Vérifiez toujours la version exacte du compilateur et les paramètres d’optimisation utilisés lors du déploiement.