ERC-721, ERC-1155 ed ERC-6551 servono a tre cose diverse

La scelta dello standard viene fatta quasi sempre per imitazione: si guarda che cosa ha usato un progetto simile e si copia. Poi arriva il momento in cui bisogna emettere cinquemila biglietti identici e la struttura scelta obbliga a cinquemila operazioni di scrittura distinte, oppure quello in cui si vorrebbe che un esemplare custodisse altri oggetti e si scopre che non è previsto.

I tre standard che oggi coprono la quasi totalità dei casi non sono versioni successive dello stesso strumento. Il primo descrive esemplari unici, il secondo descrive classi di oggetti che possono avere più copie, il terzo aggiunge a un esemplare esistente un conto proprio, capace di detenere altro.

Sceglierli male non è un errore estetico: si riflette sui costi di emissione, sulla facilità di trasferimento, sul modo in cui i metadati vengono risolti e, in alcuni casi, sulla qualificazione dell’operazione davanti alle regole europee. Quello che segue è il confronto punto per punto, con i casi in cui ciascuno è la scelta corretta.

I tre standard in sintesi

• ERC-721. Ogni identificativo esiste in un solo esemplare e ha un solo proprietario. Adatto a opere singole e a certificazioni individuali.
• ERC-1155. Un contratto ospita molte classi, ciascuna con una quantità che può andare da uno a molte migliaia. Adatto a inventari, biglietti e serie.
• ERC-6551. Non sostituisce i primi due: assegna a un esemplare già esistente un conto proprio, che può detenere altri token.
• Il costo. Emettere mille copie identiche con il primo standard significa mille scritture, con il secondo un solo aggiornamento di saldo.
• Il limite comune. Nessuno dei tre stabilisce che cosa il titolare può fare con l’opera: quello lo decide la licenza.

Le differenze tra ERC-721 e ERC-1155 in pratica

La distinzione di fondo riguarda il rapporto fra identificativo e quantità. Nel primo standard un identificativo corrisponde a un esemplare e a un proprietario: chiedere chi possiede un certo numero restituisce un indirizzo solo. Nel secondo si chiede quanto un indirizzo possiede di una certa classe, e la risposta è un numero che può essere zero, uno o diecimila.

La riga sulle autorizzazioni merita attenzione perché è quella che genera più sorprese. Con il primo standard si può autorizzare un contratto a spostare un singolo esemplare; con il secondo l’autorizzazione è tutto o niente, e chi la concede a una piattaforma le consente di muovere qualsiasi cosa quel contratto ospiti per suo conto.

ERC-721: un proprietario per ciascun identificativo

È lo standard su cui è nato il mercato dei token non fungibili e resta la scelta corretta quando l’unicità è la sostanza dell’oggetto. Un’opera che esiste in un solo esemplare, un titolo di partecipazione a un evento nominativo, una certificazione riferita a una persona o a un bene fisico specifico: in tutti questi casi la corrispondenza uno a uno fra identificativo e proprietario è esattamente ciò che serve.

La struttura è semplice e questa è la sua forza: registra chi possiede che cosa, gestisce i trasferimenti con un controllo che evita l’invio a contratti incapaci di riceverlo, e associa a ciascun esemplare un indirizzo dove risiedono le informazioni descrittive.

Il limite è il costo quando i numeri crescono. Ogni emissione è una scrittura separata sul registro, e ogni trasferimento riguarda un esemplare alla volta. Esistono implementazioni che riducono il costo dell’emissione registrando la proprietà solo all’inizio di un intervallo consecutivo, ma quel risparmio si paga dopo: i trasferimenti successivi devono ricostruire a ritroso il proprietario, e costano di più. È un trasferimento di costo dall’emittente all’acquirente, non una sua eliminazione.

Esiste poi un’estensione facoltativa che consente di elencare sul registro tutti gli esemplari esistenti e quelli posseduti da un indirizzo. È comoda per chi sviluppa, ma ogni emissione e ogni trasferimento devono aggiornare quegli elenchi, e il costo sale in modo sensibile. Molte collezioni la omettono e affidano l’elenco a un servizio esterno che ricostruisce lo stato dagli eventi: una scelta legittima, che però sposta una funzione dal registro a un’infrastruttura che qualcuno deve mantenere e che un giorno potrebbe smettere di rispondere.

ERC-1155: un contratto, molte classi di token

Nato per gli inventari dei giochi, questo standard risolve un problema molto concreto: un personaggio possiede una spada unica, trecento monete e cinque pozioni identiche, e tenere tre contratti separati per tre tipi di oggetto è insostenibile.

Un solo contratto ospita tutte le classi. Ciascuna ha un identificativo e una quantità, e nulla impedisce che una classe esista in un solo esemplare: lo standard non è alternativo all’unicità, la comprende come caso particolare. Le operazioni in lotto permettono di trasferire dieci oggetti diversi in una transazione sola, con un risparmio che cresce con il numero di elementi.

