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.