Terreni virtuali nel metaverso: cosa registra davvero il token, dove vivono coordinate e contenuti e cosa resta se la piattaforma smette di rispondere.
PB / CC BY-SA 4.0
Un lotto in un mondo virtuale si acquisisce come qualunque altro token: si collega il portafoglio, si firma, e nel giro di un blocco l’indirizzo risulta proprietario. Quello che quasi nessuno fa, né prima né dopo, è aprire il contratto e leggere che cosa è stato effettivamente scritto.
La risposta, nella maggior parte delle implementazioni, è più breve di quanto si immagini: un numero identificativo e l’indirizzo di chi lo detiene. Le coordinate, il modello tridimensionale, le texture, gli oggetti collocati sopra, le regole di accesso: niente di tutto questo vive nel registro pubblico. Vive su server che appartengono a qualcuno.
Non è un difetto nascosto, è una conseguenza diretta del costo di scrittura sulla catena. Cambia però la domanda da farsi prima di firmare, perché sposta il problema dal valore del lotto alla sua sopravvivenza tecnica: che cosa continua a esistere se il servizio che disegna quel mondo smette di funzionare. Qui si guarda l’architettura, non il mercato.
Che cosa contiene il token, in breve
- Sulla catena. Un identificativo numerico, l’indirizzo del proprietario e, nelle implementazioni migliori, la coppia di coordinate.
- Fuori dalla catena. Modelli, texture, suoni, oggetti collocati sul lotto, permessi di accesso e l’intera logica del mondo.
- Il punto di rottura. Il collegamento fra token e contenuto passa quasi sempre da un indirizzo web che qualcuno deve mantenere attivo.
- La domanda giusta. Non che cosa mostra l’interfaccia oggi, ma che cosa resta leggibile da un programma qualsiasi fra dieci anni.
- Da verificare prima. Chi può modificare l’indirizzo dei metadati, se il contratto è aggiornabile e dove sono conservati i file.
Come funzionano i terreni virtuali nel metaverso, a livello di dati
Quasi tutte le implementazioni partono dallo stesso mattone: un contratto conforme a ERC-721, lo standard dei token non fungibili raccolto insieme agli altri nella raccolta delle proposte di miglioramento di Ethereum. Il contratto tiene una tabella che associa ogni identificativo a un indirizzo, espone una funzione per leggere il proprietario e una per restituire l’indirizzo dei metadati. Il perimetro dello standard finisce qui.
Il concetto di parcella non esiste dentro lo standard: va aggiunto, e i modi per farlo sono due. Nel primo l’identificativo codifica direttamente la posizione, con una funzione che ricava la coppia di coordinate dal numero oppure con una tabella interna che la conserva. Nel secondo l’identificativo è un semplice progressivo e la posizione compare unicamente in un documento ospitato altrove.
Nel primo caso la mappa è ricostruibile leggendo la catena, senza chiedere niente a nessuno. Nel secondo, se quel documento sparisce, resta un numero privo di significato: il token continua a essere trasferibile, ma nessuno può più dire a quale punto della mappa corrispondesse. La differenza si legge nel codice pubblico, e distinguere i due casi richiede una decina di minuti su un esploratore di blocchi. Vale per i lotti come per gli altri oggetti registrati nei mondi virtuali costruiti sui token.
Le coordinate: quando restano e quando spariscono
Una coppia di coordinate occupa pochi byte, e questo la rende uno dei rari elementi che ha senso scrivere in modo permanente. Diversi progetti lo fanno, alcuni per scelta esplicita di progettazione, altri perché derivare la posizione dall’identificativo semplificava il codice.
Il controllo si fa in due passaggi. Il primo è verificare se il sorgente del contratto è pubblicato e verificato sull’esploratore: se non lo è, ogni affermazione sul suo comportamento resta una dichiarazione di parte. Il secondo è cercare, in quel sorgente, una funzione che restituisca la posizione a partire dall’identificativo, o una struttura dati che la conservi.
Se non c’è nessuna delle due, la posizione è un attributo dei metadati e dipende dal server che li serve. Oggi non è necessariamente un problema, perché il server risponde. Lo diventa il giorno in cui smette di rispondere, e quel giorno non viene annunciato in anticipo.
Esiste poi un caso intermedio che genera parecchia confusione: i lotti raggruppati. Alcune implementazioni permettono di unire più parcelle contigue in un’unica entità, rappresentata da un secondo token che prende in custodia i primi. Il proprietario formale dei singoli lotti diventa allora un contratto, mentre la persona detiene il token dell’insieme. La verifica va fatta su due livelli, perché anche la logica che tiene insieme il gruppo è codice, con le proprie funzioni amministrative e i propri difetti possibili.
Il contenuto della parcella non sta sulla catena
Una scena tridimensionale, anche modesta, pesa alcuni megabyte fra geometria, texture e animazioni. La scrittura permanente di dati su una catena pubblica si paga per byte, e il costo cresce in modo tale da rendere impraticabile qualunque contenuto grafico non elementare. Nessuna piattaforma scrive le scene sulla catena, e non è una scorciatoia: è l’unica scelta compatibile con questa struttura di costo.
Il contenuto sta quindi altrove, e l’altrove si divide in due famiglie. La prima è l’indirizzo classico, un URL su un dominio controllato dal gestore, che funziona finché il dominio viene rinnovato, il server resta acceso e l’azienda esiste. La seconda è l’indirizzamento per contenuto, in cui il riferimento coincide con l’impronta crittografica del file: chiunque conservi quel file può servirlo, e chi lo riceve verifica da sé che sia identico all’originale.
L’indirizzamento per contenuto risolve l’autenticità, non la disponibilità. Se nessun nodo conserva più quel file, l’impronta resta valida e inutile: descrive con precisione qualcosa che non esiste più da nessuna parte. La domanda da porre non è quale tecnologia sia stata scelta, ma quante copie indipendenti esistono e chi ne sostiene il costo.
Chi disegna la mappa decide che cosa esiste
La catena non disegna niente. Il mondo che l’utente vede è prodotto da un programma, il client, che legge lo stato della catena, scarica i contenuti dai server e li compone in una scena. Fra i due passaggi resta un margine di interpretazione che appartiene interamente a chi scrive quel programma.
Da quel margine derivano conseguenze concrete. Il client decide quali contenuti caricare e quali no, applica le proprie regole di moderazione, può nascondere una parcella o sostituirne il contenuto con un segnaposto. Può anche smettere di considerare valido un contratto e ignorarlo: in quel caso la proprietà registrata resta intatta mentre l’oggetto smette di comparire.
È la stessa asimmetria che si osserva ovunque nei registri pubblici, compresi i giochi costruiti su blockchain: il registro stabilisce chi detiene che cosa, non obbliga nessuno a mostrarlo. Chi ragiona sul lungo periodo dovrebbe quindi valutare non solo il contratto, ma anche quante implementazioni indipendenti del client esistono e con quale licenza sono distribuite.
Tre modelli a confronto
Le architetture in circolazione si collocano su una scala che va dal registro autosufficiente a quello puramente simbolico. Sotto, i tre punti principali di quella scala.
| Modello | Sulla catena | Dipendenza esterna | Se il servizio chiude |
|---|---|---|---|
| Registro autosufficiente | Identificativo, proprietario e coordinate | File indirizzati per contenuto, replicati da più parti | Mappa e proprietà ricostruibili, contenuti recuperabili se qualcuno li conserva |
| Modello misto | Identificativo, proprietario e coordinate | Metadati e file sui server del gestore | Resta la mappa delle proprietà, sparisce l’aspetto del mondo |
| Registro simbolico | Solo identificativo e proprietario | Posizione, metadati e file nel database del gestore | Restano un numero e un indirizzo, senza significato ricostruibile |
Nessuno dei tre è raro. La differenza non si vede dall’interfaccia, che in tutti e tre i casi mostra una mappa colorata con i lotti disponibili, e si vede benissimo dal codice.
Che cosa succede se la piattaforma chiude
La chiusura di un servizio non è un evento istantaneo, e conviene scomporla. Il primo elemento a cadere è di solito l’interfaccia web, perché è la voce di costo più visibile. Subito dopo cadono le interfacce di programmazione che servono i metadati, poi i server dei contenuti, infine il dominio, che a un certo punto non viene più rinnovato e torna disponibile per chiunque.
Il contratto invece non chiude. Continua a vivere finché vive la catena, e le funzioni di trasferimento restano utilizzabili: il token si può ancora mandare a un altro indirizzo, cedere, trasmettere agli eredi. Quello che scompare è tutto ciò che dava senso a quel trasferimento.
Un dettaglio aggrava lo scenario più di quanto sembri. Se i metadati puntano a un dominio scaduto e quel dominio viene registrato da un terzo, il nuovo titolare controlla che cosa viene mostrato al posto del contenuto originale. Il token continua a puntare esattamente dove puntava, ma dall’altra parte risponde qualcun altro.
Resta una via d’uscita parziale, e conviene conoscerla prima. Se le coordinate stanno sulla catena e i file sono indirizzati per contenuto, un gruppo di utenti può in teoria scrivere un nuovo client e rimettere in piedi la mappa, perché tutte le informazioni necessarie restano pubbliche. Se invece la posizione viveva in un database privato, non c’è ricostruzione possibile: mancano i dati, non gli strumenti. È la differenza fra un archivio disperso e un archivio cancellato.
I permessi che il token non trasferisce
Detenere il token significa figurare come proprietario nel registro. Non significa avere accesso al mondo, poter pubblicare contenuti su quella parcella, né essere immuni dalle condizioni d’uso del servizio, che restano un contratto separato fra l’utente e il gestore.
Nella pratica la pubblicazione passa quasi sempre da un account, e l’account può essere sospeso per motivi che non riguardano la proprietà del token. I diritti sui modelli e sulle texture caricate seguono la licenza scelta al momento del caricamento, non la titolarità del lotto. Le regole di visibilità dipendono dal client, come si è visto.
Va poi controllato chi mantiene poteri sul contratto stesso. Molti contratti conservano funzioni amministrative, dal cambio dell’indirizzo base dei metadati alla sospensione dei trasferimenti fino all’aggiornamento della logica dietro un componente sostituibile. La domanda pertinente non è se esistano, ma chi le controlla e con quali vincoli: una chiave singola in mano a una sola persona è una condizione diversa da uno schema a più firme con un ritardo obbligatorio.
Un caso ricorrente riguarda la concessione temporanea. Alcuni contratti prevedono la figura di un utilizzatore distinto dal proprietario, con una scadenza scritta nel registro, così che il lotto possa essere impiegato da un terzo senza trasferirne la titolarità. Dove questa figura non è prevista, l’accordo vive interamente fuori dalla catena e la sua esecuzione dipende dalla buona fede delle parti e dalle regole del gestore.
Le sei verifiche da fare sul contratto
- Sorgente verificato. Se sull’esploratore non compare il codice verificato, ci si sta fidando di una descrizione commerciale invece che del programma.
- Origine delle coordinate. Cercare nel sorgente la funzione o la struttura che collega identificativo e posizione. Se non c’è, la mappa vive fuori dalla catena.
- Schema dell’indirizzo dei metadati. Leggere il valore restituito per un identificativo qualsiasi e guardare come comincia: un dominio ordinario, un riferimento per contenuto o un documento incorporato nel contratto.
- Funzioni amministrative. Individuare chi può modificare l’indirizzo base, sospendere i trasferimenti o sostituire l’implementazione, e con quale procedura.
- Copie del contenuto. Verificare che il file sia servito da più di una fonte indipendente e capire chi ne sostiene il costo nel tempo.
- Client alternativi. Controllare se esiste più di un programma capace di leggere quel registro, e con quale licenza è distribuito.
Sono controlli che si fanno prima, in mezz’ora, con strumenti pubblici e gratuiti. Farli dopo serve soltanto a stabilire con precisione che cosa è andato perso.
Interoperabilità: quello che servirebbe davvero
L’idea che un oggetto acquisito in un mondo possa comparire in un altro richiede tre condizioni contemporanee, e nessuna delle tre è soltanto tecnica. Serve un formato di scena leggibile da motori diversi, serve una licenza che ne autorizzi la riproduzione altrove, e serve che il secondo mondo accetti di rappresentare qualcosa che non ha prodotto.
Sulla prima condizione il lavoro è avanzato: esistono formati aperti per geometria e materiali, documentati e implementati da più motori grafici, mentre le specifiche del W3C coprono la parte che passa dal browser. Sulla seconda e sulla terza si è molto più indietro, perché non sono problemi di formato ma di contratti e di scelte commerciali, come mostra bene il dibattito sui progetti costruiti attorno ai mondi virtuali.
Una precisazione sul perimetro di questo testo: qui si descrive come è fatto un sistema, non se convenga acquisire qualcosa né a quali condizioni. Non è consulenza finanziaria e non contiene valutazioni di prezzo. La verifica dell’architettura riduce un rischio tecnico preciso, quello di ritrovarsi con un riferimento che non punta più a niente, e non dice nulla su tutti gli altri.
Domande frequenti
Se acquisisco una parcella, posso spostarla su un’altra piattaforma?
Il token si trasferisce fra indirizzi, non fra mondi. La posizione ha significato solo dentro la mappa che quel contratto descrive, e un secondo mondo dovrebbe scegliere deliberatamente di leggere quel registro e rappresentarlo. Finché non lo fa, la parcella esiste soltanto dove è stata definita.
I file conservati con l’indirizzamento per contenuto sono permanenti?
No. Quel metodo garantisce che un file corrisponda esattamente al riferimento, non che qualcuno lo stia ancora conservando. La permanenza dipende dal numero di nodi che ne mantengono una copia e da chi ne paga il costo, esattamente come per qualunque altro archivio digitale.
Come faccio a sapere se le coordinate sono scritte sulla catena?
Si apre il contratto su un esploratore di blocchi, si controlla che il sorgente sia verificato e si esaminano le funzioni di sola lettura. Se una di esse restituisce la posizione a partire dall’identificativo, la mappa è ricostruibile senza intermediari. Se la posizione compare solo nel documento dei metadati, non lo è.
Il gestore può cambiare l’aspetto della mia parcella?
Se i metadati sono serviti da un suo server, tecnicamente sì, in qualsiasi momento. Se poi il contratto conserva una funzione per aggiornare l’indirizzo base, può riscrivere il collegamento per tutti i token insieme. È il motivo per cui l’esistenza di quella funzione, e l’identità di chi la controlla, è una verifica preliminare e non un dettaglio.
Che differenza c’è fra il token del lotto e quello degli oggetti collocati sopra?
Sono registrazioni distinte, spesso su contratti diversi e con regole diverse. Il legame fra un oggetto e una posizione è di solito una relazione mantenuta dal servizio, non un vincolo scritto sulla catena. Se il servizio si spegne, i due token sopravvivono separatamente e la relazione fra loro no.
Serve un portafoglio dedicato per questo tipo di token?
Non serve un portafoglio diverso, servono le cautele valide per qualunque contratto: verificare l’indirizzo su fonti indipendenti, leggere che cosa autorizza ogni firma e non concedere approvazioni senza limite a codice che non si è controllato. Le implicazioni di custodia sono identiche a quelle di un token qualsiasi.
Fra un registro che descrive una mappa e uno che conserva soltanto un numero passa una differenza che nessuna interfaccia mostra. Si legge nel codice, in mezz’ora, e decide che cosa resterà in mano il giorno in cui il servizio che oggi disegna quel mondo non ci sarà più.
