Comment rédiger un code de solidité économe en gaz et optimisé ?

Comprendre les modèles de consommation de gaz

1. Chaque opération dans la machine virtuelle Ethereum consomme une quantité déterministe de gaz, de la simple arithmétique aux écritures de stockage.

2. L'allocation de mémoire et le redimensionnement dynamique des baies entraînent des coûts de gaz disproportionnés par rapport aux structures de taille fixe.

3. Les appels de fonctions externes entraînent une surcharge en raison de la transmission des messages, de la copie de la pile et du changement de contexte EVM.

4. Les opérations SLOAD et SSTORE restent parmi les instructions les plus coûteuses, notamment lors de modifications répétées des emplacements de stockage.

5. Les itérations de boucle amplifient de manière exponentielle la consommation de gaz si elles contiennent des lectures ou des écritures de stockage sans vérification appropriée des limites.

Optimisation de la disposition du stockage

1. Le regroupement de plusieurs petites variables dans un seul emplacement de stockage de 256 bits réduit les appels SSSTORE et permet d'économiser du temps sur le déploiement et l'exécution.

2. La déclaration des variables d'état par ordre décroissant de taille (uint256 avant uint128 avant uint64) permet un regroupement plus serré et évite les espaces de remplissage implicites.

3. L'utilisation d'immuable pour les constantes initialisées une fois dans le constructeur élimine entièrement les écritures de stockage après le déploiement.

4. Le remplacement de l'adresse payable par une adresse simple là où aucun transfert n'a lieu supprime la surcharge inutile de conversion de type.

5. Éviter les structures avec des champs de tailles mixtes sans tenir compte de l'alignement entraîne un gaspillage d'espace et une augmentation du gaz par accès.

Minimiser le calcul du temps d'exécution

1. Le calcul des limites de boucle hors chaîne ou leur mise en cache en mémoire empêche les recherches de stockage répétées au sein des itérations.

2. L'utilisation de { ... } non coché pour l'arithmétique où le débordement est mathématiquement impossible ignore les contrôles de sécurité et réduit le gaz jusqu'à 40 % par opération.

3. Préférer require() à assert() garantit une défaillance plus précoce avec un coût de gaz inférieur sur les entrées invalides.

4. Déplacer une logique complexe dans des bibliothèques et utiliser déléguécall évite la duplication du bytecode entre les contrats.

5. L'intégration manuelle de petites fonctions d'assistance peut réduire la surcharge des appels, bien que les optimisations du compilateur puissent gérer cela automatiquement à des niveaux d'optimisation plus élevés.

Exploitation du compilateur et de la chaîne d'outils

1. L'activation de l'optimiseur Solidity avec --optimize --optimize-runs=200 réduit considérablement la taille du bytecode déployé et le temps d'exécution grâce à un repliement constant et à une réorganisation des sauts.

2. L'utilisation de versions récentes du compilateur comme la 0.8.24 déverrouille les vérifications intégrées et les stratégies d'inclusion plus agressives non disponibles dans les anciennes versions.

3. L'analyse des opcodes générés avec des outils comme solc --asm révèle des inefficacités cachées telles que des DUP redondants ou des SWAP inutiles.

4. L'intégration de Forge Inspect de Foundry permet d'identifier les collisions d'emplacements de stockage et les allocations de mémoire inattendues pendant les tests.

5. L'exécution d'instantanés de gaz via forge test --gas-report expose les points chauds avant le déploiement du réseau principal.

Foire aux questions

Q : L'utilisation des fonctions d'affichage élimine-t-elle tous les coûts de gaz pour les appelants ? R : Non. Bien que les fonctions d'affichage ne consomment pas de gaz lorsqu'elles sont appelées en externe via RPC, elles coûtent toujours du gaz lorsqu'elles sont invoquées en interne à partir de fonctions sans affichage au sein de la même transaction.

Q : Puis-je remplacer en toute sécurité require(msg.sender == Owner) par msg.sender == Owner dans la logique interne ? R : Pas en toute sécurité. La suppression de require élimine le retour explicite, conduisant à des échecs silencieux ou à un comportement involontaire au lieu d'une gestion contrôlée des erreurs.

Q : Est-il préférable d'émettre des événements ou de stocker des données dans des mappages pour une indexation hors chaîne ? R : Les événements sont moins chers que les écritures de stockage et suffisants à des fins d'indexation. Le stockage de données identiques à la fois dans les événements et dans les variables d'état gaspille du gaz sans avantage supplémentaire, sauf si un accès en chaîne est requis.

Q : Pourquoi la suppression d'un élément du tableau avec delete arr[i] ne réduit-elle pas le coût global du gaz contractuel ? R : Le mot-clé delete réinitialise uniquement la valeur, mais ne réduit pas la longueur du tableau ni ne récupère les emplacements de stockage. Les baies dynamiques conservent leur capacité, et un déplacement manuel ou l'utilisation de modèles push/pop sont nécessaires pour un véritable nettoyage.