Metadati e identità

EN fonte principale · P08-L05 · 45 minuti stimati · needs_review

Un token può cambiare nome o immagine senza cambiare il suo mint esatto. Due mint diversi possono mostrare un marchio identico. Un URI on-chain immutabile può comunque puntare a contenuti esterni modificabili. Queste distinzioni contano quando un analista riferisce che un asset «è ufficiale».

Questa lezione insegna un confronto dei metadati con provenienza esplicita. Mantiene i metadati NFT come utile esempio fondamentale, concentrandosi sull’identità dei token; non è richiesto il lancio di NFT né un flusso completo di valutazione NFT.

Separare l’oggetto dalla sua descrizione

L’identità è la tupla rete/indirizzo/oggetto verificata in P08-L01. I metadati descrivono l’oggetto. Un logo o un nome familiare può aiutare un utente a riconoscere un candidato, ma nessuno dei due lo identifica univocamente. Preservare la tupla quando cambiano i campi visualizzati.

L’interfaccia ERC-20 rende nome e simbolo opzionali [S08-ERC20]. Un campo visualizzato assente non cancella l’esistenza di un oggetto. Viceversa, campi visualizzati correttamente non autenticano l’affiliazione a un marchio. Leggere i metadati come un insieme di affermazioni dotate di un meccanismo, non come un certificato.

Per un asset Solana che usa Metaplex Token Metadata, esaminare il collegamento dell’account dei metadati, l’autorità di aggiornamento e il flag di modificabilità. In questo programma specifico, l’autorità di aggiornamento di un asset modificabile può cambiare determinati campi dei metadati e alcune autorità delegate hanno ambiti aggiuntivi [S08-METADATA]. Non universalizzare queste regole a ogni implementazione di metadati.

Seguire l’intera catena descrittiva

Una visualizzazione può provenire da un campo on-chain, un URI on-chain, una risposta JSON off-chain, un URL di immagine in quella risposta e una cache della piattaforma. Ogni livello ha una fonte distinta e un possibile percorso di aggiornamento. Un analista dovrebbe registrare da dove proviene effettivamente il nome visualizzato.

Se l’URI è stabile ma la sua risposta HTTP cambia, il contenuto è cambiato senza una modifica dell’URI on-chain. Se un flag on-chain impedisce futuri aggiornamenti dell’account dei metadati, ciò non congela di per sé tutti i server remoti o le cache. L’archiviazione indirizzata dal contenuto richiede il controllo del riferimento e del payload effettivi, anziché fidarsi dell’etichetta di un marchio di archiviazione.

Registrare un payload acquisito o un digest riproducibile insieme al contesto di acquisizione quando si svolge una revisione reale. Non inventare un digest da uno screenshot. Il materiale dell’esercizio fornisce campi di payload brevi e letterali, così da confrontare i contenuti senza richieste di rete dal vivo.

Distinguere modificabilità e autenticità

Un flag di modificabilità descrive un controllo, non se i dati siano veritieri. Metadati falsi possono essere immutabili; metadati legittimi possono richiedere aggiornamenti. Un percorso di aggiornamento revocato non può autenticare retroattivamente una relazione con l’emittente.

Nell’implementazione Token Metadata esaminata, isMutable=false respinge la sostituzione dell’oggetto descrittivo Data. Ciò non prova da solo che ogni campo dell’account Metadata — o l’autorità di aggiornamento — sia congelato; tali operazioni hanno autorizzazioni e invarianti separate. Verificare l’istruzione e la versione del programma distribuito prima di affermare l’immutabilità di un campo o di un’autorità specifici. [S08-METADATA-CODE] Limitare questa affermazione al meccanismo esaminato e non sostenere un congelamento universale di ogni presentazione. I campi orientati agli NFT, come creatori o collezioni verificati, hanno semantiche proprie; un segno di spunta non è una garanzia generale dell’economia o dell’identità del token.

Un dominio nei metadati è autodichiarato da chi ha fornito quei metadati. Un sito che elenca lo stesso token è un’altra dichiarazione. Secondo controllo e provenienza, possono essere due direzioni di un’unica autoaffermazione anziché corroborazione indipendente. Preservare la distinzione tra collegamenti dichiarati e associazione verificata indipendentemente.

