Standard dei Token Spiegati: ERC-20, ERC-721, ERC-1155 e Altri

Uno standard per token è una specifica pubblicata che indica a un contratto token quali funzioni esporre e quali eventi emettere. Portafogli, exchange e applicazioni possono così gestire qualsiasi token conforme senza codice personalizzato per ognuno. Questa guida copre gli standard che incontrerà più spesso (ERC-20, ERC-721, ERC-1155 e i loro equivalenti su Tron e Solana). Tratta anche del funzionamento dei decimali ERC-20 e di cosa verificare prima di integrare un token in un flusso di pagamento.

TL;DR

• Uno standard per token definisce un’interfaccia (funzioni ed eventi) più regole comportamentali, così il software può interagire con qualsiasi token conforme nello stesso modo.
• ERC-20 è per token fungibili, ERC-721 per NFT unici ed ERC-1155 per molti tipi di token in un unico contratto.
• TRC-20 rispecchia ERC-20 su Tron, mentre Solana usa il proprio programma SPL token, quindi “stesso standard” non significa mai “stessa chain”.
• Gli importi on-chain sono interi. Il valore opzionale decimals indica dove posizionare il separatore decimale per la visualizzazione.
• La conformità non è garantita. Verifichi il comportamento reale di ogni token prima di farvi affidamento.

Indice

• Cosa definisce effettivamente uno standard per token
• ERC-20: lo standard per token fungibili
• Decimali ERC-20: gestire correttamente gli importi
• ERC-721: token non fungibili
• ERC-1155: molti tipi di token in un unico contratto
• Confronto tra i tre standard Ethereum
• Standard per token su altre chain
• Cosa verificare prima di integrare un token
• Prospettiva: perché gli standard sono solo metà del lavoro
• Mettere gli standard al lavoro con Chaingateway
• FAQ
• Fonti

Cosa definisce effettivamente uno standard per token

Un token non è una coin nativa. È un registro tenuto all’interno di uno smart contract: chi detiene quanto e quali regole governano il suo spostamento. Senza una specifica condivisa, ogni token esporrebbe i propri nomi di funzione e ogni portafoglio necessiterebbe di codice su misura per leggere i saldi o inviare trasferimenti.

Uno standard risolve il problema. Secondo la pagina sugli standard per token di ethereum.org, gli standard definiscono come i token si comportano e interagiscono, mantenendo gli smart contract componibili e permettendo ai nuovi token di funzionare con exchange decentralizzati e applicazioni esistenti. La panoramica NIST sul design dei token descrive gli ERC come fornitori di dichiarazioni di funzioni ed eventi, vincoli e requisiti, e talvolta implementazioni di riferimento.

In pratica uno standard le fornisce quattro elementi:

1. Funzioni richiamabili, come la lettura di un saldo o lo spostamento di token.
2. Eventi, che il contratto emette così che il software esterno possa seguire l’attività.
3. Tipi di dati e vincoli, come la rappresentazione degli importi.
4. Requisiti comportamentali, come quali chiamate devono attivare quale evento.

Su Ethereum, queste specifiche vengono proposte come ERC, la categoria a livello applicativo delle Ethereum Improvement Proposals. Altre blockchain hanno i propri processi e nomi, ma il concetto rimane invariato.

ERC-20: lo standard per token fungibili

ERC-20 è stato creato nel 2015 e definisce una API standard per token all’interno di smart contract, in modo che portafogli ed exchange decentralizzati possano riutilizzarli. “Fungibile” significa che ogni unità è intercambiabile con qualsiasi altra unità, come dollari o chilogrammi d’oro. Stablecoin, token di governance e la maggior parte dei token di pagamento lo seguono.

L’interfaccia, come elencata nella documentazione ERC-20, include:

Funzione o evento	Cosa fa
totalSupply	Restituisce il numero totale di token in circolazione
balanceOf	Restituisce il saldo di un indirizzo
transfer	Sposta token dal chiamante a un altro indirizzo
approve	Autorizza un altro indirizzo (uno spender) a spostare fino a un importo prestabilito dei suoi token
allowance	Restituisce quanto uno spender può ancora spostare per conto di un proprietario
transferFrom	Sposta token per conto di un proprietario, utilizzando un’approvazione
name, symbol, decimals	Metadati descrittivi, comunemente presenti
Eventi Transfer, Approval	Emessi su trasferimenti e approvazioni

La specifica stabilisce che i trasferimenti devono attivare l’evento Transfer e le chiamate approve andate a buon fine devono attivare Approval. Questa regola è ciò che rende possibile il rilevamento dei pagamenti: è possibile monitorare gli eventi invece di interrogare ogni indirizzo. Approfondiamo questo aspetto nella nostra guida all’evento ERC-20 Transfer, e la nostra panoramica sullo standard ERC-20 illustra l’interfaccia completa.

Il pattern approve e transferFrom

