Maîtriser Ethereum

Une fois MetaMask installé, vous devriez voir une nouvelle icône (la tête d’un renard) dans la barre d’outils de votre navigateur. Cliquez dessus pour commencer. Il vous sera demandé d’accepter les termes et conditions puis de créer votre nouveau portefeuille Ethereum en saisissant un mot de passe (voir La page de mot de passe de l’extension MetaMask Chrome).

Une fois que vous avez défini un mot de passe, MetaMask générera un portefeuille pour vous et vous montrera un mnémonique de sauvegarde composé de 12 mots anglais (voir La sauvegarde mnémonique de votre portefeuille, créée par MetaMask). Ces mots peuvent être utilisés dans n’importe quel portefeuille compatible pour récupérer l’accès à vos fonds si quelque chose arrivait à MetaMask ou à votre ordinateur. Vous n’avez pas besoin du mot de passe pour cette récupération ; les 12 mots suffisent.

Une fois que vous avez confirmé que vous avez stocké le mnémonique en toute sécurité, vous pourrez voir les détails de votre compte Ethereum, comme indiqué dans Votre compte Ethereum dans MetaMask.

La page de votre compte affiche le nom de votre compte ("Account 1" par défaut), une adresse Ethereum (0x9E713... dans l’exemple), et une icône colorée pour vous aider à distinguer visuellement ce compte des autres comptes. En haut de la page du compte, vous pouvez voir sur quel réseau Ethereum vous travaillez actuellement ("Main Network" dans l’exemple).

Toutes nos félicitations ! Vous avez configuré votre premier portefeuille Ethereum.

Comme vous pouvez le voir sur la page du compte MetaMask, vous pouvez choisir entre plusieurs réseaux Ethereum. Par défaut, MetaMask essaiera de se connecter au réseau principal. Les autres choix sont des réseaux de test publics, tout nœud Ethereum de votre choix ou des nœuds exécutant des chaînes de blocs privées sur votre propre ordinateur (localhost) :

Votre première tâche est de financer votre portefeuille. Vous ne ferez pas cela sur le réseau principal car l’ether réel coûte de l’argent et sa manipulation nécessite un peu plus d’expérience. Pour l’instant, vous allez charger votre portefeuille avec de l’ether testnet.

Passez MetaMask au Réseau test Ropsten. Cliquez sur Deposit, puis sur Ropsten Test Faucet. MetaMask ouvrira une nouvelle page Web, comme indiqué dans MetaMask et le robinet du réseau test Ropsten.

Vous remarquerez peut-être que la page Web contient déjà l’adresse Ethereum de votre portefeuille MetaMask. MetaMask intègre les pages Web compatibles Ethereum avec votre portefeuille MetaMask et peut "voir" les adresses Ethereum sur la page Web, vous permettant, par exemple, d’envoyer un paiement à une boutique en ligne affichant une adresse Ethereum. MetaMask peut également remplir la page Web avec l’adresse de votre propre portefeuille en tant qu’adresse de destinataire si la page Web le demande. Sur cette page, l’application du robinet demande à MetaMask une adresse de portefeuille à laquelle envoyer de l’ether de test.

Cliquez sur le bouton vert "demander 1 ether au robinet". Vous verrez un ID de transaction apparaître dans la partie inférieure de la page. L’application robinet ou "faucet" a créé une transaction, un paiement qui vous est destiné. L’ID de transaction ressemble à ceci :

Dans quelques secondes, la nouvelle transaction sera exploitée par les mineurs de Ropsten et votre portefeuille MetaMask affichera un solde de 1 ETH. Cliquez sur l’ID de transaction et votre navigateur vous amènera à un explorateur de bloc, qui est un site Web qui vous permet de visualiser et d’explorer des blocs, des adresses et des transactions. MetaMask utilise Explorateur de blocs Etherscan, l’un des explorateurs de blocs Ethereum les plus populaires. La transaction contenant le paiement du Ropsten Test Faucet est affichée dans Explorateur de blocs Ropsten sur Etherscan.

La transaction a été enregistrée sur la chaîne de blocs Ropsten et peut être consultée à tout moment par n’importe qui, simplement en recherchant l’ID de transaction, ou en visitant le lien.

Essayez de visiter ce lien ou de saisir le hachage de la transaction sur le site Web ropsten.etherscan.io pour le voir par vous-même.

Une fois que vous avez reçu votre premier test d’ether du Ropsten Test Faucet, vous pouvez expérimenter l’envoi d’ether en essayant d’en renvoyer au robinet. Comme vous pouvez le voir sur la page Ropsten Test Faucet, il existe une option pour "donner" 1 ETH au robinet. Cette option est disponible pour qu’une fois que vous avez terminé les tests, vous puissiez retourner le reste de votre ether de test, afin que quelqu’un d’autre puisse l’utiliser ensuite. Même si l’ether de test n’a aucune valeur, certaines personnes l’accumulent, ce qui rend difficile pour tout le monde d’utiliser les réseaux de test. L’accumulation de l’ether de test est mal vue !

Heureusement, nous ne sommes pas des accumulateurs d’ether de test. Cliquez sur le bouton orange "1 ether" pour dire à MetaMask de créer une transaction payant le robinet 1 ether. MetaMask préparera une transaction et ouvrira une fenêtre avec la confirmation, comme indiqué dans Envoi de 1 ether au robinet.

Oups ! Vous avez probablement remarqué que vous ne pouvez pas terminer la transaction - MetaMask indique que vous avez un solde insuffisant. À première vue, cela peut sembler déroutant : vous avez 1 ETH, vous voulez envoyer 1 ETH, alors pourquoi MetaMask dit-il que vous avez des fonds insuffisants ?

La réponse est à cause du coût de gaz. Chaque transaction Ethereum nécessite le paiement d’une redevance, qui est perçue par les mineurs pour valider la transaction. Les frais d’Ethereum sont facturés dans une monnaie virtuelle appelée gaz. Vous payez le gaz avec de l’ether, dans le cadre de la transaction.

Lorsque vous avez envoyé la transaction, MetaMask a calculé le prix moyen du gaz des récentes transactions réussies à 3 gwei, ce qui signifie gigawei. Wei est la plus petite subdivision de la monnaie ether, comme nous l’avons vu dans L’ether comme unité monétaire. La limite de gaz est fixée au prix de l’envoi d’une transaction de base, soit 21 000 unités de gaz. Par conséquent, le montant maximum d’ETH que vous dépenserez est de 3 * 21 000 gwei = 63 000 gwei = 0,000063 ETH. (Sachez que les prix moyens du gaz peuvent fluctuer, car ils sont principalement déterminés par les mineurs. Nous verrons dans un chapitre ultérieur comment vous pouvez augmenter/diminuer votre limite de gaz pour vous assurer que votre transaction a la priorité si nécessaire.)

Tout cela pour dire : faire une transaction à 1 ETH coûte 1,000063 ETH. MetaMask arrondit de manière confuse au plancher d'1 ETH lors de l’affichage du total, mais le montant réel dont vous avez besoin est de 1,000063 ETH et vous n’avez que 1 ETH. Cliquez sur Reject pour annuler cette transaction.

Prenons un peu plus d’ether de test ! Cliquez à nouveau sur le bouton vert "request 1 ether from the faucet" et attendez quelques secondes. Ne vous inquiétez pas, le robinet devrait avoir beaucoup d’ether et vous en donnera plus si vous le demandez.

Une fois que vous avez un solde de 2 ETH, vous pouvez réessayer. Cette fois, lorsque vous cliquez sur le bouton de don orange "1 ether", vous disposez d’un solde suffisant pour finaliser la transaction. Cliquez sur Soumettre lorsque MetaMask apparaît dans la fenêtre de paiement. Après tout cela, vous devriez voir un solde de 0,999937 ETH car vous avez envoyé 1 ETH au robinet avec 0,000063 ETH en gaz.

Vous êtes maintenant devenu un expert dans l’utilisation de MetaMask pour envoyer et recevoir de l’ether de test. Votre portefeuille a reçu au moins deux paiements et en a envoyé au moins un. Vous pouvez afficher toutes ces transactions à l’aide de l’explorateur de blocs ropsten.etherscan.io. Vous pouvez soit copier l’adresse de votre portefeuille et la coller dans la zone de recherche de l’explorateur de blocs, soit demander à MetaMask d’ouvrir la page pour vous. À côté de l’icône de votre compte dans MetaMask, vous verrez un bouton affichant trois points. Cliquez dessus pour afficher un menu d’options liées au compte (voir Menu contextuel du compte MetaMask).

Sélectionnez "View account on Etherscan" pour ouvrir une page Web dans l’explorateur de blocs affichant l’historique des transactions de votre compte, comme indiqué dans Historique des transactions d’une adresse sur Etherscan.

Ici, vous pouvez voir l’historique complet des transactions de votre adresse Ethereum. Il montre toutes les transactions enregistrées sur la chaîne de blocs Ropsten où votre adresse est l’expéditeur ou le destinataire. Cliquez sur quelques-unes de ces transactions pour voir plus de détails.

Vous pouvez explorer l’historique des transactions de n’importe quelle adresse. Jetez un œil à l’historique des transactions de l’adresse Ropsten Test Faucet (indice : il s’agit de l’adresse « expéditeur » répertoriée dans le plus ancien paiement à votre adresse). Vous pouvez voir tout l’ether de test envoyé par le robinet à vous et à d’autres adresses. Chaque transaction que vous voyez peut vous mener à plus d’adresses et plus de transactions. D’ici peu, vous serez perdu dans le labyrinthe de données interconnectées. Les chaînes de blocs publiques contiennent une énorme richesse d’informations, qui peuvent toutes être explorées par programmation, comme nous le verrons dans de futurs exemples.

Nous avons maintenant un contrat enregistré sur la chaîne de blocs, et nous pouvons voir qu’il a une adresse Ethereum. Vérifions-le dans l’explorateur de blocs ropsten.etherscan.io et voyons à quoi ressemble un contrat. Dans l’IDE Remix, copiez l’adresse du contrat en cliquant sur l’icône du presse-papiers à côté de son nom (voir Copiez l’adresse du contrat de Remix).

Gardez Remix ouvert ; nous y reviendrons plus tard. Maintenant, naviguez dans votre navigateur jusqu’à ropsten.etherscan.io et collez l’adresse dans le champ de recherche. Vous devriez voir l’historique des adresses Ethereum du contrat, comme indiqué dans Afficher l’adresse du contrat Faucet dans l’explorateur de blocs Etherscan.

Pour l’instant, le contrat n’a qu’une seule transaction dans son historique : l’opération de création de contrat. Comme vous pouvez le voir, le contrat n’a pas non plus d’ether (solde nul). C’est parce que nous n’avons pas envoyé d’ether au contrat dans la transaction de création, même si nous aurions pu le faire.

Notre robinet a besoin de fonds ! Notre premier projet sera d’utiliser MetaMask pour envoyer de l’ether au contrat. Vous devriez toujours avoir l’adresse du contrat dans votre presse-papiers (sinon, copiez-la à nouveau depuis Remix). Ouvrez MetaMask et envoyez-lui 1 ether, exactement comme vous le feriez à n’importe quelle autre adresse Ethereum (voir Envoyer 1 ether à l’adresse du contrat).

Dans une minute, si vous rechargez l’explorateur de blocs Etherscan, il affichera une autre transaction à l’adresse du contrat et un solde mis à jour de 1 ether.

Vous souvenez-vous de la fonction de paiement externe par défaut sans nom dans notre code Faucet.sol ? Ça ressemblait à ça :

Lorsque vous avez envoyé une transaction à l’adresse du contrat, sans données spécifiant la fonction à appeler, elle a appelé cette fonction par défaut. Parce que nous l’avons déclaré comme payable, il a accepté et déposé le 1 ether dans le solde du compte du contrat. Votre transaction a entraîné l’exécution du contrat dans l’EVM, mettant à jour son solde. Vous avez financé votre robinet !

Ensuite, retirons des fonds du robinet. Pour retirer, nous devons construire une transaction qui appelle la fonction withdraw et lui passe un argument withdraw_amount. Pour garder les choses simples pour le moment, Remix construira cette transaction pour nous et MetaMask la présentera pour notre approbation.

Revenez à l’onglet Remix et consultez le contrat dans l’onglet Run. Vous devriez voir une boîte orange intitulée wthdraw (retrait) avec une entrée de champ intitulée uint256 withdraw_amount (voir La fonction de retrait (withdraw) de Faucet.sol, dans Remix).

Il s’agit de l’interface Remix du contrat. Il nous permet de construire des transactions qui appellent les fonctions définies dans le contrat. Nous entrerons un withdraw_amount et cliquerons sur le bouton de retrait pour générer la transaction.

Tout d’abord, déterminons le withdraw_amount (montant de retrait). Nous voulons essayer de retirer 0,1 ether, qui est le montant maximum autorisé par notre contrat. N’oubliez pas que toutes les valeurs monétaires d’Ethereum sont libellées en wei en interne, et notre fonction withdraw s’attend à ce que le withdraw_amount soit également libellé en wei. La quantité que nous voulons est de 0,1 ether, soit 100 000 000 000 000 000 wei (un 1 suivi de 17 zéros).

Tapez "100000000000000000" (avec les guillemets) dans la case withdraw_amount et cliquez sur le bouton de retrait (voir Cliquez sur "withdraw" dans Remix pour créer une transaction de retrait).

MetaMask fera apparaître une fenêtre de transaction que vous devrez approuver. Cliquez sur Confirmer pour envoyer votre appel de retrait au contrat (voir Transaction MetaMask pour appeler la fonction de retrait).

Attendez une minute, puis rechargez l’explorateur de blocs Etherscan pour voir la transaction reflétée dans l’historique des adresses de contrat + Faucet + (voir Etherscan montre la transaction appelant la fonction de retrait).

Nous voyons maintenant une nouvelle transaction avec l’adresse du contrat comme destination et une valeur de 0 ether. Le solde du contrat a changé et est maintenant de 0,9 ether car il nous a envoyé 0,1 ether comme demandé. Mais nous ne voyons pas de transaction "OUT" dans l'historique des adresses de contrat.

Où est le retrait sortant ? Un nouvel onglet est apparu sur la page d’historique des adresses du contrat, nommé Transactions internes. Parce que le transfert d’ether 0.1 provient du code de contrat, il s’agit d’une transaction interne (également appelée message). Cliquez sur cet onglet pour le voir (voir Etherscan montre la transaction interne transférant l’ether du contrat).

Cette "transaction interne" a été envoyée par le contrat dans cette ligne de code (à partir de la fonction withdraw dans Faucet.sol) :

