Coder un contrat intelligent NFT minimaliste dans Solidity On Ethereum: un guide pratique

@thebojdaLaszlo Fazekas

Développeur indépendant, activiste ENVIENTA, blogueur

NFT est un nouveau / ancien mot à la mode du monde de la blockchain. La norme NFT (EIP-721) a été créé en 2018, mais après CrptoKitties, ce champ était relativement silencieux.

De nos jours, les NFT sont de retour à la mode, et tout le monde veut faire du NFT à partir de tout. Vous pouvez vendre vos arts ou vos tweets, ou tout ce que vous pouvez imaginer sous forme de NFT. Mais quel est ce truc mystique de NFT?

NFT n’est pas un gros problème. Comme ERC20 Les jetons (fongibles), les NFT (jetons non fongibles) sont également de simples «bases de données» sur la blockchain.

Alors qu’un contrat de jeton ERC20 stocke les soldes des adresses Ethereum, le contrat NFT stocke les ID uniques -> les attributions d’adresses Ethereum. Lorsque vous vous créez un NFT, le contrat de jeton attribue l’ID de jeton unique à votre adresse Ethereum.

Techniquement, cet identifiant unique est le NFT lui-même.

Vous pouvez le vendre ou acheter d’autres NFT, ce qui correspond à une réaffectation de l’ID. Les métadonnées peuvent être attribuées à l’ID (par un URI) qui représente la chose derrière le NFT (ex.: Une image, un tweet, etc.). C’est tout. Facile, non? J’ai dit, NFT n’est pas un gros problème …

Bien qu’un NFT ne soit pas une chose compliquée, un contrat NFT peut être assez complexe. Si vous jetez un oeil à Implémentation de 0xcert, vous trouverez une logique de jeton complexe et de nombreuses variables d’état internes.

Le problème de la complexité est le coût de transaction élevé. Dans cet article, je vais montrer comment créer un contrat NFT minimaliste mais entièrement fonctionnel sur la blockchain Ethereum.

Tout d’abord, jetez un œil à certaines des variables d’état de l’implémentation de 0xcert:

mapping (address => uint256[]) internal ownerToIds; 
mapping (uint256 => uint256) internal idToOwnerIndex; 
mapping (uint256 => address) internal idToOwner; 
mapping (address => uint256) private ownerToNFTokenCount;

le

ownerToIds

le mappage contient les identifiants de jeton attribués à l’adresse Ethereum,

idToOwner

est un identifiant de jeton -> mappage d’adresse Ethereum,

idToOwnerIndex

affecte l’ID de jeton à l’index du tableau de jetons du propriétaire, et enfin,

ownerToNFTokenCount

attribue l’adresse Ethereum du propriétaire au nombre de jetons (combien de NFT appartiennent au propriétaire).

Comme vous le voyez, cette structure de données est fortement redondante, car chaque mappage peut être calculé à partir de la première structure ownerToIds.

Tous ces mappages sont stockés sur la blockchain, et tous doivent être gérés dans les méthodes du contrat. Malheureusement, tous sont nécessaires si nous voulons implémenter la norme de jeton ERC-721. Alors, que pouvons-nous faire pour réduire la complexité et le coût transactionnel des appels de méthode?

Si la compatibilité ERC-721 n’est pas nécessaire, nous pouvons faire une astuce simple. Dans ce cas, nous ne pouvons stocker sur la blockchain que les éléments absolument nécessaires.

Tout autre élément peut être stocké dans une base de données externe. Si nous stockons les soldes de jetons, les listes de jetons, etc. dans un stockage externe (non-blockchain), nous n’avons pas besoin des mappages redondants. Le contrat sera plus simple et les transactions seront moins chères. Après la théorie, jetons un œil au code:

Seulement 24 lignes de code. Pas mal. Mais s’agit-il vraiment d’un contrat NFT entièrement fonctionnel? Voyons voir. Il dispose de 2 méthodes: menthe et transfert. La méthode mint crée un nouveau jeton NFT. Il a 2 paramètres

