Un article détaillé sur le jeton Pandora, illustrant la dualité entre image et monnaie : deviendra-t-il un nouveau paradigme pour l'émission d'actifs ?
TechFlow SélectionTechFlow Sélection
Un article détaillé sur le jeton Pandora, illustrant la dualité entre image et monnaie : deviendra-t-il un nouveau paradigme pour l'émission d'actifs ?
D'un point de vue technique, permettre aux jetons FT et NFT, fondamentalement opposés par nature, d'être utilisés conjointement est une idée nouvelle et intéressante.
Dédié à des analyses Web3 approfondiesRédaction : Haotian
Comment comprendre l'innovation du jeton « dualité token-NFT » @Pandora_ERC404 ? Il établit une relation symbiotique entre les FT et les NFT, résolvant ainsi le problème chronique de faible liquidité des NFT. D’un point de vue technique, combiner deux types de jetons nativement opposés – FT et NFT – est à la fois novateur et fascinant.
Quelles sont les innovations apportées par la norme ERC404 ? S’agit-il d’un nouveau paradigme pour l’émission d’actifs ? Et peut-elle interagir intelligemment avec TokenScript de @SmartLayer ? Voici mon analyse :
Tout d’abord, précisons que ERC404 n’est actuellement qu’une norme expérimentale, non encore intégrée comme proposition officielle EIP sur Ethereum. Pandora est le premier jeton créé selon cette nouvelle norme expérimentale. Le but d’ERC404 est de résoudre l’incompatibilité fondamentale entre la norme ERC20 (jetons fongibles) et la norme ERC721 (jetons non fongibles).
Par exemple, un utilisateur détient simultanément des jetons FT et des jetons NFT. Quand il décide de vendre un NFT, comment le contrat intelligent peut-il déterminer clairement son intention de vendre le NFT plutôt que le FT ? Même si cette intention est correctement identifiée, comment le contrat met-il à jour sans erreur les états de données distincts correspondants ? N’est-ce pas assez abstrait ?
En termes simples, dans le cadre d’un jeton ERC20, un contrat intelligent doit simplement gérer l’état du solde — une logique de stockage simple et claire basée sur l’ajout ou la soustraction. De même, sous la norme ERC721, gérer les transferts en fonction des ID de jetons NFT est également assez direct : chaque transfert concerne un ID spécifique.
Mais gérer simultanément ERC20 et ERC721 devient compliqué :
Le contrat doit d’abord déterminer si l’appel « Transfer » concerne un FT ou un NFT. Ensuite, lorsqu’il s’agit de modifier l’état d’un NFT, il faut aussi identifier précisément quel ID de NFT est concerné. Or, des protocoles comme Uniswap ne peuvent pas traiter directement les transactions de NFT. Il faut donc créer une couche de correspondance (mapping) entre FT et NFT afin qu’une transaction FT entraîne automatiquement une mise à jour de l’état du NFT associé.
La technologie clé de la norme expérimentale ERC404 réside ici : elle utilise un schéma de codage approximatif permettant aux quantités ERC20 et aux ID uniques ERC721 d’utiliser la même structure de données dans le stockage du contrat, tout en conservant leur distinction et indépendance.
Par exemple, supposons que vous possédiez 2,9 « haricots magiques » (ERC20) et 2 « cartes magiques » (ERC721, ID 101 et ID 102). Grâce au codage approximatif, les deux types de données peuvent être gérés ensemble : la quantité 2,9 peut être stockée comme une unité unique, tandis que les ID des cartes peuvent être marqués par un préfixe spécial, par exemple 1000000000000, bien supérieur au nombre total de jetons émis. Ainsi, lors des appels au contrat, il devient facile de distinguer ERC20 de ERC721.
Une fois cette étape franchie, pour gérer efficacement la relation symbiotique entre FT et NFT, il faut programmer une logique de « mapping » dans le contrat. Par exemple : lorsque vous détenez 1 jeton FT, le contrat vous crée automatiquement 1 NFT ; quand vous en avez 2, un second NFT est frappé automatiquement ; mais si votre solde FT tombe en dessous de 1, le contrat détruit votre NFT. Cette correspondance est simple à comprendre.
Alors, comment permettre à un NFT d’être échangé sur Uniswap, un protocole qui ne supporte que les FT ? La réponse : exploiter la relation de « mapping ». Laissez Uniswap traiter normalement le FT, et le NFT suivra automatiquement dans son changement de propriété. Si vous souhaitez vendre un NFT, vendez simplement le FT associé. Le contrat enregistrera automatiquement la diminution de 1 unité de FT dans votre portefeuille, puis détruira un NFT.
Les lecteurs attentifs auront remarqué un problème : si un utilisateur détient 2,9 FT et 2 NFT, que se passe-t-il lorsqu’il vend 1 FT ? Lequel des deux NFT sera détruit ? C’est en réalité une question très complexe, car le contrat ne sait pas quelle partie du FT a été vendue, et donc ne peut pas associer précisément le NFT à détruire. Stricto sensu, c’est une « faille » de la norme expérimentale ERC404.
Mais la technologie rencontre ici la tokenomie, créant une réaction chimique inattendue.
Une solution astucieuse consiste à concevoir un mécanisme de rafraîchissement de rareté des NFT, incitant les utilisateurs à transférer régulièrement leurs FT accumulés. Chaque transfert de FT déclenche la destruction et la recréation d’un NFT, ce qui revient à « rafraîchir » son niveau de rareté. Les utilisateurs ont alors tendance à séparer leurs FT pour éviter la perte de NFT rares, tout en cherchant à améliorer la rareté de leurs nouveaux NFT.
Ainsi, un bogue logique technique devient, grâce à une conception ingénieuse de rareté, un levier d’engagement utilisateur. Bien sûr, que faire si un utilisateur tient absolument à conserver plusieurs FT dans un seul portefeuille, tout en choisissant lui-même (non aléatoirement) quel NFT doit être détruit ?
Deux approches existent aujourd’hui : 1) Détruire selon l’ordre des ID de jetons, ce qui risque de supprimer accidentellement un NFT rare ; 2) Brûler le NFT le plus proche du prix plancher, mais cela repose sur une logique hors chaîne, vulnérable aux retards des oracles, et suppose que l’utilisateur ait déjà mis en vente ses NFT pour définir ce prix plancher — autrement dit, on intègre ici des données externes issues du marché NFT.
Plutôt que ces solutions complexes, pourquoi ne pas permettre à l’utilisateur de choisir directement dans son interface ? Cela nécessite alors d’introduire un framework comme TokenScript de Smartlayer, permettant de rendre les FT programmables côté frontend. Ainsi, l’utilisateur pourrait décider, lors d’une transaction FT, quel NFT prioriser à la destruction ou à la conservation. C’est exactement la fonctionnalité que vise @SmartLayer, mentionnée dès le début.
Concernant Smartlayer, il n’a en réalité aucun lien direct avec ERC404. ERC404 cherche simplement à doter les jetons d’une image NFT de base, tandis que Smartlayer repose sur une combinaison des standards ERC-5169 et TokenScript, visant fondamentalement à rendre les jetons FT exécutables de manière programmable. Les deux convergent fonctionnellement, mais Smartlayer va plus loin en complexité.
En résumé : TokenScript est un cadre open source permettant de définir de façon standardisée le comportement et les interactions des jetons numériques. Les émetteurs peuvent ainsi concevoir une interface frontale programmable pour leurs jetons. Dans le cas d’ERC404, un utilisateur pourrait, via l’interface Smartlayer, choisir quel NFT détruire en priorité ou marquer certains NFT rares pour les protéger. Dans un contexte plus large, comme les jeux, cela permettrait de nourrir, caresser son NFT-pet dans le portefeuille, ou lui ajouter des attributs d’évolution et de mise à niveau.
Au départ, en étudiant les travaux de Smartlayer, des concepts comme « jeton programmable », « jeton intelligent » ou « script externe exécutable associé au jeton » me semblaient extrêmement complexes. Mais la venue d’ERC404 m’a soudain éclairé : le dernier maillon manquant dans le standard ERC404, à savoir la gestion différenciée des NFT, ne pourrait-il pas justement être résolu par ce frontend intelligent de Smartlayer ?
Après lecture, ressentez-vous ce sentiment de « deux-en-un » ? Vous avez maintenant une bonne compréhension du Pandora basé sur ERC404, et une vision plus profonde de Smartlayer, bientôt lancé via TGE.
L’histoire montre que chaque innovation autour de l’émission d’actifs déclenche une longue phase de narration et d’adaptation. Que ce soit les inscriptions dans l’écosystème Bitcoin ou les jetons hybrides / programmables dans l’écosystème Ethereum, chacun continuera d’inspirer toutes sortes d’innovations et d’usages. Je ne sais pas encore comment ERC404 va évoluer, ni s’il interagira avec Smartlayer pour produire de nouvelles étincelles, mais le fait de pouvoir intégrer dans un même contrat intelligent deux standards de jetons jusqu’alors incompatibles constitue bel et bien une innovation de paradigme dans l’émission d’actifs.
Note : La norme ERC404 est toujours en phase expérimentale, susceptible de subir de nombreuses itérations. Cet article vise uniquement à vulgariser le sujet et ne prétend pas offrir une interprétation définitive de cette technologie. Je poursuivrai mon analyse dans de futurs contenus.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Haotian | CryptoInsight
