EIP-6969: Neue Ideen für die Erstellung von ERC- und NFT-Metadaten

Da NFTs und tokenisierte Vermögenswerte zunehmend komponierbar und dynamisch werden, haben sich Metadaten als Engpass für Skalierbarkeit, Dauerhaftigkeit und Interoperabilität herausgestellt. Heutige Metadatenpraktiken – meist JSON über HTTP – sind fragil, schwer zu versionieren und anfällig für Ausfallzeiten. Eine neue Richtung, informell als „EIP-6969“ bezeichnet, untersucht, wie ERC- und NFT-Metadaten für das nächste Jahrzehnt konstruiert werden könnten: von Grund auf inhaltsadressiert, verifizierbar, aufrüstbar und kettenbewusst.

Dieser Artikel skizziert eine pragmatische Architektur für Metadaten im „EIP-6969-Stil“, zeigt, wie die meisten davon mit bestehenden Standards implementiert werden können, und erklärt, warum dies in einer Post-Cancun-Welt mit hochdurchsatzigen L2s und modularen Konten von Bedeutung ist.

Warum Metadaten überdacht werden müssen

Die ursprünglichen NFT-Standards, einschließlich des grundlegenden ERC-721 und des Multi-Token-ERC-1155, definieren eine tokenURI, die typischerweise auf Off-Chain-JSON verweist. Obwohl dies einfach ist, stehen Entwickler und Marktplätze regelmäßig vor folgenden Herausforderungen:

• Fragilität und Link-Rot bei der Abhängigkeit von zentralisierten HTTP-Endpunkten
• Mangel an vertrauenswürdiger Versionierung und Herkunft für sich entwickelnde Sammlungen
• Schwierigkeit, Metadaten-Updates an Indexer und UIs zu signalisieren
• Inkonsistente Multi-Chain-Auflösung über L1/L2-Ökosysteme hinweg
• Mehrdeutige Lizenz- und Lizenzierungssignale für Ersteller

Mehrere EIPs befassen sich bereits mit Teilen dieses Rätsels. Zum Beispiel fügt ERC-4906 ein Ereignis hinzu, um Metadaten-Updates an Indexer zu signalisieren; EIP-2981 standardisiert Royalty-Informationen; EIP-3668 (CCIP-Read) ermöglicht vertrauensminimierte Off-Chain-Lesevorgänge; und EIP-1014 (CREATE2) ermöglicht deterministische Vertragsadressen für Registrierungsstellen und Resolver. In der Zwischenzeit hat das Ethereum Cancun-Deneb-Upgrade (mit EIP-4844) die Datenverfügbarkeit für L2s materiell verbessert und die Tür für mehr On-Chain- oder Semi-On-Chain-Metadatenansätze geöffnet.

Wie Metadaten im „EIP-6969-Stil“ aussehen könnten

Betrachten Sie EIP-6969 nicht als eine einzige Schnittstelle, sondern als einen Bauplan, der On-Chain-Registrierungsstellen, inhaltsadressierte Off-Chain-Daten und starke Signalisierung an Wallets und Marktplätze kombiniert.

• Deterministische Metadaten-Registrierungsstellen

  • Verwenden Sie CREATE2, um eine „Metadaten-Registrierungsstelle“ pro Sammlung unter einer vorhersagbaren Adresse bereitzustellen.
  • Die Registrierungsstelle speichert Schemaverpflichtungen, Standard-Resolver, Fallback-Strategien und Versions-Tags.
  • Ermöglicht reproduzierbare Bereitstellungen über Ketten hinweg und reduziert Mehrdeutigkeit und Spoofing.

• Inhaltsadressierte Speicherung als Standard

  • Verweisen Sie Metadaten per Hash statt einer veränderlichen URL; lösen Sie über IPFS Content Addressing oder Arweave Permaweb auf.
  • Optionale HTTP-Spiegel für die Leistung, aber immer an einen verifizierbaren Digest gebunden.

• Aufrüstbare, signalisierte Metadaten

  • Geben Sie ERC-4906-Ereignisse aus, wenn Token- oder Sammlungs-Metadaten geändert werden, was zuverlässige Aktualisierungen ermöglicht.
  • Verwenden Sie semantische Versionierung in der Registrierungsstelle, um Schemaänderungen oder Resolver-Upgrades zu kennzeichnen.

• Verifizierbare Off-Chain-Auflösung

  • Übernehmen Sie CCIP-Read für vertrauensminimierte Off-Chain-Abrufe, bei denen Daten nicht On-Chain leben können.
  • Signieren Sie Metadaten-Digests mit EIP-712 typisierten Daten; Wallets und Marktplätze können Signaturen mit EIP-1271 für Vertrags-Konten verifizieren.

