Metadati NFT off chain: perché il token sopravvive al contenuto, come si legge il puntatore del contratto e le sei verifiche da fare prima di acquisire.
Acabashi / CC BY 4.0
Il riquadro grigio compare senza preavviso. Ieri al posto dell’opera c’era un’immagine, oggi c’è l’icona di un file che il browser non riesce a caricare. Il token è ancora lì, l’indirizzo risulta proprietario, la cronologia dei trasferimenti è intatta. Manca soltanto quello che si pensava di aver acquisito.
Non è un guasto momentaneo né un problema del portafoglio. È la conseguenza prevedibile di un’architettura in cui il registro conserva un puntatore e il contenuto vive altrove, su un’infrastruttura che qualcuno deve pagare, rinnovare e mantenere accesa. Quando quel qualcuno smette, il puntatore continua a puntare nel vuoto.
La parte scomoda è che la verifica costa dieci minuti e va fatta prima. Dopo serve soltanto a stabilire con precisione quale anello si è rotto, e nessuno dei rimedi disponibili rimette in piedi un server spento.
Dove si interrompe la catena
- Sul registro. Restano l’identificativo, il proprietario e una stringa di testo che indica dove cercare il resto.
- Due salti. Dal contratto al documento descrittivo, dal documento al file: sono due collegamenti indipendenti e ciascuno può rompersi da solo.
- L’errore più comune. Un indirizzo che passa da un dominio o da un intermediario controllato da una sola parte.
- Il potere residuo. Molti contratti permettono a chi li amministra di riscrivere quel puntatore dopo la cessione.
- La difesa. Leggere il puntatore prima, salvarne una copia con l’impronta del file e sapere chi può modificarlo.
Che cosa registra davvero il contratto
Un contratto conforme allo standard dei token non fungibili tiene una corrispondenza fra un numero e un indirizzo. Quella corrispondenza è l’unica cosa che la rete verifica, replica e conserva: stabilisce chi detiene il token, e si ferma lì.
L’estensione dello standard che riguarda la descrizione, documentata nella raccolta delle proposte di miglioramento di Ethereum, aggiunge una funzione di sola lettura che restituisce una stringa: l’indirizzo di un documento. Quel documento contiene di solito il nome, una descrizione e, soprattutto, un ulteriore indirizzo che punta al file vero e proprio.
Ne consegue una struttura a tre livelli che quasi nessuna interfaccia mostra. Il primo livello vive sulla catena e non si perde. Il secondo e il terzo vivono fuori e si perdono con la stessa facilità di qualunque pagina web. Un mercato che mostra l’immagine sta quasi sempre servendo una propria copia archiviata mesi prima, quindi la sua visualizzazione non dimostra che l’originale sia ancora raggiungibile.
I metadati NFT off chain e il punto in cui il registro si ferma
La ragione per cui il documento descrittivo sta fuori è la stessa che riguarda qualunque contenuto voluminoso: scrivere dati su una catena pubblica si paga per byte, e il costo rende impraticabile conservare lì un’immagine ad alta risoluzione o un video. La scelta non è una scorciatoia, è una conseguenza aritmetica.
Il problema nasce da come quella scelta viene comunicata. Chi acquisisce legge che il token è registrato su una catena pubblica e ne deduce che tutto ciò che il token rappresenta goda della stessa permanenza. La permanenza riguarda però soltanto il primo livello, e il resto eredita la fragilità dell’infrastruttura su cui è appoggiato.
Va aggiunta una seconda asimmetria, che riguarda l’integrità e non la disponibilità. Un indirizzo web ordinario non porta con sé alcuna prova di che cosa dovrebbe esserci dall’altra parte: se il file viene sostituito con un altro, il token continua a puntare allo stesso indirizzo e nessuna verifica automatica se ne accorge. Chi valuta una raccolta prima di acquisire, come chi si occupa dei criteri con cui si esamina un’opera digitale, dovrebbe partire da qui.
I quattro schemi di indirizzo, messi a confronto
La stringa restituita dal contratto comincia sempre con l’indicazione di uno schema, ed è quel prefisso a dire quasi tutto. La struttura degli indirizzi è definita da specifiche pubbliche curate dall’IETF, quindi il significato di ciascun prefisso non è materia di interpretazione.
| Schema | Dove risiede il contenuto | Chi può interromperlo | Integrità verificabile |
|---|---|---|---|
| Indirizzo web ordinario | Server di chi ha emesso i token | Chi controlla dominio e macchina | No, salvo impronta registrata a parte |
| Riferimento per contenuto | Qualunque nodo che conservi il file | Nessuno in particolare, ma nessuno è obbligato a conservarlo | Sì, l’indirizzo coincide con l’impronta |
| Archiviazione a pagamento anticipato | Rete di archiviazione remunerata in anticipo | La rete stessa, se smette di essere sostenibile | Sì |
| Documento incorporato | Nello stato del contratto | Nessuno, finché esiste la catena | Sì, per costruzione |
Le quattro righe non sono alternative equivalenti: costano in modo molto diverso e vengono scelte per ragioni economiche prima che tecniche. L’ultima riga è rara e si incontra quasi solo su opere leggere, generate da codice o composte da forme semplici, perché è l’unica compatibile con il costo di scrittura.
Perché un riferimento per contenuto non basta da solo
L’indirizzamento per contenuto ha una proprietà elegante: l’indirizzo è l’impronta crittografica del file, quindi chiunque riceva il contenuto può verificare da sé che sia esattamente quello previsto. Sostituirlo è impossibile senza cambiare l’indirizzo, e cambiare l’indirizzo significa cambiare il token.
Risolve però l’autenticità e non la disponibilità. Nessuna regola obbliga qualcuno a conservare quel file: se tutte le copie spariscono, l’impronta resta valida e inservibile, capace di descrivere con precisione qualcosa che non esiste più. La conservazione dipende da chi mantiene le copie attive e da chi ne paga il costo, esattamente come per un archivio qualunque.
C’è poi un errore ricorrente che annulla del tutto il vantaggio dello schema. Molti contratti non scrivono il riferimento nella sua forma nativa, ma lo incapsulano nell’indirizzo web di un intermediario che lo risolve. Il risultato è un indirizzo ordinario, dipendente da un operatore preciso: se quell’operatore chiude o cambia struttura, il collegamento si rompe, anche se il file continua a esistere e a essere raggiungibile da chi conosce il riferimento nativo. È un dettaglio di scrittura che sposta il rischio da tutti a uno.
Le tre varianti dello stesso errore
Gli anelli deboli si ripetono con poche variazioni, e riconoscerli è più semplice che spiegarli.
La prima variante è il dominio. L’indirizzo punta a un sito dell’emittente e sopravvive finché il dominio viene rinnovato e la macchina resta accesa. Con la chiusura del progetto cadono entrambi, e c’è un aggravante: un dominio scaduto può essere registrato da chiunque, e da quel momento il nuovo titolare decide che cosa viene mostrato al posto dell’opera.
La seconda è l’intermediario di risoluzione, appena descritta: il file starebbe anche in un sistema robusto, ma il contratto lo raggiunge attraverso una porta sola. La terza, la più insidiosa, è il documento calcolato al momento. In diverse raccolte la descrizione non esiste come file: viene generata da un servizio che risponde alla richiesta costruendola sul momento. Quando quel servizio si spegne non resta niente da recuperare, perché non c’era niente di conservato, e nemmeno una copia archiviata altrove può ricostruirlo per i token che non erano mai stati richiesti.
Riconoscerle richiede un solo sguardo alla stringa. Se comincia con l’indicazione di un protocollo web e contiene un dominio riconducibile al progetto, è la prima variante. Se dopo il dominio compare un percorso che include un identificativo lungo e apparentemente casuale, è quasi sempre la seconda. Se il percorso termina con il numero del token invece che con un nome di file, c’è una buona probabilità che sia la terza, e la conferma arriva richiedendo un identificativo inesistente: un archivio restituisce un errore, un servizio che calcola risponde comunque qualcosa.
Chi può cambiare il contenuto dopo la cessione
La domanda successiva riguarda i poteri residui. Molti contratti conservano una funzione amministrativa che modifica l’indirizzo di base da cui vengono costruiti tutti i puntatori: una sola transazione, e l’intera raccolta punta altrove.
La funzione non è di per sé un difetto. Serve a correggere errori, a spostare i file quando un fornitore cambia condizioni, a rimediare a un collegamento rotto. Il punto è chi la controlla e con quali vincoli: una chiave singola in mano a una persona è una condizione diversa da uno schema a più firme, e diversa ancora da un contratto in cui quella facoltà è stata rinunciata in modo irreversibile.
Allo stesso ordine di problemi appartiene la sostituibilità della logica. Dove il contratto è costruito per essere aggiornato, chi ne ha il controllo può modificare il comportamento dell’insieme, comprese le regole di trasferimento. Sono informazioni pubbliche, leggibili sull’esploratore nella sezione del codice verificato, e chi confronta i luoghi in cui si acquisiscono questi token farebbe bene a considerarle almeno quanto le commissioni.
Esiste una contromisura che alcuni emittenti adottano e che vale la pena cercare: registrare sulla catena, prima dell’assegnazione, l’impronta complessiva dell’insieme dei contenuti. Da quel momento qualunque sostituzione diventa dimostrabile, perché il confronto fra l’impronta pubblicata e quella dei file effettivamente serviti non torna più. Non impedisce la modifica, la rende visibile, ed è già molto più di quanto offra la maggior parte delle raccolte.
Che cosa resta quando il server si spegne
Resta la registrazione. L’indirizzo continua a figurare come proprietario, il token si può ancora trasferire, cedere o trasmettere agli eredi, e la cronologia dei passaggi rimane leggibile da chiunque. Quello che manca è la rappresentazione, cioè la ragione per cui quel token era stato acquisito.
La distinzione ha conseguenze concrete anche quando il file è recuperabile. Se qualcuno conserva una copia identica, provare che sia proprio quella indicata dal token richiede un elemento di confronto: l’impronta registrata sulla catena, se esiste, oppure una copia salvata all’epoca insieme al valore restituito dal contratto. Senza uno dei due, si può soltanto dire di avere un’immagine molto simile.
È il motivo per cui la pratica più utile è anche la meno diffusa: al momento dell’acquisizione, salvare il valore restituito dal contratto, il documento descrittivo e il file, e calcolarne l’impronta. Sono tre operazioni da qualche minuto che trasformano un ricordo in una prova, e vanno fatte quando tutto funziona ancora.
Esiste anche una via d’uscita parziale, e dipende interamente dallo schema scelto all’origine. Dove il puntatore è un riferimento per contenuto, chiunque possieda il file può rimetterlo a disposizione e il collegamento torna a funzionare per tutti, senza bisogno di toccare il contratto. Dove il puntatore è un indirizzo web su un dominio perduto, nessuna quantità di copie salvate ripara il rimando: si può conservare l’opera, non si può far tornare a funzionare il collegamento.
La verifica in sei passaggi prima di acquisire
- Leggere il puntatore. Sull’esploratore, nella sezione delle funzioni di sola lettura, richiedere il valore per l’identificativo che interessa.
- Guardare il prefisso. Stabilire a quale dei quattro schemi appartiene, tenendo presente il caso del riferimento incapsulato in un indirizzo web.
- Aprire il documento. Verificare che esista come file conservato e non come risposta generata al momento, e leggere il campo che indica il contenuto.
- Ripetere il controllo sul contenuto. Il file può usare uno schema diverso da quello del documento: sono due collegamenti separati e vanno esaminati entrambi.
- Cercare le funzioni amministrative. Individuare chi può modificare l’indirizzo di base o sostituire la logica, e con quale procedura.
- Salvare una copia e l’impronta. Documento, file e valore restituito dal contratto, archiviati insieme alla data della verifica.
Se il codice del contratto non è verificato sull’esploratore, i passaggi quattro e cinque non sono eseguibili, e questa è già un’informazione. Significa che qualunque affermazione sul comportamento del contratto poggia sulla parola di chi lo ha pubblicato.
Il token non è l’opera, e il diritto lo dice da tempo
La perdita del file rende evidente una separazione che esisteva comunque. Il trasferimento di un token non trasferisce i diritti sull’opera rappresentata: la titolarità dei diritti di utilizzazione economica si sposta solo attraverso un atto che li abbia per oggetto, e l’ordinamento italiano richiede la prova scritta di quel trasferimento. Nella grande maggioranza dei casi ciò che si acquisisce è una licenza d’uso definita dall’emittente, di ampiezza variabile, che sopravvive o meno alla scomparsa del contenuto a seconda di come è stata redatta.
Ne discende una conseguenza pratica sui rimedi. Se il contenuto diventa irraggiungibile, l’eventuale pretesa si rivolge a chi ha ceduto il token e dipende da che cosa era stato promesso al momento della cessione: una descrizione che garantiva la conservazione permanente ha un peso diverso da una che non diceva nulla. Verso il mercato che ha ospitato lo scambio le condizioni contrattuali limitano quasi sempre la responsabilità al funzionamento della piattaforma. Sono temi che si intrecciano con quelli affrontati parlando di diritto d’autore applicato ai token, e che conviene chiarire prima e non dopo.
Una precisazione sul perimetro di questo testo: qui si descrivono un’architettura e i suoi punti di rottura, non si valuta la convenienza di acquisire alcunché e non si esprime alcun giudizio su singole raccolte. Non è consulenza finanziaria né parere legale sul caso concreto. La verifica descritta riduce un rischio tecnico preciso, quello di ritrovarsi con un puntatore che non porta più a nulla, e non incide su tutti gli altri.
Domande frequenti
Se l’immagine sparisce, perdo la proprietà del token?
No. La registrazione sulla catena resta intatta e il token continua a essere trasferibile. Quello che si perde è la possibilità di visualizzare il contenuto a cui rimandava, e con essa gran parte di ciò che rendeva significativa quella registrazione.
Il mercato mi mostra ancora l’immagine, quindi il collegamento funziona?
Non necessariamente. Le piattaforme conservano copie archiviate delle immagini per velocizzare la navigazione, e continuano a mostrarle anche quando l’origine non risponde più. La verifica attendibile consiste nel leggere il puntatore direttamente dal contratto e provare a raggiungerlo.
Un riferimento per contenuto garantisce la permanenza?
Garantisce l’integrità, non la permanenza. Assicura che il file ricevuto sia esattamente quello indicato, ma non che qualcuno lo stia ancora conservando. Se nessuna copia resta attiva, l’indirizzo continua a essere valido e non porta più a nessun contenuto.
Posso conservare io una copia e considerarla al sicuro?
Conservare documento, file e impronta è la pratica più utile, e va fatta quando tutto funziona ancora. Non ripristina il collegamento pubblico: serve a dimostrare che cosa il token indicava alla data della verifica, il che è una cosa diversa e comunque preziosa in caso di contestazione.
Chi ha emesso i token può cambiare l’opera dopo la vendita?
Può farlo se il contratto conserva una funzione per modificare l’indirizzo di base e se chi la controlla decide di usarla. È una verifica preliminare, non un dettaglio: si esamina il codice verificato sull’esploratore e si guarda chi detiene quella facoltà e con quali vincoli.
Le opere conservate interamente sulla catena sono immuni?
Da questo rischio sì, perché contenuto e registrazione coincidono. Restano soggette ad altri limiti: il costo di scrittura le confina a file leggeri, e quando l’opera è generata da codice occorre verificare che tutte le dipendenze necessarie a riprodurla siano anch’esse conservate sulla catena e non richiamate da un servizio esterno.
La domanda da porre prima di qualunque acquisizione è una sola, e si risponde leggendo una stringa: dove punta questo token, e chi può decidere di farlo puntare altrove.