Corroborare con attenzione

Partire da una comunicazione autenticata dell’emittente e confrontare rete/indirizzo esatti. Indicare come è stata stabilita la provenienza della comunicazione. Posizione nei risultati di ricerca, numero di follower e marchi copiati non stabiliscono il controllo dell’emittente.

Se la provenienza dell’emittente non è fornita, classificare la relazione come dichiarata e non verificata. Se una pubblicazione autenticata in modo affidabile nomina un mint diverso, si può riferire una mancata corrispondenza con quella dichiarazione. Non passare dalla mancata corrispondenza a un’accusa legale di frode; comunicazioni compromesse o pubblicazioni obsolete sono spiegazioni alternative che richiedono indagine.

Archiviare l’affermazione pertinente e il suo contesto di pubblicazione/acquisizione. Una pagina web attuale non può provare cosa mostrasse durante un lancio precedente senza un appropriato record storico. Separare l’ora del recupero attuale dalla data dichiarata di una pubblicazione.

Gestire visualizzazioni discordanti

Quando due interfacce mostrano nomi diversi per lo stesso oggetto, identificare stato on-chain, contesto di acquisizione del payload e politica della cache. Non «risolvere» la discordanza scegliendo silenziosamente il marchio più attraente. Il rapporto può preservare l’oggetto esatto lasciando irrisolta la discrepanza di presentazione.

Quando due oggetti mostrano nomi identici, preservare entrambi gli identificatori e confrontarli indipendentemente. Uno può essere una rappresentazione wrapped o una copia deliberata; la sola presentazione identica non può classificare la relazione. Un’affermazione relativa a un bridge richiede propri meccanismi e prove di custodia, fuori da questo esercizio sui metadati.

Gli aggiornamenti della visualizzazione non dovrebbero sovrascrivere prove già acquisite. Un rapporto necessita della versione su cui si è basato, affinché un revisore successivo possa riprodurre la decisione. Le etichette sintetiche S0/S1 di questa lezione sono contesti dell’esercizio, non timestamp di osservazione effettivi.

Scrivere il risultato circoscritto

Risultati utili distinguono identità esatta, campi visualizzati, controlli modificabili e corrispondenza con l’emittente. «Stesso mint, nome off-chain cambiato a S1» è specifico. «Il token ha cambiato identità» è fuorviante se l’indirizzo resta fisso.

Stato commerciale, uso di Creator Lab e completamento dell’Academy non possono migliorare la classificazione delle prove sui metadati. Un’analisi dei metadati non fornisce una previsione di prezzo né un certificato di sicurezza. Può comunque sostenere un’indagine precisa sull’identità senza accesso a strumenti a pagamento.

• Metadati: campi descrittivi associati a un oggetto.
• URI (identificatore uniforme di risorsa): riferimento che identifica una risorsa; questo materiale lo usa per individuare un payload esterno.
• Payload: contenuto recuperato da quella risorsa.
• Autorità di aggiornamento: permesso che governa un’operazione specifica sui metadati.
• Modificabilità: possibilità di cambiamenti consentita da un meccanismo.
• Corroborazione: prove che sostengono una relazione dichiarata oltre una dichiarazione non verificata.

ILLUSTRATIVE — FIX-P08-05. SIM-SOL-A in S0/S1 fittizi. Gli URL terminanti in .invalid sono etichette formative non funzionanti.

Non sono forniti un inventario degli aggiornamenti delegati né una pubblicazione autenticata dell’emittente. Tutti i payload sono sintetici.

OBSERVED nel materiale: il mint esatto e i campi on-chain di A restano fissi tra S0/S1; i contenuti URI differiscono. B è un mint diverso con un marchio simile.

INFERRED: la presentazione remota cambiata di A non richiede un cambiamento dell’URI on-chain fornito. D1/D2 formano un ciclo di dichiarazioni.

UNKNOWN: autenticità dell’emittente, controllo del dominio, comportamento della cache e ambito completo degli aggiornamenti delegati.