• Kettenbewusste, Multi-Ressourcen-URIs

  • Integrieren Sie CAIP-2 Ketten-Identifikatoren in URIs und Registrierungsdatensätze, um L1- vs. L2-Varianten zu disambiguieren, im Einklang mit CAIP-2.
  • Bevorzugen Sie ein „Multi-Ressourcen“-Design: primäre Inhaltsadresse plus optionale Spiegel (z. B. IPFS CID + HTTPS-Gateway + Arweave TX).

• Komponierbares Schema für NFTs und fungible ERCs

  • Veröffentlichen Sie JSON-Schema oder JSON-LD für die Struktur von Merkmalen, Attributen und Medienbeziehungen, um Mehrdeutigkeiten für Indexer zu reduzieren; siehe Marktplatz-Richtlinien wie OpenSea's Metadata Standards.
  • Unterstützen Sie rollenbasierte Ansichten (Ersteller vs. Halter vs. Marktplatz), während ein einzelner kanonischer Digest pro Token-Zustand beibehalten wird.

• Optionale Konto-Beteiligung

  • Integrieren Sie Metadaten-Kontrollen mit modularen Smart Accounts über EIP-6900 (Modular Accounts) oder Token-gebundene Controller (z. B. EIP-6551), wenn Ersteller programmierbare Richtlinien für Updates, Lizenz-Gates oder token-spezifische Logik benötigen.

Wie man das heute mit bestehenden EIPs baut

Bis ein formelles EIP landet, ist die Architektur größtenteils mit bewährten Standards und einfachen Mustern implementierbar:

1. Bereitstellen einer Metadaten-Registrierungsstelle mit CREATE2

   • Speichern:
     • schemaHash (inhaltsadressiertes Schema)
     • resolver (Vertrag oder CCIP-Endpunkt)
     • version (semver-String)
     • fallbacks (Array von Multi-Ressourcen-URIs)
   • Schnittstellenerkennung über ERC-165.

2. Token-Metadaten über CCIP-Read auflösen

   • On-Chain-Methode gibt einen Selector zurück, der den Client anweist, Off-Chain-Daten von einem zulässigen Ursprung abzurufen.
   • Off-Chain-Payload gibt Metadaten plus eine EIP-712-Signatur zurück; Clients verifizieren gegen den öffentlichen Schlüssel eines EOA oder einen EIP-1271-Vertrag.

3. ERC-4906-Ereignisse bei Updates ausgeben

   • Für NFT-Sammlungen mit sich entwickelnden Merkmalen oder dynamischer Kunst lösen Sie MetadataUpdate(tokenId) oder BatchMetadataUpdate(fromTokenId, toTokenId) aus.

4. Inhaltsadressierte URIs überall verwenden

   • Heften Sie kanonisches JSON an IPFS oder Arweave an; betten Sie die CID/TX in Registrierungsdatensätze ein.
   • Spiegel können die Latenz verbessern, aber Clients sollten dem Digest vertrauen.

5. Ein Schema veröffentlichen

   • Dokumentieren Sie Attribute, Medienbeziehungen, Animationen und Editionen in einem maschinenlesbaren Schema (z. B. JSON Schema) und veröffentlichen Sie den Schema-Hash in der Registrierungsstelle.
   • Richten Sie sich nach den von Marktplätzen erwarteten Datenfeldern, wie z. B. OpenSea's Metadata Guidance.

6. Royalty- und Lizenzsignale

   • Implementieren Sie EIP-2981 für Royalties und stellen Sie Lizenzreferenzen als Teil des Schemas bereit, um rechtliche Metadaten portabel und verifizierbar zu halten.

Designmuster, die sich auszahlen

• Zwei-Phasen-Auflösung

  • Phase 1: Lesen von On-Chain-Registrierungsdaten für Version, Resolver und Content-Digest.
  • Phase 2: Durchführung von CCIP-Read oder Off-Chain-Abruf, Verifizierung der Signatur gegen den erwarteten Signierer des Resolvers und Vergleich der Digests.

• Multi-Chain-Konsistenz

  • Verwenden Sie CAIP-2 Identifikatoren neben ketten-spezifischen Registrierungsadressen. Marktplätze und Wallets können disambiguieren, zu welcher Kettenvariante ein Token gehört, und so die Cross-Chain-UX verbessern.

• Governance und Wiederherstellung

  • Registrierungsaktualisierungen sollten durch klar definierte Richtlinien gesteuert werden, idealerweise über modulare Konten (EIP-6900) oder zeitgesteuerte Rollen. Erwägen Sie gestaffelte Updates, bei denen ein neuer Resolver oder ein neues Schema nach einer Verzögerung aktiv wird.

