Du standard ERC-20 à l’ERC-3525 : les cas d’utilisation et le développement des contrats de jetons standards

Introduction

Nous connaissons tous les jetons, les NFTs et les normes classiques de jetons, telles que ERC-20 et ERC-721, sur lesquelles ils sont basés. Plus précisément, l’ERC-20 est conçu pour les jetons fongibles, tandis que l’ERC-721 représente une norme pour les jetons non fongibles et convient aux œuvres d’art ou aux actifs rares. Cela dit, comment ces jetons sont-ils mis en œuvre ? Comment peuvent-ils être appliqués aux applications concernées ?

Aujourd’hui, nous allons passer en revue les principes, le champ d’application et les tendances futures de ces contrats de jetons, en couvrant les normes relatives aux jetons qui incluent les standards ERC-20, ERC-721, ERC-1155, et ERC-3525 récemment finalisé.
(Les codes concernant ERC-20, ERC-721 et ERC-1155 proviennent d’OpenZeppelin, et le jeton ERC-3525 provient de Solv Protocol).

Table de hachage

Avant d’aborder le principe des contrats de jetons, nous devons d’abord aborder un concept essentiel : la table de hachage (mapping). En termes simples, une table de hachage est une structure de données pour le mapping qui nous permet de trouver rapidement des valeurs en fonction des clés. Les contrats de jetons utilisent des tables de hachage pour stocker des informations sur les actifs et les personnes autorisées. Pour des informations plus spécifiques sur les tables de hachage, veuillez vous référer à : https://en.wikipedia.org/wiki/Hash_table.

Hachage de données et fonctionnalités

Les jetons effectuent le hachage des données de différentes manières. L’approche du hachage des données détermine les fonctionnalités d’un jeton et peut être considérée comme la manière dont les actifs sont structurés et enregistrés. En fonction de l’objectif spécifique, le hachage de données peut être divisé en compte général et compte individuel. Le compte général enregistre l’état général des actifs du jeton (son type, son numéro et son autorisation) et contient également les paramètres des personnes autorisées/administrateurs (les personnes autorisées peuvent librement transférer/autoriser les actifs du propriétaire des actifs).

Dans ce contexte, les fonctionnalités font référence à la conception du hachage des données basée sur les jetons et aux fonctionnalités réalisables des jetons (c’est-à-dire les fonctionnalités publiques), y compris l’interrogation et la transmission, la frappe et la combustion des actifs.

Dans les paragraphes suivants, nous allons passer en revue les différents standards de jetons en termes de hachage de données et de fonctionnalités.

ERC-20

1. Data Hashing

Compte général : le standard ERC-20 gère et enregistre l’ensemble des actifs du jeton par le biais d’une table de hachage : Mapping (adresse => uint256). En particulier, la Clé est l’adresse de l’utilisateur, et la Valeur mappée est un nombre entier positif utilisé pour enregistrer le nombre de jetons possédés par chaque adresse.

Mapping(address => uint256)

Address

Amount

0x1…

100

0x2…

200

…

Compte individuel : Grâce à sa propre simplicité, l’ERC-20 peut enregistrer tous les actifs en utilisant une seule table de hachage. Ainsi, une seule table est nécessaire pour enregistrer les personnes autorisées du compte individuel. Cette table utilise une adresse unique comme clé pour mapper à une autre table qui vise des clés qui sont des entiers positifs :

Par exemple, 0x1 est un compte pour le Token A et peut autoriser d’autres comptes (par exemple 0x2, 0x3) à utiliser ses jetons en son nom. Il convient de noter que la limite de montant de ces comptes autorisés n’est valable que lorsqu’elle est fixée par le compte où se trouvent les jetons (dans ce cas, 0x1).

