Solidity suit un modèle de versionnage appelé versionnage de sémantique (semantic versioning), qui spécifie les numéros de version structurés comme trois nombres séparés par des points : MAJEUR.MINEUR.CORRECTIF. Le numéro "majeur" est incrémenté pour les modifications majeures et rétro-incompatibles, le numéro "mineur" est incrémenté lorsque des fonctionnalités rétrocompatibles sont ajoutées entre les versions majeures, et le numéro "correctif" est incrémenté pour les corrections de bogues rétrocompatibles.

Au moment de la rédaction, Solidity est à la version 0.4.24. Les règles de la version majeure 0, qui concerne le développement initial d’un projet, sont différentes : tout peut changer à tout moment. En pratique, Solidity traite le numéro "mineur" comme s’il s’agissait de la version majeure et le numéro de "correctif" comme s’il s’agissait de la version mineure. Par conséquent, dans la version 0.4.24, 4 est considérée comme la version majeure et 24 comme la version mineure.

La sortie de la version majeure 0.5 de Solidity est attendue de manière imminente.

Comme vous l’avez vu dans [intro_chapter], vos programmes Solidity peuvent contenir une directive pragma qui spécifie les versions minimale et maximale de Solidity avec lesquelles il est compatible, et peut être utilisée pour compiler votre contrat.

Étant donné que Solidity évolue rapidement, il est souvent préférable d’installer la dernière version.

Il existe un certain nombre de méthodes que vous pouvez utiliser pour télécharger et installer Solidity, soit sous forme de version binaire, soit en compilant à partir du code source. Vous pouvez trouver des instructions détaillées dans http://bit.ly/2RrZmup [la documentation de Solidity].

Voici comment installer la dernière version binaire de Solidity sur un système d’exploitation Ubuntu/Debian, en utilisant le gestionnaire de paquets apt :

Une fois que vous avez installé solc, vérifiez la version en exécutant :

Il existe plusieurs autres façons d’installer Solidity, en fonction de votre système d’exploitation et de vos exigences, y compris la compilation directe à partir du code source. Pour plus d’informations, consultez https://github.com/ethereum/solidity.

Pour développer dans Solidity, vous pouvez utiliser n’importe quel éditeur de texte et solc sur la ligne de commande. Cependant, vous constaterez peut-être que certains éditeurs de texte conçus pour le développement, tels que Emacs, Vim et Atom, offrent des fonctionnalités supplémentaires telles que la coloration syntaxique et les macros qui facilitent le développement de Solidity.

Il existe également des environnements de développement basés sur le Web, tels que Remix IDE et EthFiddle.

Utilisez les outils qui vous rendent productif. En fin de compte, les programmes Solidity ne sont que des fichiers texte. Bien que des éditeurs et des environnements de développement sophistiqués puissent faciliter les choses, vous n’avez besoin de rien de plus qu’un simple éditeur de texte, tel que nano (Linux/Unix), TextEdit (macOS) ou même NotePad (Windows). Enregistrez simplement le code source de votre programme avec une extension .sol et il sera reconnu par le compilateur Solidity comme un programme Solidity.

Dans [intro_chapter], nous avons écrit notre premier programme Solidity. Lorsque nous avons créé le contrat Faucet pour la première fois, nous avons utilisé l’IDE Remix pour compiler et déployer le contrat. Dans cette section, nous allons revisiter, améliorer et embellir Faucet.

Notre première tentative ressemblait à Faucet.sol : Un contrat Solidity mettant en place un robinet.

Maintenant, nous allons utilisez le compilateur Solidity en ligne de commande pour compiler directement notre contrat. Le compilateur Solidity solc offre une variété d’options, que vous pouvez voir en passant l’argument --help.

Nous utilisons les arguments --bin et --optimize de solc pour produire un binaire optimisé de notre exemple de contrat :

Le résultat que solc produit est un binaire sérialisé hexadécimal qui peut être soumis à la chaîne de blocs Ethereum.

Comme nous l’avons vu dans le code précédent, notre contrat Faucet se compile avec succès avec Solidity version 0.4.21. Et si nous avions utilisé une version différente du compilateur Solidity ? Le langage est toujours en constante évolution et les choses peuvent changer de manière inattendue. Notre contrat est assez simple, mais que se passerait-il si notre programme utilisait une fonctionnalité qui n’a été ajoutée que dans la version 0.4.19 de Solidity et que nous essayions de la compiler avec la version 0.4.18 ?