Il pattern in due passaggi confonde i nuovi arrivati. Con transfer, il detentore del token invia i token direttamente. Con approve più transferFrom, il detentore autorizza prima uno spender, e lo spender preleva i token in un secondo momento. È così che un exchange decentralizzato o un contratto di abbonamento incassa un pagamento senza detenere le sue chiavi. Se deve solo inviare token da un portafoglio che controlla, transfer è tutto ciò che le serve. La nostra procedura dettagliata su come inviare token ERC-20 confronta i metodi tramite portafoglio, codice e API.

ERC-20 decimals: gestire correttamente gli importi

Gli smart contract non memorizzano frazioni. Ogni saldo è un intero, e decimals indica quante delle cifre più a destra rappresentano la parte frazionaria. La specifica ERC-20 rende il metodo opzionale e fornisce un esempio: con 8 decimali, si divide l’importo del token per 100000000 per ottenere la sua rappresentazione per l’utente.

Ciò ha tre conseguenze pratiche.

Legga sempre decimals dal contratto. Non codifichi un valore fisso per tutti i token. Due token che entrambi vengono visualizzati come “1,00” possono essere memorizzati come interi molto diversi.

Esegua i calcoli con interi o tipi big-number. Gli importi grezzi possono superare ciò che un numero a virgola mobile standard contiene esattamente. Utilizzi BigInt, BigNumber, o il tipo decimale del suo linguaggio, e formatti per la visualizzazione solo all’ultimo passaggio.

Considerare un metodo decimals mancante come un caso da gestire. Poiché il metodo è opzionale, un token conforme potrebbe non esporlo. Decida una strategia di fallback, come rifiutare il token o richiedere una configurazione manuale, piuttosto che assumere silenziosamente un valore predefinito.

Un esempio pratico: un token con 6 decimali mostra un saldo grezzo di 2500000. Dividendo per 10^6 si ottengono 2,5 token. Per inviare 0,75 token si invia 750000, non 0,75. Inviare per errore il valore visualizzato invierebbe una quantità infinitesima, e la transazione avrebbe comunque successo.

ERC-721: token non fungibili

Mentre ERC-20 tratta ogni unità allo stesso modo, ERC-721 è un’interfaccia per token non fungibili, come opere d’arte o brani musicali unici. Ogni token ha un identificatore distinto all’interno del suo contratto, quindi la proprietà viene tracciata per token piuttosto che come saldo. Gli usi tipici sono oggetti da collezione, biglietti, oggetti di gioco e prove di proprietà.

Il compromesso è costo e complessità. Spostare dieci NFT non correlati significa dieci trasferimenti separati. Per i dettagli dell’interfaccia, consulti la nostra guida allo standard ERC-721.

ERC-1155: molti tipi di token in un unico contratto

ERC-1155 è un’interfaccia multi-token. Un singolo contratto distribuito può rappresentare qualsiasi numero di tipi di token fungibili, non fungibili o semi-fungibili, ciascuno identificato da un token ID che può avere i propri metadati e la propria fornitura. La specifica supporta anche il trasferimento di più tipi di token in un’unica operazione.

Ciò lo rende ideale per i giochi, dove un singolo contratto potrebbe contenere una valuta, un set di consumabili e alcuni oggetti unici. Si distribuisce una volta e si possono raggruppare i movimenti invece di inviare una transazione per tipo di asset.

Confronto tra i tre standard Ethereum

	ERC-20	ERC-721	ERC-1155
Tipo di token	Fungibile	Non fungibile	Fungibile, non fungibile o semi-fungibile
Traccia	Un saldo per indirizzo	Un proprietario per token ID	Saldi per indirizzo per token ID
Contratti necessari	Uno per token	Uno per collezione	Uno per molti tipi di token
Trasferimenti batch	Non parte dello standard	Non parte dello standard	Integrati
Uso tipico	Stablecoin, token di pagamento e governance	Oggetti da collezione, biglietti, asset unici	Giochi, cataloghi di asset misti

Standard token su altre chain

I nomi cambiano da chain a chain, ma l’idea rimane la stessa.

Tron: TRC-20 e TRC-10. TRC-20 è lo standard per token fungibili su TRON ed è compatibile con ERC-20 a livello di interfaccia, quindi la maggior parte dei contratti token Ethereum richiede poche modifiche per funzionare lì. Tron ha anche il più vecchio TRC-10 a livello di protocollo. Spieghiamo le differenze pratiche in TRC-10 vs TRC-20.

BNB Chain: BEP-20. BEP-20 segue il modello ERC-20 su una chain compatibile EVM, quindi i nomi delle funzioni e le forme degli eventi le risulteranno familiari.

Solana: token SPL. Solana non distribuisce un nuovo contratto per ogni token. I token vengono creati tramite il programma SPL Token condiviso, e un NFT su Solana è semplicemente un token creato con zero decimali. Il modello mentale differisce da Ethereum, anche se l’obiettivo di interoperabilità è lo stesso.

