EIP-6969: Nuevas ideas para la construcción de metadatos de ERC y NFT

A medida que los NFT y los activos tokenizados se vuelven cada vez más componibles y dinámicos, los metadatos se han convertido en un cuello de botella para la escalabilidad, la permanencia y la interoperabilidad. Las prácticas de metadatos actuales —en su mayoría JSON servido a través de HTTP— son frágiles, difíciles de versionar y propensas a tiempos de inactividad. Una nueva dirección, informalmente denominada "EIP-6969", explora cómo los metadatos de ERC y NFT podrían construirse para la próxima década: direccionables por contenido, verificables, actualizables y conscientes de la cadena por diseño.

Este artículo describe una arquitectura pragmática para metadatos "estilo EIP-6969", muestra cómo implementar la mayor parte con estándares existentes y explica por qué esto es importante en un mundo post-Cancún de L2 de alto rendimiento y cuentas modulares.

Por qué los metadatos necesitan una reconsideración

Los estándares NFT originales, incluyendo el fundamental ERC-721 y el multiobjeto ERC-1155, definen un tokenURI que normalmente resuelve a JSON fuera de la cadena. Si bien es simple, los desarrolladores y los mercados se enfrentan habitualmente a:

• Fragilidad y enlaces rotos al depender de puntos finales HTTP centralizados.
• Falta de versionado confiable y procedencia para colecciones en evolución.
• Dificultad para señalar actualizaciones de metadatos a indexadores e interfaces de usuario.
• Resolución inconsistente multicanal en ecosistemas L1/L2.
• Señales de regalías y licencias ambiguas para los creadores.

Varios EIP ya abordan partes de este rompecabezas. Por ejemplo, ERC-4906 agrega un evento para señalar actualizaciones de metadatos a los indexadores; EIP-2981 estandariza la información de regalías; EIP-3668 (CCIP-Read) permite lecturas fuera de la cadena con confianza minimizada; y EIP-1014 (CREATE2) permite direcciones de contrato deterministas para registros y resolutores. Mientras tanto, la actualización Cancun-Deneb de Ethereum (con EIP-4844) mejoró materialmente la disponibilidad de datos para L2, abriendo la puerta a enfoques de metadatos más en cadena o semi-en cadena.

Cómo podrían ser los metadatos "estilo EIP-6969"

Piense en EIP-6969 no como una interfaz única, sino como un plano que combina registros en cadena, datos fuera de cadena direccionables por contenido y señalización sólida a billeteras y mercados.

• Registros de metadatos deterministas

  • Use CREATE2 para implementar un "Registro de Metadatos" por colección en una dirección predecible.
  • El registro almacena compromisos de esquema, resolutores predeterminados, estrategias de respaldo y etiquetas de versión.
  • Permite implementaciones reproducibles en diferentes cadenas, reduciendo la ambigüedad y la suplantación.

• Almacenamiento direccionable por contenido por defecto

  • Referencie metadatos por hash en lugar de una URL mutable; resuelva a través del direccionamiento por contenido de IPFS o Arweave Permaweb.
  • Espejos HTTP opcionales para rendimiento, pero siempre anclados a un resumen verificable.

• Metadatos actualizables y señalizados

  • Emita eventos ERC-4906 cuando los metadatos a nivel de token o de colección cambien, permitiendo actualizaciones confiables.
  • Use versionado semántico en el registro para denotar cambios de esquema o actualizaciones de resolutores.

• Resolución fuera de cadena verificable

  • Adopte CCIP-Read para búsquedas fuera de cadena con confianza minimizada donde los datos no puedan residir en la cadena.
  • Firme resúmenes de metadatos con datos tipificados EIP-712; las billeteras y los mercados pueden verificar firmas usando EIP-1271 para cuentas de contrato.

• URIs conscientes de la cadena y multirecurso

  • Incorpore identificadores de cadena CAIP-2 en URIs y registros para desambiguar variantes L1 frente a L2, de acuerdo con CAIP-2.
  • Prefiera un diseño de "multirecurso": dirección de contenido principal más espejos opcionales (por ejemplo, CID de IPFS + puerta de enlace HTTPS + TX de Arweave).

• Esquema componible para NFTs y ERC fungibles

  • Publique JSON Schema o JSON-LD para la estructura de atributos, atributos y relaciones de medios para reducir la ambigüedad para los indexadores; consulte la guía de mercados como los estándares de metadatos de OpenSea.
  • Admite vistas conscientes de roles (creador vs. poseedor vs. mercado) manteniendo un único resumen canónico por estado del token.

• Participación opcional de cuentas

  • Integre controles de metadatos con cuentas inteligentes modulares a través de EIP-6900 (cuentas modulares) o controladores vinculados a tokens (por ejemplo, EIP-6551) cuando los creadores necesiten políticas programables para actualizaciones, puertas de acceso a licencias o lógica específica del token.

Cómo construir esto hoy con EIP existentes

Hasta que aterrice un EIP formal, la mayor parte de la arquitectura es implementable utilizando estándares probados y patrones sencillos:

1. Implementar un Registro de Metadatos con CREATE2

   • Almacenar:
     • schemaHash (esquema direccionable por contenido)
     • resolver (contrato o punto final CCIP)
     • version (cadena semver)
     • fallbacks (matriz de URIs multirecurso)
   • Detección de interfaz a través de ERC-165.

2. Resolver metadatos de tokens a través de CCIP-Read

   • El método en cadena devuelve un selector que instruye al cliente a recuperar datos fuera de la cadena de un origen permitido.
   • La carga útil fuera de cadena devuelve metadatos más una firma EIP-712; los clientes verifican contra la clave pública de un EOA o un contrato EIP-1271.