Pour résoudre ces problèmes, Solidity propose une directive du compilateur connue sous le nom de version pragma qui indique au compilateur que le programme attend un compilateur (et un langage) spécifique à une version. Regardons un exemple :

Le compilateur Solidity lit le pragma de version et génère une erreur si la version du compilateur est incompatible avec le pragma de version. Dans ce cas, notre pragma de version indique que ce programme peut être compilé par un compilateur Solidity avec une version minimale de 0.4.19. Le symbole ^ indique, cependant, que nous autorisons la compilation avec toute révision mineure au-dessus de 0.4.19 ; par exemple, 0.4.20, mais pas 0.5.0 (qui est une révision majeure, pas une révision mineure). Les directives Pragma ne sont pas compilées dans le code intermédiaire EVM. Ils ne sont utilisés par le compilateur que pour vérifier la compatibilité.

Ajoutons une directive pragma à notre contrat Faucet. Nous nommerons le nouveau fichier Faucet2.sol, pour garder une trace de nos modifications au fur et à mesure que nous avancerons dans ces exemples en commençant par Faucet2.sol : Ajout du pragma de version à Faucet.

L’ajout d’un pragma de version est une bonne pratique, car il évite les problèmes liés aux versions incompatibles du compilateur et du langage. Nous explorerons d’autres bonnes pratiques et continuerons d’améliorer le contrat Faucet tout au long de ce chapitre.

D’abord, examinons certains des types de données de base proposés dans Solidity :

Byte array (dynamique):: tableaux d’octets de taille variable, déclarés avec bytes ou string.

En plus de ces types de données, Solidity propose également une variété de valeurs littérales qui peuvent être utilisées pour calculer différentes unités :

Dans notre exemple de contrat Faucet, nous avons utilisé un uint (qui est un alias pour uint256)pour la variable withdraw_amount. Nous avons également utilisé indirectement une variable address, que nous avons définie avec msg.sender. Nous utiliserons plus de ces types de données dans nos exemples dans le reste de ce chapitre.

Utilisons l’un des multiplicateurs d’unités pour améliorer la lisibilité de notre exemple de contrat. Dans la fonction withdraw nous limitons le retrait maximum, en exprimant la limite en wei, l’unité de base de l’ether :

Ce n’est pas très facile à lire. Nous pouvons améliorer notre code en utilisant le multiplicateur d’unité ether, pour exprimer la valeur en ether au lieu de wei :

Lorsqu’un contrat est exécuté dans l’EVM, il a accès à un petit ensemble d’objets globaux. Ceux-ci incluent les objets block, msg et tx. De plus, Solidity expose un certain nombre d’opcodes EVM en tant que fonctions prédéfinies. Dans cette section, nous examinerons les variables et les fonctions auxquelles vous pouvez accéder à partir d’un contrat intelligent dans Solidity.

Le type de données principal de Solidity est contract ; notre exemple Faucet définit simplement un objet contract. Semblable à tout objet dans un langage orienté objet, le contrat est un conteneur qui inclut des données et des méthodes.

Solidity propose deux autres types d’objets qui s’apparentent à un contrat :

Au sein d’un contrat, on définit des fonctions qui peuvent être appelées par une transaction EOA ou un autre contrat. Dans notre exemple Faucet, nous avons deux fonctions : withdraw et la fonction (sans nom) fallback.

La syntaxe que nous utilisons pour déclarer une fonction dans Solidity est la suivante :

Examinons chacun de ces composants :

Le prochain ensemble de mots clés (public, private, internal, external) spécifie la visibilité de la fonction :

Gardez à l’esprit que les termes internal et private sont quelque peu trompeurs. Toute fonction ou donnée à l’intérieur d’un contrat est toujours visible sur la chaîne de blocs publique, ce qui signifie que n’importe qui peut voir le code ou les données. Les mots clés décrits ici n’affectent que comment et quand une fonction peut être appelée.

Le deuxième ensemble de mots clés (pure, constant, view, payable) affecte le comportement de la fonction :

Comme vous pouvez le voir dans notre exemple Faucet, nous avons une fonction payante (la fonction de secours), qui est la seule fonction qui peut recevoir des paiements entrants.

Il existe une fonction spéciale qui n’est utilisée qu’une seule fois . Lorsqu’un contrat est créé, il exécute également la fonction constructor s’il en existe une, pour initialiser l’état du contrat. Le constructeur est exécuté dans la même transaction que la création du contrat. La fonction constructeur est facultative ; vous remarquerez que notre exemple Faucet n’en a pas.

