Nous avons déjà exploré de façon générale les tokens ou jetons dans cet article dédié aux actifs numériques. Penchons-nous maintenant sur une forme particulière de ces tokens : les ERC20. Ceux-ci pullulent sur Ethereum aujourd’hui, du fait de la simplicité de leur déploiement mais aussi, voire surtout, de la multiplication des ICOs, ces opérations de vente de tokens (bien décrites sur ICO Mentor ou BitConseil). A tel point qu’il existe aujourd’hui plus de 18 000 tokens ERC20 déployés ! Etat des lieux et aperçu du futur de ce qu’est aujourd’hui l’application d’Ethereum la plus utilisée.

Comportement d’un contrat de token sur Ethereum

Un contrat de token déployé sur Ethereum est un smart-contract comme un autre, contenant simplement un registre désignant les propriétaires de tokens du contrat et gérant l’ensemble des transferts de ces tokens en mettant à jour ledit registre.

L’état d’un contrat de tokens, représenté sous forme de tableau

Par exemple, si X envoie une transaction de transfert de 100 tokens à Y, le contrat modifie son registre pour réduire le nombre total de tokens de X de 100 et augmenter au même moment celui de Y.

Dans cet exemple le compte 0x0148… a envoyé 1000 tokens au compte 0x9f7a…

ERC20, document de travail devenu standard

Les tokens dits « ERC20 » sont issus du processus de proposition / amélioration mis en oeuvre par la Fondation Ethereum sur son compte Github. ERC signifie littéralement Ethereum Request for Comments : un processus par lequel une personne demande à la communauté de revoir et de commenter une proposition pour Ethereum. En l’occurence, la 20ème proposition postée sur le Github le 19 novembre 2015 concernait une proposition de standards pour le développement de tokens sur Ethereum – elle s’appela donc ERC20. L’idée de token programmable était une des plus simples à implémenter sur la blockchain. Initiée par frozeman (Fabian Vogelsteller), la proposition a immédiatement donné lieu à d’intenses discussions.

Il est donc important de souligner qu’ERC20 est un standard : il définit des fonctions et des événements qu’un token doit gérer pour être qualifié d’ERC20. Il ne s’agit pas d’un code précis ou d’un produit. Chacun peut créer son propre code de token ERC20 tant que celui-ci respecte les fonctions standard et leur comportement. En l’occurence, il existe de nombreux contrats de tokens ERC20 : le code fourni sur ethereum.org, le code modulaire d’OpenZepplin, le code de ce wiki, etc.

N’importe quel code mettant en application les spécifications ERC20 crée un token ERC20.

Intérêt, limites et évolutions futures du standard ERC20

Cette standardisation a permis le développement rapide d’un très large écosystème de tokens sur Ethereum. Avant sa création, chaque service, chaque projet devait réinventer la roue (le token), ce qui a d’ailleurs provoqué des erreurs et des incompatibilités. Avec un standard simple et ouvert, les tokens peuvent être déployés facilement. C’est aussi le cas des les services utilisant ces tokens.

De fait, l’essentiel des services développés sur Ethereum aujourd’hui gèrent ce standard et uniquement ce standard. Il est facile de créer un service gérant les tokens ERC20 car vous connaissez à l’avance les fonctions basique que ce token va accepter. Par exemple, MyEtherWallet et Etherscan sont capables d’afficher le solde de vos tokens ERC20 sur son interface, et EtherDelta gère nativement les échanges décentralisés entre tous les tokens ERC20 existants.

Cette standardisation a naturellement eu l’effet pervers de toutes les spécifications, en figeant d’une certaine façon les tokens dans leur forme actuelle pendant un certain temps. Lorsque le standard devient la norme, l’expérimentation ne peut se faire que dans le cadre restreint de ce standard. Il est heureux que les créateurs du standard avaient dès le départ en tête ces limitations et ont veillé à en faire un standard « minimum » avec des spécifications portant uniquement sur les fonctions essentielles d’un token.

Ce standard a cependant été critiqué pour de nombreuses raisons. D’abord, il n’est valable que pour un token fongible (tous les tokens d’un contrat ERC20 ont les mêmes caractéristiques, ils ne sont pas uniques et on peut échanger deux tokens du même contrat ERC20 sans effet) et il ne prévoit aucune fonction pour éviter les erreurs d’envoi, aucun standard de mise à jour de son code ou de bonnes pratiques quant à son émission, etc.

En réaction à ce caractère limité du standard, de nombreuses initiatives ont vu le jour, et notamment :

• La proposition ERC223, qui vise à intégrer des mécanismes de contrôle dans le contrat de token directement visant à éviter les transferts de tokens vers une adresse ne pouvant elle-même gérer les tokens (soit parce qu’il s’agit d’une adresse de contrat, soit parce qu’il s’agit de l’adresse du token ERC20 elle-même).
• La proposition Minime Token, un token ERC20 avec des fonctions supplémentaires. Par exemple, il est facile de cloner le token et toutes ses balances, notamment pour mettre à jour ses fonctionnalités. Il est aussi possible de définir une personne qui contrôle les tokens (Token Controller) qui peut les déplacer, en créer de nouveaux, en détruire… Ou encore, l’historique des soldes de tokens par compte est enregistré et facilement consultable.

D’autres propositions sont visibles sur le github officiel de la Fondation.

Spécifications ERC20

Les fonctions et les événement qu’un token « ERC20 » doit pouvoir gérer sont les suivants :

• name est la fonction qui doit renvoyer le nom du token (par exemple OmiseGo ou VariabL Contribution Token)
• symbol doit renvoyer le symbole du token (par exemple « OMG » est le symbole du token OmiseGo, « VCT » est le symbole de VariabL Contribution Token)
• decimals renvoie le nombre de décimales qu’il faut prendre en compte pour le token. En effet, les balances de tokens sont gérés sans décimales par les contrats ERC20 – pour une personne possédant 1 token à 18 décimales, la fonction balanceOf définie ci-dessous renverra 1000000000000000000.
• totalSupply doit renvoyer le nombre total de tokens existant
• balanceOf doit permettre de consulter le nombre de tokens détenu par un compte
• allowance renvoie le nombre de tokens qu’une adresse est autorisée à retirer du contrat de token
• transfer est la fonction permettant à un compte possédant des tokens d’en envoyer à un autre compte
• transferFrom permet de transférer des tokens d’une adresse à une autre, sans que l’adresse qui envoie la transaction soit celle qui détient les tokens
• approve est une fonction permettant au détenteur d’un contrat de token d’approuver un retrait pour un montant déterminé par un compte précis (change l' »allowance » de ce compte)

Ces fonctions doivent également déclencher deux événements :

• Transfer se déclenche pour chaque appel à la fonction transfer ou transferFrom
• Approval se déclenche à chaque appel à la fonction approve

Le détail de ces fonctions et des événements associés est consultable sur la page de l’Ethereum Improvement Proposal correspondant au standard ERC20.

Pour aller plus loin, quelques articles (en anglais) sur les tokens ERC20 :

• Understanding ERC-20 token contracts par Jim McDonald
• Ethereum ERC20 Tokens Explained par James Seibel
• Ethereum ‘Tokens’ Are All the Rage. But What Are They Anyway? par Amy Castor