Pour récapituler : vous avez envoyé une transaction depuis votre portefeuille MetaMask contenant des instructions de données pour appeler la fonction withdraw avec un argument withdraw_amount de 0,1 ether. Cette transaction a entraîné l’exécution du contrat à l’intérieur de l’EVM. Lorsque l’EVM a exécuté la fonction withdraw du contrat Faucet, il a d’abord appelé la fonction require et validé que le montant demandé était inférieur ou égal au retrait maximal autorisé de 0,1 ether. Ensuite, il a appelé la fonction transfer pour vous envoyer l’ether. L’exécution de la fonction transfer a généré une transaction interne qui a déposé 0,1 ether dans votre adresse de portefeuille, à partir du solde du contrat. C’est celui affiché sur l’onglet Internal Transactions dans Etherscan.

La santé, la résilience et la résistance à la censure des chaînes de blocs dépendent de leur nombre de nœuds complets exploités indépendamment et dispersés géographiquement. Chaque nœud complet peut aider d’autres nouveaux nœuds à obtenir les données de bloc pour amorcer leur fonctionnement, tout en offrant à l’opérateur une vérification faisant autorité et indépendante de toutes les transactions et contrats.

Cependant, l’exécution d’un nœud complet entraînera un coût en ressources matérielles et en bande passante. Un nœud complet doit télécharger 80 à 300 Go de données (à compter de janvier 2020, selon la configuration du client) et les stocker sur un disque dur local. Cette charge de données augmente assez rapidement chaque jour à mesure que de nouvelles transactions et de nouveaux blocs sont ajoutés. Nous abordons ce sujet plus en détail dans Configuration matérielle requise pour un nœud complet.

Un nœud complet fonctionnant sur un réseau mainnet en direct n’est pas nécessaire pour le développement d’Ethereum. Vous pouvez faire presque tout ce que vous devez faire avec un nœud testnet (qui vous connecte à l’une des plus petites chaînes de blocs de test publiques), avec une chaîne de blocs privée locale comme Ganache, ou avec un client Ethereum basé sur le cloud proposé par un fournisseur de services comme Infura.

Vous avez également la possibilité d’exécuter un client distant, qui ne stocke pas de copie locale de la chaîne de blocs ni ne valide les blocs et les transactions. Ces clients offrent la fonctionnalité d’un portefeuille et peuvent créer et diffuser des transactions. Les clients distants peuvent être utilisés pour se connecter à des réseaux existants, tels que votre propre nœud complet, une chaîne de blocs publique, un testnet public ou autorisé (preuve d’autorité), ou une chaîne de blocs locale privée. En pratique, vous utiliserez probablement un client distant tel que MetaMask, Emerald Wallet, MyEtherWallet ou MyCrypto comme moyen pratique de basculer entre toutes les différentes options de nœud.

Les termes "client distant" et "portefeuille" sont utilisés de manière interchangeable, bien qu’il existe certains différences. Habituellement, un client distant propose une API (telle que l’API web3.js) en plus de la fonctionnalité de transaction d’un portefeuille.

Ne confondez pas le concept de portefeuille distant dans Ethereum avec celui d’un client léger (qui est analogue à un client de vérification simplifiée des paiements dans Bitcoin). Les clients légers valident les en-têtes de bloc et utilisent les preuves Merkle pour valider l’inclusion des transactions dans la chaîne de blocs et déterminer leurs effets, leur donnant un niveau de sécurité similaire à un nœud complet. Inversement, les clients distants Ethereum ne valident pas les en-têtes de bloc ou les transactions. Ils font entièrement confiance à un client complet pour leur donner accès à la chaîne de blocs, et perdent ainsi d’importantes garanties de sécurité et d’anonymat. Vous pouvez atténuer ces problèmes en utilisant un client complet que vous exécutez vous-même.

Choisir d’exécuter un nœud complet facilite le fonctionnement des réseaux auxquels vous le connectez, mais entraîne également des coûts légers à modérés pour vous. Regardons quelques-uns des avantages et des inconvénients.

Avantages:

Désavantages:

Que vous choisissiez ou non d’exécuter un nœud complet, vous souhaiterez probablement exécuter un nœud testnet public. Examinons quelques-uns des avantages et des inconvénients de l’utilisation d’un testnet public.

Avantages:

Désavantages:

À de nombreuses fins de test, la meilleure option consiste à lancer une chaîne de blocs privée à instance unique. Ganache (anciennement nommé testrpc)est l’une des simulations de chaîne de blocs locales les plus populaires avec lesquelles vous pouvez interagir, sans aucun autre participant. Il partage de nombreux avantages et inconvénients du testnet public, mais présente également quelques différences.

Avantages:

Désavantages:

Avant de commencer, vous devez vous assurer que vous disposez d’un ordinateur doté de ressources suffisantes pour fonctionner un nœud complet Ethereum. Vous aurez besoin d’au moins 300 Go d’espace disque pour stocker une copie complète de la chaîne de blocs Ethereum. Si vous souhaitez également exécuter un nœud complet sur le testnet Ethereum, vous aurez besoin d’au moins 45 Go supplémentaires. Le téléchargement de 345 Go de données de la chaîne de blocs peut prendre beaucoup de temps, il est donc recommandé de travailler sur une connexion Internet rapide.

La synchronisation de la chaîne de blocs Ethereum est très intensive en entrée/sortie (E/S). Il est préférable d’avoir un disque statique électronique (SSD). Si vous avez un disque dur mécanique (HDD), vous aurez besoin d’au moins 8 Go de RAM à utiliser comme cache. Sinon, vous découvrirez peut-être que votre système est trop lent pour suivre et synchroniser complètement.

Exigences minimales:

Ce sont les exigences minimales pour synchroniser une copie complète (mais élaguée) d’une chaîne de blocs basée sur Ethereum.

Au moment de la rédaction, la base de code Parity est plus légère sur les ressources, donc si vous utilisez un matériel limité, vous obtiendrez probablement de meilleurs résultats en utilisant Parity.

Si vous souhaitez synchroniser dans un délai raisonnable et stocker tous les outils de développement, bibliothèques, clients et chaînes de blocs dont nous parlons dans ce livre, vous voudrez un ordinateur plus performant.

Spécifications recommandées :

Il est difficile de prédire à quelle vitesse la taille d’une chaîne de blocs augmentera et quand plus d’espace disque sera nécessaire, il est donc recommandé de vérifier la dernière taille de la chaîne de blocs avant de commencer la synchronisation.

Ces liens fournissent des estimations à jour de la taille de la chaîne de blocs :

Cette section couvre les logiciels clients Parity et Geth. Il suppose également que vous utilisez un environnement de ligne de commande de type Unix. Les exemples montrent les commandes et la sortie telles qu’elles apparaissent sur un système d’exploitation Ubuntu GNU/Linux exécutant le shell bash (environnement d’exécution en ligne de commande).

En règle générale, chaque chaîne de blocs aura sa propre version de Geth, tandis que Parity prend en charge plusieurs chaînes de blocs basées sur Ethereum (Ethereum, Ethereum Classic, Ellaism, Expanse, Musicoin) avec le même client téléchargé.

Avant de commencer, vous devrez peut-être installer certains logiciels. Si vous n’avez jamais fait de développement logiciel sur l’ordinateur que vous utilisez actuellement, vous devrez probablement installer quelques outils de base. Pour les exemples qui suivent, vous devrez installer git, le système de gestion du code source ; golang, le langage de programmation Go et les bibliothèques standard ; et Rust, un langage de programmation système.

Git peut être installé en suivant les instructions sur https://git-scm.com.

Go peut être installé en suivant les instructions sur https://golang.org, ou https://github.com/golang/ go/wiki/Ubuntu[] si vous utilisez Ubuntu.

Rust peut être installé en suivant les instructions sur https://www.rustup.rs/.

Parity nécessite également certaines bibliothèques logicielles, telles que OpenSSL et libudev. Pour les installer sur un système compatible Ubuntu ou Debian GNU/Linux, utilisez la commande suivante :

Pour les autres systèmes d’exploitation, utilisez le gestionnaire d’applications de votre système d’exploitation ou suivez les https://github.com/paritytech/parity/wiki/Setup [instructions Wiki] pour installer les bibliothèques requises.

Maintenant que vous avez installé git, golang, Rust et les bibliothèques nécessaires, mettons-nous au travail !

Parity est une implémentation d’un client Ethereum à nœud complet et d’un navigateur DApp. Il a été écrit « à partir de zéro » en Rust, un langage de programmation système, dans le but de créer un client Ethereum modulaire, sécurisé et évolutif. Parity est développé par Parity Tech, une société britannique, et est publié sous la licence de logiciel libre GPLv3.

Pour installer Parity, vous pouvez utiliser le gestionnaire d’applications Rust cargo ou télécharger le code source depuis GitHub. Le gestionnaire d’applications télécharge également le code source, il n’y a donc pas beaucoup de différence entre les deux options. Dans la section suivante, nous vous montrerons comment télécharger et compiler Parity vous-même.

Geth est l’implémentation avec le langage Go activement développée par la Fondation Ethereum, elle est donc considérée comme l’implémentation "officielle" du client Ethereum. En règle générale, chaque chaîne de blocs basée sur Ethereum aura sa propre implémentation Geth. Si vous utilisez Geth, assurez-vous de récupérer la bonne version pour votre chaîne de blocs en utilisant l’un des liens de référentiel suivants :

Maintenant que vous comprenez les défis de la "première synchronisation", vous êtes prêt à démarrer un client Ethereum et à synchroniser la chaîne de blocs. Pour Geth et Parity, vous pouvez utiliser l’option --help pour voir tous les paramètres de configuration. Les paramètres par défaut sont généralement judicieux et appropriés pour la plupart des utilisations. Choisissez comment configurer les paramètres facultatifs en fonction de vos besoins, puis démarrez Geth ou Parity pour synchroniser la chaîne. Puis attendre…​

Les clients Ethereum offrent une interface de programmation d’application et un ensemble de commandes Remote Procedure Call (RPC), qui sont encodées en JavaScript Object Notation (JSON). Vous verrez cela appelé API JSON-RPC. Essentiellement, l’API JSON-RPC est une interface qui nous permet d’écrire des programmes qui utilisent un client Ethereum comme passerelle vers un réseau Ethereum et une chaîne de blocs.

Habituellement, l’interface RPC est proposée en tant que service HTTP sur le port 8545. Pour des raisons de sécurité, il est restreint, par défaut, de n’accepter que les connexions de localhost (l’adresse IP de votre propre ordinateur, qui est 127.0.0.1).

Pour accéder à l’API JSON-RPC, vous pouvez utiliser une bibliothèque spécialisée (écrite dans le langage de programmation de votre choix) qui fournit des appels de fonction "stub" correspondant à chaque commande RPC disponible, ou vous pouvez construire manuellement des requêtes HTTP et envoyer/recevoir des requêtes codées en JSON. Vous pouvez même utiliser un client HTTP de ligne de commande générique, comme curl, pour appeler l’interface RPC. Essayons ça. Tout d’abord, assurez-vous que Geth est opérationnel, configuré avec --rpc pour autoriser l’accès HTTP à l’interface RPC, puis passez à une nouvelle fenêtre de terminal (par exemple, avec Ctrl-Maj-N ou Ctrl-Maj-T dans un fenêtre de terminal) comme indiqué ici :

Dans cet exemple, nous utilisons curl pour établir une connexion HTTP à l’adresse http://localhost:8545. Nous exécutons déjà geth, qui propose l’API JSON-RPC en tant que service HTTP sur le port 8545. Nous demandons à curl d’utiliser la commande HTTP POST et d’identifier le contenu en tant que type application/json. Enfin, nous transmettons une requête encodée en JSON en tant que composant data de notre requête HTTP. La majeure partie de notre ligne de commande consiste simplement à configurer curl pour établir correctement la connexion HTTP. La partie intéressante est la commande JSON-RPC que nous émettons :

La requête JSON-RPC est formatée conformément à la https://www.jsonrpc.org/specification [spécification JSON-RPC 2.0]. Chaque demande contient quatre éléments :

La réponse que nous recevons est :

Cela nous indique que l’API JSON-RPC est servie par la version 1.13.4 du client Geth.

Essayons quelque chose d’un peu plus intéressant. Dans l’exemple suivant, nous demandons à l’API JSON-RPC le prix actuel du gaz en wei :

La réponse, 0x430e23400, nous indique que le prix actuel du gaz est de 18 gwei (gigawei ou milliard de wei). Si, comme nous, vous ne pensez pas en hexadécimal, vous pouvez le convertir en décimal sur la ligne de commande avec un petit bash-fu :

L’API JSON-RPC complète peut être étudiée sur le wiki Ethereum.

Tous les portefeuilles mobiles sont des clients distants, car les téléphones intelligents ne disposent pas des ressources adéquates pour exécuter un client Ethereum complet. Les clients légers sont en développement et ne sont pas généralement utilisés pour Ethereum. Dans le cas de Parity, le client léger est marqué "expérimental" et peut être utilisé en exécutant parity avec l’option --light.

Les portefeuilles mobiles populaires incluent les éléments suivants (nous les énumérons simplement à titre d’exemples ; il ne s’agit pas d’une approbation ou d’une indication de la sécurité ou de la fonctionnalité de ces portefeuilles) :

Une variété de portefeuilles et de navigateurs DApp sont disponibles en tant que plug-ins ou extensions de navigateurs Web tels que Chrome et Firefox. Ce sont des clients distants qui s’exécutent dans votre navigateur.

Certains des plus populaires sont MetaMask, Jaxx, MyEtherWallet et MyCrypto.

Le premier et l’étape la plus importante dans la génération de clés consiste à trouver une source sécurisée d’entropie ou de caractère aléatoire. La création d’une clé privée Ethereum consiste essentiellement à choisir un nombre compris entre 1 et 2²⁵⁶. La méthode exacte que vous utilisez pour choisir ce nombre n’a pas d’importance tant qu’elle n’est pas prévisible ou déterministe. Le logiciel Ethereum utilise le générateur de nombres aléatoires du système d’exploitation sous-jacent pour produire 256 bits aléatoires. Habituellement, le générateur de nombres aléatoires du système d’exploitation est initialisé par une source humaine d’aléatoire, c’est pourquoi il peut vous être demandé de remuer votre souris pendant quelques secondes ou d’appuyer sur des touches aléatoires de votre clavier. Une alternative pourrait être le bruit de rayonnement cosmique sur le canal du microphone de l’ordinateur.