Les constructeurs peuvent être spécifiés de deux manières. Jusqu’à et y compris dans Solidity v0.4.21, le constructeur est une fonction dont le nom correspond au nom du contrat, comme vous pouvez le voir ici :

La difficulté avec ce format est que si le nom du contrat est modifié et que le nom de la fonction constructeur n’est pas modifié, ce n’est plus un constructeur. De même, s’il y a une faute de frappe accidentelle dans la dénomination du contrat et/ou du constructeur, la fonction n’est plus un constructeur. Cela peut provoquer des bogues assez désagréables, inattendus et difficiles à trouver. Imaginez par exemple si le constructeur met le propriétaire du contrat à des fins de contrôle. Si la fonction n’est pas réellement le constructeur en raison d’une erreur de nommage, non seulement le propriétaire ne sera pas défini au moment de la création du contrat, mais la fonction peut également être déployée en tant que partie permanente et "appelable" du contrat, comme un fonction normale, permettant à tout tiers de détourner le contrat et d’en devenir le "propriétaire" après la création du contrat.

Pour résoudre les problèmes potentiels avec les fonctions constructeur basées sur le fait d’avoir un nom identique à celui du contrat, Solidity v0.4.22 introduit un mot-clé constructor qui fonctionne comme une fonction constructeur mais n’a pas de nom. Renommer le contrat n’affecte en rien le constructeur. De plus, il est plus facile d’identifier quelle fonction est le constructeur. Il ressemble à ceci :

Pour résumer, le cycle de vie d’un contrat commence par une transaction de création à partir d’un compte EOA ou un contrat. S’il existe un constructeur, il est exécuté dans le cadre de la création du contrat, pour initialiser l’état du contrat lors de sa création, puis est supprimé.

L’autre la fin du cycle de vie du contrat est la destruction du contrat. Les contrats sont détruits par un opcode EVM spécial appelé SELFDESTRUCT. Il s’appelait autrefois SUICIDE, mais ce nom a été déprécié en raison des associations négatives du mot. Dans Solidity, cet opcode est exposé sous la forme d’une fonction intégrée de haut niveau appelée selfdestruct, qui prend un argument : l’adresse pour recevoir tout solde d’ether restant dans le compte du contrat. Il ressemble à ceci :

Notez que vous devez explicitement ajouter cette commande à votre contrat si vous voulez qu’il soit supprimable - c’est la seule façon de supprimer un contrat, et il n’est pas présent par défaut. De cette manière, les utilisateurs d’un contrat qui pourraient s’attendre à ce qu’un contrat soit là pour toujours peuvent être certains qu’un contrat ne peut pas être supprimé s’il ne contient pas d’opcode SELFDESTRUCT.

L’exemple de contrat Faucet que nous avons introduit dans [intro_chapter] n’a pas de constructeur ou de fonctions selfdestruct. C’est un contrat éternel qui ne peut pas être supprimé. Changeons cela en ajoutant un constructeur et une fonction selfdestruct. Nous voulons probablement que selfdestruct soit appelable uniquement par l’EOA qui a initialement créé le contrat. Par convention, ceci est généralement stocké dans une variable d’adresse appelée owner. Notre constructeur définit la variable owner, et la fonction selfdestruct vérifiera d’abord que le propriétaire l’a appelée directement.

Tout d’abord, notre constructeur :

Nous avons modifié la directive pragma pour spécifier la v0.4.22 comme version minimale pour cet exemple, car nous utilisons le nouveau mot-clé constructor introduit dans la v0.4.22 de Solidity. Notre contrat a maintenant une variable de type address nommée owner. Le nom "owner" n’est en aucun cas spécial. Nous pourrions appeler cette variable d’adresse "potato" et l’utiliser toujours de la même manière. Le nom owner rend simplement son objectif clair.

Ensuite, notre constructeur, qui s’exécute dans le cadre de la transaction de création de contrat, attribue l’adresse de msg.sender à la variable owner. Nous avons utilisé msg.sender dans la fonction remove pour identifier l’initiateur de la demande de withdraw. Dans le constructeur, cependant, le msg.sender est l’EOA ou l’adresse du contrat qui a initié la création du contrat. Nous savons que c’est le cas car il s’agit d’une fonction constructeur : elle ne s’exécute qu’une seule fois, lors de la création du contrat.