• Caching und Revalidierung

  • Clients cachen inhaltsadressierte Payloads; revalidieren Sie bei ERC-4906-Ereignissen oder Versionsänderungen. Dies reduziert die Bandbreite und hält die Daten aktuell.

Sicherheitsüberlegungen

• Vertrauensgrenzen

  • Trennen Sie klar, „wer Metadaten signieren kann“ von „wer Resolver aufrüsten kann“. Verwenden Sie eindeutige Schlüssel und veröffentlichen Sie diese in der Registrierungsstelle.

• Signatur-Hygiene

  • Bevorzugen Sie EIP-712 mit Domain-Trennung, Chain-IDs, Ablaufdatum und Nonce, um Replay- und Cross-Domain-Verwirrung zu verhindern.

• Gateways und Spiegel

  • Wenn HTTPS-Spiegel verwendet werden, erzwingen Sie clientseitige Digest-Prüfungen. Vertrauen Sie nicht auf die Verfügbarkeit von Gateways für die Authentizität; verlassen Sie sich auf Inhaltsadressierung.

• Abwärtskompatibilität

  • Behalten Sie eine Legacy-tokenURI für minimale Kompatibilität bei, verweisen Sie aber auf einen inhaltsadressierten Digest und fügen Sie Registrierungsreferenzen für fortgeschrittene Clients hinzu.

Was das für Benutzer und Marktplätze bedeutet

Für Sammler bedeuten Metadaten im EIP-6969-Stil weniger kaputte Bilder, schnellere Aktualisierungen und klarere Herkunft. Für Marktplätze reduzieren deterministische Registrierungsstellen und starke Signalisierung Off-Chain-Heuristiken, verbessern die Indexierungsgenauigkeit und reduzieren Streitigkeiten über Royalties oder Lizenzen. Für Ersteller werden programmierbare Richtlinien praktisch: Merkmale nach dem Minting weiterentwickeln, Editionen verzweigen oder Updates über modulare Konten steuern – ohne die Verifizierbarkeit zu opfern.

Die Standardisierung konvergiert auch und hilft der Tooling-Entwicklung. Indexer können sich auf ERC-4906-Ereignisse verlassen. Wallets können Signaturen mit EIP-1271 verifizieren. Multi-Chain-Dapps können sich auf CAIP-2 abstimmen, um kohärente Cross-Chain-Sammlungen darzustellen. Und die Inhaltsadressierung über IPFS oder Arweave hält den kanonischen Datensatz manipulationssicher.

Eine Roadmap für 2025

• Beginnen Sie mit der Migration von Sammlungen zu inhaltsadressierten URIs und der Veröffentlichung eines Schema-Hashes.
• Fügen Sie einen einfachen CREATE2-Registrierungsvertrag hinzu und geben Sie ERC-4906-Ereignisse bei Updates aus.
• Implementieren Sie CCIP-Read für dynamische Daten, die nicht vollständig On-Chain leben können; signieren Sie Payloads mit EIP-712.
• Nutzen Sie für neue Mints auf L2s die Cancun-fähige Datenverfügbarkeit (Übersicht), um mehr Metadaten On-Chain oder in Blobs zu speichern und Off-Chain-Payloads an den Kettenzustand zu binden.
• Erwägen Sie die Steuerung durch modulare Konten (EIP-6900), wenn Sie programmierbare Update-Richtlinien benötigen.

Abschließende Gedanken und ein praktischer Tipp

Auch wenn sich Metadaten hin zu verifizierbaren, inhaltsadressierten und modularen Designs bewegen, bleibt eine Konstante bestehen: Die Signatur ist die Wurzel des Vertrauens. Ob Sie ein Ersteller sind, der eine Schemaänderung veröffentlicht, oder ein Marktplatz, der CCIP-Read-Payloads verifiziert – sicheres EIP-712-Signing und Schlüsselisolierung sind unerlässlich.

Wenn Sie eine Hardware-Wallet für stärkere Schlüsselsicherheit bevorzugen, bietet OneKey Open-Source-Firmware, robusten Secure-Element-Schutz und reibungslose Unterstützung für moderne Signing-Flows wie EIP-712 in beliebten dApps. Da Metadaten-Architekturen zunehmend auf klare, verifizierbare Signaturen angewiesen sind – insbesondere mit CCIP-Read und vertragsbasierter Verifizierung über EIP-1271 –, ist eine zuverlässige, prüfbare Signatur in Ihrem Workflow ein praktisches Upgrade für Ersteller und Sammler gleichermaßen.

Durch die Übernahme dieser Muster im „EIP-6969-Stil“ noch heute kann das Ökosystem ERC- und NFT-Metadaten haltbarer, interoperabler und zukunftssicherer machen – bereit für die Multi-Chain-Welt mit hohem Durchsatz, die Ethereum und seine L2s stetig liefern.