Plus précisément, une clé privée peut être n’importe quel nombre différent de zéro jusqu’à un très grand nombre légèrement inférieur à 2²⁵⁶ - un énorme nombre à 78 chiffres, environ 1,158 * 10⁷⁷. Le nombre exact partage les 38 premiers chiffres avec 2²⁵⁶ et est défini comme l’ordre de la courbe elliptique utilisée dans Ethereum (voir La cryptographie à courbe elliptique expliquée). Pour créer une clé privée, nous choisissons au hasard un nombre de 256 bits et vérifions qu’il se trouve dans la plage valide. En termes de programmation, cela est généralement réalisé en introduisant une chaîne encore plus grande de bits aléatoires (collectés à partir d’une source aléatoire sécurisée par cryptographie) dans un algorithme de hachage de 256 bits tel que Keccak-256 ou SHA-256, qui produiront commodément un nombre de 256 bits. Si le résultat est dans la plage valide, nous avons une clé privée appropriée. Sinon, nous réessayons simplement avec un autre nombre aléatoire.

Notez que le processus de génération de clé privée est hors ligne ; il ne nécessite aucune communication avec le réseau Ethereum, ni même aucune communication avec qui que ce soit. En tant que tel, afin de choisir un nombre que personne d’autre ne choisira jamais, il doit être vraiment aléatoire. Si vous choisissez vous-même le numéro, la probabilité que quelqu’un d’autre l’essaie (et s’enfuie ensuite avec votre ether) est trop élevée. Utiliser un mauvais générateur de nombres aléatoires (comme la fonction pseudo-aléatoire rand dans la plupart des langages de programmation) est encore pire, car il est encore plus évident et encore plus facile à reproduire. Tout comme pour les mots de passe des comptes en ligne, la clé privée doit être impossible à deviner. Heureusement, vous n’avez jamais besoin de vous souvenir de votre clé privée, vous pouvez donc adopter la meilleure approche possible pour la choisir : à savoir, le vrai hasard.

Ce qui suit est une clé privée générée aléatoirement affichée au format hexadécimal (256 bits affichés sous la forme de 64 chiffres hexadécimaux, chacun de 4 bits) :

La courbe elliptique cryptographique est un type de cryptographie asymétrique ou cryptographie à clé publique basée sur le problème du logarithme discret exprimé par addition et multiplication sur les points d’une courbe elliptique.

Une visualisation d’une courbe elliptique est un exemple de courbe elliptique, similaire à celle utilisée par Ethereum.

Ethereum utilise une courbe elliptique spécifique et un ensemble de constantes mathématiques, telles que définies dans une norme appelée secp256k1, établie par le National Institute of Standards and Technology (NIST) des États-Unis. La courbe secp256k1 est définie par la fonction suivante, qui produit une courbe elliptique :

Le mod p (modulo nombre premier p) indique que cette courbe est sur un corps fini d’ordre premier p, également écrit comme (𝔽 p), où p = 2²⁵⁶ – 2³² – 2⁹ – 2⁸ – 2⁷ – 2⁶ – 2⁴ – 1, qui est un très grand nombre premier.

Parce que cette courbe est définie sur un champ fini d’ordre premier au lieu de sur les nombres réels, elle ressemble à un motif de points dispersés en deux dimensions, ce qui la rend difficile à visualiser. Cependant, le calcul est identique à celui d’une courbe elliptique sur des nombres réels. A titre d’exemple, Cryptographie sur courbe elliptique: visualisation d’une courbe elliptique sur F(p), avec p=17 montre la même courbe elliptique sur un champ fini beaucoup plus petit d’ordre premier 17, montrant un motif de points sur une grille. La courbe elliptique secp256k1 Ethereum peut être considérée comme un motif beaucoup plus complexe de points sur une grille insondable.

Ainsi, par exemple, ce qui suit est un point Q avec des coordonnées (x,y) qui est un point sur la courbe secp256k1 :

[example_1] montre comment vous pouvez vérifier cela vous-même en utilisant Python. Les variables x et y sont les coordonnées du point Q, comme dans l’exemple précédent. La variable p est l’ordre premier de la courbe elliptique (le premier qui est utilisé pour toutes les opérations modulo). La dernière ligne de Python est l’équation de la courbe elliptique (l’opérateur % en Python est l’opérateur modulo). Si x et y sont bien les coordonnées d’un point sur la courbe elliptique, alors elles satisfont l’équation et le résultat est zéro (0L est un entier long valant zéro). Essayez vous-même, en tapant python sur une ligne de commande et en copiant chaque ligne (après l’invite + >>> +)de la liste.

Beaucoup de mathématiques sur les courbes elliptiques ressemblent beaucoup à l’arithmétique des nombres entiers que nous avons apprise à l’école. Plus précisément, nous pouvons définir un opérateur d’addition qui, au lieu de sauter le long de la droite numérique, saute vers d’autres points de la courbe. Une fois que nous avons l’opérateur d’addition, nous pouvons également définir la multiplication d’un point et d’un nombre entier, ce qui équivaut à une addition répétée.

L’addition de courbe elliptique est définie de telle sorte que, étant donné deux points P₁ et P₂ sur la courbe elliptique, il existe un troisième point P₃ = P₁ + P₂, également sur la courbe elliptique.

Géométriquement, ce troisième point P₃ est calculé en traçant une ligne entre P₁ et P₂. Cette ligne coupera la courbe elliptique exactement à un endroit supplémentaire (étonnamment). Appelez ce point P₃' = (x, y). Réfléchissez ensuite sur l’axe des x pour obtenir P₃ = (x, –y).

Si P₁ et P₂ sont au même point, la ligne "entre" P₁ et P₂ devrait s’étendre pour être la tangente à la courbe en ce point P₁. Cette tangente coupera la courbe exactement en un nouveau point. Vous pouvez utiliser des techniques de calcul pour déterminer la pente de la ligne tangente. Curieusement, ces techniques fonctionnent, même si nous restreignons notre intérêt aux points de la courbe à deux coordonnées entières !

Dans les mathématiques des courbes elliptiques, il existe également un point appelé "point à l’infini", qui correspond à peu près au rôle du nombre zéro en addition. Sur les ordinateurs, il est parfois représenté par x = y = 0 (ce qui ne satisfait pas l’équation de la courbe elliptique, mais c’est un cas séparé facile qui peut être vérifié). Il y a quelques cas particuliers qui expliquent la nécessité du point à l’infini.

Dans certains cas (par exemple, si P₁ et P₂ ont les mêmes valeurs x mais des valeurs y différentes), la ligne sera exactement verticale, auquel cas P₃ = le point à l’infini.

Si P₁ est le point à l’infini, alors P₁ + P₂ = P₂. De même, si P₂ est le point à l’infini, alors P₁ + P₂ = P₁. Cela montre comment le point à l’infini joue le rôle que joue zéro dans l’arithmétique "normale".

Il s’avère que + est associatif, ce qui signifie que (A + B) + C = A + (B + C). Cela signifie que nous pouvons écrire A + B + C (sans parenthèses) sans ambiguïté.

Maintenant que nous avons défini l’addition, nous pouvons définir la multiplication de la manière standard qui étend l’addition. Pour un point P sur la courbe elliptique, si k est un nombre entier, alors k * P = P + P + P + …​ + P (k fois). Notez que k est parfois (peut-être de manière déroutante) appelé un "exposant" dans ce cas.

Commencer avec une clé privée sous la forme d’un nombre k généré aléatoirement, nous le multiplions par un point prédéterminé sur la courbe appelé point générateur G pour produire un autre point ailleurs sur la courbe, qui est la clé publique correspondante K :

Le point générateur est spécifié dans le cadre de la norme secp256k1 ; c’est la même chose pour toutes les implémentations de secp256k1, et toutes les clés dérivées de cette courbe utilisent le même point G. Comme le point générateur est toujours le même pour tous les utilisateurs d’Ethereum, une clé privée k multipliée par G donnera toujours la même clé publique K. La relation entre k et K est fixe, mais ne peut être calculée que dans un sens, de k vers K. C’est pourquoi une adresse Ethereum (dérivée de K) peut être partagée avec n’importe qui et ne révèle pas la clé privée de l’utilisateur (k).

Comme nous l’avons décrit dans la section précédente, la multiplication de k * G est équivalente à une addition répétée, donc G + G + G + …​ + G, répété k fois. En résumé, pour produire une clé publique K à partir d’une clé privée k, on ajoute le point générateur G à lui-même, k fois.

Appliquons ce calcul pour trouver la clé publique de la clé privée spécifique que nous vous avons montrée dans Clés privées :

Une bibliothèque cryptographique peut nous aider à calculer K, en utilisant la multiplication de courbes elliptiques. La clé publique résultante K est définie comme le point :

où :

Dans Ethereum, vous pouvez voir des clés publiques représentées par une sérialisation de 130 caractères hexadécimaux (65 octets ). Ceci est adopté à partir d’un format de sérialisation standard proposé par le consortium industriel Standards for Efficient Cryptography Group (SECG), documenté dans http://www.secg.org/sec1-v2.pdf [Standards for Efficient Cryptography (SEC1)]. La norme définit quatre préfixes possibles pouvant être utilisés pour identifier des points sur une courbe elliptique, répertoriés dans Préfixes de clé publique EC sérialisés.

Ethereum utilise uniquement des clés publiques non compressées ; par conséquent, le seul préfixe pertinent est (hex) 04. La sérialisation concatène les coordonnées x et y de la clé publique :

Par conséquent, la clé publique que nous avons calculée précédemment est sérialisée comme suit :

Il existe quelques implémentations de la courbe elliptique secp256k1 qui sont utilisées dans les projets liés à la cryptomonnaie :

Ethereum utilise le hachage cryptographique Keccak-256 dans de nombreux endroits. Keccak-256 a été conçu comme candidat pour le SHA-3 Cryptographic Hash Function Competition organisé en 2007 par le National Institute of Science and Technology (NIST). Keccak était l’algorithme gagnant, qui a été normalisé en tant que Federal Information Processing Standard (FIPS) 202 en 2015.

Cependant, pendant la période de développement d’Ethereum, la normalisation du NIST n’était pas encore finalisée. Le NIST a ajusté certains des paramètres de Keccak après l’achèvement du processus de normalisation, prétendument pour améliorer son efficacité. Cela se produisait en même temps que le dénonciateur héroïque Edward Snowden a révélé des documents qui impliquent que le NIST pourrait avoir été indûment influencé par la National Security Agency (NSA) pour affaiblir intentionnellement la norme de générateur de nombres aléatoires Dual_EC_DRBG, plaçant effectivement une porte dérobée dans le générateur de nombres aléatoires standard. Le résultat de cette controverse a été une réaction violente contre les modifications proposées et un retard important dans la normalisation de SHA-3. À l’époque, la Fondation Ethereum a décidé d’implémenter l’algorithme Keccak original, tel que proposé par ses inventeurs, plutôt que la norme SHA-3 telle que modifiée par le NIST.

Comment pouvez-vous savoir si la bibliothèque de logiciels que vous utilisez implémente FIPS-202 SHA-3 ou Keccak-256, si les deux pouvaient s’appeler "SHA-3" ?

Un moyen simple de le dire est d’utiliser un vecteur de test, une sortie attendue pour une entrée donnée. Le test le plus couramment utilisé pour une fonction de hachage est l' entrée vide. Si vous exécutez la fonction de hachage avec une chaîne vide en entrée, vous devriez voir les résultats suivants :

Quel que soit le nom de la fonction, vous pouvez la tester pour voir s’il s’agit du Keccak-256 d’origine ou de la norme NIST finale FIPS-202 SHA-3 en exécutant ce test simple. N’oubliez pas qu’Ethereum utilise Keccak-256, même s’il est souvent appelé SHA-3 dans le code.

Examinons ensuite la première application de Keccak-256 dans Ethereum, qui consiste à produire des adresses Ethereum à partir de clés publiques.

Les adresses Ethereum sont des nombres hexadécimaux, des identifiants dérivés des 20 derniers octets du hachage Keccak-256 de la clé publique.