INSUFFICIENT EVIDENCE: il flag di immutabilità di B non autentica il suo logo o emittente. D1/D2 da soli non possono stabilire corroborazione indipendente.

Equiparare cambiamenti del nome a cambiamenti del mint; chiamare contenuto immutabile un URI invariato; presumere che metadati immutabili siano veri; contare dichiarazioni reciproche come verifica indipendente; trattare etichette di collezione/creatore come approvazioni economiche.

Confrontare M1/M2 e J1/J2 separatamente. Spiegare se il mint di A è cambiato. Valutare l’affermazione di B di essere «l’Alpha ufficiale perché immutabile». Classificare D1/D2 ed elencare tre richieste successive di prove.

• Preservare l’oggetto esatto confrontando le visualizzazioni.
• Ricondurre i campi a dati on-chain, URI, payload o cache.
• Registrare permessi di modifica e ambito del meccanismo.
• Separare modificabilità e autenticità.
• Preservare le dichiarazioni reciproche come non verificate finché non corroborate.

I metadati sono una catena descrittiva con meccanismi di aggiornamento. L’identità esatta può restare fissa mentre cambia il contenuto visualizzato.

Immutabile non significa autenticato. Un URI stabile non è automaticamente contenuto stabile. Lo stesso marchio non significa stesso mint o emittente.

Disegnare la catena mint→metadati→URI→payload→immagine con colonne S0/S1. Contrassegnare i campi on-chain come uguali e il payload come diverso. Confrontare MINT-B separatamente; usare un ciclo di dichiarazioni D1/D2 tratteggiato, mai un distintivo ufficiale.

Cambiamenti di visualizzazione e collegamenti dichiarati illustrativi; associazione all’emittente irrisolta.

Usare SVG/HTML deterministici o grafici con alternative testuali, blu navy scuro/nero e accenti sobri ciano, blu elettrico e viola. Etichettare ogni quantità e incertezza. A 390px impilare i pannelli; verifica a 768px/desktop e RTL arabo restano lavoro futuro sulle risorse. Tenere gli identificatori in LTR e invariati assi fattuali/direzioni degli archi. Usare soltanto il marchio ufficiale BlockAssay fornito se viene aggiunto il marchio. Entrambi i record sono specifiche, non risorse consegnate.

Usare RADAR per lo scopo educativo circoscritto della lezione soltanto se sono verificati supporto della rete, identità esatta, campi e provenienza. Questo contenuto non afferma alcun endpoint runtime o capacità del fornitore. Usare il materiale offline incorporato senza accesso a pagamento. I dati mancanti restano sconosciuti; non sono necessari collegamento a wallet, firma di transazioni, lancio di token o operazioni dal vivo. Progressi nell’Academy, pagamenti e referral non cambiano mai le prove di Radar. Un Diagnostic Passport preserva osservazioni e limiti, non una previsione di prezzo o un certificato di sicurezza.

• Metaplex Token Metadata: aggiornare asset — Autorità di aggiornamento, flag di modificabilità e campi di metadati modificabili in questo programma specifico. Verificato 2026-09-30.
• Standard di token ERC-20 — Interfaccia standard; nome, simbolo e decimali opzionali; non certificazione di privilegi o identità. Verificato 2026-09-30.
• Implementazione Metaplex Token Metadata (riferimento fissato) — Il controllo is_mutable respinge la sostituzione di Data; new_update_authority è gestita separatamente secondo la sua autorizzazione e le sue invarianti. Verificato 2026-10-05.

La documentazione sostiene meccanismi, non valori dei dataset fittizi. Tutti gli esempi e i record degli esercizi sono materiale originale ILLUSTRATIVE, fissato in questo file. S0/S1 sono etichette di contesto sintetiche; observedAt è null perché non è stata raccolta alcuna misurazione di un registro dal vivo o storico. Riesaminare documentazione e comportamento effettivamente distribuito prima di qualsiasi pubblicazione o integrazione.

P08-L06 dopo l’esercizio svolto e la revisione del quiz.