L’ERC721 est un standard de smart contract qui permet de normer les NFT.
En quoi ce standard est-il utile? Plusieurs raisons:
Faciliter la création de NFT, via l’existence d’un code standardisé que l’on peut reproduire et réutiliser facilement
Faire en sorte d’avoir des marketplace qui prennent en compte l’ensemble des fonctionnalités définies par le standard,
Avoir du code sécurisé, et partageable facilement entre développeurs
Nous avons déjà vu l’ERC20 lors du chapitre sur la DeFi, on va voir les points communs.
On utilise un standard défini par la norme ERC721. Ce standard est défini par des fonctions dont les en-têtes sont une interface de communication, et de vérification pour les marketplace réutilisant ce standard.
Regardons ce standard d’un peu plus près. Il est disponible ici:
On peut voir que pour satisfaire ce standard, on a besoin d’utiliser 3 events, et 9 fonctions, ainsi qu’un contrat, l’ERC165 pour vérifier les interfaces.
Ces fonctions définissent la manière de gérer la preuve de possession et son ownership dans la blockchain. Comme on peut le voir, les fonctions ne sont pas explicitement écrites, seules les en-têtes sont disponible, à nous de remplir ces fonctions.
Voici un exemple d’utilisation, dans les NFT historiques CryptoKitties: https://gist.github.com/arpit/071e54b95a81d13cb29681407680794f
Dans ce contrat (un peu daté, mais intéressant), il y a l’ERC721 avec uniquement les en-têtes, puis leur implémentation dans KittyOwnership, où chacune des fonctions est précisée.
Ce standard possède une implémentation dans la librairie OpenZeppelin, dont voici le smart contract: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol
Aussi, dans la doc d’OpenZeppelin on peut voir une utilisation avec une petite personnalisation: https://docs.openzeppelin.com/contracts/4.x/erc721
Ce standard mérite donc d’être réutilisé avec, pourquoi pas, une implémentation différente, tant qu’on ne change pas les en-têtes de fonctions. Cette implémentation, par une réécriture des fonctions du standard, permet la personnalisation des NFT. Mais on peut réutiliser le standard dans sa norme directement. Dans tous les cas, ce contrat permet de déployer des NFT facilement, et de manière sécurisée. (Faire attention de respecter les normes de la version 4 des contrats d’open Zeppelin. Token uri par exemple est géré dans une extension)
Petit détail, on peut lire dans le smart contract d’utilisation d’OpenZeppelin le concept de Mint de NFT. Ce concept met en place la création d’un nouveau NFT dans les mappings assurant la possession. Ainsi, quand on utilise ce contrat de la librairie, on doit faire une fonction pour assurer le mapping, selon un identifiant que l’on souhaite, selon les méthodes de création que l’on souhaite, et notamment dans l’utilisation de métadonnées.
Les metadatas, directement inscrites dans les contrats, sont notées dans le smart contract optionnel erc721Metadata.sol, ce qui permet de normer la manière dont on stock les metadatas des NFT. Elles sont définies par un nom, un symbol, mais surtout un tokenURI qui pointe vers l’URI de notre NFT. L’inscription dans la blockchain de cet URI permet de s’assurer de la perenité de notre objet digital, d’autant plus si il est sur un serveur comme IPFS que l’on a vu ensemble.
Enfin, ces métadatas elles-mêmes doivent être normées, comme indiqué sur la page de présentation de l’EIP. Un Json, et des tuples, qu’on peut aussi normer selon les demandes d’OpenSea pour pouvoir avoir ses NFT listés dessus: https://docs.opensea.io/docs/metadata-standards