EIP-6969 : Nouvelles idées pour la construction des métadonnées ERC et NFT

Alors que les NFT et les actifs tokenisés deviennent de plus en plus composables et dynamiques, les métadonnées sont devenues un goulot d'étranglement pour la scalabilité, la permanence et l'interopérabilité. Les pratiques actuelles en matière de métadonnées — le plus souvent du JSON servi via HTTP — sont fragiles, difficiles à versionner et sujettes aux interruptions de service. Une nouvelle orientation, surnommée informellement « EIP-6969 », explore comment les métadonnées ERC et NFT pourraient être construites pour la prochaine décennie : adressables par contenu, vérifiables, évolutives et conçues pour être conscientes de la chaîne.

Cet article présente une architecture pragmatique pour les métadonnées de type « EIP-6969 », montre comment en implémenter la majeure partie avec les normes existantes, et explique pourquoi cela est important dans un monde post-Cancun de L2 à haut débit et de comptes modulaires.

Pourquoi les métadonnées nécessitent une refonte

Les normes NFT originales, y compris les normes fondamentales ERC-721 et le standard multi-jetons ERC-1155, définissent un tokenURI qui pointe généralement vers du JSON hors chaîne. Bien que simple, les développeurs et les marketplaces rencontrent régulièrement :

• Fragilité et liens rompus en raison de la dépendance à des points d'accès HTTP centralisés.
• Manque de versionnage et de provenance fiables pour les collections en évolution.
• Difficulté à signaler les mises à jour des métadonnées aux indexeurs et aux interfaces utilisateur.
• Résolution incohérente multi-chaînes à travers les écosystèmes L1/L2.
• Signaux ambigus sur les redevances et les licences pour les créateurs.

Plusieurs EIP abordent déjà des parties de ce puzzle. Par exemple, ERC-4906 ajoute un événement pour signaler les mises à jour des métadonnées aux indexeurs ; EIP-2981 standardise les informations sur les redevances ; EIP-3668 (CCIP-Read) permet des lectures hors chaîne minimisant la confiance ; et EIP-1014 (CREATE2) permet des adresses de contrat déterministes pour les registres et les résolveurs. Pendant ce temps, la mise à niveau Cancun-Deneb d'Ethereum (avec EIP-4844) a matériellement amélioré la disponibilité des données pour les L2, ouvrant la voie à des approches de métadonnées plus sur chaîne ou semi-sur chaîne.

À quoi pourraient ressembler les métadonnées de type « EIP-6969 »

Considérez l'EIP-6969 non pas comme une seule interface, mais comme un plan combinant des registres sur chaîne, des données hors chaîne adressables par contenu, et une signalisation forte aux portefeuilles et aux marketplaces.

• Registres de métadonnées déterministes

  • Utilisez CREATE2 pour déployer un « Registre de métadonnées » par collection à une adresse prévisible.
  • Le registre stocke les engagements de schéma, les résolveurs par défaut, les stratégies de repli et les balises de version.
  • Permet des déploiements reproductibles sur différentes chaînes, réduisant l'ambiguïté et l'usurpation.

• Stockage adressable par contenu par défaut

  • Référencez les métadonnées par hachage plutôt que par une URL mutable ; résolvez via l'adressage par contenu IPFS ou Arweave Permaweb.
  • Miroirs HTTP optionnels pour la performance, mais toujours ancrés à un digest vérifiable.

• Métadonnées évolutives et signalées

  • Émettez des événements ERC-4906 lorsque les métadonnées au niveau du jeton ou de la collection changent, permettant des actualisations fiables.
  • Utilisez le versionnage sémantique dans le registre pour indiquer les changements de schéma ou les mises à niveau des résolveurs.

• Résolution hors chaîne vérifiable

  • Adoptez CCIP-Read pour les récupérations hors chaîne minimisant la confiance lorsque les données ne peuvent pas être stockées sur chaîne.
  • Signez les digests de métadonnées avec des données typées EIP-712 ; les portefeuilles et les marketplaces peuvent vérifier les signatures en utilisant EIP-1271 pour les comptes de contrat.