Il rovescio riguarda la granularità dei permessi, già ricordata, e la lettura dei dati. Un’applicazione che vuole sapere che cosa possiede un indirizzo non può limitarsi a interrogare il contratto: deve conoscere in anticipo le classi da controllare, oppure ricostruirle dagli eventi emessi. È il motivo per cui gli inventari di questo tipo si appoggiano quasi sempre a un servizio di indicizzazione esterno, con la dipendenza che ne consegue.

Per gli usi ludici il vantaggio resta netto, ed è la ragione per cui questo standard domina il settore descritto in questa analisi dei token nel gaming.

ERC-6551: quando il token possiede qualcosa

Il terzo standard risponde a una domanda diversa: come si fa a dare a un esemplare esistente la capacità di detenere altri beni. La risposta è un conto associato deterministicamente a quell’esemplare, calcolato da un registro condiviso a partire dal contratto e dall’identificativo.

Il punto che lo rende interessante è la compatibilità. Non richiede alcuna modifica al contratto originario: funziona con collezioni già distribuite anni fa, perché il collegamento è calcolato all’esterno. Chi controlla l’esemplare controlla il conto, e il controllo si trasferisce automaticamente con l’esemplare.

Da qui nasce anche il rischio principale, che chiunque valuti un acquisto deve conoscere: vendendo l’esemplare si vende tutto ciò che il conto associato contiene. E l’inverso è più insidioso: chi acquista guardando il contenuto del conto può trovarlo vuoto, perché il venditore lo ha svuotato nell’intervallo fra la valutazione e la conclusione dell’operazione. La verifica del contenuto va fatta al momento del trasferimento, non prima, e le piattaforme che gestiscono questi oggetti devono prevederlo esplicitamente. Una panoramica delle differenze fra piattaforme si trova in questa rassegna dei marketplace.

Sul piano dei costi la struttura è più leggera di quanto sembri. I conti non sono contratti completi replicati per ciascun esemplare, ma copie minime che rimandano a un’unica implementazione condivisa, e nella maggior parte delle realizzazioni vengono creati soltanto quando servono davvero. Un esemplare che non ha mai usato il proprio conto non ha fatto sostenere costi aggiuntivi a nessuno, e l’indirizzo resta comunque calcolabile in anticipo da chiunque conosca il contratto e l’identificativo.

Che cosa cambia sui costi di emissione

Il confronto sui costi non si fa sul singolo numero ma sulla forma dell’operazione. Un’emissione di molti esemplari identici e un’emissione di molti esemplari diversi hanno profili opposti.

La lettura corretta della tabella è che il secondo standard vince quando le copie sono numerose e identiche, e non offre alcun vantaggio quando ogni esemplare è diverso: mille classi da creare costano quanto mille esemplari da emettere. Il terzo aggiunge un costo per esemplare che, nella maggior parte delle implementazioni, viene rinviato al momento in cui il conto serve davvero, quindi non grava sull’emissione iniziale.

I metadati: due modi diversi di indicare il contenuto

Il primo standard associa a ciascun identificativo un indirizzo completo, restituito su richiesta. Il secondo usa un modello unico, valido per tutte le classi, con un segnaposto che l’applicazione sostituisce con l’identificativo scritto in esadecimale, riempito di zeri fino a una lunghezza fissa.

La differenza sembra tecnica e invece ha una conseguenza pratica. Con un modello unico, cambiare la posizione dei contenuti significa aggiornare una stringa sola; con un indirizzo per esemplare, l’aggiornamento riguarda ogni singolo elemento e può risultare impraticabile. È un vantaggio per chi deve manutenere una collezione grande e un rischio per chi acquista, perché la stessa facilità consente di modificare in blocco ciò a cui l’esemplare rimanda.

Il punto vale per entrambi gli standard: la stringa registrata sul registro distribuito indica dove si trova il contenuto, non lo contiene. Se quell’indirizzo smette di rispondere, il token continua a esistere e a essere trasferibile mentre l’immagine non si carica più. È una verifica da fare prima di acquisire qualsiasi cosa, e non dipende dalla scelta dello standard.

Errori ricorrenti nella scelta dello standard

1. Usare il primo per una serie di copie identiche. Biglietti, coupon e attestati di partecipazione uguali fra loro moltiplicano il costo senza aggiungere nulla.
2. Usare il secondo per opere realmente uniche. Si perde la granularità delle autorizzazioni e si complica la lettura da parte delle piattaforme, senza risparmiare nulla.
3. Contare su un’autorizzazione singola dove non esiste. Concedere accesso a un contratto che ospita l’intero inventario è una decisione diversa dal concederlo su un esemplare.
4. Adottare il terzo standard senza gestire il contenuto in vendita. Un’interfaccia che non mostra e non blocca il contenuto del conto associato espone l’acquirente a una sorpresa.
5. Trattare l’emissione differita come un risparmio netto. Il costo si sposta su chi acquista o su chi trasferisce, e va dichiarato nelle condizioni.

