Token, stablecoin e smart contract · Lezione 3 di 5
Standard dei token: fungibili e non fungibili
7 min di lettura
Perché le interfacce condivise sono importanti
Uno standard per i token è un insieme pubblicato di convenzioni che descrive come le applicazioni dovrebbero interagire con un token. Gli standard aiutano wallet, registri, servizi software e revisori a interpretare funzioni comuni senza sviluppare un supporto separato per ogni emittente. Non costituiscono una certificazione universale di sicurezza, autenticità o conformità. Due programmi possono implementare la stessa interfaccia pur differendo per poteri amministrativi, diritti economici, documentazione o qualità della sicurezza.
Fungibile significa intercambiabile all'interno di una classe definita: si intende che un'unità sia equivalente a un'altra unità della stessa classe. Non fungibile significa distinguibile in modo univoco: un record può identificare un determinato elemento separatamente da un altro. La distinzione riguarda la rappresentazione del token, non l'eventualità che l'elemento abbia un valore reale unico. Per esempio, due pass numerati possono essere tecnicamente distinti anche se entrambi consentono l'ingresso allo stesso evento. Uno standard facilita lo scambio di istruzioni tra sistemi, ma non ne determina il significato commerciale.
ERC-20: saldi fungibili
La proposta di miglioramento di Ethereum EIP-20, comunemente chiamata ERC-20, descrive un'interfaccia per token fungibili. Le sue funzioni includono la verifica di un saldo, il trasferimento di token, la concessione di un'autorizzazione di spesa e il trasferimento per conto di un titolare che ha approvato l'operazione. Un'autorizzazione di spesa è un permesso di spesa registrato: un titolare autorizza una parte designata a trasferire fino a un determinato importo di token, in base alle regole dell'implementazione. L'autorizzazione di spesa non prova necessariamente che sia avvenuto un trasferimento effettivo. Lo standard definisce inoltre eventi come Transfer e Approval per aiutare il software a osservare l'attività del contratto.
Alcuni campi familiari, come il nome visualizzato di un token, il simbolo e il numero di decimali, sono metodi d'interfaccia facoltativi e non prove garantite di identità o valore. I decimali descrivono la precisione di visualizzazione, non un valore aggiuntivo. Se un token usa sei decimali, un saldo grezzo di 1.000.000 di unità di base può essere visualizzato come un token intero. I team operativi devono verificare la scala prima di generare i report; confondere le unità di base con le unità visualizzate può causare gravi errori di rendicontazione.
ERC-721: identificatori di token distinguibili
EIP-721, chiamata anche ERC-721, fornisce un'interfaccia standard per i token non fungibili (NFT). All'interno di un contratto, ogni identificatore di token distingue un singolo record. Su una rete Ethereum, la combinazione dell'indirizzo del contratto e del token ID è più informativa del solo token ID. Un record può rimandare a metadati che descrivono un'opera d'arte, una credenziale, un oggetto o un documento, ma il token non coincide automaticamente con l'asset sottostante né con un diritto di proprietà azionabile.
I metadati di un NFT sono informazioni associate a un token, come un titolo, una descrizione o un riferimento a un'immagine. Possono essere archiviati direttamente on-chain, su un server separato o in un sistema decentralizzato di indirizzamento dei file. La loro posizione incide sulla disponibilità e sull'integrità. Anche quando il token rimane nel registro, un'immagine o una descrizione esterna può risultare mancante o essere modificata, a seconda di come viene mantenuta. Inoltre, un token ID univoco non prova che l'emittente fosse autorizzato a tokenizzare l'opera a cui fa riferimento.
ERC-1155: più tipi di token in un unico contratto
EIP-1155, comunemente chiamata ERC-1155, supporta più identificatori di token in un unico contratto, con saldi associati a ciascun identificatore. Lo stesso sistema può rappresentare elementi fungibili, non fungibili e a fornitura limitata, a seconda della sua progettazione. Le operazioni in batch possono semplificare i trasferimenti di più elementi. Un'implementazione potrebbe rappresentare 500 pass d'accesso identici con un identificatore e una singola credenziale commemorativa con un altro. Lo standard non impone un modello commerciale specifico e gli studenti non dovrebbero presumere che ogni identificatore ERC-1155 si comporti come un token ERC-721.
I tre standard sono utili esempi comparativi, non un inventario completo. Altri ecosistemi blockchain utilizzano programmi e interfacce per token differenti. Anche all'interno di un unico ambiente, le estensioni possono introdurre funzionalità come restrizioni ai trasferimenti, diritti di voto, snapshot o amministrazione basata sui ruoli. Quando si legge un rapporto tecnico, occorre identificare lo standard esatto e gli eventuali comportamenti aggiuntivi, invece di dedurre tutte le funzionalità da un acronimo noto.
Interfacce e diritti
Uno standard indica al software quali operazioni aspettarsi; in generale, non dice a un tribunale se un trasferimento fosse lecito o se un oggetto digitale conferisca diritti d'autore, la proprietà di un immobile o l'appartenenza a un'organizzazione. Un token descritto come “atto di proprietà” può essere semplicemente un marcatore che rimanda a un registro esterno. Un certificato digitale può attestare la partecipazione senza essere trasferibile in modo indipendente. Un NFT che si presume rappresenti la proprietà può conferire privilegi contrattuali limitati anziché la proprietà dell'immagine associata. Per sapere cosa riceve effettivamente il titolare, occorre esaminare le condizioni dell'emittente e la normativa pertinente.
Alcuni regimi relativi ai cripto-asset escludono gli asset unici e non fungibili con altri asset; il regolamento MiCA dell'UE ne è un esempio. Tali esclusioni non costituiscono un'esenzione generale per qualsiasi asset commercializzato come NFT: le autorità di regolamentazione considerano la sostanza, soprattutto quando sono coinvolte serie di grandi dimensioni o unità intercambiabili. Separatamente, un token che funziona come strumento finanziario può essere soggetto alla normativa sui valori mobiliari indipendentemente dalla sua interfaccia.
| Standard | Modello principale | Caratteristica tecnica comune | Cosa non stabilisce |
|---|---|---|---|
| ERC-20 / EIP-20 | Unità fungibili | Saldi e autorizzazioni di spesa | Copertura da riserve o diritti legali |
| ERC-721 / EIP-721 | ID di token individuali | Un titolare registrato per ogni ID | Proprietà dei contenuti collegati |
| ERC-1155 / EIP-1155 | Più tipi e saldi | Trasferimenti in batch tra ID | Un valore economico specifico |
Leggere i record dei token in modo responsabile
Un revisore dovrebbe porsi cinque domande collegate: quale rete viene utilizzata; quale contratto o identificatore dell'asset è pertinente; quale interfaccia implementa; quali controlli speciali sono presenti; e dove sono descritti i diritti legali? Un block explorer può mostrare un token ID o un evento, ma l'esistenza di un evento non costituisce una verifica indipendente della qualità dei metadati. Un evento “mint” può supportare la conclusione che il codice abbia emesso un'unità; non dimostra la veridicità di un'affermazione associata a tale unità. Un evento di approvazione può rivelare un'autorità delegata, non una vendita conclusa.
Questa distinzione migliora anche le valutazioni di interoperabilità. Gli standard riducono i costi d'integrazione concordando le strutture dei messaggi, ma non possono standardizzare ogni procedura operativa o obbligo giuridico. I progetti del settore pubblico dovrebbero documentare i registri accessibili, i requisiti di conservazione, le procedure di revoca e le modalità con cui i beneficiari possono correggere gli errori. Un'interfaccia standardizzata per i token può essere una componente di un sistema di questo tipo. Non dovrebbe sostituire tacitamente i processi consolidati di identità, registrazione o ricorso senza un'analisi adeguata.
Un esempio di ispezione strutturata
Supponiamo che un ente riceva un NFT che dichiara di certificare la partecipazione a una conferenza. Dovrebbe esaminare l'indirizzo del contratto e il token ID, l'autorità dell'emittente a rilasciare credenziali, la posizione dei metadati e le regole per le correzioni o la revoca. Non dovrebbe presumere che la credenziale sia trasferibile solo perché lo standard supporta i trasferimenti: le funzioni effettive possono includere controlli. Allo stesso modo, un certificato trasferibile potrebbe non soddisfare i requisiti di verifica istituzionali se non è possibile accertare in modo affidabile l'identità del destinatario originale.
Standard e riferimenti giuridici
Le proposte di miglioramento di Ethereum EIP-20 (ERC-20), EIP-721 (ERC-721) ed EIP-1155 (ERC-1155) specificano le interfacce discusse sopra. La qualificazione giuridica resta distinta dalla compatibilità dell'interfaccia.
Focus d'esame: Associa ERC-20 ai saldi fungibili, ERC-721 agli identificatori univoci dei token ed ERC-1155 a più tipi di token; spiega perché i metadati e gli standard dei token non stabiliscono autonomamente la proprietà giuridica.