• URIs multi-ressources et conscientes de la chaîne

  • Intégrez les identifiants de chaîne CAIP-2 dans les URIs et les enregistrements du registre pour désambiguïser les variantes L1 vs L2, conformément à CAIP-2.
  • Privilégiez une conception « multi-ressources » : adresse de contenu principale plus miroirs optionnels (par exemple, CID IPFS + passerelle HTTPS + transaction Arweave).

• Schéma composable pour les NFT et les ERC fongibles

  • Publiez des schémas JSON ou JSON-LD pour la structure des traits, les attributs et les relations média afin de réduire l'ambiguïté pour les indexeurs ; consultez les directives des marketplaces comme les normes de métadonnées d'OpenSea.
  • Supportez des vues conscientes des rôles (créateur vs détenteur vs marketplace) tout en conservant un seul digest canonique par état de jeton.

• Implication optionnelle des comptes

  • Intégrez les contrôles de métadonnées avec des comptes intelligents modulaires via EIP-6900 (comptes modulaires) ou des contrôleurs liés aux jetons (par exemple, EIP-6551) lorsque les créateurs ont besoin de politiques programmables pour les mises à jour, les portes de licence ou la logique spécifique aux jetons.

Comment construire cela aujourd'hui avec les EIP existants

En attendant qu'un EIP formel soit finalisé, la majeure partie de l'architecture est implémentable à l'aide de normes éprouvées et de modèles simples :

