En suivant ces pratiques, les développeurs peuvent réduire la consommation de gaz dans les smart contracts, réduire les coûts de transaction et créer des applications plus efficaces et conviviales.
Les frais de gaz sur le réseau principal d'Ethereum ont toujours été un problème majeur, surtout pendant les périodes de congestion du réseau. Pendant les heures de pointe, les utilisateurs doivent souvent payer des frais de transaction extrêmement élevés. Par conséquent, optimiser les coûts de gaz lors de la phase de développement des contrats intelligents est crucial. L'optimisation du gaz permet non seulement de réduire efficacement les coûts de transaction, mais aussi d'améliorer l'efficacité des transactions, offrant aux utilisateurs une expérience blockchain plus économique et efficace.
Cet article exposera le mécanisme des frais de gaz de l'Ethereum Virtual Machine (EVM), les concepts fondamentaux liés à l'optimisation des frais de gaz, et les meilleures pratiques pour optimiser les frais de gaz lors du développement de contrats intelligents. On espère que ce contenu inspirera et aidera les développeurs, tout en aidant également les utilisateurs ordinaires à mieux comprendre le fonctionnement du système de frais de gaz de l'EVM, en abordant ensemble les défis au sein de l'écosystème blockchain.
Dans les réseaux compatibles avec l'EVM, le terme "Gas" fait référence à l'unité utilisée pour mesurer la puissance de calcul nécessaire à l'exécution d'opérations spécifiques.
Le diagramme ci-dessous illustre la structure de l'EVM. Dans le diagramme, la consommation de gaz est divisée en trois parties: l'exécution des opérations, les appels de messages externes et la lecture/écriture de la mémoire et du stockage.
Source : Site officiel d'Ethereum[1]
Depuis l'activation de l'EIP-1559 (London Hard Fork), les frais de gaz sont calculés à l'aide de la formule suivante :
Frais de gaz = unités de gaz utilisées * (frais de base + frais de priorité)
La commission de base est brûlée, tandis que la commission de priorité sert d'incitation pour encourager les validateurs à inclure la transaction dans la blockchain. Fixer une commission de priorité plus élevée lors de l'envoi d'une transaction augmente la probabilité que la transaction soit incluse dans le bloc suivant. Cela ressemble à un "pourboire" payé par les utilisateurs aux validateurs.
Lors de la compilation d'un contrat intelligent avec Solidity, le contrat est converti en une série de "codes opérationnels", ou opcodes.
Chaque opcode (comme la création d'un contrat, les appels de message, l'accès au stockage du compte et l'exécution d'opérations sur la machine virtuelle) a un coût de consommation de Gas associé, qui est documenté dans le Livre Jaune d'Ethereum[2].
Après plusieurs modifications EIP, les coûts de gaz de certains opcodes ont été ajustés, ce qui peut différer des valeurs indiquées dans le Livre Jaune. Pour des informations détaillées sur les coûts les plus récents des opcodes, veuillez vous référer à cette source [3].
Le concept central de l'optimisation du gas est de prioriser les opérations rentables sur la blockchain EVM et d'éviter les opérations qui entraînent des coûts élevés en gas.
Dans l'EVM, les opérations suivantes sont relativement peu coûteuses :
Les opérations coûteuses comprennent :
Sur la base des concepts de base ci-dessus, nous avons compilé une liste des meilleures pratiques d'optimisation des frais de gaz pour la communauté des développeurs. En suivant ces pratiques, les développeurs peuvent réduire la consommation de gaz des contrats intelligents, abaisser les coûts de transaction et créer des applications plus efficaces et conviviales.
En Solidity, le stockage est une ressource limitée, et sa consommation de gaz est significativement plus élevée que celle de la mémoire. Chaque fois qu'un contrat intelligent lit ou écrit dans le stockage, cela entraîne un coût de gaz élevé.
Selon la définition du Livre jaune d'Ethereum, le coût des opérations de stockage est plus de 100 fois plus élevé que celui des opérations de mémoire. Par exemple, des opcodes comme sload et sstore coûtent au moins 100 unités de gaz dans le meilleur des cas, tandis que les opérations de mémoire comme mload et mstore ne consomment que 3 unités de gaz.
Les méthodes pour limiter l'utilisation du stockage comprennent :
Le nombre d'emplacements de stockage utilisés dans un contrat intelligent et la manière dont les développeurs représentent les données peuvent avoir un impact significatif sur la consommation de gaz.
Le compilateur Solidity emballe les variables de stockage consécutives lors du processus de compilation, en utilisant des emplacements de stockage de 32 octets comme unité de base pour le stockage des variables. Le regroupement de variables fait référence à la pratique d'arranger les variables de manière à permettre à plusieurs variables de s'insérer dans un seul emplacement de stockage.
À gauche se trouve une implémentation moins efficace qui consomme 3 emplacements de stockage ; à droite se trouve une implémentation plus efficace.
En effectuant cette modification, les développeurs peuvent économiser 20 000 unités de gaz (car le stockage d'un emplacement de stockage inutilisé coûte 20 000 gaz), mais maintenant seulement deux emplacements de stockage sont nécessaires.
Étant donné que chaque emplacement de stockage consomme du gaz, l'optimisation de l'empaquetage de variables optimise l'utilisation du gaz en réduisant le nombre d'emplacements de stockage requis.
Une variable peut être représentée en utilisant différents types de données, mais les coûts d'opération varient en fonction du type. Le choix du type de données approprié aide à optimiser l'utilisation du gas.
Par exemple, en Solidity, les entiers peuvent être subdivisés en différentes tailles : uint8, uint16, uint32, etc. Étant donné que l'EVM fonctionne par unités de 256 bits, l'utilisation de uint8 signifie que l'EVM doit d'abord le convertir en uint256, et cette conversion entraîne des coûts supplémentaires en gaz.
Nous pouvons comparer les coûts en gaz de uint8 et uint256 en utilisant le code dans le diagramme. La fonction UseUint() consomme 120 382 unités de gaz, tandis que la fonction UseUInt8() consomme 166 111 unités de gaz.
À lui seul, uint256 est moins cher que uint8. Cependant, si nous appliquons l'optimisation de regroupement de variables précédemment suggérée, cela fait une différence. Si les développeurs peuvent regrouper quatre variables uint8 dans un seul emplacement de stockage, le coût total de l'itération sur eux sera inférieur à l'utilisation de quatre variables uint256. Dans ce cas, le contrat intelligent peut lire et écrire l'emplacement de stockage une fois et charger les quatre variables uint8 en mémoire/stockage en une seule opération.
Si les données peuvent être contraintes à 32 octets, il est recommandé d'utiliser le type de données bytes32 plutôt que bytes ou strings. En général, les variables de taille fixe consomment moins de Gas que les variables de taille dynamique. Si la longueur en octets peut être limitée, essayez de choisir la plus petite longueur de bytes1 à bytes32.
En Solidity, les listes de données peuvent être représentées à l'aide de deux types de données: des tableaux et des mappages, chacun avec une syntaxe et une structure distinctes.
Dans la plupart des cas, les mappings sont généralement plus efficaces et rentables, tandis que les tableaux sont itérables et prennent en charge le regroupement des types de données. Par conséquent, il est recommandé de donner la priorité à l'utilisation de mappings lors de la gestion des listes de données, sauf si l'itération est nécessaire ou que la consommation de gaz peut être optimisée grâce au regroupement des types de données.
Les variables déclarées dans les paramètres de fonction peuvent être stockées soit dans calldata, soit dans la mémoire. La principale différence est que la mémoire peut être modifiée par la fonction, tandis que calldata est immuable.
Gardez à l'esprit ce principe : si les paramètres de fonction sont en lecture seule, préférez utiliser calldata plutôt que memory. Cela évite les opérations de copie inutiles de calldata de fonction vers la mémoire.
Exemple 1: Utilisation de la mémoire
Lors de l'utilisation du mot-clé mémoire, les valeurs du tableau sont copiées du calldata encodé dans la mémoire lors du décodage ABI. Le coût d'exécution de ce bloc de code est de 3 694 unités de gaz.
Exemple 2: Utilisation de calldata
Lors de la lecture des valeurs directement depuis les données d'appel, l'opération intermédiaire de mémoire est ignorée. Cette optimisation réduit le coût d'exécution à seulement 2 413 unités de gaz, ce qui se traduit par une amélioration de l'efficacité énergétique de 35%.
Les variables constantes/immuables ne sont pas stockées dans la mémoire de stockage du contrat. Ces variables sont calculées au moment de la compilation et stockées dans le bytecode du contrat. Par conséquent, leur coût d'accès est beaucoup plus faible que celui des variables de stockage. Il est recommandé d'utiliser les mots-clés Constant ou Immutable chaque fois que possible.
Lorsque les développeurs peuvent être certains que les opérations arithmétiques ne provoqueront pas de débordement ou de sous-débordement, ils peuvent utiliser le mot-clé non vérifié introduit dans Solidity v0.8.0 pour éviter les vérifications inutiles de débordement ou de sous-débordement, ce qui permet d'économiser les frais de gaz.
Dans le schéma ci-dessous, la conditionnellement contrainte i
De plus, les versions du compilateur 0.8.0 et supérieures ne nécessitent plus l'utilisation de la bibliothèque SafeMath, car le compilateur lui-même inclut désormais une protection intégrée contre le débordement et le dépassement.
Le code des modificateurs est intégré aux fonctions qu'ils modifient. Chaque fois qu'un modificateur est utilisé, son code est dupliqué, ce qui augmente la taille du bytecode et augmente la consommation de Gas. Voici une façon d'optimiser le coût en Gas des modificateurs :
Avant l'optimisation:
Après optimisation:
Dans cet exemple, en refactorisant la logique dans une fonction interne _checkOwner(), qui peut être réutilisée dans le modificateur, la taille du bytecode est réduite et les coûts en gaz sont diminués.
Pour || (OR) et && (AND) opérateurs, les opérations logiques sont évaluées avec un court-circuit, ce qui signifie que si la première condition est suffisante pour déterminer le résultat de l'expression logique, la deuxième condition ne sera pas évaluée.
Pour optimiser la consommation de gaz, les conditions avec des coûts de calcul plus faibles doivent être placées en premier, de sorte que des calculs potentiellement coûteux puissent être évités.
S'il y a des fonctions ou des variables inutilisées dans le contrat, il est recommandé de les supprimer. C'est le moyen le plus direct de réduire les coûts de déploiement du contrat et de maintenir la taille du contrat petite.
Voici quelques suggestions pratiques:
Utilisez les algorithmes les plus efficaces pour les calculs. Si le contrat utilise directement certains résultats de calcul, les calculs redondants doivent être supprimés. Essentiellement, tous les calculs inutilisés doivent être supprimés. Dans Ethereum, les développeurs peuvent recevoir des récompenses en Gas en libérant de l'espace de stockage. Si une variable n'est plus nécessaire, elle doit être supprimée à l'aide du mot-clé delete ou réinitialisée à sa valeur par défaut.
Optimisation de la boucle : Évitez les opérations coûteuses dans la boucle, essayez de fusionner les boucles et déplacez les calculs répétés hors du corps de la boucle.
Les contrats précompilés fournissent des fonctions de bibliothèque complexes telles que les opérations de cryptographie et de hachage. Comme le code n'est pas exécuté sur l'EVM mais s'exécute localement sur le nœud client, moins de gas est requis. L'utilisation de contrats précompilés peut économiser du gas en réduisant la charge de calcul nécessaire pour exécuter le contrat intelligent.
Les exemples de contrats précompilés comprennent l'algorithme de signature numérique à courbes elliptiques (ECDSA) et l'algorithme de hachage SHA2-256. En utilisant ces contrats précompilés dans les contrats intelligents, les développeurs peuvent réduire les coûts de gaz et améliorer l'efficacité de l'application.
Pour obtenir une liste complète des contrats précompilés pris en charge par le réseau Ethereum, veuillez consulter ce lien [4].
L'assemblage en ligne permet aux développeurs d'écrire un code de bas niveau mais efficace qui peut être directement exécuté par l'EVM, sans utiliser des opcodes Solidity coûteux. L'assemblage en ligne permet également d'avoir un contrôle plus précis sur l'utilisation de la mémoire et du stockage, réduisant ainsi davantage les coûts de gaz. De plus, l'assemblage en ligne peut effectuer certaines opérations complexes qu'il est difficile de mettre en œuvre avec Solidity seul, offrant ainsi plus de flexibilité pour optimiser la consommation de gaz.
Voici un exemple d'utilisation de l'assemblage en ligne pour économiser du gas :
Comme on peut le voir dans l'exemple ci-dessus, le deuxième cas, qui utilise l'assemblage en ligne, a une efficacité de gaz plus élevée par rapport au cas standard.
Cependant, l'utilisation de l'assemblage en ligne peut également introduire des risques et est susceptible d'erreurs. Par conséquent, il convient de l'utiliser avec prudence et est recommandé uniquement pour les développeurs expérimentés.
Les solutions de couche 2 peuvent réduire la quantité de données qui doivent être stockées et calculées sur le réseau principal Ethereum.
Les solutions de couche 2 telles que les rollups, les sidechains et les canaux d'état déchargent le traitement des transactions de la chaîne principale Ethereum, ce qui permet des transactions plus rapides et moins coûteuses.
En regroupant un grand nombre de transactions ensemble, ces solutions réduisent le nombre de transactions on-chain, ce qui à son tour réduit les frais de gaz. L'utilisation de solutions de couche 2 améliore également la scalabilité d'Ethereum, permettant à davantage d'utilisateurs et d'applications de participer au réseau sans causer de congestion due à la surcharge.
Il existe plusieurs outils d'optimisation disponibles, tels que l'optimiseur solc, l'optimiseur de construction de Truffle et le compilateur Solidity de Remix.
Ces outils peuvent aider à minimiser la taille de l'octet de code, supprimer le code inutilisé et réduire le nombre d'opérations nécessaires pour exécuter des contrats intelligents. Associés à d'autres bibliothèques d'optimisation du gaz comme "solmate", les développeurs peuvent efficacement réduire les coûts en gaz et améliorer l'efficacité des contrats intelligents.
Optimiser la consommation de gaz est une étape importante pour les développeurs, car cela permet non seulement de minimiser les coûts de transaction, mais aussi d'améliorer l'efficacité des contrats intelligents sur les réseaux compatibles avec EVM. En privilégiant les opérations d'économie de coûts, en réduisant l'utilisation du stockage, en utilisant l'assemblage en ligne et en suivant les meilleures pratiques discutées dans cet article, les développeurs peuvent efficacement réduire la consommation de gaz des contrats.
Cependant, il est important de noter que lors du processus d'optimisation, les développeurs doivent faire preuve de prudence pour éviter d'introduire des vulnérabilités de sécurité. Dans le processus d'optimisation du code et de réduction de la consommation de gaz, la sécurité inhérente du contrat intelligent ne doit jamais être compromise.
[1]https://ethereum.org/fr/developers/docs/gas/
[2] https://ethereum.github.io/yellowpaper/paper.pdf
[3] https://www.evm.codes/
[4]https://www.evm.codes/precompiled
En suivant ces pratiques, les développeurs peuvent réduire la consommation de gaz dans les smart contracts, réduire les coûts de transaction et créer des applications plus efficaces et conviviales.
Les frais de gaz sur le réseau principal d'Ethereum ont toujours été un problème majeur, surtout pendant les périodes de congestion du réseau. Pendant les heures de pointe, les utilisateurs doivent souvent payer des frais de transaction extrêmement élevés. Par conséquent, optimiser les coûts de gaz lors de la phase de développement des contrats intelligents est crucial. L'optimisation du gaz permet non seulement de réduire efficacement les coûts de transaction, mais aussi d'améliorer l'efficacité des transactions, offrant aux utilisateurs une expérience blockchain plus économique et efficace.
Cet article exposera le mécanisme des frais de gaz de l'Ethereum Virtual Machine (EVM), les concepts fondamentaux liés à l'optimisation des frais de gaz, et les meilleures pratiques pour optimiser les frais de gaz lors du développement de contrats intelligents. On espère que ce contenu inspirera et aidera les développeurs, tout en aidant également les utilisateurs ordinaires à mieux comprendre le fonctionnement du système de frais de gaz de l'EVM, en abordant ensemble les défis au sein de l'écosystème blockchain.
Dans les réseaux compatibles avec l'EVM, le terme "Gas" fait référence à l'unité utilisée pour mesurer la puissance de calcul nécessaire à l'exécution d'opérations spécifiques.
Le diagramme ci-dessous illustre la structure de l'EVM. Dans le diagramme, la consommation de gaz est divisée en trois parties: l'exécution des opérations, les appels de messages externes et la lecture/écriture de la mémoire et du stockage.
Source : Site officiel d'Ethereum[1]
Depuis l'activation de l'EIP-1559 (London Hard Fork), les frais de gaz sont calculés à l'aide de la formule suivante :
Frais de gaz = unités de gaz utilisées * (frais de base + frais de priorité)
La commission de base est brûlée, tandis que la commission de priorité sert d'incitation pour encourager les validateurs à inclure la transaction dans la blockchain. Fixer une commission de priorité plus élevée lors de l'envoi d'une transaction augmente la probabilité que la transaction soit incluse dans le bloc suivant. Cela ressemble à un "pourboire" payé par les utilisateurs aux validateurs.
Lors de la compilation d'un contrat intelligent avec Solidity, le contrat est converti en une série de "codes opérationnels", ou opcodes.
Chaque opcode (comme la création d'un contrat, les appels de message, l'accès au stockage du compte et l'exécution d'opérations sur la machine virtuelle) a un coût de consommation de Gas associé, qui est documenté dans le Livre Jaune d'Ethereum[2].
Après plusieurs modifications EIP, les coûts de gaz de certains opcodes ont été ajustés, ce qui peut différer des valeurs indiquées dans le Livre Jaune. Pour des informations détaillées sur les coûts les plus récents des opcodes, veuillez vous référer à cette source [3].
Le concept central de l'optimisation du gas est de prioriser les opérations rentables sur la blockchain EVM et d'éviter les opérations qui entraînent des coûts élevés en gas.
Dans l'EVM, les opérations suivantes sont relativement peu coûteuses :
Les opérations coûteuses comprennent :
Sur la base des concepts de base ci-dessus, nous avons compilé une liste des meilleures pratiques d'optimisation des frais de gaz pour la communauté des développeurs. En suivant ces pratiques, les développeurs peuvent réduire la consommation de gaz des contrats intelligents, abaisser les coûts de transaction et créer des applications plus efficaces et conviviales.
En Solidity, le stockage est une ressource limitée, et sa consommation de gaz est significativement plus élevée que celle de la mémoire. Chaque fois qu'un contrat intelligent lit ou écrit dans le stockage, cela entraîne un coût de gaz élevé.
Selon la définition du Livre jaune d'Ethereum, le coût des opérations de stockage est plus de 100 fois plus élevé que celui des opérations de mémoire. Par exemple, des opcodes comme sload et sstore coûtent au moins 100 unités de gaz dans le meilleur des cas, tandis que les opérations de mémoire comme mload et mstore ne consomment que 3 unités de gaz.
Les méthodes pour limiter l'utilisation du stockage comprennent :
Le nombre d'emplacements de stockage utilisés dans un contrat intelligent et la manière dont les développeurs représentent les données peuvent avoir un impact significatif sur la consommation de gaz.
Le compilateur Solidity emballe les variables de stockage consécutives lors du processus de compilation, en utilisant des emplacements de stockage de 32 octets comme unité de base pour le stockage des variables. Le regroupement de variables fait référence à la pratique d'arranger les variables de manière à permettre à plusieurs variables de s'insérer dans un seul emplacement de stockage.
À gauche se trouve une implémentation moins efficace qui consomme 3 emplacements de stockage ; à droite se trouve une implémentation plus efficace.
En effectuant cette modification, les développeurs peuvent économiser 20 000 unités de gaz (car le stockage d'un emplacement de stockage inutilisé coûte 20 000 gaz), mais maintenant seulement deux emplacements de stockage sont nécessaires.
Étant donné que chaque emplacement de stockage consomme du gaz, l'optimisation de l'empaquetage de variables optimise l'utilisation du gaz en réduisant le nombre d'emplacements de stockage requis.
Une variable peut être représentée en utilisant différents types de données, mais les coûts d'opération varient en fonction du type. Le choix du type de données approprié aide à optimiser l'utilisation du gas.
Par exemple, en Solidity, les entiers peuvent être subdivisés en différentes tailles : uint8, uint16, uint32, etc. Étant donné que l'EVM fonctionne par unités de 256 bits, l'utilisation de uint8 signifie que l'EVM doit d'abord le convertir en uint256, et cette conversion entraîne des coûts supplémentaires en gaz.
Nous pouvons comparer les coûts en gaz de uint8 et uint256 en utilisant le code dans le diagramme. La fonction UseUint() consomme 120 382 unités de gaz, tandis que la fonction UseUInt8() consomme 166 111 unités de gaz.
À lui seul, uint256 est moins cher que uint8. Cependant, si nous appliquons l'optimisation de regroupement de variables précédemment suggérée, cela fait une différence. Si les développeurs peuvent regrouper quatre variables uint8 dans un seul emplacement de stockage, le coût total de l'itération sur eux sera inférieur à l'utilisation de quatre variables uint256. Dans ce cas, le contrat intelligent peut lire et écrire l'emplacement de stockage une fois et charger les quatre variables uint8 en mémoire/stockage en une seule opération.
Si les données peuvent être contraintes à 32 octets, il est recommandé d'utiliser le type de données bytes32 plutôt que bytes ou strings. En général, les variables de taille fixe consomment moins de Gas que les variables de taille dynamique. Si la longueur en octets peut être limitée, essayez de choisir la plus petite longueur de bytes1 à bytes32.
En Solidity, les listes de données peuvent être représentées à l'aide de deux types de données: des tableaux et des mappages, chacun avec une syntaxe et une structure distinctes.
Dans la plupart des cas, les mappings sont généralement plus efficaces et rentables, tandis que les tableaux sont itérables et prennent en charge le regroupement des types de données. Par conséquent, il est recommandé de donner la priorité à l'utilisation de mappings lors de la gestion des listes de données, sauf si l'itération est nécessaire ou que la consommation de gaz peut être optimisée grâce au regroupement des types de données.
Les variables déclarées dans les paramètres de fonction peuvent être stockées soit dans calldata, soit dans la mémoire. La principale différence est que la mémoire peut être modifiée par la fonction, tandis que calldata est immuable.
Gardez à l'esprit ce principe : si les paramètres de fonction sont en lecture seule, préférez utiliser calldata plutôt que memory. Cela évite les opérations de copie inutiles de calldata de fonction vers la mémoire.
Exemple 1: Utilisation de la mémoire
Lors de l'utilisation du mot-clé mémoire, les valeurs du tableau sont copiées du calldata encodé dans la mémoire lors du décodage ABI. Le coût d'exécution de ce bloc de code est de 3 694 unités de gaz.
Exemple 2: Utilisation de calldata
Lors de la lecture des valeurs directement depuis les données d'appel, l'opération intermédiaire de mémoire est ignorée. Cette optimisation réduit le coût d'exécution à seulement 2 413 unités de gaz, ce qui se traduit par une amélioration de l'efficacité énergétique de 35%.
Les variables constantes/immuables ne sont pas stockées dans la mémoire de stockage du contrat. Ces variables sont calculées au moment de la compilation et stockées dans le bytecode du contrat. Par conséquent, leur coût d'accès est beaucoup plus faible que celui des variables de stockage. Il est recommandé d'utiliser les mots-clés Constant ou Immutable chaque fois que possible.
Lorsque les développeurs peuvent être certains que les opérations arithmétiques ne provoqueront pas de débordement ou de sous-débordement, ils peuvent utiliser le mot-clé non vérifié introduit dans Solidity v0.8.0 pour éviter les vérifications inutiles de débordement ou de sous-débordement, ce qui permet d'économiser les frais de gaz.
Dans le schéma ci-dessous, la conditionnellement contrainte i
De plus, les versions du compilateur 0.8.0 et supérieures ne nécessitent plus l'utilisation de la bibliothèque SafeMath, car le compilateur lui-même inclut désormais une protection intégrée contre le débordement et le dépassement.
Le code des modificateurs est intégré aux fonctions qu'ils modifient. Chaque fois qu'un modificateur est utilisé, son code est dupliqué, ce qui augmente la taille du bytecode et augmente la consommation de Gas. Voici une façon d'optimiser le coût en Gas des modificateurs :
Avant l'optimisation:
Après optimisation:
Dans cet exemple, en refactorisant la logique dans une fonction interne _checkOwner(), qui peut être réutilisée dans le modificateur, la taille du bytecode est réduite et les coûts en gaz sont diminués.
Pour || (OR) et && (AND) opérateurs, les opérations logiques sont évaluées avec un court-circuit, ce qui signifie que si la première condition est suffisante pour déterminer le résultat de l'expression logique, la deuxième condition ne sera pas évaluée.
Pour optimiser la consommation de gaz, les conditions avec des coûts de calcul plus faibles doivent être placées en premier, de sorte que des calculs potentiellement coûteux puissent être évités.
S'il y a des fonctions ou des variables inutilisées dans le contrat, il est recommandé de les supprimer. C'est le moyen le plus direct de réduire les coûts de déploiement du contrat et de maintenir la taille du contrat petite.
Voici quelques suggestions pratiques:
Utilisez les algorithmes les plus efficaces pour les calculs. Si le contrat utilise directement certains résultats de calcul, les calculs redondants doivent être supprimés. Essentiellement, tous les calculs inutilisés doivent être supprimés. Dans Ethereum, les développeurs peuvent recevoir des récompenses en Gas en libérant de l'espace de stockage. Si une variable n'est plus nécessaire, elle doit être supprimée à l'aide du mot-clé delete ou réinitialisée à sa valeur par défaut.
Optimisation de la boucle : Évitez les opérations coûteuses dans la boucle, essayez de fusionner les boucles et déplacez les calculs répétés hors du corps de la boucle.
Les contrats précompilés fournissent des fonctions de bibliothèque complexes telles que les opérations de cryptographie et de hachage. Comme le code n'est pas exécuté sur l'EVM mais s'exécute localement sur le nœud client, moins de gas est requis. L'utilisation de contrats précompilés peut économiser du gas en réduisant la charge de calcul nécessaire pour exécuter le contrat intelligent.
Les exemples de contrats précompilés comprennent l'algorithme de signature numérique à courbes elliptiques (ECDSA) et l'algorithme de hachage SHA2-256. En utilisant ces contrats précompilés dans les contrats intelligents, les développeurs peuvent réduire les coûts de gaz et améliorer l'efficacité de l'application.
Pour obtenir une liste complète des contrats précompilés pris en charge par le réseau Ethereum, veuillez consulter ce lien [4].
L'assemblage en ligne permet aux développeurs d'écrire un code de bas niveau mais efficace qui peut être directement exécuté par l'EVM, sans utiliser des opcodes Solidity coûteux. L'assemblage en ligne permet également d'avoir un contrôle plus précis sur l'utilisation de la mémoire et du stockage, réduisant ainsi davantage les coûts de gaz. De plus, l'assemblage en ligne peut effectuer certaines opérations complexes qu'il est difficile de mettre en œuvre avec Solidity seul, offrant ainsi plus de flexibilité pour optimiser la consommation de gaz.
Voici un exemple d'utilisation de l'assemblage en ligne pour économiser du gas :
Comme on peut le voir dans l'exemple ci-dessus, le deuxième cas, qui utilise l'assemblage en ligne, a une efficacité de gaz plus élevée par rapport au cas standard.
Cependant, l'utilisation de l'assemblage en ligne peut également introduire des risques et est susceptible d'erreurs. Par conséquent, il convient de l'utiliser avec prudence et est recommandé uniquement pour les développeurs expérimentés.
Les solutions de couche 2 peuvent réduire la quantité de données qui doivent être stockées et calculées sur le réseau principal Ethereum.
Les solutions de couche 2 telles que les rollups, les sidechains et les canaux d'état déchargent le traitement des transactions de la chaîne principale Ethereum, ce qui permet des transactions plus rapides et moins coûteuses.
En regroupant un grand nombre de transactions ensemble, ces solutions réduisent le nombre de transactions on-chain, ce qui à son tour réduit les frais de gaz. L'utilisation de solutions de couche 2 améliore également la scalabilité d'Ethereum, permettant à davantage d'utilisateurs et d'applications de participer au réseau sans causer de congestion due à la surcharge.
Il existe plusieurs outils d'optimisation disponibles, tels que l'optimiseur solc, l'optimiseur de construction de Truffle et le compilateur Solidity de Remix.
Ces outils peuvent aider à minimiser la taille de l'octet de code, supprimer le code inutilisé et réduire le nombre d'opérations nécessaires pour exécuter des contrats intelligents. Associés à d'autres bibliothèques d'optimisation du gaz comme "solmate", les développeurs peuvent efficacement réduire les coûts en gaz et améliorer l'efficacité des contrats intelligents.
Optimiser la consommation de gaz est une étape importante pour les développeurs, car cela permet non seulement de minimiser les coûts de transaction, mais aussi d'améliorer l'efficacité des contrats intelligents sur les réseaux compatibles avec EVM. En privilégiant les opérations d'économie de coûts, en réduisant l'utilisation du stockage, en utilisant l'assemblage en ligne et en suivant les meilleures pratiques discutées dans cet article, les développeurs peuvent efficacement réduire la consommation de gaz des contrats.
Cependant, il est important de noter que lors du processus d'optimisation, les développeurs doivent faire preuve de prudence pour éviter d'introduire des vulnérabilités de sécurité. Dans le processus d'optimisation du code et de réduction de la consommation de gaz, la sécurité inhérente du contrat intelligent ne doit jamais être compromise.
[1]https://ethereum.org/fr/developers/docs/gas/
[2] https://ethereum.github.io/yellowpaper/paper.pdf
[3] https://www.evm.codes/
[4]https://www.evm.codes/precompiled