Ecosistema Cosmos: CW20. La specifica CW20 gestisce saldi e trasferimenti utilizzando interi Uint128 e delega la gestione dei decimali all’interfaccia utente, che è la stessa separazione tra intero e visualizzazione di ERC-20.

Uno standard con lo stesso nome su una catena diversa non è mai intercambiabile con l’originale. Un USDT TRC-20 e un USDT ERC-20 sono asset diversi su reti diverse, e l’invio alla rete sbagliata può causare la perdita dei fondi. Abbinare sempre un indirizzo alla sua rete nel proprio modello dati.

Cosa verificare prima di integrare un token

Uno standard descrive cosa un token dovrebbe fare, non cosa fa ogni contratto distribuito. Uno studio del 2022 su IET Software ha riportato che l’ambiguità nell’interfaccia ERC-20 può portare a interpretazioni diverse e vulnerabilità di conformità tra i contratti token reali.

La checklist per l’integrazione dei token su ethereum.org è una buona base di partenza. Chiede agli sviluppatori di esaminare:

• conformità e valori di ritorno delle funzioni standard,
• funzioni opzionali e decimali,
• mitigazione delle race condition sulle approvazioni,
• chiamate esterne all’interno del token,
• commissioni o interessi prelevati al trasferimento,
• aggiornabilità, poteri di minting, pausa e blacklisting,
• rischi legati al proprietario e al team, e concentrazione dell’offerta.

Per un prodotto di pagamento, quelli che creano più problemi sono spesso il comportamento fee-on-transfer (l’importo ricevuto è inferiore a quello inviato), il blacklisting (un trasferimento può essere bloccato a posteriori) e i valori di ritorno non standard. Testare ogni token che si intende supportare su una testnet con trasferimenti reali, e accreditare i depositi in base all’importo effettivamente ricevuto, non a quello richiesto.

Prospettiva: perché gli standard sono solo metà del lavoro

Gli standard risolvono il problema di come un token parla con una catena. Non risolvono il problema di gestire un prodotto su diverse catene. Se accetta pagamenti su Ethereum, Tron e Solana, deve comunque affrontare formati di indirizzo diversi, modelli di commissioni diversi, strutture di eventi diverse e infrastrutture di nodi diverse.

Abbiamo creato Chaingateway per colmare questo divario. La nostra visione è che gli sviluppatori non dovrebbero dover mantenere endpoint specifici per catena o gestire i propri nodi solo per sapere che un cliente ha pagato. Ecco perché restituiamo dati pre-decodificati, così un trasferimento arriva come campi leggibili invece di argomenti di log grezzi, e perché stimiamo il gas automaticamente. Firmiamo le richieste webhook con HMAC in modo che il Suo backend possa verificare che una notifica di pagamento sia autentica.

Il nostro consiglio per i team che iniziano: scelga lo standard che corrisponde al suo asset (fungibile, unico o misto), legga i decimali dal contratto ogni volta, e costruisca il rilevamento dei pagamenti sugli eventi piuttosto che sul polling. Tutto il resto è impiantistica, e l’impiantistica è ciò che un’API dovrebbe assorbire.

— Bitblade

Mettere gli standard al lavoro con Chaingateway

Se sta sviluppando pagamenti o wallet basati su questi standard, la nostra Blockchain API Le offre un’unica interfaccia REST per creare wallet, inviare trasferimenti di token e NFT, recuperare dati di transazione decodificati e stimare le commissioni su Ethereum, Bitcoin, Tron, Solana, Polygon, BNB Chain e Arbitrum. Supporta i principali standard di token, inclusi ERC-20, BEP-20, TRC-20 ed ERC-721. I Chaingateway Webhooks inviano notifiche in tempo reale quando arriva un pagamento, così non deve fare polling.

I piani partono da 49 € al mese per Plus, con Pro a 99 €, Premium a 249 € ed Enterprise a 499 € al mese. La fatturazione annuale è rispettivamente di 490 €, 990 €, 2.490 € e 4.990 €. Consulti la pagina dei prezzi per vedere cosa include ogni piano. Per Ethereum in particolare, la nostra Ethereum API mostra come inviare token ERC-20 via REST senza web3.js.

Fonti

• Standard per i token, ethereum.org
• Standard per lo sviluppo su Ethereum, ethereum.org
• Standard per token ERC-20, ethereum.org
• ERC-20: Standard per token, EIP-20
• ERC-1155: Standard per token multipli, EIP-1155
• Elenco di controllo per l’integrazione dei token, ethereum.org
• Reti blockchain: Panoramica su progettazione e gestione dei token, NIST
• Valutazione della conformità dei primi 100 smart contract di token Ethereum, IET Software
• Standard per token fungibili TRC-20, documentazione per sviluppatori TRON
• Token, documentazione Solana SPL
• Specifica CW20, CosmWasm

Consigliati

• Lo standard per token ERC20
• Lo standard per token ERC721