Mapping(address => (Mapping(address => uint256))

Individual address

Admin address

Amount manageable

0x1

0x2

100

0x3

200

….

0x123

….

….

….

0x455

….

…

2. Fonctionnalités (de base)

Le standard ERC-20 offre presque toutes les conditions requises pour la circulation et pour que les jetons puissent être utilisés comme des actions et des marchandises. De plus, la norme permet également une facilité d’utilisation.

ERC-721

1. Data Hashing

Compte général :

La table fait correspondre des entiers positifs à des adresses. Ici, l’ID est la clé et l’adresse est la valeur. En outre, chaque ID ne correspond qu’à une seule adresse, ce qui permet d’obtenir l’unicité et la rareté requises par les NFT.

Compte individuel : Par rapport à l’ERC-20, qui enregistre le solde des actifs de toutes les adresses à l’aide d’une table, l’ERC-721 ajoute une deuxième table qui contient les enregistrements des actifs des comptes individuels. Dans ce tableau, l’adresse individuelle est la clé, et le nombre de NFT détenus par les adresses est la valeur. Elle enregistre le total des NFT détenus par chaque adresse. Cependant, la table n’enregistre pas l’identifiant spécifique des NFT détenus par les comptes individuels, et l’identifiant ne peut être obtenu qu’en interrogeant les événements.

En termes d’autorisation des personnes autorisées, avec les jetons ERC-721, un compte individuel est accompagné d’une personne autorisée globale, et cette adresse autorisée peut exploiter tous les jetons de contrat contenus dans le compte.

Seul le compte individuel peut donner de telles autorisations.

D’autre part, un NFT avec un ID peut également être autorisé indépendamment : Mapping (uint256=>address), et la personne autorisée peut faire fonctionner le NFT correspondant. Dans ce cas, tant le détenteur du NFT que la personne autorisée globale peuvent accorder cette autorisation.

En somme, une adresse individuelle peut avoir un nombre illimité de personnes autorisées, qui peuvent toutes changer les personnes autorisées des ID de l’adresse individuelle. Un ID individuel, en revanche, ne peut avoir qu’une seule personne autorisée par adresse.

Par exemple, 0x1 possède trois NFTs dans une série de NFTs qui correspondent à trois IDs : 1, 2 et 3. Dans ce cas, 0x1 accorde une autorisation concernant les NFT à d’innombrables adresses individuelles. S’il autorisait 0x2, alors 0x2 serait en mesure de transférer les trois NFT. Dans le même temps, 0x2 pourrait également accorder l’autorisation de transfert d’un ID (par exemple 1) à une autre adresse comme 0x3. À ce stade, 0x3 pourrait transmettre le NFT correspondant à l’ID de la manière qu’il juge la plus appropriée.

2. Fonctionnalités

ERC-721 garantit l’unicité et la rareté des œuvres d’art numériques en s’assurant qu’un identifiant ne correspond qu’à une seule œuvre d’art qui ne peut être possédée que par une seule adresse. En outre, les collectionneurs peuvent également collecter plusieurs ID d’une même série et vérifier le nombre de NFT qu’ils possèdent. Cependant, les contrats ERC-721 ne supportent pas la requête des ID de tous les NFTs détenus par une adresse, ce qui est une caractéristique qui est peut-être une restriction motivée par la consommation de gaz. Par exemple, 0x1 détient deux NFTs de la même série. Bien que nous puissions dire que l’adresse détient deux NFT grâce à la fonctionnalité du contrat, nous ne pouvons pas déterminer les NFT spécifiques qu’elle détient. Pour déterminer les ID spécifiques des deux NFT, nous devons recourir au journal/événement du contrat.

ERC-1155

1. Data Hashing

Dans ERC-1155, le compte global et le compte individuel sont mis en œuvre simultanément. Avec ERC-1155, les jetons sont enregistrés en utilisant un Mapping dont l’adresse pointe vers Mapping.

Nous avons découvert un fait intéressant : la conception de l’ERC-1155 est en fait une sorte de fusion entre l’ERC-20 et l’ERC-721. En tant que tel, l’ERC-1155 peut être considéré comme une solution de gestion des jetons qui combine plusieurs jetons basés sur l’ERC20 et l’ERC721 (montant fixé à un, et chaque adresse ne correspond qu’à un seul montant).

En ce qui concerne la gestion des autorisations, l’ERC-1155 n’offre pas d’autorisation pour les identifiants individuels et permet uniquement aux utilisateurs d’accorder une autorisation complète pour les comptes individuels, ce qui simplifie la gestion des autorisations.

2. Fonctionnalités

Pour résumer, nous avons remarqué que l’ERC-1155 n’est pas strictement une norme de jetons, mais une solution de gestion des jetons. Le contrat global n’a même pas de nom ou de symbole. En outre, un ID peut être détenu par plusieurs adresses en même temps, ce qui permet à un ID d’être soit fongible, soit non fongible. En tant que tel, ERC-1155 peut être appliqué dans des scénarios où plusieurs types de jetons sont demandés. Par exemple, dans les jeux blockchain, les articles comprenant des pièces ou des matériaux non fongibles et des armes légendaires uniques peuvent tous être obtenus à l’aide d’un contrat ERC-1155. En outre, la norme peut également être adoptée par des écosystèmes relativement petits, tels que l’écosystème des LP Tokens des DEX.

En même temps, puisque le standard ERC-1155 a introduit le concept de valeur, si une personne ne peut posséder qu’un seul ID, un paramètre qui pourrait être atteint par les futurs contrats, alors l’ERC-1155 pourrait devenir une version de ERC-721 qui présente des valeurs numériques (c’est-à-dire un Jeton Semi-Fongible). Cela signifie que l’ERC-1155 rend les NFTs actualisables. Par exemple, en termes de crédit, la norme permet aux utilisateurs de mettre à jour leur score de crédit et facilite l’établissement de systèmes de comportement multi-crédit qui décrivent chaque aspect de l’état de crédit d’une personne avec un niveau numérique.

Malgré cela, nous pensons que la norme ERC-1155 n’est pas adaptée à la gestion des systèmes de jetons au sein de grands écosystèmes car sa gestion des autorisations est beaucoup trop simple : Dans le standard ERC-1155, il n’y a qu’une autorisation complète ; vous ne pouvez pas donner la permission d’opérer un ID, ni fixer le quota maximum. De plus, l’ERC-1155 n’a pas non plus d’enregistrement complet des comptes individuels. En d’autres termes, vous ne pouvez pas cartographier tous les actifs qui correspondent à l’ID pertinent en utilisant l’adresse individuelle comme clé, et cette information n’est disponible que par le biais de log/event.

ERC-3525

Bien que l’ERC-3525 soit un contrat comparativement plus complexe, il offre une gamme complète de fonctionnalités et d’enregistrements, ainsi qu’une grande capacité de personnalisation.

1. Data Hashing

Compte général : ERC-3525 a construit une structure innovante appelée TokenData, qui est utilisée pour décrire un ID. Pour ceux d’entre vous qui ne sont pas familiers avec les codes, cette structure peut être considérée comme une carte de description d’un ID qui contient l’ID, le Slot (une innovation majeure de l’ERC-3525), le montant du jeton, tout le monde, la personne autorisée (il ne peut y avoir qu’une seule personne autorisée), et l’adresse autorisée qui peut dépenser le solde de l’ID.

Avec cette carte, nous pouvons enregistrer les informations de chaque ID, puis placer les cartes dans une liste appelée _allTokens pour les faire sauvegarder.

Cela dit, comment localiser une carte lorsque l’on souhaite la vérifier ? L’ERC-3525 associe un ID à son emplacement structuré dans la liste. Par exemple, si l’emplacement de l’ID 214 est 1, alors _allTokens[1] nous mènera à la carte cible dans la liste. La liste _allTokens enregistre le statut de tous les actifs de l’ERC-3525.

En termes d’autorisation de l’ID, l’ERC-3525 ajoute l’objectif des valeurs numériques. C’est-à-dire qu’elle marque le quota maximum par différentes adresses en utilisant l’ID comme clé.

Compte individuel : Le standard ERC-3525 construit une carte AddressData et une table de hachage pour gérer les comptes individuels. La carte comprend une liste des ID des Tokens possédés, une table de hachage des emplacements des ID possédés dans la liste globale des comptes, et une table de hachage des personnes autorisées du compte. En d’autres termes, la carte enregistre les identifiants détenus par les comptes individuels (les identifiants sont tous enregistrés) et les personnes autorisées des comptes.

Ensuite, un mappage est utilisé pour enregistrer les informations correspondantes de la carte (AddressData) en utilisant l’adresse individuelle comme clé.

Slot

De manière générale, l’enregistrement des données de l’ERC 3525 est complet et bien organisé. Malgré cela, jusqu’à présent, à part des enregistrements mieux documentés, la norme n’est pas très différente de l’ERC-1155. Ceci nous amène au Slot, une variable ajoutée à la carte d’identité. C’est le Slot qui rend l’ERC-3525 hautement personnalisable et permet des fonctionnalités qui ne sont pas disponibles dans l’ERC-1155.

En termes simples, comme AddressData et TokenData que nous avons présentés précédemment, Slot est également une structure. Cependant, dans l’ERC-3525, les slots sont personnalisables. En d’autres termes, les développeurs peuvent ajouter n’importe quel nombre et n’importe quel type de variable au Slot en fonction de la demande spécifique du produit. Par exemple, dans le cas d’une obligation convertible sur le protocole Solv, les informations que les slots peuvent contenir comprennent la date d’échéance, le prix de conversion et le caractère convertible. Ce slot, combiné à des variables telles que l’ID (#6800) et le solde (2 400 USDC), permet aux développeurs de créer une obligation convertible NFT.

2. Fonctionnalités

Comme l’ERC-3525 couvre l’ensemble des registres comptables, il offre un large éventail de fonctionnalités et nous laisse plus de place pour l’imagination. L’ERC-3525 se caractérise notamment par le fait qu’il permet le transfert de valeurs d’identifiants et le transfert de valeurs entre des identifiants appartenant à des adresses individuelles, ce qui ouvre de nouvelles possibilités pour les NFT.

Par exemple, avec le transfert des valeurs d’identification, le NFT peut mettre à jour son propre statut de valeur. Pour les NFT de crédit et d’âme, un simple ERC-721 qui ne prend pas en charge le transfert de valeurs ne répond pas à toutes les exigences fonctionnelles. Les crédits individuels changent constamment, et l’ERC-3525 peut modifier les valeurs pertinentes pour refléter les changements dans les crédits individuels. Cette fonctionnalité peut également être appliquée aux positions NFT comme celles d’Uniswap V3, permettant aux utilisateurs de mettre à jour la taille de leur position d’une manière plus pratique. Cela dit, ERC-1155 peut également être utilisé pour réaliser cette fonctionnalité, et tout ce que nous avons à faire est de fixer le nombre de propriétaires de chaque ID à une adresse (bien que ce ne soit pas le cas en termes de structure de Data Hashing, c’est réalisable par la suite), ce qui nous permet de transférer/mettre à jour les valeurs sous ERC-1155. De plus, l’ERC-1155 a un design plus simple. De plus, il est plus applicable dans des scénarios où plusieurs types de jetons sont demandés.

Le transfert de valeur entre les ID détenus par des comptes individuels est la plus grande différence entre les standards ERC-3525, ERC-1155 et ERC-721 en termes de fonctionnalité. Cette fonctionnalité est précieuse dans le domaine de la finance. Par exemple, elle pourrait être adoptée pour réaliser la reconduction de deux contrats de livraison avec des durées différentes ou le passage entre différents comptes financiers (par exemple, du spot au future, ce qui ressemble à la conception des CEX). Dans de tels scénarios, chaque ID est transformé en un compte financier. Pendant ce temps, le Slot est utilisé pour enregistrer les informations du compte, et la valeur représente le solde du compte. Un autre exemple est la gestion de la plage (en plus de la valeur) dans Uniswap V3. Dans ce cas, la fourchette peut être enregistrée par le biais du Slot, et lorsqu’un utilisateur individuel souhaite modifier la fourchette de sa position, la plate-forme peut répondre à la demande en transférant la valeur entre les ID.

Il y a également certains endroits qui ne sont pas pris en compte dans la norme ERC-3525. Par exemple, dans la norme ERC-3525, le nom des IDs ne peut pas être modifié manuellement. Les noms doivent commencer à zéro et suivre un ordre séquentiel. En d’autres termes, le nom de l’ID d’un nouveau NFT dans une collection est toujours N+1, N étant le nombre existant de NFT dans la collection. Il s’agit peut-être d’un moyen d’éviter le chevauchement des identifiants ou de faciliter la gestion des identifiants. En outre, dans certaines extensions, bien que l’ERC-3525 enregistre les slots et les mette en ordre, il ne prend pas en charge la classification/recherche d’identifiants basée sur les slots. À notre avis, de telles méthodes de classification/recherche pourraient être utiles pour de nombreux produits et cas d’utilisation. Par exemple, les produits obligataires peuvent enregistrer les informations de différentes obligations par le biais de slots avant leur émission. Si les slots sont utilisés pour séparer les obligations ayant le même ID d’échéance, nous pourrions créer des produits de transaction/gestion plus pratiques et plus fonctionnels. Pour l’instant, cette fonctionnalité n’est réalisable qu’en interrogeant les informations sur les slots des ID et en construisant ensuite la base de données des slots et des ID sur la base de cette interrogation, ou en construisant des événements et des journaux.

Conclusion

En résumé, les contrats ERC-20, ERC-721, ERC-1155 et ERC-3525 ont tous des cas d’utilisation uniques, et les projets doivent choisir le standard de jeton le plus approprié en fonction de la demande spécifique de leur tokenomics. Malgré cela, il convient de noter que le nouveau standard ERC-3525 est beaucoup plus complexe que les trois autres contrats. Non seulement il hérite des caractéristiques des normes précédentes, mais il a également introduit la structure de données unique Slot, qui lui permet d’effectuer de nouvelles tâches. En outre, bien que l’ERC-3525 offre davantage de fonctionnalités, il conserve l’ordre des enregistrements, ce qui nous semble être une innovation remarquable. Cela dit, compte tenu des informations et des enregistrements plus diversifiés, il est prévisible que les frais de gaz de l’ERC-3525 seront élevés, et que la norme sera sujette à des attaques de vulnérabilité inconnues (après tout, elle a résisté à l’épreuve du temps).