("somme de contrôle","dans les formats d’adresses Ethereum"Contrairement aux adresses Bitcoin, qui sont encodées dans l’interface utilisateur de tous les clients pour inclure une somme de contrôle intégrée pour se protéger contre les adresses mal saisies, les adresses Ethereum sont présentées sous forme hexadécimale brute sans aucune somme de contrôle.

La justification de cette décision était que les adresses Ethereum seraient éventuellement cachées derrière des abstractions (telles que les services de noms) aux couches supérieures du système et que des sommes de contrôle devraient être ajoutées aux couches supérieures si nécessaire.

En réalité, ces couches supérieures ont été développées trop lentement et ce choix de conception a entraîné un certain nombre de problèmes dans les premiers jours de l’écosystème, notamment la perte de fonds en raison d’adresses mal saisies et d’erreurs de validation des entrées. De plus, comme les services de noms Ethereum ont été développés plus lentement que prévu initialement, les encodages alternatifs ont été adoptés très lentement par les développeurs de portefeuilles. Nous examinerons ensuite quelques-unes des options d’encodage.

Le client Inter exchange Address Protocol (ICAP) est un codage d’adresse Ethereum partiellement compatible avec le International Bank Account Number (IBAN), offrant un encodage polyvalent, à somme de contrôle et interopérable pour les adresses Ethereum. Les adresses ICAP peuvent encoder des adresses Ethereum ou des noms communs enregistrés auprès d’un registre de noms Ethereum. Vous pouvez en savoir plus sur ICAP sur Ethereum Wiki.

L’IBAN est une norme internationale d’identification des numéros de compte bancaire, principalement utilisée pour les virements électroniques. Il est largement adopté dans l’espace européen unique de paiements en euros (SEPA) et au-delà. L’IBAN est un service centralisé et fortement réglementé. ICAP est une implémentation décentralisée mais compatible pour les adresses Ethereum.

Un IBAN consiste en une chaîne de 34 caractères alphanumériques au maximum (insensible à la casse) comprenant un code pays, une somme de contrôle et un identifiant de compte bancaire (qui est spécifique au pays).

ICAP utilise la même structure en introduisant un code de pays non standard, "XE", qui signifie "Ethereum", suivi d’une somme de contrôle à deux caractères et de trois variantes possibles d’un identifiant de compte :

Nous pouvons utiliser l’outil de ligne de commande helpeth pour créer des adresses ICAP. Vous pouvez obtenir de l’aide en l’installant avec :

Si vous n’avez pas npm, vous devrez peut-être d’abord installer nodeJS, ce que vous pouvez faire en suivant les instructions sur https://nodeJS.org.

Maintenant que nous avons helpeth, essayons de créer une adresse ICAP avec notre exemple de clé privée (préfixée par 0x et passée en paramètre à helpeth).

La commande helpeth construit une adresse Ethereum hexadécimale ainsi qu’une adresse ICAP pour nous. L’adresse ICAP de notre exemple de clé est :

Étant donné que notre exemple d’adresse Ethereum commence par un octet zéro, il peut être encodé à l’aide de la méthode d’encodage Direct ICAP qui est valide au format IBAN. Vous pouvez le dire car il comporte 33 caractères.

Si notre adresse ne commençait pas par un zéro, elle serait encodée avec l’encodage Basic, qui comporterait 35 caractères et serait invalide en tant qu’IBAN.

À l’heure actuelle, ICAP n’est malheureusement pris en charge que par quelques portefeuilles.

En raison de la lenteur du déploiement d’ICAP et des services de noms, une norme a été proposée par la Proposition d’amélioration d’Ethereum 55 (EIP-55). EIP-55 offre une somme de contrôle rétrocompatible pour les adresses Ethereum en modifiant la capitalisation de l’adresse hexadécimale. L’idée est que les adresses Ethereum sont insensibles à la casse et que tous les portefeuilles sont censés accepter les adresses Ethereum exprimées en majuscules ou en minuscules, sans aucune différence d’interprétation.

En modifiant la capitalisation des caractères alphabétiques dans l’adresse, nous pouvons transmettre une somme de contrôle qui peut être utilisée pour protéger l’intégrité de l’adresse contre les erreurs de frappe ou de lecture. Les portefeuilles qui ne prennent pas en charge les sommes de contrôle EIP-55 ignorent simplement le fait que l’adresse contient des majuscules mixtes, mais ceux qui la prennent en charge peuvent la valider et détecter les erreurs avec une précision de 99,986 %.

L’encodage en majuscules mixtes est subtil et vous ne le remarquerez peut-être pas au début. Notre exemple d’adresse est :

Avec une somme de contrôle à capitalisation mixte EIP-55, cela devient :

Pouvez-vous faire la différence ? Certains des caractères alphabétiques (A à F) de l’alphabet de codage hexadécimal sont désormais en majuscules, tandis que d’autres sont en minuscules.

EIP-55 est assez simple à mettre en œuvre. Nous prenons le hachage Keccak-256 de l’adresse hexadécimale minuscule. Ce hachage agit comme une empreinte numérique de l’adresse, nous donnant une somme de contrôle pratique. Tout petit changement dans l’entrée (l’adresse) devrait entraîner un grand changement dans le hachage résultant (la somme de contrôle), nous permettant de détecter efficacement les erreurs. Le hachage de notre adresse est ensuite encodé dans la capitalisation de l’adresse elle-même. Décomposons-le, étape par étape :

Notre adresse contient un caractère alphabétique d en quatrième position. Le quatrième caractère du hachage est 6, qui est inférieur à 8. Donc, nous laissons le d minuscule. Le prochain caractère alphabétique de notre adresse est f, en sixième position. Le sixième caractère du hachage hexadécimal est c, qui est supérieur à 8. Par conséquent, nous capitalisons le F dans l’adresse, et ainsi de suite. Comme vous pouvez le voir, nous n’utilisons que les 20 premiers octets (40 caractères hexadécimaux) du hachage comme somme de contrôle, car nous n’avons que 20 octets (40 caractères hexadécimaux) dans l’adresse à capitaliser de manière appropriée.

Vérifiez vous-même l’adresse en majuscules mixtes résultante et voyez si vous pouvez dire quels caractères ont été en majuscules et à quels caractères ils correspondent dans le hachage de l’adresse :

Dans le premier portefeuille Ethereum (produit pour la prévente Ethereum), chaque fichier de portefeuille stockait une seule clé privée générée aléatoirement. Ces portefeuilles sont remplacés par des portefeuilles déterministes car ces portefeuilles "à l’ancienne" sont à bien des égards inférieurs. Par exemple, il est considéré comme une bonne pratique d’éviter la réutilisation de l’adresse Ethereum dans le cadre de la maximisation de votre vie privée lors de l’utilisation d’Ethereum, c’est-à-dire d’utiliser une nouvelle adresse (qui nécessite une nouvelle clé privée) chaque fois que vous recevez des fonds. Vous pouvez aller plus loin et utiliser une nouvelle adresse pour chaque transaction, bien que cela puisse coûter cher si vous traitez beaucoup de jetons. Pour suivre cette pratique, un portefeuille non déterministe devra régulièrement augmenter sa liste de clés, ce qui signifie que vous devrez effectuer des sauvegardes régulières. Si jamais vous perdez vos données (panne de disque, accident d’abus de boisson, vol de téléphone) avant d’avoir réussi à sauvegarder votre portefeuille, vous perdrez l’accès à vos fonds et à vos contrats intelligents. Les portefeuilles non déterministes de "type 0" sont les plus difficiles à gérer, car ils créent un nouveau fichier de portefeuille pour chaque nouvelle adresse de manière "juste à temps".

Néanmoins, de nombreux clients Ethereum (y compris geth)utilisent un fichier keystore ou magasin de clés, qui est un fichier codé JSON contenant une clé privée unique (générée de manière aléatoire), chiffrée par une phrase secrète pour plus de sécurité . Le contenu du fichier JSON ressemble à ceci :

Le format de magasin de clés utilise une fonction de dérivation de clé (KDF ou key derivation function), également connue sous le nom d’algorithme d’étirement de mot de passe, qui protège contre les attaques par force, par dictionnaire et par table arc-en-ciel. En termes simples, la clé privée n’est pas chiffrée directement par la phrase secrète. Au lieu de cela, la phrase secrète est étirée, en la hachant à plusieurs reprises. La fonction de hachage est répétée pendant 262 144 tours, ce qui peut être vu dans le magasin de clés JSON sous la forme du paramètre crypto.kdfparams.n. Un attaquant essayant de forcer brutalement la phrase secrète devrait appliquer 262 144 cycles de hachage pour chaque phrase secrète tentée, ce qui ralentit suffisamment l’attaque pour la rendre impossible pour les phrases secrètes d’une complexité et d’une longueur suffisantes.

Il existe un certain nombre de bibliothèques logicielles qui peuvent lire et écrire le format keystore, comme la bibliothèque JavaScript keythereum.

Les portefeuilles déterministes ou "ensemencés par valeurs d’amorçages" sont des portefeuilles qui contiennent des clés privées qui sont toutes dérivées d’une seule clé maîtresse ou valeur d’amorçage. La valeur d’amorçage est un nombre généré aléatoirement qui est combiné avec d’autres données, telles qu’un numéro d’index ou un "code de chaîne" (voir Clés publiques et privées étendues), pour dériver n’importe quel nombre de clés privées. Dans un portefeuille déterministe, la valeur d’amorçage est suffisante pour récupérer toutes les clés dérivées, et donc une seule sauvegarde, au moment de la création, est suffisante pour sécuriser tous les fonds et contrats intelligents dans le portefeuille. La valeur d’amorçage est également suffisante pour une exportation ou une importation de portefeuille, permettant une migration facile de toutes les clés entre différentes implémentations de portefeuille.

Cette conception rend la sécurité de la valeur d’amorçage d’une plus haute importance, car seule la valeur d’amorçage est nécessaire pour accéder à l’ensemble du portefeuille. D’un autre côté, le fait de pouvoir concentrer les efforts de sécurité sur une seule donnée peut être considéré comme un avantage.

Les portefeuilles déterministes ont été développés pour faciliter la dérivation de nombreuses clés à partir d’une seule valeur d’amorçage. Actuellement, la forme la plus avancée de portefeuille déterministe est le portefeuille hiérarchique déterministe (HD ou Hierarchical Deterministic) défini par le standard BIP-32 de Bitcoin. Les portefeuilles HD contiennent des clés dérivées dans une structure arborescente, de sorte qu’une clé parent peut dériver une séquence de clés enfants, chacune pouvant dériver une séquence de clés petits-enfants, et ainsi de suite. Cette arborescence est illustrée dans Portefeuille HD : un arbre de clés généré à partir d’une seule valeur d’amorçage.

Les portefeuilles HD offrent quelques avantages clés par rapport aux portefeuilles déterministes plus simples. Tout d’abord, la structure arborescente peut être utilisée pour exprimer une signification organisationnelle supplémentaire, par exemple lorsqu’une branche spécifique de sous-clés est utilisée pour recevoir des paiements entrants et qu’une branche différente est utilisée pour recevoir la monnaie des paiements sortants. Les branches de clés peuvent également être utilisées dans les paramètres de l’entreprise, en attribuant différentes branches à des départements, des filiales, des fonctions spécifiques ou des catégories comptables.

Le deuxième avantage des portefeuilles HD est que les utilisateurs peuvent créer une séquence de clés publiques sans avoir accès aux clés privées correspondantes. Cela permet aux portefeuilles HD d’être utilisés sur un serveur non sécurisé ou dans une capacité de surveillance ou de réception uniquement, où le portefeuille n’a pas les clés privées qui peuvent dépenser les fonds.

Il y a beaucoup de manières d’encoder une clé privée pour une sauvegarde et une récupération sécurisées. La méthode actuellement préférée consiste à utiliser une séquence de mots qui, lorsqu’ils sont pris ensemble dans le bon ordre, peuvent recréer de manière unique la clé privée. Ceci est parfois connu sous le nom de mnémonique, et l’approche a été normalisée par BIP-39. Aujourd’hui, de nombreux portefeuilles Ethereum (ainsi que des portefeuilles pour d’autres crypto-monnaies) utilisent cette norme et peuvent importer et exporter des valeurs d’amorçage pour la sauvegarde et la récupération à l’aide de mnémoniques interopérables.

Pour comprendre pourquoi cette approche est devenue populaire, examinons un exemple :

En termes pratiques, le risque d’erreur lors de l’écriture de la séquence hexadécimale est inacceptablement élevé. En revanche, la liste des mots connus est assez facile à gérer, principalement parce qu’il y a une forte redondance dans l’écriture des mots (surtout des mots anglais). Si « inzect » avait été enregistré par accident, il pourrait être rapidement déterminé, lors de la récupération du portefeuille, que « inzect » n’est pas un mot anglais valide et que « insect » devrait être utilisé à la place. Nous parlons d’écrire une représentation de la valeur d’amorçage car c’est une bonne pratique lors de la gestion des portefeuilles HD : la valeur d’amorçage est nécessaire pour récupérer un portefeuille en cas de perte de données (que ce soit par accident ou par vol), il est donc très prudent de conserver une sauvegarde. Cependant, la valeur d’amorçage doit rester extrêmement privée, les sauvegardes numériques doivent donc être soigneusement évitées ; d’où le conseil précédent de sauvegarder avec un stylo et du papier.

En résumé, l’utilisation d’une liste de mots de récupération pour coder la valeur d’amorçage d’un portefeuille HD constitue le moyen le plus simple d’exporter, de transcrire, d’enregistrer sur papier en toute sécurité, de lire sans erreur et d’importer un ensemble de clés privées dans un autre portefeuille.

Les mots de code mnémoniques sont des séquences de mots qui encodent un nombre aléatoire utilisé comme valeur d’amorçage pour dériver un portefeuille déterministe. La séquence de mots est suffisante pour recréer la valeur d’amorçage, et à partir de là recréer le portefeuille et toutes les clés dérivées. Une application de portefeuille qui implémente des portefeuilles déterministes avec des mots mnémoniques montrera à l’utilisateur une séquence de 12 à 24 mots lors de la première création d’un portefeuille. Cette séquence de mots est la sauvegarde du portefeuille et peut être utilisée pour récupérer et recréer toutes les clés dans la même application de portefeuille ou dans n’importe quelle application de portefeuille compatible. Comme nous l’avons expliqué précédemment, les listes de mots mnémoniques facilitent la sauvegarde des portefeuilles par les utilisateurs, car elles sont faciles à lire et correctement transcrire.

Les codes mnémoniques sont définis dans le BIP-39. Notez que BIP-39 est une implémentation d’une norme de code mnémonique. Il existe une norme différente, avec un ensemble de mots différent, utilisée par le portefeuille Electrum Bitcoin et antérieure à BIP-39. BIP-39 a été proposé par la société à l’origine du portefeuille matériel Trezor et est incompatible avec la mise en œuvre d’Electrum. Cependant, BIP-39 a maintenant obtenu un large soutien de l’industrie à travers des dizaines d’implémentations interopérables et devrait être considéré comme la norme de facto industrielle. De plus, BIP-39 peut être utilisé pour produire des portefeuilles multidevises prenant en charge Ethereum, contrairement aux valeurs d’amorçage Electrum.

La BIP-39 définit la création d’un code mnémonique et d’une valeur d’amorçage, que nous décrivons ici en neuf étapes. Pour plus de clarté, le processus est divisé en deux parties : les étapes 1 à 6 sont présentées dans Génération de mots mnémoniques et les étapes 7 à 9 sont illustrées dans Du mnémonique à la valeur d’amorçage.

Les portefeuilles HD sont créés à partir d’une seule valeur d’amorçage racine, qui est un nombre aléatoire de 128, 256 ou 512 bits. Le plus souvent, cette valeur d’amorçage est générée à partir d’un mnémonique comme détaillé dans la section précédente.

Chaque clé du portefeuille HD est dérivée de manière déterministe de cette valeur d’amorçage racine, ce qui permet de recréer l’intégralité du portefeuille HD à partir de cette valeur d’amorçage dans n’importe quel portefeuille HD compatible. Cela facilite l’exportation, la sauvegarde, la restauration et l’importation de portefeuilles HD contenant des milliers, voire des millions de clés en transférant uniquement le mnémonique à partir duquel la valeur d’amorçage racine est dérivée.

La plupart des portefeuilles HD suivent le Standard BIP-32, qui est devenu un standard industriel de facto pour la génération de clé déterministe.

Nous ne discuterons pas de tous les détails du BIP-32 ici, seulement des composants nécessaires pour comprendre comment il est utilisé dans les portefeuilles. Le principal aspect important est les relations hiérarchiques arborescentes qu’il est possible que les clés dérivées aient, comme vous pouvez le voir dans Portefeuille HD : un arbre de clés généré à partir d’une seule valeur d’amorçage. Il est également important de comprendre les notions de clés étendues et clés renforcées, qui sont expliquées dans les sections suivantes.

Il existe des dizaines d’implémentations interopérables de BIP-32 proposées dans de nombreuses bibliothèques de logiciels. Ceux-ci sont principalement conçus pour les portefeuilles Bitcoin, qui implémentent les adresses d’une manière différente, mais partagent la même implémentation de dérivation de clé que les portefeuilles compatibles BIP-32 d’Ethereum. Utilisez-en un https://github.com/ConsenSys/eth-lightwallet [conçu pour Ethereum], ou adaptez-en un à partir de Bitcoin en ajoutant une bibliothèque d’encodage d’adresses Ethereum.

Il existe également un générateur BIP-32 implémenté sous la forme d’une page Web autonome qui est très utile pour tester et expérimenter avec BIP-32.

En termes pratiques, le nonce est un décompte à jour du nombre de transactions confirmées (c’est-à-dire en chaîne) provenant d’un compte. Pour savoir ce qu’est le nonce, vous pouvez interroger la chaîne de blocs, par exemple via l’interface web3. Ouvrez une console JavaScript dans Geth (ou votre interface web3 préférée) sur Ropsten testnet, puis tapez :

Votre portefeuille gardera une trace des nonces pour chaque adresse qu’il gère. C’est assez simple à faire, tant que vous n’effectuez des transactions qu’à partir d’un seul point. Disons que vous écrivez votre propre logiciel de portefeuille ou une autre application qui génère des transactions. Comment suivre les nonces ?

Lorsque vous créez une nouvelle transaction, vous affectez le nonce suivant dans la séquence. Mais jusqu’à ce qu’il soit confirmé, il ne comptera pas dans le total getTransactionCount.

Regardons un exemple :

Comme vous pouvez le voir, la première transaction que nous avons envoyée a augmenté le nombre de transactions à 41, indiquant la transaction en attente. Mais lorsque nous avons envoyé trois autres transactions en succession rapide, l’appel getTransactionCount ne les a pas comptées. Il n’en comptait qu’un, même si vous vous attendiez à ce qu’il y en ait trois en attente dans le mempool. Si nous attendons quelques secondes pour permettre aux communications réseau de s’établir, l’appel getTransactionCount renverra le nombre attendu. Mais dans l’intervalle, bien qu’il y ait plus d’une transaction en attente, cela pourrait ne pas nous aider.

Lorsque vous construisez une application qui construit des transactions, elle ne peut pas s’appuyer sur getTransactionCount pour les transactions en attente. Ce n’est que lorsque les nombres en attente et confirmés sont égaux (toutes les transactions en attente sont confirmées) que vous pouvez faire confiance à la sortie de getTransactionCount pour démarrer votre compteur de nonce. Par la suite, gardez une trace du nonce dans votre application jusqu’à ce que chaque transaction soit confirmée.

L’interface JSON RPC de Parity propose la fonction parity_nextNonce, qui renvoie le prochain nonce à utiliser dans une transaction. La fonction parity_nextNonce compte correctement les nonces, même si vous construisez plusieurs transactions en succession rapide sans les confirmer :

Il est important de garder une trace des nonces si vous créez des transactions par programmation, surtout si vous le faites à partir de plusieurs processus indépendants simultanément.

Le réseau Ethereum traite les transactions de manière séquentielle, sur la base du nonce. Cela signifie que si vous transmettez une transaction avec nonce 0, puis transmettez une transaction avec nonce 2, la deuxième transaction ne sera incluse dans aucun bloc. Il sera stocké dans le mempool, pendant que le réseau Ethereum attend que le nonce manquant apparaisse. Tous les nœuds supposeront que le nonce manquant a simplement été retardé et que la transaction avec le nonce 2 a été reçue dans le désordre.

Si vous transmettez ensuite une transaction avec le nonce 1 manquant, les deux transactions (nonces 1 et 2) seront traitées et incluses (si elles sont valides, bien sûr). Une fois que vous avez comblé le vide, le réseau peut exploiter la transaction hors séquence qu’il a conservée dans le mempool.

Cela signifie que si vous créez plusieurs transactions en séquence et que l’une d’entre elles n’est officiellement incluse dans aucun bloc, toutes les transactions suivantes seront "bloquées", en attendant le nonce manquant. Une transaction peut créer un "écart" par inadvertance dans la séquence nonce car elle n’est pas valide ou n’a pas suffisamment de gaz. Pour que les choses bougent à nouveau, vous devez transmettre une transaction valide avec le nonce manquant. Vous devez également garder à l’esprit qu’une fois qu’une transaction avec le nonce "manquant" est validée par le réseau, toutes les transactions de diffusion avec les nonces suivants deviendront progressivement valides ; il n’est pas possible de "rappeler" une transaction !

Si, en revanche, vous dupliquez accidentellement un nonce, par exemple en transmettant deux transactions avec le même nonce mais différents destinataires ou valeurs, l’un d’entre eux sera confirmé et l’autre sera rejeté. Celui qui est confirmé sera déterminé par la séquence dans laquelle ils arrivent au premier nœud de validation qui les reçoit, c’est-à-dire que ce sera assez aléatoire.

Comme vous pouvez le constater, le suivi des nonces est nécessaire, et si votre application ne gère pas correctement ce processus, vous rencontrerez des problèmes. Malheureusement, les choses deviennent encore plus difficiles si vous essayez de le faire simultanément, comme nous le verrons dans la section suivante.

La concurrence est un aspect complexe de l’informatique, et il apparaît parfois de manière inattendue, en particulier dans les systèmes en temps réel décentralisés et distribués comme Ethereum.

En termes simples, la concurrence est lorsque vous avez un calcul simultané par plusieurs systèmes indépendants. Ceux-ci peuvent se trouver dans le même programme (par exemple, multithreading), sur le même processeur (par exemple, multitraitement) ou sur différents ordinateurs (c’est-à-dire, systèmes distribués). Ethereum, par définition, est un système qui permet la simultanéité des opérations (nœuds, clients, DApps) mais applique un état singleton par consensus.

Maintenant, imaginez que vous ayez plusieurs applications de portefeuille indépendantes qui génèrent des transactions à partir de la ou des mêmes adresses. Un exemple d’une telle situation serait un échange traitant des retraits du portefeuille chaud de l’échange (un portefeuille dont les clés sont stockées en ligne, contrairement à un portefeuille froid où les clés ne sont jamais en ligne). Idéalement, vous voudriez avoir plus d’un ordinateur traitant les retraits, afin qu’il ne devienne pas un goulot d’étranglement ou un point de défaillance unique. Cependant, cela devient rapidement problématique, car le fait d’avoir plus d’un ordinateur produisant des retraits entraînera des problèmes épineux de concurrence, dont le moindre n’est pas la sélection des nonces. Comment plusieurs ordinateurs générant, signant et diffusant des transactions à partir du même compte du portefeuille chaud (Hot Wallet) se coordonnent-ils ?

Vous pouvez utiliser un seul ordinateur pour attribuer des nonces, selon le principe du premier arrivé, premier servi, aux ordinateurs signant des transactions. Cependant, cet ordinateur est maintenant un point de défaillance unique. Pire encore, si plusieurs nonces sont attribués et que l’un d’entre eux n’est jamais utilisé (à cause d’une défaillance de l’ordinateur traitant la transaction avec ce nonce), toutes les transactions suivantes restent bloquées.

Une autre approche serait de générer les transactions, mais de ne pas leur attribuer de nonce (et donc de les laisser non signées - rappelez-vous que le nonce fait partie intégrante des données de transaction et doit donc être inclus dans la signature numérique qui authentifie la transaction) . Vous pouvez ensuite les mettre en file d’attente sur un seul nœud qui les signe et garde également une trace des nonces. Encore une fois, cependant, ce serait un point d’étranglement dans le processus : la signature et le suivi des nonces est la partie de votre opération qui est susceptible d’être encombrée sous charge, alors que la génération de la transaction non signée est la partie que vous n’avez pas vraiment besoin de paralléliser. Vous auriez une certaine concurrence, mais il y aurait un manque dans une partie essentielle du processus.

En fin de compte, ces problèmes de simultanéité, en plus de la difficulté de suivre les soldes des comptes et les confirmations de transaction dans des processus indépendants, obligent la plupart des implémentations à éviter la simultanéité et à créer des goulots d’étranglement tels qu’un processus unique gérant toutes les transactions de retrait dans un échange, ou la mise en place de plusieurs des portefeuilles chauds qui peuvent fonctionner de manière totalement indépendante pour les retraits et ne doivent être rééquilibrés que par intermittence.

Lorsque vous construisez une transaction Ethereum qui contient une valeur, c’est l’équivalent d’un paiement. Ces transactions se comportent différemment selon que l’adresse de destination est un contrat ou non.

Pour les adresses EOA, ou plutôt pour toute adresse qui n’est pas signalée comme un contrat sur la chaîne de blocs, Ethereum enregistrera un changement d’état, ajoutant la valeur que vous avez envoyée au solde de l’adresse. Si l’adresse n’a pas été vue auparavant, elle sera ajoutée à la représentation interne de l’état du client et son solde initialisé à la valeur de votre paiement.

Si l’adresse de destination (to)est un contrat, alors l’EVM exécutera le contrat et tentera d’appeler la fonction nommée dans la charge utile de données de votre transaction. S’il n’y a pas de données dans votre transaction, l’EVM appellera une fonction fallback (ou fonction de repli ou par défaut) et, si cette fonction est payante, l’exécutera pour déterminer ce qu’il faut faire ensuite. S’il n’y a pas de code dans la fonction de secours, l’effet de la transaction sera d’augmenter le solde du contrat, exactement comme un paiement sur un portefeuille. S’il n’y a pas de fonction de secours ou de fonction de secours non payante, la transaction sera annulée.

Un contrat peut rejeter les paiements entrants en levant une exception immédiatement lorsqu’une fonction est appelée, ou tel que déterminé par des conditions codées dans une fonction. Si la fonction se termine avec succès (sans exception), l’état du contrat est mis à jour pour refléter une augmentation du solde d’ether du contrat.

Lorsque votre transaction contient des données, elle est très probablement adressée à une adresse de contrat. Cela ne signifie pas que vous ne pouvez pas envoyer une charge utile de données à un EOA, ce qui est tout à fait valide dans le protocole Ethereum. Cependant, dans ce cas, l’interprétation des données dépend du portefeuille que vous utilisez pour accéder à l’EOA. Il est ignoré par le protocole Ethereum. La plupart des portefeuilles ignorent également toutes les données reçues lors d’une transaction vers un EOA qu’ils contrôlent. À l’avenir, il est possible que des normes émergent qui permettent aux portefeuilles d’interpréter les données comme le font les contrats, permettant ainsi aux transactions d’invoquer des fonctions exécutées à l’intérieur des portefeuilles des utilisateurs. La différence essentielle est que toute interprétation de la charge utile de données par un EOA n’est pas soumise aux règles de consensus d’Ethereum, contrairement à un contrat exécution.

Pour l’instant, supposons que votre transaction envoie des données à une adresse contractuelle. Dans ce cas, les données seront interprétées par l’EVM comme une invocation de contrat. La plupart des contrats utilisent ces données plus spécifiquement comme invocation de fonction, appelant la fonction nommée et transmettant tous les arguments codés à la fonction.

La charge utile de données envoyée à un contrat compatible ABI (dont vous pouvez supposer que tous les contrats le sont) est un codage hexadécimal de :

Dans Faucet.sol: Un contrat Solidity mettant en place un robinet, nous avons défini une fonction pour les retraits :

Le prototype d’une fonction est défini comme la chaîne contenant le nom de la fonction, suivi des types de données de chacun de ses arguments, entre parenthèses et séparés par des virgules. Le nom de la fonction ici est withdraw et il prend un seul argument qui est un uint (qui est un alias pour uint256), donc le prototype de withdraw serait :

Calculons le hachage Keccak-256 de cette chaîne :

Les 4 premiers octets du hachage sont 0x2e1a7d4d. C’est notre valeur "sélecteur de fonction", qui indiquera au contrat quelle fonction nous voulons appeler.

Ensuite, calculons une valeur à passer comme argument withdraw_amount. Nous voulons retirer 0,01 ether. Encodons cela en un entier 256 bits non signé gros-boutiste hexa-sérialisé, libellé en wei :

Maintenant, nous ajoutons le sélecteur de fonction au montant (rembourré à 32 octets) :

C’est la charge utile de données pour notre transaction, appelant la fonction withdraw et demandant 0,01 éther comme withdraw_amount.

L’algorithme de signature numérique utilisé dans Ethereum est l'Elliptic Curve Digital Signature Algorithm ( ECDSA). Il est basé sur des paires de clés privées-publiques à courbe elliptique, comme décrit dans La cryptographie à courbe elliptique expliquée.

Une signature numérique sert trois objectifs dans Ethereum (voir l’encadré suivant). Premièrement, la signature prouve que le propriétaire de la clé privée, qui est implicitement le propriétaire d’un compte Ethereum, a autorisé la dépense d’ether ou l’exécution d’un contrat. Deuxièmement, il garantit la non-répudiation : la preuve de l’autorisation est indéniable. Troisièmement, la signature prouve que les données de transaction n’ont pas été et ne peuvent pas être modifiées par quiconque après la signature de la transaction.

Une signature numérique est un schéma mathématique composé de deux parties. La première partie est un algorithme de création d’une signature, à l’aide d’une clé privée (la clé de signature), à partir d’un message (qui dans notre cas est la transaction). La deuxième partie est un algorithme qui permet à quiconque de vérifier la signature en utilisant uniquement le message et une clé publique.

Pour vérifier la signature, il faut avoir la signature (r et s), la transaction sérialisée et la clé publique qui correspond à la clé privée utilisée pour créer la signature. Essentiellement, la vérification d’une signature signifie que "seul le propriétaire de la clé privée qui a généré cette clé publique pourrait avoir produit cette signature sur cette transaction".

L’algorithme de vérification de signature prend le message (c’est-à-dire, un hachage de la transaction pour notre usage), la clé publique du signataire et la signature (valeurs r et s), et renvoie true si la signature est valide pour ce message et la clé publique .

Comme mentionné précédemment, les signatures sont créées par une fonction mathématique F_sig qui produit une signature composée de deux valeurs, r et s. Dans cette section, nous examinons la fonction F_sig plus en détail.

L’algorithme de signature génère d’abord une clé privée éphémère (temporaire) de manière cryptographiquement sécurisée. Cette clé temporaire est utilisée dans le calcul des valeurs r et s pour s’assurer que la clé privée réelle de l’expéditeur ne peut pas être calculée par des attaquants qui surveillent les transactions signées sur le réseau Ethereum.

Comme nous le savons depuis Clés publiques, la clé privée éphémère est utilisée pour dériver la clé publique (éphémère) correspondante, nous avons donc :

La valeur r de la signature numérique est alors la coordonnée x de la clé publique éphémère Q.

A partir de là, l’algorithme calcule la valeur s de la signature, telle que :

où :

La vérification est l’inverse de la fonction de génération de signature, utilisant les valeurs r et s et la clé publique de l’expéditeur pour calculer une valeur Q, qui est un point sur la courbe elliptique (la clé publique éphémère utilisée dans la création de la signature). Les étapes sont les suivantes:

où :

Si la coordonnée x du point calculé Q est égale à r, alors le vérificateur peut conclure que la signature est valide.

Notez qu’en vérifiant la signature, la clé privée n’est ni connue ni révélée.

Pour produire une transaction valide, l’expéditeur doit signer numériquement le message, en utilisant l’algorithme de signature numérique à courbe elliptique. Lorsque nous disons "signer la transaction", nous entendons en fait "signer le hachage Keccak-256 des données de transaction sérialisées RLP". La signature est appliquée au hachage des données de transaction, pas à la transaction elle-même.

Pour signer une transaction dans Ethereum, l’initiateur doit :

La variable de signature spéciale v indique deux choses : l’ID (identifiant) de chaîne et l’identifiant de récupération pour aider la fonction ECDSArecover à vérifier la signature. Il est calculé comme l’un des 27 ou 28, ou comme l’ID de chaîne doublé plus 35 ou 36. Pour plus d’informations sur l’ID de chaîne, voir Création de transactions brutes avec EIP-155. L’identifiant de récupération (27 ou 28 dans les signatures "à l’ancienne", ou 35 ou 36 dans les transactions complètes de type Spurious Dragon) est utilisé pour indiquer la parité du composant y de la clé publique (voir La valeur du préfixe de signature (v) et la récupération de la clé publique pour plus de détails).

Dans cette section, nous allons créer une transaction brute et la signer, en utilisant la bibliothèque ethereumjs-tx, qui peut être installé avec npm. Cela démontre les fonctions qui seraient normalement utilisées dans un portefeuille ou une application qui signe des transactions au nom d’un utilisateur. Le code source de cet exemple se trouve dans le fichier raw_tx_demo.js dans le référentiel GitHub du livre :

L’exécution de l’exemple de code produit les résultats suivants :

La norme EIP-155 "Simple Replay Attack Protection" spécifie un codage de transaction protégé contre les attaques de relecture, qui inclut un identifiant de chaîne dans les données de transaction, avant la signature. Cela garantit que les transactions créées pour une chaîne de blocs (par exemple, le réseau principal Ethereum) sont invalides sur une autre chaîne de blocs (par exemple, Ethereum Classic ou le réseau de test Ropsten). Par conséquent, les transactions diffusées sur un réseau ne peuvent pas être rejouées sur un autre, d’où le nom de la norme.

EIP-155 ajoute trois champs aux six principaux champs de la structure de données de transaction, à savoir l’identifiant de chaîne, 0 et 0. Ces trois champs sont ajoutés aux données de transaction avant qu’elles ne soient encodées et hachées. Ils modifient donc le hash de la transaction, auquel la signature est ensuite appliquée. En incluant l’identifiant de la chaîne dans les données à signer, la signature de la transaction empêche tout changement, car la signature est invalidée si l’identifiant de la chaîne est modifié. Par conséquent, EIP-155 rend impossible la relecture d’une transaction sur une autre chaîne, car la validité de la signature dépend de l’identifiant de la chaîne.

Le champ d’identifiant de chaîne prend une valeur en fonction du réseau auquel la transaction est destinée, comme indiqué dans Identifiants de chaîne.

La structure de transaction résultante est codée RLP, hachée et signée. L’algorithme de signature est légèrement modifié pour encoder également l’identifiant de la chaîne dans le préfixe v.

Pour plus de détails, voir la spécification EIP-155.

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 Les bases d’Ethereum, 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 Les bases d’Ethereum, 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 Les bases d’Ethereum 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 La machine virtuelle Ethereum. 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.

Comme nous l’avons vu dans le chapitre précédent, dans Solidity vous pouvez écrire une fonction à l’aide de modificateurs (modifiers). Par exemple, la fonction suivante, changeOwner, exécutera le code dans un modificateur appelé onlyBy dans le cadre de son exécution :

Ce modificateur applique une règle relative à la propriété. Comme vous pouvez le voir, ce modificateur particulier agit comme un mécanisme pour effectuer une pré-vérification au nom de la fonction changeOwner :

Mais les modificateurs ne sont pas là uniquement pour effectuer des vérifications, comme illustré ici. En fait, en tant que modificateurs, ils peuvent modifier considérablement l’environnement d’un contrat intelligent, dans le contexte de la fonction appelante. En termes simples, les modificateurs sont omniprésents.

Regardons un autre exemple de style Solidity :

D’une part, les développeurs doivent toujours vérifier tout autre code que leur propre code appelle. Cependant, il est possible que dans certaines situations (comme lorsque les contraintes de temps ou l’épuisement entraînent un manque de concentration), un développeur oublie une seule ligne de code. Cela est encore plus probable si le développeur doit se déplacer dans un fichier volumineux tout en gardant mentalement une trace de la hiérarchie des appels de fonction et en mémorisant l’état des variables de contrat intelligent.

Regardons l’exemple précédent un peu plus en profondeur. Imaginez qu’un développeur écrive une fonction publique appelée "a". Le développeur est nouveau dans ce contrat et utilise un modificateur écrit par quelqu’un d’autre. En un coup d’œil, il semble que le modificateur stageTimeConfirmation effectue simplement quelques vérifications concernant l’âge du contrat par rapport à la fonction appelante. Ce que le développeur peut ne pas réaliser, c’est que le modificateur appelle également une autre fonction, nextStage. Dans ce scénario de démonstration simpliste, le simple fait d’appeler la fonction publique "a" entraîne le déplacement de la variable "stage" du contrat intelligent de "SafeStage" à "DangerStage".

Vyper a complètement supprimé les modificateurs. Les recommandations de Vyper sont les suivantes : si vous n’exécutez que des assertions avec des modificateurs, utilisez simplement des vérifications et des assertions en ligne dans le cadre de la fonction ; si vous modifiez l’état du contrat intelligent, etc., intégrez à nouveau ces modifications explicitement à la fonction. Cela améliore l’auditabilité et la lisibilité, car le lecteur n’a pas à "envelopper" mentalement (ou manuellement) le code du modificateur autour de la fonction pour voir ce qu’elle fait.

L’héritage permet aux programmeurs pour exploiter la puissance du code pré-écrit en acquérant des fonctionnalités, des propriétés et des comportements préexistants à partir de bibliothèques de logiciels existantes. L’héritage est puissant et favorise la réutilisation du code. Solidity prend en charge l’héritage multiple ainsi que le polymorphisme, mais bien que ce soient des fonctionnalités clés de la programmation orientée objet, Vyper ne les prend pas en charge. Vyper soutient que la mise en œuvre de l’héritage nécessite que les codeurs et les auditeurs sautent entre plusieurs fichiers afin de comprendre ce que fait le programme. Vyper considère également que l’héritage multiple peut rendre le code trop compliqué à comprendre - un point de vue tacitement admis par la documentation Solidity, qui donne un exemple de la façon dont l’héritage multiple peut être problématique.

L’assemblage en ligne donne aux développeurs un accès de bas niveau à Ethereum Virtual Machine, permettant aux programmes Solidity d’effectuer des opérations en accédant directement aux instructions EVM. Par exemple, le code assembleur en ligne suivant ajoute 3 à l’emplacement mémoire 0x80 :

Vyper considère que la perte de lisibilité est un prix trop élevé à payer pour la puissance supplémentaire et ne prend donc pas en charge l’assemblage en ligne.

La surcharge de fonction permet aux développeurs d’écrire plusieurs fonctions du même nom. La fonction utilisée à une occasion donnée dépend des types d’arguments fournis. Prenons par exemple les deux fonctions suivantes :

La première fonction (nommée f)accepte un argument d’entrée de type uint ; la deuxième fonction (également nommée f)accepte deux arguments, un de type uint et un de type bytes32. Avoir plusieurs définitions de fonction avec le même nom prenant des arguments différents peut être déroutant, donc Vyper ne prend pas en charge la surcharge de fonction.

Il existe deux types de typage : implicite et explicite

Le transtypage implicite est souvent effectué au moment de la compilation. Par exemple, si une conversion de type est sémantiquement correcte et qu’aucune information n’est susceptible d’être perdue, le compilateur peut effectuer une conversion implicite, telle que la conversion d’une variable de type uint8 en uint16. Les premières versions de Vyper autorisaient le transtypage implicite des variables, mais pas les versions récentes.

Les transtypages explicites peuvent être insérés dans Solidity. Malheureusement, ils peuvent entraîner des comportements inattendus. Par exemple, convertir un uint32 en un type plus petit uint16 supprime simplement les bits d’ordre supérieur, comme illustré ici :

Vyper a à la place une fonction convert pour effectuer des transtypages explicites. La fonction convert (trouvée à la ligne 82 de convert.py) :

Notez l’utilisation de conversion_table (trouvé à la ligne 90 du même fichier), qui ressemble à ceci :

Lorsqu’un développeur appelle convert, il fait référence à conversion_table, ce qui garantit que la conversion appropriée est effectuée. Par exemple, si un développeur passe un int128 à la fonction convert, la fonction to_int128 à la ligne 26 du même fichier (convert.py) sera exécutée. La fonction to_int128 est la suivante :

Comme vous pouvez le constater, le processus de conversion garantit qu’aucune information ne peut être perdue. si c’est possible, une exception est levée. Le code de conversion empêche la troncation ainsi que d’autres anomalies qui seraient normalement autorisées par un transtypage implicite.

Choisir un transtypage explicite plutôt qu’implicite signifie que le développeur est responsable de l’exécution de tous les transtypages. Bien que cette approche produise un code plus détaillé, elle améliore également la sécurité et la vérifiabilité des contrats intelligents.

Vyper gère explicitement les préconditions, les postconditions et les changements d’état. Bien que cela produise un code redondant, cela permet également une lisibilité et une sécurité maximales. Lors de la rédaction d’un contrat intelligent dans Vyper, un développeur doit observer les trois points suivants :

Idéalement, chacun de ces points devrait être soigneusement examiné puis documenté de manière approfondie dans le code. Cela améliorera la conception du code, le rendant finalement plus lisible et auditable.

L’attaque DAO (Decentralized Autonomous Organization) a été l’un des principaux piratages survenus au début du développement d’Ethereum. À l’époque, le contrat détenait plus de 150 millions de dollars. La réentrance a joué un rôle majeur dans l’attaque, qui a finalement conduit à l’embranchement divergent (hard fork) qui a créé Ethereum Classic (ETC). Pour une bonne analyse de l’exploit DAO, voir http://bit.ly/2EQaLCI . Plus d’informations sur l’historique des embranchements d’Ethereum, la chronologie du piratage DAO et la naissance d’ETC dans un embranchement divergent peuvent être trouvées dans Normes Ethereum.

Proof of Weak Hands Coin ( PoWHC ), conçu à l’origine comme une sorte de blague, était un stratagème de Ponzi écrit par un collectif Internet. Malheureusement , il semble que l’auteur ou les auteurs du contrat n’avaient pas vu de soupassement/dépassement auparavant, et par conséquent 866 ethers ont été libérés de son contrat. Eric Banisadr donne un bon aperçu de la façon dont le dépassement s’est produit (ce qui n’est pas trop différent du défi Ethernaut décrit précédemment) dans son article de blog sur l’événement.

Un autre exemple provient de l’implémentation d’une fonction batchTransfer() dans un groupe de contrats de jetons ERC20. L’implémentation contenait une vulnérabilité de dépassement; vous pouvez lire les détails dans le compte rendu de PeckShield.

Quelques exemples de contrats exploitables ont été donnés dans le Underhanded Solidity Coding Contest , qui fournit également des exemples détaillés d’un certain nombre de pièges soulevés dans cette section.

Le deuxième hack de Parity Multisig Wallet est un exemple de la façon dont un code de bibliothèque bien écrit peut être exploité s’il est exécuté en dehors de son contexte prévu. Il existe un certain nombre de bonnes explications de ce hack, telles que "Parity Multisig Hacked. Encore une fois » et « Un examen approfondi du bogue multisig de parity ».

Pour compléter ces références, explorons les contrats qui ont été exploités. Les contrats de bibliothèque et de portefeuille peuvent être trouvés sur GitHub .

Le contrat de bibliothèque est le suivant :

Et voici le contrat de portefeuille :

Notez que le contrat Wallet transmet essentiellement tous les appels au contrat WalletLibrary via un appel délégué. L’adresse constante _walletLibrary dans cet extrait de code agit comme un espace réservé pour le déploiement réel de contrat WalletLibrary (qui était à 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 ).

L’opération voulue de ces contrats est d’avoir un portefeuille Wallet déployable à faible coût dont la base de code et les principales fonctionnalités se trouvaient dans le contrat WalletLibrary. Malheureusement, le contrat WalletLibrary est lui-même un contrat et conserve son propre état. Pouvez-vous voir pourquoi cela pourrait être un problème?

Il est possible d’envoyer des appels au contrat WalletLibrary lui-même. Plus précisément, le contrat WalletLibrary pourrait être initialisé et devenir propriétaire. En fait, un utilisateur a fait cela, appelant la fonction initWallet sur le contrat WalletLibrary et devenant propriétaire du contrat de bibliothèque. Le même utilisateur a ensuite appelé la fonction kill . Étant donné que l’utilisateur était propriétaire du contrat de bibliothèque, le modificateur a été adopté et le contrat de bibliothèque s’est auto-détruit. Comme tous les contrats Wallet existants se réfèrent à ce contrat de bibliothèque et ne contiennent aucune méthode pour modifier cette référence, toutes leurs fonctionnalités, y compris la possibilité de retirer de l’ether, ont été perdues avec le contrat WalletLibrary . En conséquence, tout l’ether de tous les portefeuilles multisig Parity de ce type a été instantanément perdu ou définitivement irrécupérable..

Dans le premier multisig hack de Parity, environ 31 millions de dollars d’ether ont été volés, principalement dans trois portefeuilles. Un bon récapitulatif de la façon exacte dont cela a été fait est donné par Haseeb Qureshi.

Essentiellement, le portefeuille multisig est construit à partir d’un contrat Wallet de base, qui appelle un contrat de bibliothèque contenant la fonctionnalité de base (comme décrit dans Exemple concret : Parity Multisig Wallet (Second Hack)). Le contrat de bibliothèque contient le code pour initialiser le portefeuille, comme le montre l’extrait suivant :

Notez qu’aucune des fonctions ne spécifie leur visibilité, donc les deux sont par défaut public . La fonction initWallet est appelée dans le constructeur du portefeuille et définit les propriétaires du portefeuille multisig comme on peut le voir dans la fonction initMultiowned . Étant donné que ces fonctions ont été accidentellement laissées publiques , un attaquant a pu appeler ces fonctions sur des contrats déployés, réinitialisant la propriété à l’adresse de l’attaquant. En tant que propriétaire, l’attaquant a ensuite vidé les portefeuilles de tout leur ether.

En février 2018 Arseny Reutov a blogué sur son analyse de 3 649 contrats intelligents en direct qui utilisaient une sorte de générateur de nombres pseudo-aléatoires (PRNG) ; il a trouvé 43 contrats qui pourraient être exploités.

Un certain nombre de pots de miel récents ont été publiés sur le réseau principal. Ces contrats tentent de déjouer les pirates Ethereum qui tentent d’exploiter les contrats, mais qui finissent par perdre de l’ether au profit du contrat qu’ils s’attendent à exploiter. Un exemple utilise cette attaque en remplaçant un contrat attendu par un contrat malveillant dans le constructeur. Le code se trouve ici :

Ce message d’un utilisateur de reddit explique comment il a perdu 1 ether à cause de ce contrat en essayant d’exploiter le bogue de réentrance qu’il s’attendait à trouver dans le contrat..

Etherpot était une loterie de contrats intelligents, pas trop différente de l’exemple de contrat mentionné précédemment. La chute de ce contrat était principalement due à une utilisation incorrecte des hachages de bloc (seuls les 256 derniers hachages de bloc sont utilisables ; voir le post d’Aakil Fernandes sur la manière dont Etherpot n’a pas réussi à en tenir compte correctement). Cependant, ce contrat a également souffert d’une valeur d’appel non contrôlée. Considérez la fonction cash dans lotto.sol: Code snippet.

Notez qu’à la ligne 21, la valeur de retour de la fonction send n’est pas vérifiée, et la ligne suivante définit alors un booléen indiquant que le gagnant a reçu ses fonds. Ce bogue peut autoriser un état où le gagnant ne reçoit pas son ether, mais l’état du contrat peut indiquer que le gagnant a déjà été payé.

Une version plus sérieuse de ce bogue s’est produite dans le King of the Ether. Un excellent post-mortem de ce contrat a été écrit qui détaille comment un envoi échoué non contrôlé pourrait être utilisé pour attaquer le contrat.

La norme ERC20 est assez connue pour la construction de jetons sur Ethereum. Cette norme présente une vulnérabilité de devancement potentielle due à la fonction d’approbation approve. Mikhail Vladimirov et Dmitry Khovratovich ont écrit une bonne explication de cette vulnérabilité (et des moyens d’atténuer l’attaque).

La norme spécifie la fonction d' approbation approve comme suit :

Cette fonction permet à un utilisateur d’autoriser d’autres utilisateurs à transférer des jetons en son nom. La vulnérabilité de devancement se produit dans le scénario où une utilisatrice Alice autorise son ami Bob à dépenser 100 jetons. Alice décide plus tard qu’elle veut révoquer l’autorisation de Bob de dépenser, disons, 100 jetons, alors elle crée une transaction qui fixe l’allocation de Bob à 50 jetons. Bob, qui a observé attentivement la chaîne, voit cette transaction et construit sa propre transaction en dépensant les 100 jetons. Il met un gasPrice plus élevé sur sa transaction que celle d’Alice, donc sa transaction est prioritaire sur la sienne. Certaines implémentations d' approbation approve permettraient à Bob de transférer ses 100 jetons, puis, lorsque la transaction d’Alice est validée, réinitialiserait l’approbation de Bob à 50 jetons, donnant ainsi à Bob l’accès à 150 jetons.

Bancor est un autre exemple important dans le monde réel. Ivan Bogatyy et son équipe ont documenté une attaque rentable sur la mise en œuvre initiale de Bancor. Son article de blog et sa conférence DevCon3 expliquent en détail comment cela a été fait. Essentiellement, les prix des jetons sont déterminés en fonction de la valeur de la transaction ; les utilisateurs peuvent surveiller le bassin de transactions pour les transactions Bancor et les exécuter en amont pour profiter des différences de prix. Cette attaque a été traitée par l’équipe de Bancor.

GovernMental était un ancien schéma de Ponzi qui accumulait une assez grande quantité d’ether (1 100 ether, à un moment donné). Malheureusement, il était sensible aux vulnérabilités DoS mentionnées dans cette section. Un post Reddit par etherik décrit comment le contrat exigeait la suppression d’un grand mappage afin de retirer l’ether. La suppression de cette cartographie avait un coût en gaz qui dépassait la limite de gaz du bloc à l’époque, et il n’était donc pas possible de retirer les 1 100 ethers . L’adresse du contrat est 0xF45717552f12Ef7cb65e95476F217Ea008167Ae3, et vous pouvez voir dans la transaction 0x0d80d67202bd9cb6773df8dd2020e719 0a1b0793e8ec4fc105257e8128f0506b que les 1 100 ether ont finalement été obtenus via 2.5M en frais de gaz (et ce quand la limite du gaz fût augmenté).

GovernMental, l’ancien schéma de Ponzi mentionné ci-dessus, était également vulnérable à une attaque basée sur l’horodatage. Le contrat est payé au joueur qui a été le dernier joueur à rejoindre (pendant au moins une minute) un tour. Ainsi, un mineur qui était un joueur pouvait ajuster l’horodatage (à une heure future, pour donner l’impression qu’une minute s’était écoulée) pour faire apparaître qu’il était le dernier joueur à rejoindre pendant plus d’une minute (même si ce n’était pas vrai dans la réalité). Plus de détails à ce sujet peuvent être trouvés dans le post "Historique des vulnérabilités de sécurité d’Ethereum, des piratages et de leurs correctifs" par Tanya Bahrynovska.

Rubixi était un autre système pyramidal qui présentait ce type de vulnérabilité. Il s’appelait à l’origine DynamicPyramid , mais le nom du contrat a été modifié avant le déploiement sur Rubixi. Le nom du constructeur n’a pas été modifié, permettant à n’importe quel utilisateur de devenir le créateur. Des discussions intéressantes liées à ce bogue peuvent être trouvées sur Bitcointalk. En fin de compte, cela a permis aux utilisateurs de se battre pour le statut de créateur afin de réclamer les frais du système pyramidal. Plus de détails sur ce bogue particulier peuvent être trouvés dans "Historique des vulnérabilités de sécurité d’Ethereum, des piratages et de leurs correctifs".

Un pot de miel nommé OpenAddressLotterya été déployé qui a utilisé cette bizarrerie de variable de stockage non initialisée pour collecter de l’ether auprès de certains pirates potentiels. Le contrat est plutôt impliqué, nous laisserons donc l’analyse au fil Reddit où l’attaque est assez clairement expliquée.

Un autre pot de miel, CryptoRoulette, a également utilisé cette astuce pour essayer de collecter de l’ether. Si vous ne pouvez pas comprendre comment fonctionne l’attaque, consultez « Une analyse de quelques contrats de pot de miel Ethereum » pour un aperçu de ce contrat et d’autres.

Le contrat Ethstickn’utilise pas la précision étendue; cependant, il traite de wei. Donc, ce contrat aura des problèmes d’arrondi, mais seulement au niveau de précision wei. Il a quelques défauts plus graves, mais ceux-ci sont liés à la difficulté d’obtenir de l’entropie sur la chaîne de blocs (voir Illusion d’entropie). Pour une discussion plus approfondie du contrat Ethstick, nous vous renverrons à un autre article de Peter Vessenes, "Les contrats Ethereum vont être des bonbons pour les pirates".

De nombreuses startups sont confrontées à un problème difficile : les jetons sont un excellent mécanisme de collecte de fonds, mais offrir des titres (actions) au public est une activité réglementée dans la plupart des juridictions. En déguisant les jetons d’équité en jetons utilitaires, de nombreuses startups espèrent contourner ces restrictions réglementaires et lever des fonds à partir d’une offre publique tout en la présentant comme une prévente de "bons d’accès au service" ou, comme nous les appelons, de jetons utilitaires. Reste à savoir si ces offres d’actions à peine déguisées pourront contourner les régulateurs.

Comme le dit le dicton populaire : "Si ça marche comme un canard et cancane comme un canard, c’est un canard." Les régulateurs ne risquent pas d’être distraits par ces contorsions sémantiques ; bien au contraire, ils sont plus susceptibles de considérer ce sophisme juridique comme une tentative de tromper le public.

Le vrai problème est que les jetons utilitaires introduisent des risques importants et des obstacles à l’adoption pour les startups. Peut-être que dans un avenir lointain, "tokéniser toutes les choses" deviendra réalité, mais à l’heure actuelle, l’ensemble des personnes qui comprennent et souhaitent utiliser un jeton est un sous-ensemble du marché déjà petit de la crypto-monnaie.

Pour une startup, chaque innovation représente un risque et un filtre de marché. L’innovation, c’est emprunter le chemin le moins fréquenté, s’éloigner du chemin de la tradition. C’est déjà une promenade solitaire. Si une startup essaie d’innover dans un nouveau domaine technologique, tel que le partage de stockage sur des réseaux P2P, c’est une voie assez solitaire. L’ajout d’un jeton utilitaire à cette innovation et l’obligation pour les utilisateurs d’adopter des jetons afin d’utiliser le service aggravent le risque et augmentent les obstacles à l’adoption. C’est sortir de la piste déjà solitaire de l’innovation de stockage P2P et dans le désert.

Considérez chaque innovation comme un filtre. Cela limite l’adoption au sous-ensemble du marché qui peut devenir les premiers à adopter cette innovation. L’ajout d’un deuxième filtre aggrave cet effet, limitant davantage le marché adressable. Vous demandez à vos premiers utilisateurs d’adopter non pas une mais deux technologies entièrement nouvelles : la nouvelle application/plate-forme/service que vous avez créée et l’économie des jetons.

Pour une startup, chaque innovation introduit des risques qui augmentent les chances d’échec de la startup. Si vous prenez votre idée de démarrage déjà risquée et ajoutez un jeton utilitaire, vous ajoutez tous les risques de la plate-forme sous-jacente (Ethereum), de l’économie plus large (échanges, liquidité), de l’environnement réglementaire (régulateurs des actions/matières premières) et de la technologie (contrats intelligents , normes symboliques). C’est beaucoup de risques pour une startup.

Les partisans de la "tokénisation de toutes les choses" rétorqueront probablement qu’en adoptant des jetons, ils héritent également de l’enthousiasme du marché, des premiers utilisateurs, de la technologie, de l’innovation et de la liquidité de l’ensemble de l’économie des jetons. C’est vrai aussi. La question est de savoir si les avantages et l’enthousiasme l’emportent sur les risques et les incertitudes.

Néanmoins, certaines des idées commerciales les plus innovantes se déroulent effectivement dans le domaine de la cryptographie. Si les régulateurs ne sont pas assez rapides pour adopter des lois et soutenir de nouveaux modèles commerciaux, les entrepreneurs et les talents associés chercheront à opérer dans d’autres juridictions plus favorables à la cryptographie. Cela se produit déjà.

Enfin, au début de ce chapitre, lors de l’introduction des jetons, nous avons discuté de la signification familière du « jeton » comme « quelque chose de valeur insignifiante ». La raison sous-jacente de la valeur insignifiante de la plupart des jetons est qu’ils ne peuvent être utilisés que dans un contexte très étroit : une compagnie d’autobus, une buanderie automatique, une arcade, un hôtel ou un magasin d’entreprise. Une liquidité limitée, une applicabilité limitée et des coûts de conversion élevés réduisent la valeur des jetons jusqu’à ce qu’ils n’aient plus qu’une valeur « symbolique ». Ainsi, lorsque vous ajoutez un jeton utilitaire à votre plateforme, mais que le jeton ne peut être utilisé que sur votre seule plateforme avec un petit marché, vous recréez les conditions qui ont rendu les jetons physiques sans valeur. Cela peut en effet être la bonne façon d’intégrer la tokenisation dans votre projet. Cependant, si pour utiliser votre plate-forme, un utilisateur doit convertir quelque chose en votre jeton utilitaire, l’utiliser, puis reconvertir le reste en quelque chose de plus généralement utile, vous avez créé un certificat d’entreprise. Les coûts de commutation d’un jeton numérique sont des ordres de grandeur inférieurs à ceux d’un jeton physique sans marché, mais ils ne sont pas nuls. Les jetons utilitaires qui fonctionnent dans tout un secteur industriel seront très intéressants et probablement très précieux. Mais si vous configurez votre startup pour qu’elle doive amorcer une norme industrielle entière pour réussir, vous avez peut-être déjà échoué.

Prenez cette décision pour les bonnes raisons. Adoptez un jeton car votre application ne peut pas fonctionner sans jeton. Adoptez-le car le jeton lève une barrière fondamentale du marché ou résout un problème d’accès. N’introduisez pas de jeton utilitaire car c’est le seul moyen de collecter des fonds rapidement et vous devez prétendre qu’il ne s’agit pas d’une offre publique de titres .

La première norme a été introduite en novembre 2015 par Fabian Vogelsteller en tant que demande de commentaires Ethereum (ERC). Il s’est automatiquement vu attribuer le numéro de problème GitHub 20, donnant lieu au nom de "jeton ERC20". La grande majorité des jetons sont actuellement basés sur la norme ERC20. La demande de commentaires ERC20 est finalement devenue la proposition d’amélioration Ethereum 20 (EIP-20), mais elle est encore principalement désignée par le nom d’origine, ERC20.

ERC20 est une norme pour les jetons fongibles, ce qui signifie que différentes unités d’un token ERC20 sont interchangeables et n’ont pas de propriétés uniques.

La norme ERC20 définit une interface commune pour les contrats mettant en œuvre un jeton, de sorte que tout jeton compatible est accessible et utilisable de la même manière. L’interface se compose d’un certain nombre de fonctions qui doivent être présentes dans chaque implémentation de la norme, ainsi que de certaines fonctions et attributs facultatifs qui peuvent être ajoutés par les développeurs.

Créons et lançons notre propre jeton. Pour cet exemple, nous utiliserons le cadre de développement (framework) Truffle. L’exemple suppose que vous avez déjà installé truffle et que vous l’avez configuré, et que vous êtes familiarisé avec son fonctionnement de base (pour plus de détails, voir Truffle).

Nous appellerons notre jeton "Mastering Ethereum Token", avec le symbole "MET".

Commençons par créer et initialiser un répertoire de projet Truffle. Exécutez ces quatre commandes et acceptez les réponses par défaut à toutes les questions :

Vous devriez maintenant avoir la structure de répertoires suivante :

Modifiez le fichier de configuration truffle.js ou truffle-config.js pour configurer votre environnement Truffle, ou copiez ce dernier depuis le référentiel.

Si vous utilisez l’exemple truffle-config.js, pensez à créer un fichier .env dans le dossier METoken contenant vos clés privées de test pour le test et le déploiement sur les réseaux publics de test Ethereum, tels que Ropsten ou Kovan. Vous pouvez exporter votre clé privée de réseau de test à partir de MetaMask.

Après cela, votre répertoire devrait ressembler à :

Pour notre exemple, nous allons importer la bibliothèque OpenZeppelin, qui implémente des contrôles de sécurité importants et est facile à étendre :

Le module de dévelopement openzeppelin-solidity ajoutera environ 250 fichiers sous le répertoire node_modules. La bibliothèque OpenZeppelin comprend bien plus que le jeton ERC20, mais nous n’en utiliserons qu’une petite partie.

Ensuite, écrivons notre contrat de jeton. Créez un nouveau fichier, METoken.sol, et copiez l’exemple de code depuis GitHub.

Notre contrat, illustré en METoken.sol : Un contrat Solidity implémentant un token ERC20, est très simple, car il hérite toutes ses fonctionnalités de la bibliothèque OpenZeppelin.

Ici, nous définissons les variables optionnelles name, symbol et decimals. Nous définissons également une variable _initial_supply, définie sur 21 millions de jetons ; avec deux décimales de subdivision qui donne 2,1 milliards d’unités au total. Dans la fonction d’initialisation (constructeur) du contrat, nous définissons le totalSupply égal à _initial_supply et allouons tout le _initial_supply au solde du compte (msg.sender)qui crée le contrat METoken.

Nous utilisons maintenant truffle pour compiler le code METoken :

Comme vous pouvez le voir, truffle intègre les dépendances nécessaires des bibliothèques OpenZeppelin et compile également ces contrats.

Configurons un script de migration pour déployer le contrat METoken. Créez un nouveau fichier appelé 2_deploy_contracts.js, dans le dossier METoken/migrations. Copiez le contenu de l’exemple dans le référentiel GitHub :

Avant de déployer sur l’un des réseaux de test Ethereum, démarrons une chaîne de blocs locale pour tout tester. Démarrez la chaîne de blocs ganache, soit depuis la ligne de commande avec ganache-cli, soit depuis l’interface utilisateur graphique.

Une fois ganache lancé, nous pouvons déployer notre contrat METoken et voir si tout fonctionne comme prévu :

Sur la console ganache, nous devrions voir que notre déploiement a créé quatre nouvelles transactions, comme illustré dans Déploiement METoken sur ganache.

L’adoption de la norme de jeton ERC20 a été vraiment explosive. Des milliers de jetons ont été lancés, à la fois pour expérimenter de nouvelles capacités et pour lever des fonds dans diverses enchères et "financements participatifs" ICO. Cependant, il existe des pièges potentiels, comme nous l’avons vu avec la question du transfert de jetons vers des adresses contractuelles.

L’un des problèmes les moins évidents avec les jetons ERC20 est qu’ils exposent des différences subtiles entre les jetons et l’ether lui-même. Lorsque l’ether est transféré par une transaction qui a une adresse de destinataire comme destination, les transferts de jeton se produisent dans l'état spécifique du contrat de jeton et ont le contrat de jeton comme destination, et non l’adresse du destinataire. Le contrat de jeton suit les soldes et émet des événements. Dans un transfert de jeton, aucune transaction n’est réellement envoyée au destinataire du jeton. Au lieu de cela, l’adresse du destinataire est ajoutée à un tableau dans le contrat de jeton lui-même. Une transaction envoyant de l’ether à une adresse modifie l’état d’une adresse. Une transaction transférant un jeton à une adresse ne modifie que l’état du contrat de jeton, pas l’état de l’adresse du destinataire. Même un portefeuille prenant en charge les jetons ERC20 ne prend pas connaissance d’un solde de jetons à moins que l’utilisateur n’ajoute explicitement un contrat de jeton spécifique à « surveiller ». Certains portefeuilles surveillent les contrats de jetons les plus populaires pour détecter les soldes détenus par les adresses qu’ils contrôlent, mais cela est limité à une petite fraction des contrats ERC20 existants.

En fait, il est peu probable qu’un utilisateur veuille suivre tous les soldes de tous les contrats de jetons ERC20 possibles. De nombreux jetons ERC20 ressemblent plus à du courrier indésirable qu’à des jetons utilisables. Ils créent automatiquement des soldes pour les comptes qui ont une activité ether, afin d’attirer les utilisateurs. Si vous avez une adresse Ethereum avec une longue histoire d’activité, surtout si elle a été créée lors de la prévente, vous la trouverez pleine de jetons "indésirables" qui sont apparus de nulle part. Bien sûr, l’adresse n’est pas vraiment pleine de jetons ; ce sont les contrats symboliques qui contiennent votre adresse. Vous ne voyez ces soldes que si ces contrats de jetons sont surveillés par l’explorateur de blocs ou le portefeuille que vous utilisez pour afficher votre adresse.

Les jetons ne se comportent pas de la même manière que l’ether. L’ether est envoyé avec la fonction send et accepté par toute fonction payante dans un contrat ou toute adresse détenue en externe. Les jetons sont envoyés à l’aide des fonctions transfer ou approve et transferFrom qui n’existent que dans le contrat ERC20, et ne déclenchent (du moins dans ERC20) aucune fonction payante dans un contrat destinataire. Les jetons sont censés fonctionner comme une cryptomonnaie telle que l’ether, mais ils présentent certaines différences qui brisent cette illusion.

Envisagez un autre problème. Pour envoyer de l’ether ou utiliser un contrat Ethereum, vous avez besoin d’ether pour payer le gaz. Pour envoyer des jetons, vous avez également besoin d’ether. Vous ne pouvez pas payer le gaz d’une transaction avec un jeton et le contrat de jeton ne peut pas payer le gaz pour vous. Cela peut changer à un moment donné dans un avenir lointain, mais entre-temps, cela peut entraîner des expériences utilisateur plutôt étranges. Par exemple, supposons que vous utilisiez un échange ou ShapeShift pour convertir du bitcoin en jeton. Vous "recevez" le jeton dans un portefeuille qui suit le contrat de ce jeton et affiche votre solde. Il ressemble à toutes les autres crypto-monnaies que vous avez dans votre portefeuille. Essayez d’envoyer le jeton et votre portefeuille vous informera que vous avez besoin d’ether pour le faire. Vous pourriez être confus - après tout, vous n’aviez pas besoin d’ether pour recevoir le jeton. Peut-être que vous n’avez pas d’ether. Peut-être ne saviez-vous même pas que le jeton était un jeton ERC20 sur Ethereum; peut-être pensiez-vous qu’il s’agissait d’une cryptomonnaie avec sa propre chaîne de blocs. L’illusion vient de se briser.

Certains de ces problèmes sont spécifiques aux jetons ERC20. D’autres sont des problèmes plus généraux liés à l’abstraction et aux limites d’interface au sein d’Ethereum. Certains peuvent être résolus en modifiant l’interface du jeton, tandis que d’autres peuvent nécessiter des modifications des structures fondamentales au sein d’Ethereum (comme la distinction entre EOA et contrats, et entre transactions et messages). Certains peuvent ne pas être exactement "solvable" et peuvent nécessiter une conception d’interface utilisateur pour masquer les nuances et rendre l’expérience utilisateur cohérente, quelles que soient les distinctions sous-jacentes.

Dans les prochaines sections, nous examinerons diverses propositions qui tentent de résoudre certains de ces problèmes.

La proposition ERC223 tente de résoudre le problème du transfert par inadvertance de jetons vers un contrat (qui peut ou non prendre en charge jetons) en détectant si l’adresse de destination est un contrat ou non. ERC223 exige que les contrats conçus pour accepter des jetons implémentent une fonction nommée tokenFallback. Si la destination d’un transfert est un contrat et que le contrat ne prend pas en charge les jetons (c’est-à-dire qu’il n’implémente pas tokenFallback), le transfert échoue.

Pour détecter si l’adresse de destination est un contrat, l’implémentation de référence ERC223 utilise un petit segment de code intermédiaire en ligne d’une manière plutôt créative :

La spécification de l’interface de contrat ERC223 est :

ERC223 n’est pas largement mis en œuvre, et il y a un débat dans le fil de discussion ERC sur la rétrocompatibilité et les compromis entre la mise en œuvre des changements au niveau de l’interface du contrat par rapport à l’interface utilisateur. Le débat continue.

Une autre proposition pour une norme de contrat de jeton améliorée est ERC777. Cette proposition a plusieurs objectifs, notamment :

La discussion en cours sur ERC777 peut être trouvée sur GitHub.

La spécification de l’interface de contrat ERC777 est :

Toutes les normes de jeton que nous avons examinées jusqu’à présent concernent les jetons fungible, ce qui signifie que les unités de un jeton sont interchangeables. La norme de jeton ERC20 ne suit que le solde final de chaque compte et ne suit pas (explicitement) la provenance d’un jeton.

La proposition ERC721 concerne une norme pour les jetons non fongibles, également appelés actes.

Extrait du dictionnaire Oxford :

L’utilisation du mot "acte" est destinée à refléter la partie "propriété d’un bien", même si ceux-ci ne sont pas reconnus comme des "documents juridiques" dans aucune juridiction - pour le moment. Il est probable qu’à un moment donné dans le futur, la propriété légale basée sur des signatures numériques sur une plate-forme chaîne de blocs sera légalement reconnue.

Les jetons non fongibles suivent la propriété d’une chose unique. L’objet possédé peut être un objet numérique, tel qu’un objet de jeu ou un objet de collection numérique ; ou la chose peut être un objet physique dont la propriété est suivie par un jeton, comme une maison, une voiture ou une œuvre d’art. Les actes peuvent également représenter des choses de valeur négative, telles que des prêts (dettes), des privilèges, des servitudes, etc. La norme ERC721 n’impose aucune limitation ou attente sur la nature de la chose dont la propriété est suivie par un acte et exige seulement qu’elle puisse être identifié de manière unique, ce qui, dans le cas de cette norme, est obtenu par un identifiant de 256 bits .

Les détails de la norme et de la discussion sont suivis sur deux fils GitHub différents:

Pour saisir la différence fondamentale entre ERC20 et ERC721, il suffit de regarder la structure de données interne utilisée dans ERC721 :

Alors que l’ERC20 suit les soldes appartenant à chaque propriétaire, le propriétaire étant la clé primaire du mappage, l’ERC721 suit chaque ID d’acte et son propriétaire, l’ID d’acte étant la clé primaire du mappage. De cette différence fondamentale découlent toutes les propriétés d’un jeton non fongible.

La spécification de l’interface de contrat ERC721 est :

ERC721 prend également en charge deux interfaces optionnelles, une pour les métadonnées et une pour l’énumération des actes et des propriétaires.

L’interface optionnelle ERC721 pour les métadonnées est :

L’interface optionnelle ERC721 pour l’énumération est :

Les normes de jetons sont les spécifications minimales pour une implémentation. Cela signifie que pour être conforme, par exemple, à ERC20, vous devez au minimum implémenter les fonctions et le comportement spécifiés par la norme ERC20. Vous êtes également libre d'ajouter à la fonctionnalité en implémentant des fonctions qui ne font pas partie de la norme.

L’objectif principal de ces normes est d’encourager l'interopérabilité entre les contrats. Ainsi, tous les portefeuilles, échanges, interfaces utilisateur et autres composants d’infrastructure peuvent s’interfacer de manière prévisible avec tout contrat qui suit la spécification. En d’autres termes, si vous déployez un contrat qui suit la norme ERC20, tous les utilisateurs de portefeuille existants peuvent commencer à échanger votre jeton de manière transparente sans aucune mise à niveau de portefeuille ni effort de votre part.

Les normes sont censées être descriptives plutôt que prescriptives. La façon dont vous choisissez de mettre en œuvre ces fonctions dépend de vous - le fonctionnement interne du contrat n’est pas pertinent pour la norme. Ils ont des exigences fonctionnelles, qui régissent le comportement dans des circonstances spécifiques, mais ils ne prescrivent pas de mise en œuvre. Un exemple de ceci est le comportement d’une fonction transfer si la valeur est définie sur zéro.

Compte tenu de tous ces standards, chaque développeur est confronté à un dilemme : utiliser les standards existants ou innover au-delà des contraintes qu’ils imposent ?

Ce dilemme n’est pas facile à résoudre. Les normes restreignent nécessairement votre capacité à innover, en créant une "ornière" étroite que vous devez suivre. D’autre part, les normes de base ont émergé de l’expérience de centaines d’applications et s’adaptent souvent bien à la grande majorité des cas d’utilisation.

Dans le cadre de cette considération, il y a un problème encore plus important : la valeur de l’interopérabilité et de l’adoption à grande échelle. Si vous choisissez d’utiliser une norme existante, vous gagnez la valeur de tous les systèmes conçus pour fonctionner avec cette norme. Si vous choisissez de vous écarter de la norme, vous devez prendre en compte le coût de la construction de toute l’infrastructure de support par vous-même ou persuader les autres de prendre en charge votre mise en œuvre en tant que nouvelle norme. La tendance à forger votre propre chemin et à ignorer les normes existantes est connue sous le nom de syndrome "Not Invented Here" (Non inventé ici) et est contraire à la culture open source. D’autre part, le progrès et l’innovation dépendent parfois de l’abandon de la tradition. C’est un choix délicat, alors réfléchissez bien !

Au-delà du choix de la norme, il y a le choix parallèle de la mise en oeuvre. Lorsque vous décidez d’utiliser une norme telle que ERC20, vous devez ensuite décider comment mettre en œuvre une conception compatible. Il existe un certain nombre d’implémentations "de référence" existantes qui sont largement utilisées dans l’écosystème Ethereum, ou vous pouvez écrire la vôtre à partir de zéro. Encore une fois, ce choix représente un dilemme qui peut avoir de graves implications en matière de sécurité.

Les implémentations existantes sont "testées au combat". Bien qu’il soit impossible de prouver qu’ils sont sécurisés, beaucoup d’entre eux sous-tendent des millions de dollars de jetons. Ils ont été attaqués, à plusieurs reprises et vigoureusement. Jusqu’à présent, aucune vulnérabilité significative n’a été découverte. Rédiger le vôtre n’est pas facile - il existe de nombreuses façons subtiles de compromettre un contrat. Il est beaucoup plus sûr d’utiliser une implémentation largement testée et largement utilisée. Dans nos exemples, nous avons utilisé l’implémentation OpenZeppelin de la norme ERC20, car cette implémentation est entièrement axée sur la sécurité.

Si vous utilisez une implémentation existante, vous pouvez également l’étendre. Encore une fois, cependant, soyez prudent avec cette impulsion. La complexité est l’ennemie de la sécurité. Chaque ligne de code que vous ajoutez étend la surface d’attaque de votre contrat et pourrait représenter une vulnérabilité en attente. Vous ne remarquerez peut-être pas un problème jusqu’à ce que vous accordiez beaucoup de valeur au contrat et que quelqu’un le rompe.