Comment convertir un NFT de la norme ERC-721 à la norme ERC-1155 ?

Comprendre l'incompatibilité fondamentale

1. ERC-721 et ERC-1155 sont des normes structurellement distinctes avec des interfaces non interopérables.

2. Un jeton ERC-721 est défini par un seul tokenId uint256 mappé à un propriétaire, tandis qu'un jeton ERC-1155 est identifié par une paire : (adresse, uint256 _id, montant uint256), permettant une sémantique multi-actifs au sein d'un seul contrat.

3. Il n'existe aucun mécanisme en chaîne pour « réécrire » ou « rebaser » un jeton ERC-721 existant en un actif ERC-1155 sans rompre sa provenance, son historique de propriété et son lien avec les métadonnées.

4. La blockchain enregistre séparément les transitions d'état de chaque norme ; aucune opération Ethereum EVM ne peut muter le bytecode ou la disposition de stockage d'un contrat ERC-721 déployé pour se conformer au comportement ERC-1155.

5. Toute affirmation de conversion directe dénature la façon dont les contrats intelligents et la propriété de jetons sont immuablement ancrés dans la chaîne.

Voies de migration pratiques

1. Un nouveau contrat ERC-1155 doit être déployé avec une logique de mappage clairement définie, par exemple en attribuant chaque tokenId ERC-721 d'origine à un _id correspondant dans le nouveau contrat.

2. Les détenteurs de jetons doivent explicitement s'inscrire via une fonction de réclamation ou de frappe, exigeant souvent une vérification de la signature ou une preuve basée sur le portefeuille de la propriété antérieure de l'ERC-721.

3. Le processus de migration implique généralement la gravure du jeton ERC-721 d'origine en cas de réclamation réussie, appliqué via des attestations hors chaîne ou des vérifications de solde en chaîne.

4. Les URI de métadonnées peuvent être préservées en réutilisant le même chemin de hachage ou de passerelle IPFS, mais le contexte de résolution d'URI passe de l'URI par jeton d'ERC-721 à l'URI par-_id d'ERC-1155, ce qui nécessite potentiellement une génération JSON dynamique pour les variantes semi-fongibles.

5. Les portefeuilles et les places de marché doivent mettre à jour leur logique de détection de jetons pour reconnaître la nouvelle adresse du contrat et interpréter balanceOf(address, uint256) au lieu deownerOf(uint256).

Implications en matière de sécurité et de confiance

1. Les utilisateurs conservent le contrôle total sur l’opportunité de migrer ; aucun transfert automatique ne se produit, éliminant ainsi les risques de mouvements forcés d’actifs.

2. L'empoisonnement par la réentrée et l'approbation restent pertinents pendant les flux de réclamation par lots : safeBatchTransferFrom doit être associé à des modificateurs non réentrants et à une validation d'entrée stricte.

3. Le contrat de migration lui-même devient une cible de grande valeur ; il doit subir un audit formel avant le lancement et éviter les clés d'administration centralisées après le déploiement.

4. La recherche de propriété devient plus complexe : le même actif visuel peut désormais exister à travers deux chaînes de contrôle : l'une ancrée dans l'histoire de l'ERC-721, l'autre dans la délivrance de l'ERC-1155, ce qui rend l'analyse médico-légale moins déterministe.

5. Le pontage économe en gaz entre les normes nécessite des preuves Merkle précalculées ou des couches de vérification optimistes, et non des instructions EVM natives.

Compatibilité Marketplace et indexeur

1. OpenSea et Blur traitent ERC-721 et ERC-1155 comme des classes d'actifs distinctes ; les listes des jetons migrés apparaissent sous la nouvelle adresse du contrat, et non sous l'ancienne.

2. Les données historiques sur les prix planchers, les graphiques de volume et les classements de rareté ne sont pas automatiquement conservés : la version ERC-1155 commence avec un historique de négociation nul.

3. Les indexeurs comme Dune Analytics ou Nansen nécessitent de nouveaux modèles de requête pour agréger les soldes en utilisant le schéma basé sur l'identifiant plutôt que l'énumération tokenId.

4. Les interfaces utilisateur du portefeuille affichent les actifs ERC-1155 différemment : en regroupant les avoirs _id identiques dans des compteurs empilables au lieu de répertorier chaque tokenId individuellement.

5. Les outils de rareté conçus pour les traits ERC-721 échouent sur ERC-1155 à moins que les métadonnées ne suivent une structure déterministe et énumérable compatible avec les heuristiques d'extraction de traits.

Foire aux questions

Q : Puis-je utiliser la même adresse de portefeuille pour conserver les versions ERC-721 et ERC-1155 de la même œuvre d'art numérique ? Oui. Une seule adresse Ethereum peut contenir des jetons provenant de n’importe quel nombre de contrats conformes, quelle que soit la norme. Les requêtes de solde diffèrent : ERC-721 utiliseownerOf(tokenId), ERC-1155 utilise balanceOf(address, id).

Q : La migration vers ERC-1155 affecte-t-elle le statut juridique ou le droit d'auteur de l'œuvre numérique sous-jacente ? Non. Les conditions de droits d'auteur et de licence sont régies par des accords hors chaîne ou des champs de licence en chaîne dans les métadonnées, et non par des spécifications standard de jeton.

Q : Pourquoi certains projets déploient-ils simultanément les contrats ERC-721 et ERC-1155 au lieu de migrer ? Le déploiement simultané préserve la compatibilité existante tout en activant de nouvelles fonctionnalités, telles que les transferts par lots d'éléments utilitaires, sans perturber les ressources destinées aux collectionneurs telles que les photos de profil ou les éditions artistiques génératives.

Q : Est-il possible de vérifier qu'un jeton ERC-1155 correspond réellement à un jeton ERC-721 spécifique après la migration ? Uniquement si le contrat de migration intègre des preuves cryptographiques vérifiables, comme des hachages de messages signés ou une inclusion de racine Merkle, liant le tokenId d'origine au nouveau _id. En l'absence de telles preuves, la correspondance reste une assertion hors chaîne.