EIP-6969: Novas ideias para a construção de metadados de ERC e NFT

À medida que os NFTs e os ativos tokenizados se tornam cada vez mais compostos e dinâmicos, os metadados emergiram como um gargalo para escalabilidade, permanência e interoperabilidade. As práticas de metadados atuais — o mais comum é o JSON servido sobre HTTP — são frágeis, difíceis de versionar e propensas a inatividade. Uma nova direção informalmente denominada “EIP-6969” explora como os metadados de ERC e NFT poderiam ser construídos para a próxima década: com endereçamento de conteúdo, verificáveis, atualizáveis e cientes da blockchain por design.

Este artigo descreve uma arquitetura pragmática para metadados no “estilo EIP-6969”, mostra como implementar a maior parte disso com padrões existentes e explica por que isso importa em um mundo pós-Cancun de L2s de alta vazão e contas modulares.

Por que os metadados precisam de uma reformulação

Os padrões originais de NFT, incluindo o fundamental ERC-721 e o token multi ERC-1155, definem um tokenURI que geralmente é resolvido para JSON off-chain. Embora seja simples, desenvolvedores e marketplaces enfrentam rotineiramente:

• Fragilidade e links quebrados ao depender de endpoints HTTP centralizados
• Falta de versionamento confiável e proveniência para coleções em evolução
• Dificuldade em sinalizar atualizações de metadados para indexadores e UIs
• Resolução inconsistente multi-chain em ecossistemas L1/L2
• Sinais ambíguos de royalties e licenciamento para criadores

Vários EIPs já abordam partes deste quebra-cabeça. Por exemplo, o ERC-4906 adiciona um evento para sinalizar atualizações de metadados para indexadores; o EIP-2981 padroniza informações de royalties; o EIP-3668 (CCIP-Read) permite leituras off-chain com minimização de confiança; e o EIP-1014 (CREATE2) permite endereços de contrato determinísticos para registros e resolvedores. Enquanto isso, a atualização Cancun-Deneb do Ethereum (com EIP-4844) melhorou materialmente a disponibilidade de dados para L2s, abrindo caminho para mais abordagens de metadados on-chain ou semi-on-chain.

Como os metadados no “estilo EIP-6969” poderiam ser

Pense no EIP-6969 não como uma única interface, mas como um projeto que combina registros on-chain, dados off-chain com endereçamento de conteúdo e sinalização forte para carteiras e marketplaces.

• Registros de metadados determinísticos

  • Use CREATE2 para implantar um “Registro de Metadados” por coleção em um endereço previsível.
  • O registro armazena compromissos de esquema, resolvedores padrão, estratégias de fallback e tags de versão.
  • Permite implantações reproduzíveis em diferentes blockchains, reduzindo a ambiguidade e a falsificação.

• Armazenamento com endereçamento de conteúdo por padrão

  • Referencie metadados por hash em vez de um URL mutável; resolva via endereçamento de conteúdo IPFS ou Arweave Permaweb.
  • Espelhos HTTP opcionais para desempenho, mas sempre ancorados a um digest verificável.

• Metadados atualizáveis e sinalizados

  • Emita eventos ERC-4906 quando os metadados em nível de token ou de coleção mudarem, permitindo atualizações confiáveis.
  • Use versionamento semântico no registro para denotar alterações de esquema ou atualizações de resolvedor.

• Resolução off-chain verificável

  • Adote CCIP-Read para buscas off-chain com minimização de confiança onde os dados não podem residir on-chain.
  • Assine digests de metadados com dados tipados EIP-712; carteiras e marketplaces podem verificar assinaturas usando EIP-1271 para contas de contrato.

• URIs cientes da blockchain e multi-recurso

  • Incorpore identificadores de blockchain CAIP-2 em URIs e registros para desambiguar variantes L1 vs. L2, consistente com CAIP-2.
  • Prefira um design “multi-recurso”: endereço de conteúdo principal mais espelhos opcionais (por exemplo, CID IPFS + gateway HTTPS + TX Arweave).

• Esquema compostável para NFTs e ERCs fungíveis

  • Publique JSON Schema ou JSON-LD para estrutura de traits, atributos e relações de mídia para reduzir a ambiguidade para indexadores; consulte orientações de marketplaces como padrões de metadados da OpenSea.
  • Suporte a visualizações com reconhecimento de função (criador vs. detentor vs. marketplace) mantendo um único digest canônico por estado do token.

• Envolvimento opcional da conta

  • Integre controles de metadados com contas inteligentes modulares através de EIP-6900 (contas modulares) ou controladores vinculados a tokens (por exemplo, EIP-6551) quando os criadores precisarem de políticas programáveis para atualizações, portões de licenciamento ou lógica específica do token.

Como construir isso hoje com EIPs existentes

Até que um EIP formal seja lançado, a maior parte da arquitetura é implementável usando padrões comprovados e padrões simples:

1. Implante um Registro de Metadados com CREATE2

   • Armazene:
     • schemaHash (esquema com endereçamento de conteúdo)
     • resolver (contrato ou endpoint CCIP)
     • version (string semver)
     • fallbacks (array de URIs multi-recurso)
   • Detecção de interface via ERC-165.

2. Resolva metadados de token via CCIP-Read

   • O método on-chain retorna um seletor instruindo o cliente a buscar dados off-chain de uma origem permitida.
   • A carga útil off-chain retorna metadados mais uma assinatura EIP-712; os clientes verificam contra a chave pública de um EOA ou um contrato EIP-1271.

