ERC-1155

ERC-1155 è lo standard multi-token di Ethereum: un contratto può registrare molti tipi di token fungibili, non fungibili o misti per ID e trasferire più ID in un unico lotto.

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

ERC-1155 è lo standard multi-token di Ethereum. Un singolo contratto può gestire molti tipi di token e ogni token ID può rappresentare un saldo fungibile, un oggetto non fungibile o un’altra struttura dell’offerta scelta dall’implementazione. La chiave dell’asset è quindi contract address + token ID, non il solo ID del token.

Lo standard definisce interrogazioni del saldo singole e in batch, trasferimenti sicuri singoli e in batch, approvazione globale dell’operatore, callback del destinatario, eventi di trasferimento e un comportamento opzionale per l’URI dei metadati. Non stabilisce chi possa coniare, se l’offerta abbia un limite, se i metadati siano permanenti, quali diritti legali conferisca un token o quanto valga. Queste proprietà devono essere verificate nel contratto specifico, nei suoi ruoli e nelle sue dipendenze esterne.

Come funziona

Identificare il saldo. balanceOf(account, id) restituisce la quantità di un ID detenuta da un account. balanceOfBatch(accounts, ids) interroga coppie account-ID. Due contratti possono usare entrambi l’ID 1 per asset non correlati, quindi l’identità completa resta la blockchain, l’indirizzo del contratto e l’ID.
Autorizzare il chiamante. Un titolare può trasferire il proprio saldo o chiamare setApprovalForAll(operator, true). Questa approvazione copre ogni ID ERC-1155 che il titolare possiede in quel contratto; isApprovedForAll(owner, operator) ne indica lo stato. ERC-1155 non include un’approvazione nativa limitata a un singolo ID o importo.
Applicare un trasferimento singolo o in batch. safeTransferFrom sposta un ID e una quantità. safeBatchTransferFrom sposta gli array paralleli ids e values, che devono avere lunghezza e ordine corrispondenti. Il batching può ridurre i costi ripetuti delle transazioni, ma non è garantito che sia più economico per ogni implementazione o carico di lavoro.
Controllare un contratto destinatario. Dopo aver aggiornato i saldi ed emesso l’evento pertinente, un trasferimento conforme verso un contratto chiama onERC1155Received o onERC1155BatchReceived. Una callback non supportata, un valore di ritorno errato o un rifiuto normalmente annullano il trasferimento. Questo controllo riduce i blocchi accidentali; non dimostra che il contratto destinatario sia affidabile o offra un percorso di prelievo.
Ricostruire lo stato dagli eventi. Ogni conio, trasferimento e distruzione deve essere rappresentato da TransferSingle o TransferBatch. Il conio usa l’indirizzo zero come from; la distruzione lo usa come to. Gli indicizzatori possono ricavare da questi log i saldi e l’offerta netta coniata per ID, ma devono elaborare correttamente l’intera cronologia, le riorganizzazioni della blockchain e le migrazioni dei contratti.
Risolvere i metadati. L’estensione URI opzionale può restituire un modello condiviso contenente {id}. Un client lo sostituisce con l’ID del token esadecimale in minuscolo, completato con zeri fino a 64 caratteri e senza il prefisso 0x. I metadati possono comunque essere modificabili, non disponibili o fuorvianti, a meno che l’implementazione e le garanzie di archiviazione non indichino diversamente.

Esempio pratico

Un contratto di gioco assegna l’ID 1 alle monete d’oro, l’ID 7 ai pass di accesso e l’ID 42 a una spada unica. Alice detiene balanceOf(Alice, 1) = 500, balanceOf(Alice, 7) = 3 e balanceOf(Alice, 42) = 1.

Alice chiama safeBatchTransferFrom con ids = [1, 7, 42] e values = [120, 1, 1]. Se la convalida riesce, i suoi nuovi saldi sono 500 - 120 = 380, 3 - 1 = 2 e 1 - 1 = 0; il destinatario riceve le quantità corrispondenti.
Il contratto emette TransferBatch. Se il destinatario è un contratto, deve accettare il batch tramite onERC1155BatchReceived; altrimenti l’intera transazione viene annullata e nessuna delle tre modifiche ai saldi rimane.
L’ID 42 si comporta come non fungibile solo perché la sua logica di emissione e trasferimento mantiene l’offerta a 1. ERC-1155 non impone questa regola. Lo stesso contratto può coniare in seguito altre unità dell’ID 1, nel rispetto del proprio controllo degli accessi.

Rischi e controlli

Ampia autorità dell’operatore. Un operatore malevolo o compromesso approvato tramite setApprovalForAll può spostare ogni ID posseduto in quel contratto. Verifica l’indirizzo e il contratto dell’operatore, usa un wallet separato quando opportuno e revoca le approvazioni obsolete.
Poteri di conio, sospensione e aggiornamento. Sono caratteristiche dell’implementazione, non garanzie dello standard. Esamina i titolari dei ruoli, gli amministratori dei proxy, i timelock, le estensioni dell’offerta e se un aggiornamento possa modificare i saldi o le regole di trasferimento.
Disallineamento tra metadati e asset. Un URI o un file JSON ospitato può cambiare mentre l’ID on-chain resta invariato. Verifica gli hash dei contenuti, la persistenza dell’archiviazione, gli impegni dell’emittente e i diritti rappresentati al di fuori del contratto del token.
Errori di integrazione. Wallet e indicizzatori possono abbinare in modo errato gli array di un batch, omettere eventi storici, gestire male le riorganizzazioni o confondere lo stesso ID tra contratti e blockchain. Concilia le chiamate al contratto, i log e i saldi finali.
Rischio del destinatario e di rientranza. Le callback del destinatario eseguono codice esterno durante il flusso di trasferimento. Le implementazioni e i protocolli che le integrano necessitano di un ordine dello stato adeguato e di difese contro la rientranza; il supporto delle callback, da solo, non costituisce una verifica di sicurezza.
Rischio di costi e liquidità. I trasferimenti in batch consumano comunque gas e vengono annullati atomicamente se una condizione necessaria non è soddisfatta. Liquidità di mercato, determinazione dei prezzi, royalty, bridge, riscatto e applicazione off-chain non rientrano in ERC-1155.

Idee sbagliate comuni

«Ogni ID è un NFT». Un ID può avere qualsiasi quantità; la non fungibilità dipende dall’offerta e dalla semantica dell’implementazione.
«Un contratto equivale a una collezione». Un contratto può contenere molti tipi di token non correlati e lo stesso ID numerico in un altro contratto identifica un asset diverso.
«Trasferimento sicuro significa che l’asset è sicuro». La callback verifica la compatibilità del destinatario, non la qualità del contratto, il prezzo, i metadati o la recuperabilità.
«Il batching fa sempre risparmiare gas». Spesso evita costi ripetuti, ma il risultato effettivo dipende dall’implementazione, dal numero di ID, dalle modifiche all’archiviazione, dai calldata e dal modello di commissioni della rete.