1. Déployer un Registre de Métadonnées avec CREATE2

   • Stocker :
     • schemaHash (schéma adressé par contenu)
     • resolver (contrat ou point d'accès CCIP)
     • version (chaîne semver)
     • fallbacks (tableau d'URIs multi-ressources)
   • Détection d'interface via ERC-165.

2. Résoudre les métadonnées des jetons via CCIP-Read

   • La méthode sur chaîne renvoie un sélecteur indiquant au client de récupérer les données hors chaîne d'une origine autorisée.
   • La charge utile hors chaîne renvoie les métadonnées plus une signature EIP-712 ; les clients vérifient contre la clé publique d'un EOA ou un contrat EIP-1271.

3. Émettre des événements ERC-4906 lors des mises à jour

   • Pour les collections NFT avec des évolutions de traits ou de l'art dynamique, déclenchez MetadataUpdate(tokenId) ou BatchMetadataUpdate(fromTokenId, toTokenId).

4. Utiliser des URIs adressables par contenu partout

   • Épinglez le JSON canonique sur IPFS ou Arweave ; intégrez le CID/TX dans les enregistrements du registre.
   • Les miroirs peuvent améliorer la latence, mais les clients doivent faire confiance au digest.

5. Publier un schéma

   • Documentez les attributs, les relations média, l'animation et l'édition dans un schéma lisible par machine (par exemple, JSON Schema) et publiez le hachage du schéma dans le registre.
   • Alignez-vous sur les champs de données attendus par les marketplaces tels que les directives de métadonnées d'OpenSea.

6. Signaux de redevances et de licences

   • Implémentez EIP-2981 pour les redevances, et exposez les références de licence dans le cadre du schéma pour maintenir les métadonnées légales portables et vérifiables.

Modèles de conception qui portent leurs fruits

• Résolution en deux phases

  • Phase 1 : Lire les données du registre sur chaîne pour la version, le résolveur et le digest de contenu.
  • Phase 2 : Effectuer une récupération CCIP-Read ou hors chaîne, vérifier la signature par rapport au signataire attendu du résolveur, et comparer les digests.

• Cohérence Multi-chaînes

  • Utilisez des identifiants CAIP-2 aux côtés des adresses de registre spécifiques à la chaîne. Les marketplaces et les portefeuilles peuvent désambiguïser à quelle variante de chaîne un jeton appartient, améliorant l'expérience utilisateur inter-chaînes.

• Gouvernance et récupération

  • Les mises à jour du registre doivent être contrôlées par des politiques bien définies, idéalement via des comptes modulaires (EIP-6900) ou des rôles verrouillés dans le temps. Envisagez des mises à jour staged où un nouveau résolveur ou schéma devient actif après un délai.

• Mise en cache et revalidation

  • Les clients mettent en cache les charges utiles adressées par contenu ; revalidez lors des événements ERC-4906 ou des changements de version. Cela réduit la bande passante tout en gardant les données fraîches.

Considérations de sécurité

• Limites de confiance

  • Séparez clairement « qui peut signer les métadonnées » de « qui peut mettre à jour les résolveurs ». Utilisez des clés distinctes et publiez-les dans le registre.

• Hygiène des signatures

  • Privilégiez EIP-712 avec séparation de domaine, IDs de chaîne, expiration et nonce pour prévenir les rejeux et la confusion inter-domaines.

• Passerelles et miroirs

  • Si vous utilisez des miroirs HTTPS, appliquez des vérifications de digest côté client. Évitez de faire confiance à la disponibilité des passerelles pour l'authenticité ; fiez-vous à l'adressage par contenu.

• Compatibilité ascendante

  • Maintenez un tokenURI hérité pour une compatibilité minimale, mais pointez vers un digest adressé par contenu et incluez des références au registre pour les clients avancés.

Ce que cela signifie pour les utilisateurs et les marketplaces

Pour les collectionneurs, les métadonnées de type EIP-6969 signifient moins d'images brisées, des actualisations plus rapides et une provenance plus claire. Pour les marketplaces, les registres déterministes et une signalisation forte réduisent les heuristiques hors chaîne, améliorent la précision de l'indexation et réduisent les litiges sur les redevances ou les licences. Pour les créateurs, les politiques programmables deviennent pratiques : faire évoluer les traits après la frappe, créer des éditions ramifiées ou conditionner les mises à jour via des comptes modulaires, sans sacrifier la vérifiabilité.

La convergence des normes aide également aux outils. Les indexeurs peuvent s'appuyer sur les événements ERC-4906. Les portefeuilles peuvent vérifier les signatures avec EIP-1271. Les dapps multi-chaînes peuvent s'aligner sur CAIP-2 pour présenter des collections inter-chaînes cohérentes. Et l'adressage par contenu via IPFS ou Arweave maintient l'enregistrement canonique inviolable.

Une feuille de route prête pour 2025

• Commencez à migrer les collections vers des URIs adressées par contenu et publiez un hachage de schéma.
• Ajoutez un contrat de registre CREATE2 simple et émettez ERC-4906 lors des mises à jour.
• Implémentez CCIP-Read pour les données dynamiques qui ne peuvent pas résider entièrement sur chaîne ; signez les charges utiles avec EIP-712.
• Pour les nouvelles frappes sur les L2, exploitez la disponibilité des données activée par Cancun (aperçu) pour stocker plus de métadonnées sur chaîne ou dans des blobs, et ancrez les charges utiles hors chaîne à l'état de la chaîne.
• Explorez les contrôles de compte modulaires (EIP-6900) si vous avez besoin de politiques de mise à niveau programmables.

Réflexions finales et un conseil pratique

Même si les métadonnées évoluent vers des conceptions vérifiables, adressées par contenu et modulaires, une constante demeure : la signature est la racine de la confiance. Que vous soyez un créateur publiant un changement de schéma ou une marketplace vérifiant des charges utiles CCIP-Read, la signature sécurisée EIP-712 et l'isolation des clés sont essentielles.

Si vous préférez un portefeuille matériel pour une sécurité de clé plus forte, OneKey fournit un firmware open-source, une protection robuste par élément sécurisé et un support fluide pour les flux de signature modernes comme EIP-712 dans les dapps populaires. Alors que les architectures de métadonnées s'appuient de plus en plus sur des signatures claires et vérifiables — en particulier avec CCIP-Read et la vérification basée sur contrat via EIP-1271 — disposer d'une signature fiable et auditable dans votre flux de travail est une mise à niveau pratique pour les créateurs et les collectionneurs.

En adoptant ces modèles de type « EIP-6969 » dès aujourd'hui, l'écosystème peut rendre les métadonnées ERC et NFT plus durables, interopérables et pérennes, prêtes pour le monde multi-chaînes à haut débit qu'Ethereum et ses L2 livrent progressivement.