Nous pouvons maintenant ajouter une fonction pour détruire le contrat. Nous devons nous assurer que seul le propriétaire peut exécuter cette fonction, nous utiliserons donc une instruction require pour contrôler l’accès. Voici à quoi cela ressemblera :

Si quelqu’un appelle cette fonction destroy depuis une adresse autre que owner, elle échouera. Mais si la même adresse stockée dans owner par le constructeur l’appelle, le contrat s’autodétruira et enverra tout solde restant à l’adresse owner. Notez que nous n’avons pas utilisé le non sécurisé tx.origin pour déterminer si le propriétaire souhaitait détruire le contrat. L’utilisation de tx.origin permettrait à des contrats malveillants de détruire votre contrat sans votre permission.

Solidity offre un type spécial de fonction appelé modificateur de fonction. Vous appliquez des modificateurs aux fonctions en ajoutant le nom du modificateur dans la déclaration de la fonction. Les modificateurs sont le plus souvent utilisés pour créer des conditions qui s’appliquent à de nombreuses fonctions au sein d’un contrat. Nous avons déjà une instruction de contrôle d’accès dans notre fonction destroy. Créons un modificateur de fonction qui exprime cette condition :

Ce modificateur de fonction, nommé onlyOwner, définit une condition sur toute fonction qu’il modifie, exigeant que l’adresse stockée en tant que owner du contrat soit la même que l’adresse du msg.sender de la transaction. Il s’agit du modèle de conception de base pour le contrôle d’accès, permettant uniquement au propriétaire d’un contrat d’exécuter toute fonction qui a le modificateur onlyOwner.

Vous avez peut-être remarqué que notre modificateur de fonction contient un "espace réservé" syntaxique particulier, un trait de soulignement suivi d’un point-virgule (_;). Cet espace réservé est remplacé par le code de la fonction en cours de modification. Essentiellement, le modificateur est "enroulé autour" de la fonction modifiée, plaçant son code à l’emplacement identifié par le caractère de soulignement.

Pour appliquer un modificateur, vous ajoutez son nom à la déclaration de la fonction. Plusieurs modificateurs peuvent être appliqués à une fonction ; ils sont appliqués dans l’ordre dans lequel ils sont déclarés, sous forme de liste séparée par des virgules.

Réécrivons notre fonction destroy pour utiliser le modificateur onlyOwner :

Le nom du modificateur de fonction (onlyOwner)se trouve après le mot-clé public et nous indique que la fonction destroy est modifiée par le modificateur onlyOwner. Essentiellement, vous pouvez lire cela comme "Seul le propriétaire peut détruire ce contrat". En pratique, le code résultant équivaut à "envelopper" le code de onlyOwner autour de destroy.

Les modificateurs de fonction sont un outil extrêmement utile car ils nous permettent d’écrire des conditions préalables pour les fonctions et de les appliquer de manière cohérente, ce qui rend le code plus facile à lire et, par conséquent, plus facile à auditer pour la sécurité. Ils sont le plus souvent utilisés pour le contrôle d’accès, mais ils sont assez polyvalents et peuvent être utilisés à diverses autres fins.

A l’intérieur d’un modificateur, vous pouvez accéder à toutes les valeurs (variables et arguments) visibles par la fonction modifiée. Dans ce cas, nous pouvons accéder à la variable owner, qui est déclarée dans le contrat. Cependant, l’inverse n’est pas vrai : vous ne pouvez accéder à aucune des variables du modificateur à l’intérieur de la fonction modifiée.

L’objet contract de Solidity prend en charge l'héritage, qui est un mécanisme permettant d’étendre un contrat de base avec des fonctionnalités supplémentaires. Pour utiliser l’héritage, spécifiez un contrat parent avec le mot-clé is :

Avec cette construction, le contrat Child hérite de toutes les méthodes, fonctionnalités et variables de Parent. Solidity prend également en charge l’héritage multiple, qui peut être spécifié par des noms de contrat séparés par des virgules après le mot-clé is :

L’héritage de contrat nous permet d’écrire nos contrats de manière à atteindre la modularité, l’extensibilité et la réutilisation. Nous commençons par des contrats simples et implémentons les capacités les plus génériques, puis nous les étendons en héritant de ces capacités dans des contrats plus spécialisés.