_to

et

_ipfsHash

. Le premier paramètre est l’adresse Ethereum cible qui possédera le jeton nouvellement créé.

Le deuxième paramètre est un hachage unique qui pointe vers les métadonnées sur IPFS. Dans la spécification originale ERC-721, les métadonnées sont pointées par un

tokenURI

. Pourquoi utilisons-nous un hachage IPFS à la place? Il y a plusieurs raisons.

Un hachage IPFS ne fait que 32 octets, donc l’écrire dans la blockchain est moins cher qu’une chaîne URI. La deuxième raison est que IPFS est immuable. Le contenu ne peut pas être modifié, car s’il change, le hachage IPFS changera également. Ainsi, stocker les données sur IPFS et écrire le hachage dans la blockchain revient à écrire les données elles-mêmes dans la blockchain, mais beaucoup moins cher.

le menthe La méthode lit la valeur actuelle de la

tokenCounter

variable pour obtenir un ID de jeton unique. La méthode incrémente cette variable à chaque appel, de sorte que l’ID de jeton sera absolument unique. La méthode stocke l’ID de jeton – Attribution d’adresse Ethereum dans le

idToOwner

mapping, qui est le seul à cartographier ce que nous stockons sur la blockchain. Dans la dernière étape, la méthode émet un événement Mint, qui sera très important plus tard.

le transfert la méthode a deux paramètres

_to

et

_tokenId

. Le premier paramètre est l’adresse cible qui possédera le NFT, et le deuxième paramètre est l’ID du jeton. La première ligne de la méthode vérifie la propriété du jeton à l’aide du

idToOwner

cartographie. Seul le propriétaire du jeton peut appeler la méthode de transfert. Si le jeton appartient à l’appelant, la méthode modifie l’affectation dans le mappage et émet un événement de transfert.

Ces deux méthodes sont suffisantes pour un NFT entièrement fonctionnel. Mais qu’en est-il des soldes, des demandes de propriété, etc.? Voici la base de données externe. Lorsqu’un contrat émet un un événement, il sera stocké sur la blockchain dans les logs.

Ces journaux sont disponibles via le API JSON-RPC directement, ou vous pouvez utiliser l’API JavaScript pour les lire. Ces journaux contiennent l’historique complet des transactions, ils contiennent donc toutes les informations nécessaires. Puisqu’ils sont stockés sur la blockchain, à chaque instant, une base de données peut être construite à partir d’eux qui contient la propriété du jeton, les soldes et toutes les autres données nécessaires.

Pour le montrer, vérifions les méthodes ERC-721 et comment une base de données externe peut fournir les données.

balanceOf

,

ownerOf

– Ceux-ci peuvent être facilement calculés à partir des événements Mint et Transfer

approve

,

setApprovalForAll

,

getApproved

,

isApprovedForAll

– Notre NFT minimaliste ne fournit pas de logique d’approbation, seul le propriétaire peut transférer les jetons. Si nécessaire, cette fonctionnalité peut être implémentée par un deuxième mappage.

safeTransferFrom

,

transferFrom

– La sécurité du transfert peut être vérifiée en externe, et le paramètre n’a pas de sens ici, car nos jetons ne peuvent être transférés que par le propriétaire.

tokenURI

– L’URI du jeton peut être généré à partir de la partie hachage IPFS de l’événement Mint.

totalSupply

,

tokenByIndex

,

tokenOfOwnerByIndex

– Ceux-ci peuvent être calculés facilement à partir des événements Mint et Transfer.

Comme vous pouvez le voir, notre jeton NFT minimaliste peut faire tout ce qu’un jeton ERC-721 peut faire à l’exception de la logique d’approbation, mais il peut être implémenté si nécessaire.

Histoires liées

Mots clés