I testi di riferimento dei tre standard sono pubblici e consultabili nella raccolta delle proposte di miglioramento di Ethereum, che resta la fonte da leggere prima di qualsiasi documentazione promozionale di progetto.

Lo standard non decide i diritti

Nessuno dei tre standard stabilisce che cosa il titolare può fare con l’opera collegata. Il registro attesta la titolarità di una voce in un contratto; l’uso commerciale, la riproduzione e la trasformazione dipendono dalla licenza concessa dall’autore, che è un documento separato e spesso assente.

Nell’ordinamento italiano la questione ha un profilo preciso: la trasmissione dei diritti di utilizzazione delle opere dell’ingegno deve essere provata per iscritto. Una descrizione generica nel materiale di lancio, o un messaggio pubblicato su un canale sociale, difficilmente soddisfano quel requisito. Chi acquisisce un esemplare credendo di acquisire i diritti di sfruttamento si trova, in molti casi, con un titolo che attesta la titolarità del token e nient’altro. Il tema è ripreso con maggiore dettaglio in questo approfondimento sul diritto d’autore.

Va aggiunta una precisazione: quanto scritto qui descrive il funzionamento tecnico degli standard e il quadro giuridico generale, non è un parere legale su un caso concreto e non costituisce consulenza finanziaria. La valutazione economica di un’acquisizione dipende da elementi che nessuna specifica tecnica contiene.

Dove passa il confine con le regole europee

La scelta dello standard ha anche una conseguenza che raramente viene considerata in fase di progettazione. Il quadro europeo sulle cripto-attività esclude dal proprio ambito i token davvero unici e non fungibili, ma guarda alla sostanza dell’emissione e non all’etichetta.

Una classe emessa in molte copie identiche è fungibile per definizione, qualunque sia lo standard usato per rappresentarla. E anche una collezione di esemplari formalmente distinti, ma economicamente intercambiabili perché generati combinando gli stessi attributi, può essere trattata come una serie fungibile. Il secondo standard, che rende naturale l’emissione di quantità elevate della stessa classe, si colloca più vicino a quel confine del primo.

Non ne discende un divieto, ma un ordine di lavoro: chi progetta un’emissione numerosa dovrebbe documentare fin dall’inizio perché ritiene che ciascun esemplare abbia caratteristiche proprie, e conservare quella valutazione con la sua data. È la prima cosa che serve se la qualificazione viene messa in discussione.

Domande frequenti

Posso convertire una collezione da uno standard all’altro?

Non con una migrazione automatica. La strada praticabile è emettere una nuova collezione con lo standard desiderato e prevedere un meccanismo di scambio volontario, che di norma richiede il deposito dell’esemplare originario. Comporta costi, richiede la collaborazione dei titolari e lascia in circolazione la vecchia serie, che resta valida e trasferibile.

Il secondo standard è sempre più economico?

Solo quando ci sono copie multiple della stessa classe o trasferimenti in lotto. Se ogni esemplare è diverso e viene spostato singolarmente, il vantaggio si riduce a poco o nulla, perché il numero di scritture sul registro è sostanzialmente lo stesso.

Un conto associato a un esemplare può ricevere qualsiasi cosa?

Può detenere token fungibili e non fungibili come un normale indirizzo, e può eseguire operazioni se chi controlla l’esemplare le autorizza. Restano fuori i beni che non risiedono su quel registro: un conto associato non contiene un file, contiene riferimenti ad altre voci registrate.

Le piattaforme supportano tutti e tre gli standard?

I primi due sono supportati in modo generalizzato. Il terzo è più recente e il livello di supporto varia: alcune interfacce mostrano il conto associato e il suo contenuto, altre trattano l’esemplare come un token qualsiasi. Verificare questo comportamento prima di mettere in vendita un oggetto che contiene altro è una precauzione elementare.

Che cosa succede se il contratto ha una funzione amministrativa nascosta?

Nessuno standard vieta all’autore del contratto di inserire funzioni riservate, per esempio la possibilità di modificare l’indirizzo dei metadati o di sospendere i trasferimenti. La verifica si fa leggendo il codice pubblicato e confrontandolo con quello effettivamente in esecuzione: se il codice non è verificabile, l’assenza di quelle funzioni non è dimostrabile.

Conviene aspettare uno standard successivo?

Gli standard esistenti non vengono ritirati e i contratti distribuiti continuano a funzionare, quindi l’attesa non protegge da nulla. Il criterio ragionevole resta l’aderenza al caso d’uso: unicità sostanziale, quantità multiple oppure necessità che l’esemplare detenga altro. La domanda a cui rispondere è che cosa deve fare l’oggetto, non quale sigla è la più recente.

Tre standard, tre problemi distinti: rappresentare un esemplare unico, gestire quantità e classi, dare a un esemplare un conto proprio. La scelta si fa partendo dal comportamento richiesto e non dalla sigla, perché il costo dell’errore compare mesi dopo, quando la collezione è già in circolazione e ogni correzione richiede la collaborazione di chi la detiene.