Dans notre contrat Faucet, nous avons introduit le constructeur et le destructeur, ainsi qu’un contrôle d’accès pour un propriétaire, assigné à la construction. Ces capacités sont assez génériques : de nombreux contrats en auront. Nous pouvons les définir comme des contrats génériques, puis utiliser l’héritage pour les étendre au contrat Faucet.

Nous commençons par définir un contrat de base owned, qui a une variable owner, en la définissant dans le constructeur du contrat :

Ensuite, nous définissons un contrat de base mortal, qui hérite de owned :

Comme vous pouvez le voir, le contrat mortal peut utiliser le modificateur de fonction onlyOwner, défini dans owned. Il utilise aussi indirectement la variable d’adresse owner et le constructeur défini dans owned. L’héritage rend chaque contrat plus simple et axé sur sa fonctionnalité spécifique, nous permettant de gérer les détails de manière modulaire.

Nous pouvons maintenant étendre davantage le contrat owned, en héritant de ses capacités dans Faucet :

En héritant de mortal, qui à son tour hérite de owned, le contrat Faucet a maintenant les fonctions constructeur et destroy, et un propriétaire défini. La fonctionnalité est la même que lorsque ces fonctions étaient dans Faucet, mais maintenant nous pouvons réutiliser ces fonctions dans d’autres contrats sans les réécrire. La réutilisation et la modularité du code rendent notre code plus propre, plus facile à lire et plus facile à auditer.

Un appel de contrat peut se terminer et renvoyer une erreur. La gestion des erreurs dans Solidity est gérée par quatre fonctions : assert, require, revert et throw (désormais obsolète).

Lorsqu’un contrat se termine avec une erreur, tous les changements d’état (changements de variables, de soldes, etc.) sont annulés, tout au long de la chaîne d’appels de contrat si plusieurs contrats ont été appelés. Cela garantit que les transactions sont atomiques, ce qui signifie qu’elles se terminent avec succès ou n’ont aucun effet sur l’état et sont entièrement annulées.

Les fonctions assert et require fonctionnent de la même manière, évaluant une condition et arrêtant l’exécution avec une erreur si la condition c’est fausse. Par convention, assert est utilisé lorsque le résultat est censé être vrai, ce qui signifie que nous utilisons assert pour tester les conditions internes. Par comparaison, require est utilisé lors du test d’entrées (telles que des arguments de fonction ou des champs de transaction), définissant nos attentes pour ces conditions.

Nous avons utilisé require dans notre modificateur de fonction onlyOwner, pour tester que l’expéditeur du message est le propriétaire du contrat :

La fonction require agit comme une condition d’entrée, empêchant l’exécution du reste de la fonction et produisant une erreur si elle n’est pas satisfaite.

Depuis Solidity v0.4.22, require peut également inclure un message texte utile qui peut être utilisé pour indiquer la raison de l’erreur. Le message d’erreur est enregistré dans le journal des transactions. Ainsi, nous pouvons améliorer notre code en ajoutant un message d’erreur dans notre fonction require :

Les fonctions revert et throw interrompent l’exécution du contrat et annulent tout changement d’état. La fonction throw est obsolète et sera supprimée dans les futures versions de Solidity ; vous devriez utiliser revert à la place. La fonction revert peut également prendre un message d’erreur comme seul argument, qui est enregistré dans le journal des transactions.

Certaines conditions d’un contrat généreront des erreurs, que nous les vérifiions explicitement ou non. Par exemple, dans notre contrat Faucet, nous ne vérifions pas s’il y a suffisamment d’ether pour satisfaire une demande de retrait. En effet, la fonction transfer échouera avec une erreur et annulera la transaction si le solde est insuffisant pour effectuer le transfert :

Cependant, il peut être préférable de vérifier explicitement et de fournir un message d’erreur clair en cas d’échec. Nous pouvons le faire en ajoutant une instruction require avant le transfert :

Un code de vérification d’erreur supplémentaire comme celui-ci augmentera légèrement la consommation de gaz, mais il offre un meilleur rapport d’erreur que s’il est omis. Vous devrez trouver le bon équilibre entre la consommation de gaz et la vérification détaillée des erreurs en fonction de l’utilisation prévue de votre contrat. Dans le cas d’un contrat Faucet destiné à un testnet, nous pouvons probablement abuser du côté des rapports supplémentaires même si cela coûte plus cher en gaz. Peut-être que pour un contrat de réseau principal, nous choisirons plutôt d’être économes avec notre consommation de gaz.