3. Emitir eventos ERC-4906 en actualizaciones

   • Para colecciones de NFT con evoluciones de atributos o arte dinámico, active MetadataUpdate(tokenId) o BatchMetadataUpdate(fromTokenId, toTokenId).

4. Usar URIs direccionables por contenido en todas partes

   • Fije el JSON canónico en IPFS o Arweave; incruste el CID/TX en los registros del registro.
   • Los espejos pueden mejorar la latencia, pero los clientes deben confiar en el resumen.

5. Publicar un esquema

   • Documente atributos, relaciones de medios, animaciones y ediciones en un esquema legible por máquina (por ejemplo, JSON Schema) y publique el hash del esquema en el registro.
   • Alinearse con los campos de datos esperados por los mercados como la guía de metadatos de OpenSea.

6. Señales de regalías y licencias

   • Implemente EIP-2981 para regalías y exponga referencias de licencias como parte del esquema para mantener los metadatos legales portátiles y verificables.

Patrones de diseño que dan sus frutos

• Resolución en dos fases

  • Fase 1: Leer datos del registro en cadena para obtener la versión, el resolutor y el resumen de contenido.
  • Fase 2: Realizar CCIP-Read o búsqueda fuera de cadena, verificar la firma contra el firmante esperado del resolutor y comparar resúmenes.

• Consistencia multicanal

  • Use identificadores CAIP-2 junto con direcciones de registro específicas de la cadena. Los mercados y las billeteras pueden desambiguar a qué variante de cadena pertenece un token, mejorando la experiencia de usuario entre cadenas.

• Gobernanza y recuperación

  • Las actualizaciones del registro deben ser controladas por políticas bien definidas, idealmente a través de cuentas modulares (EIP-6900) o roles bloqueados en el tiempo. Considere actualizaciones escalonadas donde un nuevo resolutor o esquema se active después de un retraso.

• Almacenamiento en caché y revalidación

  • Los clientes almacenan en caché cargas útiles direccionables por contenido; revalidar en eventos ERC-4906 o cambios de versión. Esto reduce el ancho de banda mientras mantiene los datos actualizados.

Consideraciones de seguridad

• Límites de confianza

  • Separe claramente "quién puede firmar metadatos" de "quién puede actualizar resolutores". Use claves distintas y publíquelas en el registro.

• Higiene de las firmas

  • Prefiera EIP-712 con separación de dominios, IDs de cadena, vencimiento y nonce para prevenir repeticiones y confusión entre dominios.

• Puertas de enlace y espejos

  • Si usa espejos HTTPS, imponga verificaciones de resumen en el lado del cliente. Evite confiar en la disponibilidad de la puerta de enlace para la autenticidad; confíe en el direccionamiento por contenido.

• Compatibilidad con versiones anteriores

  • Mantenga un tokenURI heredado para una compatibilidad mínima, pero apunte a un resumen direccionable por contenido e incluya referencias de registro para clientes avanzados.

Lo que esto significa para usuarios y mercados

Para los coleccionistas, los metadatos estilo EIP-6969 significan menos imágenes rotas, actualizaciones más rápidas y procedencia más clara. Para los mercados, los registros deterministas y la señalización sólida reducen las heurísticas fuera de cadena, mejoran la precisión de la indexación y disminuyen las disputas sobre regalías o licencias. Para los creadores, las políticas programables se vuelven prácticas: evolucionar atributos post-acuñación, ramificar ediciones o restringir actualizaciones a través de cuentas modulares, sin sacrificar la verificabilidad.

La convergencia de estándares también ayuda a las herramientas. Los indexadores pueden confiar en eventos ERC-4906. Las billeteras pueden verificar firmas con EIP-1271. Las dapps multicanal pueden alinearse en CAIP-2 para presentar colecciones coherentes entre cadenas. Y el direccionamiento por contenido a través de IPFS o Arweave mantiene el registro canónico a prueba de manipulaciones.

Una hoja de ruta lista para 2025

• Comience a migrar colecciones a URIs direccionables por contenido y publique un hash de esquema.
• Agregue un contrato de registro CREATE2 simple y emita ERC-4906 en actualizaciones.
• Implemente CCIP-Read para datos dinámicos que no pueden residir completamente en la cadena; firme cargas útiles con EIP-712.
• Para nuevas acuñaciones en L2, aproveche la disponibilidad de datos habilitada por Cancun (resumen) para almacenar más metadatos en la cadena o en blobs, y ancle las cargas útiles fuera de cadena al estado de la cadena.
• Explore controles de cuentas modulares (EIP-6900) si necesita políticas de actualización programables.

Reflexiones finales y un consejo práctico

Incluso a medida que los metadatos avanzan hacia diseños verificables, direccionables por contenido y modulares, una constante permanece: la firma es la raíz de la confianza. Ya sea que sea un creador que publica un cambio de esquema o un mercado que verifica cargas útiles de CCIP-Read, la firma segura de EIP-712 y el aislamiento de claves son esenciales.

Si prefiere una billetera de hardware para una mayor seguridad de claves, OneKey proporciona firmware de código abierto, protección robusta de elementos seguros y soporte fluido para flujos de firma modernos como EIP-712 en dapps populares. Dado que las arquitecturas de metadatos dependen cada vez más de firmas claras y verificables —especialmente con CCIP-Read y verificación basada en contratos a través de EIP-1271—, tener una firma confiable y auditable en su flujo de trabajo es una mejora práctica tanto para creadores como para coleccionistas.

Al adoptar estos patrones "estilo EIP-6969" hoy, el ecosistema puede hacer que los metadatos de ERC y NFT sean más duraderos, interoperables y preparados para el futuro, listos para el mundo multicanal de alto rendimiento que Ethereum y sus L2 están entregando de manera constante.