Pendant des semaines, l’industrie du NFT a crié « LES PRIX DU GAZ SONT SI ÉLEVÉS L’ETHEREUM EST CASSÉ ».
Serrons les freins et examinons cela.
Vous verrez, les choses ne sont pas ce à quoi vous vous attendiez. Au lieu d’avoir une méthode de gestion efficace pour vos NFT préférés, les développeurs assemblent des pièces souvent sans trop prendre en compte les conséquences qui en découlent. Avec Open Zeppelin aléatoire et pièces copiées collées ensemble, bon nombre des collections les plus populaires sont les contrats les moins bien écrits de l’industrie.
Aujourd’hui, nous allons nous plonger dans cela et réaliser que donner des millions de dollars à des développeurs inexpérimentés n’est pas une réalité préférable. Le mérite d’avoir attiré mon attention sur ce point revient à squeebo_nft et le GoldenXnft équipe.
Pour les non-initiés, Open Zeppelin est une bibliothèque open source qui contient de nombreux contrats intelligents populaires qui sont utilisés dans l’ensemble de l’industrie NFT.
C’est une excellente entrée dans Solidity et prend une tonne de conjectures et de lutte initiale de vos premiers jours…
… mais en tant que développeur, on entendra souvent ne pas utiliser de bibliothèques pas complètement comprises…
Pourquoi?
Parce que le plus souvent, il y a un tas de choses dont vous n’avez pas besoin ou dont vous ne vous souciez pas pour votre usage spécifique. C’est ce qui nous est arrivé dans ce cycle.
Pour la durée de cet article, nous utilisons :
OpenZeppelin version 4.3.2 et Solidity 0.8.4.
Allons droit au but et commençons à courir avec une menthe d’essai 🧪 de :
Une transaction à 1 jeton, puis une transaction à 5 jetons.
Les résultats illustrent immédiatement le problème…
Monnaie avec Open Zeppelin : 204,83 $ (34,13 $/mention)
Frappe avec contrat optimisé : 80,24 $ (13,37 $/pièce)
C’est une énorme différence.
Maintenant, il est important de garder à l’esprit que dans ce test, nous avons une menthe de 1 et une menthe de 5. Bien que nous fassions des quantités différentes, le gaz utilisé par ces transactions de menthe n’évolue pas de manière linéaire.
Chaque fois que nous exécutons la transaction, nous vérifions que les exigences sont remplies quel que soit le nombre, mais si nous avons un nombre supérieur à un, nous n’avons pas besoin de vérifier les exigences à chaque fois et donc le gaz utilisé par menthe sur une quantité plus élevée menthes est plus faible. Hyper simple, non ?
Alors, quel est le problème ici ?
Prêt à l’emploi, Open Zeppelin ERC721Enumerable est livré avec une quantité excessive de traitement de transfert qui n’est tout simplement pas nécessaire pour la majorité des projets. C’est quoi ce traitement ?
Pour décomposer cela aussi simplement que possible : non seulement du gaz est gaspillé lors de la frappe, mais également à chaque fois que le jeton est transféré… Le propriétaire du jeton paie des frais bien plus élevés qu’il ne devrait l’être. Pourquoi? Développeurs inexpérimentés. Alors, la prochaine fois que vous vous demandez : « Pourquoi cela coûte-t-il 90 $ pour transférer ce jeton ? » vous avez presque assurément votre réponse.
Au lieu d’essayer de gérer le coût des transferts, la méthode de suivi peut être déplacée dans les fonctions de visualisation. En règle générale, un contrat de projet nécessitera quelques modifications pour s’adapter à cette méthode, mais il est assez facile de démarrer.
Il existe trois fonctions principales que les développeurs utilisent ERC721Enumerable. Assurons-nous que nous les traitons maintenant et que vous puissiez décider jusqu’où vous voulez aller en profondeur. Donc, au lieu d’utiliser la version fournie par Open Zeppelin créons la nôtre et assurons-nous d’avoir ces fonctions de base :
Remarques : Ce que vous remarquerez immédiatement, c’est que tokenOfOwnerByIndex() est extrêmement inefficace. C’est un sacrifice que nous faisons pour sauver la petite fortune de nos acheteurs.
Nous ne supprimons pas seulement quelques lignes, nous devons retravailler les choses dans une large mesure, vous voudrez donc vous assurer et tester chaque centimètre carré avant de mettre quoi que ce soit en production. Pour référence, ce fut le point de départ de tokenOfOwnerByIndex()
Incroyablement, ce n’est pas là que s’arrêtent les optimisations de coûts lors de l’utilisation d’Open Zeppelin. Nous pouvons aller plus loin dans cette analyse et examiner le contrat ERC721 de base.
Immédiatement, nous pouvons voir que nous avons pas mal de redondances que nous pouvons optimiser. Concentrons-nous cependant sur un élément clé :
Si vous êtes un développeur, vous savez que l’idée de stocker deux fois la même donnée est une très mauvaise pratique immédiatement. Mais, même si vous ne l’êtes pas, expliquons pourquoi.
Dans ce contrat, nous avons également la variable :
Et bien que nous ayons les propriétaires, nous connaissons également le totalSupply() de la collection à un moment donné. Cela signifie que nous connaissons déjà les équilibres par nature. Il faut juste bien gérer les données pour ne pas avoir besoin de stocker et d’utiliser des informations redondantes, surtout quand cela coûte plus cher !
Ainsi, si nous voulons parcourir nos propriétaires, nous gérons plutôt nos propriétaires sous forme de tableau. Immédiatement, nous avons supprimé un mappage que nous devons gérer et nous avons remplacé un mappage par un tableau d’adresses. Ce n’est pas un changement massif, mais il a des impacts massifs.
Une fois la structure finale déterminée, il est temps de tout mettre à jour, comme :
Et avec cela, nous allons aller de l’avant et mettre à jour la gestion de ces propriétaires comme :
Même pour le créateur général, ce n’est pas un effort discutable. Il y a deux autres choses importantes que nous devons d’abord examiner avant de pouvoir dire cela :
La quantité de gaz que vous économisez réellement l’écosystème.
👉 L’argent qui peut être économisé pendant le déploiement.
En tant que créateurs, nous devons voir la valeur de sauver notre communauté plusieurs centaines de milliers.
Dans un projet qui vend 10 000 jetons avec une guerre au gaz zéro absolu, plusieurs centaines de milliers de dollars restent dans l’écosystème. Si vous avez une guerre du gaz, cela peut devenir des millions.
Chaque centime compte.
Avec un cycle d’optimisation, nous pouvons réduire le coût de déploiement sur le réseau principal Ethereum de 2 004 $ à 1 760 $ avec quelques minutes de concentration…
Objectif atteint : 💪 Réduire encore plus le risque du créateur et réduire le coût de frappe pour chaque acheteur d’au moins 50 %, même pendant une guerre du gaz.
Compter sur Open Zeppelin pour prendre le relais en valait-il la peine ? Le temps gagné n’a-t-il pas été d’apprendre ce qu’il y avait dans le contrat intelligent valant les millions perdus dans le gaz et les projets stagnants ? Connaissez-vous une solution à cela? Est-ce que ça vaut la peine de faire un wrapper pour des projets sur un mauvais contrat ?
Peut-on revenir en arrière et annuler le temps ?
Ce n’est cependant pas la faute d’Open Zeppelin. Tant de fois, ils insistent pour comprendre ce qui se passe dans votre contrat, surtout avant de passer à la production…
Voici une liste de contrôle de base pour éviter ce problème dans votre projet :
Vérifiez tout ce qui se passe pendant le temps de transfert.
Limitez la quantité de stockage de données que vous obligez un monnayeur à payer.
Déplacez le traitement coûteux pour afficher les fonctions lorsque cela est possible.
L’industrie est mûre et cela permet à des erreurs folles comme celle-ci de ternir toute une industrie pendant tout un cycle de 🔁.
Rejoignez Coinmonks Telegram Channel et Youtube Channel pour en savoir plus sur le trading et l’investissement crypto