Lorsque une transaction se termine (avec succès ou non), elle produit une réception de transaction, comme nous le verrons dans [evm_chapter]. Le reçu de transaction contient des entrées log qui fournissent des informations sur les actions qui se sont produites lors de l’exécution de la transaction. Les Événements ou Events sont les objets de haut niveau de Solidity utilisés pour construire ces journaux.

Les événements sont particulièrement utiles pour les clients légers et les services DApp, qui peuvent "surveiller" des événements spécifiques et les signaler à l’interface utilisateur, ou modifier l’état de l’application pour refléter un événement dans un contrat sous-jacent.

Les objets d’événement prennent des arguments qui sont sérialisés et enregistrés dans les journaux de transactions, dans la chaîne de blocs. Vous pouvez fournir le mot-clé indexé avant un argument, pour que la valeur fasse partie d’une table indexée (table de hachage) qui peut être recherchée ou filtrée par une application.

Nous n’avons ajouté aucun événement dans notre exemple Faucet jusqu’à présent, alors faisons cela. Nous ajouterons deux événements, un pour enregistrer les retraits et un pour enregistrer les dépôts. Nous appellerons ces événements Withdrawal et Deposit, respectivement. Tout d’abord, nous définissons les événements dans le contrat Faucet :

Nous avons choisi de rendre les adresses indexed, pour permettre la recherche et le filtrage dans n’importe quelle interface utilisateur conçue pour accéder à notre Faucet.

Ensuite, nous utilisons le mot-clé emit pour incorporer les données d’événement dans les journaux de transactions :

Le contrat Faucet.sol résultant ressemble à Faucet8.sol : contrat de robinet révisé, avec événements.

Appeler d’autres contrats depuis votre contrat est une opération très utile mais potentiellement dangereuse. Nous examinerons les différentes façons d’y parvenir et évaluerons les risques de chaque méthode. En bref, les risques découlent du fait que vous ne savez peut-être pas grand-chose sur un contrat auquel vous faites appel ou qui fait appel à votre contrat. Lors de la rédaction de contrats intelligents, vous devez garder à l’esprit que même si vous vous attendez principalement à traiter avec des EOA, rien n’empêche des contrats arbitrairement complexes et peut-être malveillants d’appeler et d’être appelés par votre code.

Toute boucle à travers un tableau de taille dynamique où une fonction effectue des opérations sur chaque élément ou recherche un élément particulier introduit le risque d’utiliser trop de gaz. En effet, le contrat peut s’essouffler avant d’avoir trouvé le résultat souhaité, ou avant d’agir sur chaque élément, perdant ainsi du temps et de l’ether sans donner le moindre résultat.

Appeler d’autres contrats, surtout lorsque le coût en gaz de leurs fonctions n’est pas connu, introduit le risque de manquer de gaz. Évitez d’utiliser des bibliothèques qui ne sont pas bien testées et largement utilisées. Moins une bibliothèque a été examinée par d’autres programmeurs, plus le risque de l’utiliser est grand.

Si vous avez besoin d’estimer le gaz nécessaire pour exécuter une certaine méthode d’un contrat en tenant compte ses arguments, vous pouvez utiliser la procédure suivante :

gasEstimate vous indiquera le nombre d’unités de gaz nécessaires à son exécution. Il s’agit d’une estimation en raison de l’exhaustivité de Turing de l’EVM - il est relativement trivial de créer une fonction qui prendra des quantités de gaz très différentes pour exécuter différents appels. Même le code de production peut modifier les chemins d’exécution de manière subtile, ce qui entraîne des coûts de gaz extrêmement différents d’un appel à l’autre. Cependant, la plupart des fonctions sont sensibles et estimateGas donnera une bonne estimation la plupart du temps.

Pour obtenir le prix du gaz du réseau, vous pouvez utiliser :

Et à partir de là, vous pouvez estimer le coût du gaz :

Appliquons nos fonctions d’estimation de gaz pour estimer le coût du gaz de notre exemple Faucet, en utilisant le code du référentiel du livre.

Démarrez Truffle en mode développement et exécutez le fichier JavaScript dans gas_estimates.js : Utilisation de la fonction estimateGas, gas_estimates.js.

Voici à quoi cela ressemble dans la console de développement Truffle :

Il est recommandé d’évaluer le coût en gaz des fonctions dans le cadre de votre workflow de développement, afin d’éviter toute surprise lors du déploiement de contrats sur le réseau principal.