3. Emita eventos ERC-4906 em atualizações

   • Para coleções de NFT com evolução de traits ou arte dinâmica, acione MetadataUpdate(tokenId) ou BatchMetadataUpdate(fromTokenId, toTokenId).

4. Use URIs com endereçamento de conteúdo em todos os lugares

   • Fixe JSON canônico no IPFS ou Arweave; incorpore o CID/TX nos registros.
   • Espelhos podem melhorar a latência, mas os clientes devem confiar no digest.

5. Publique um esquema

   • Documente atributos, relações de mídia, animação e edição em um esquema legível por máquina (por exemplo, JSON Schema) e publique o hash do esquema no registro.
   • Alinhe-se com os campos de dados esperados por marketplaces como a orientação de metadados da OpenSea.

6. Sinais de royalties e licenciamento

   • Implemente EIP-2981 para royalties e exponha referências de licença como parte do esquema para manter metadados legais portáteis e verificáveis.

Padrões de design que compensam

• Resolução em duas fases

  • Fase 1: Leia os dados do registro on-chain para versão, resolvedor e digest de conteúdo.
  • Fase 2: Execute a leitura CCIP ou busca off-chain, verifique a assinatura contra o signatário esperado do resolvedor e compare os digests.

• Consistência multi-chain

  • Use identificadores CAIP-2 ao lado de endereços de registro específicos da blockchain. Marketplaces e carteiras podem desambiguar a qual variante de blockchain um token pertence, melhorando a experiência do usuário cross-chain.

• Governança e recuperação

  • As atualizações de registro devem ser controladas por políticas bem definidas, idealmente via contas modulares (EIP-6900) ou funções com bloqueio de tempo. Considere atualizações escalonadas onde um novo resolvedor ou esquema se torna ativo após um atraso.

• Cache e revalidação

  • Clientes armazenam em cache cargas úteis com endereçamento de conteúdo; revalide em eventos ERC-4906 ou alterações de versão. Isso reduz a largura de banda enquanto mantém os dados atualizados.

Considerações de segurança

• Limites de confiança

  • Separe claramente “quem pode assinar metadados” de “quem pode atualizar resolvedores”. Use chaves distintas e publique-as no registro.

• Higiene de assinatura

  • Prefira EIP-712 com separação de domínio, IDs de blockchain, expiração e nonce para evitar reexecução e confusão cross-domínio.

• Gateways e espelhos

  • Se estiver usando espelhos HTTPS, imponha verificações de digest no lado do cliente. Evite confiar na disponibilidade do gateway para autenticidade; confie no endereçamento de conteúdo.

• Compatibilidade com versões anteriores

  • Mantenha um tokenURI legado para compatibilidade mínima, mas aponte para um digest com endereçamento de conteúdo e inclua referências de registro para clientes avançados.

O que isso significa para usuários e marketplaces

Para colecionadores, metadados no estilo EIP-6969 significam menos imagens quebradas, atualizações mais rápidas e proveniência mais clara. Para marketplaces, registros determinísticos e sinalização forte reduzem as heurísticas off-chain, melhoram a precisão da indexação e diminuem disputas sobre royalties ou licenças. Para criadores, políticas programáveis se tornam práticas: evoluir traits pós-mint, ramificar edições ou controlar atualizações por meio de contas modulares — sem sacrificar a verificabilidade.

A convergência de padrões também ajuda as ferramentas. Indexadores podem confiar nos eventos ERC-4906. Carteiras podem verificar assinaturas com EIP-1271. DApps multi-chain podem se alinhar com CAIP-2 para apresentar coleções cross-chain coerentes. E o endereçamento de conteúdo via IPFS ou Arweave mantém o registro canônico à prova de adulteração.

Um roteiro pronto para 2025

• Comece a migrar coleções para URIs com endereçamento de conteúdo e publique um hash de esquema.
• Adicione um contrato de registro CREATE2 simples e emita ERC-4906 nas atualizações.
• Implemente CCIP-Read para dados dinâmicos que não podem residir totalmente on-chain; assine cargas úteis com EIP-712.
• Para novas emissões em L2s, aproveite a disponibilidade de dados habilitada pelo Cancun (visão geral) para armazenar mais metadados on-chain ou em blobs, e ancore cargas úteis off-chain ao estado da blockchain.
• Explore controles de conta modulares (EIP-6900) se precisar de políticas de atualização programáveis.

Pensamentos finais e uma dica prática

Mesmo que os metadados se movam em direção a designs verificáveis, com endereçamento de conteúdo e modulares, uma constante permanece: a assinatura é a raiz da confiança. Seja você um criador publicando uma alteração de esquema ou um marketplace verificando cargas úteis CCIP-Read, a assinatura segura EIP-712 e o isolamento de chaves são essenciais.

Se você prefere uma carteira de hardware para maior segurança de chave, a OneKey oferece firmware de código aberto, proteção robusta de elemento seguro e suporte impecável para fluxos de assinatura modernos como EIP-712 em dApps populares. À medida que as arquiteturas de metadados dependem cada vez mais de assinaturas claras e verificáveis — especialmente com CCIP-Read e verificação baseada em contrato via EIP-1271 — ter uma assinatura confiável e auditável em seu fluxo de trabalho é uma atualização prática tanto para criadores quanto para colecionadores.

Ao adotar esses padrões no “estilo EIP-6969” hoje, o ecossistema pode tornar os metadados de ERC e NFT mais duráveis, interoperáveis e preparados para o futuro — prontos para o mundo multi-chain e de alta vazão que o Ethereum e seus L2s estão entregando firmemente.