Standard multi-jetons ERC-1155

Introduction

Une interface standard pour les contrats qui gèrent plusieurs types de jetons. Un seul contrat déployé peut inclure n'importe quelle combinaison de jetons fongibles, de jetons non fongibles ou d'autres configurations (par exemple, des jetons semi-fongibles).

Qu'entend-on par standard multi-jetons ?

L'idée est simple et vise à créer une interface de contrat intelligent capable de représenter et de contrôler n'importe quel nombre de types de jetons fongibles et non fongibles. De cette façon, le jeton ERC-1155 peut remplir les mêmes fonctions qu'un jeton ERC-20 et ERC-721, et même les deux en même temps. Il améliore les fonctionnalités des standards ERC-20 et ERC-721, le rendant plus efficace et corrigeant des erreurs d'implémentation évidentes.

Le jeton ERC-1155 est décrit en détail dans l'EIP-1155 (opens in a new tab).

Prérequis

Pour mieux comprendre cette page, nous vous recommandons de lire d'abord les informations sur les standards de jetons, l'ERC-20 et l'ERC-721.

Fonctions et caractéristiques de l'ERC-1155 :

Transfert par lots : Transférer plusieurs actifs en un seul appel.
Solde par lots : Obtenir les soldes de plusieurs actifs en un seul appel.
Approbation par lots : Approuver tous les jetons pour une adresse.
Hooks : Hook de réception de jetons.
Prise en charge des NFT : Si l'offre n'est que de 1, traitez-le comme un NFT.
Règles de transfert sécurisé : Ensemble de règles pour un transfert sécurisé.

Transferts par lots

Le transfert par lots fonctionne de manière très similaire aux transferts ERC-20 classiques. Regardons la fonction transferFrom classique de l'ERC-20 :

// ERC-20
function transferFrom(address from, address to, uint256 value) external returns (bool);

// ERC-1155
function safeBatchTransferFrom(
    address _from,
    address _to,
    uint256[] calldata _ids,
    uint256[] calldata _values,
    bytes calldata _data
) external;

La seule différence dans l'ERC-1155 est que nous passons les valeurs sous forme de tableau et nous passons également un tableau d'identifiants (ids). Par exemple, avec ids=[3, 6, 13] et values=[100, 200, 5], les transferts résultants seront :

Transférer 100 jetons avec l'id 3 de _from vers _to.
Transférer 200 jetons avec l'id 6 de _from vers _to.
Transférer 5 jetons avec l'id 13 de _from vers _to.

Dans l'ERC-1155, nous n'avons que transferFrom, pas de transfer. Pour l'utiliser comme un transfer classique, il suffit de définir l'adresse d'origine (from) comme étant l'adresse qui appelle la fonction.

Solde par lots

L'appel balanceOf respectif de l'ERC-20 a également sa fonction partenaire avec prise en charge des lots. Pour rappel, voici la version ERC-20 :

// ERC-20
function balanceOf(address owner) external view returns (uint256);

// ERC-1155
function balanceOfBatch(
    address[] calldata _owners,
    uint256[] calldata _ids
) external view returns (uint256[] memory);

Encore plus simple pour l'appel de solde, nous pouvons récupérer plusieurs soldes en un seul appel. Nous passons le tableau des propriétaires, suivi du tableau des identifiants de jetons.

Par exemple, avec _ids=[3, 6, 13] et _owners=[0xbeef..., 0x1337..., 0x1111...], la valeur de retour sera :

[
    balanceOf(0xbeef...),
    balanceOf(0x1337...),
    balanceOf(0x1111...)
]

Approbation par lots

// ERC-1155
function setApprovalForAll(
    address _operator,
    bool _approved
) external;

function isApprovedForAll(
    address _owner,
    address _operator
) external view returns (bool);

Les approbations sont légèrement différentes de celles de l'ERC-20. Au lieu d'approuver des montants spécifiques, vous définissez un opérateur comme approuvé ou non approuvé via setApprovalForAll.

La lecture du statut actuel peut être effectuée via isApprovedForAll. Comme vous pouvez le voir, c'est une opération du tout ou rien. Vous ne pouvez pas définir combien de jetons approuver, ni même quelle classe de jetons.

Ceci est intentionnellement conçu dans un souci de simplicité. Vous ne pouvez tout approuver que pour une seule adresse.

Hook de réception

function onERC1155BatchReceived(
    address _operator,
    address _from,
    uint256[] calldata _ids,
    uint256[] calldata _values,
    bytes calldata _data
) external returns(bytes4);

Étant donné la prise en charge de l'EIP-165 (opens in a new tab), l'ERC-1155 prend en charge les hooks de réception uniquement pour les contrats intelligents. La fonction hook doit renvoyer une valeur magique prédéfinie de type bytes4 qui est donnée comme suit :

bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))

Lorsque le contrat récepteur renvoie cette valeur, on suppose que le contrat accepte le transfert et sait comment gérer les jetons ERC-1155. Super, fini les jetons bloqués dans un contrat !

Prise en charge des NFT

Lorsque l'offre n'est que de un, le jeton est essentiellement un jeton non fongible (NFT). Et comme c'est la norme pour l'ERC-721, vous pouvez définir une URL de métadonnées. L'URL peut être lue et modifiée par les clients, voir ici (opens in a new tab).

Règle de transfert sécurisé

Nous avons déjà abordé quelques règles de transfert sécurisé dans les explications précédentes. Mais examinons la plus importante de ces règles :

L'appelant doit être approuvé pour dépenser les jetons pour l'adresse _from ou l'appelant doit être égal à _from.
L'appel de transfert doit s'annuler si :
1. L'adresse _to est 0.
2. La longueur de _ids n'est pas la même que la longueur de _values.
3. L'un des soldes du ou des détenteurs pour le ou les jetons dans _ids est inférieur au(x) montant(s) respectif(s) dans _values envoyé(s) au destinataire.
4. Toute autre erreur se produit.

Remarque : Toutes les fonctions par lots, y compris le hook, existent également en versions sans lot. Cela est fait pour optimiser la consommation de gaz, considérant que le transfert d'un seul actif restera probablement la méthode la plus couramment utilisée. Nous les avons omises pour des raisons de simplicité dans les explications, y compris les règles de transfert sécurisé. Les noms sont identiques, il suffit de supprimer « Batch ».