Conoscere i token nativi

[Paucio]

Documento tradotto da docs.cardano “Learn about native tokens”

I token nativi sono una nuova caratteristica che consente la transazione di multi-asset su Cardano. Gli utenti possono transare con ada e un numero illimitato di token definiti dall’utente (personalizzati) in modo nativo.

Il supporto nativo offre vantaggi distinti per gli sviluppatori: non c’è bisogno di creare contratti intelligenti per gestire i token personalizzati, per esempio, che rimuove un livello di complessità aggiuntiva e il potenziale di errori manuali, poiché il libro mastro gestisce tutte le funzionalità relative ai token.

La funzione dei token nativi estende l’infrastruttura contabile esistente definita nel modello del libro mastro (originariamente progettata per l’elaborazione di transazioni solo ada) per accogliere le transazioni che utilizzano una serie di asset. Questi asset includono ada e una varietà di tipi di token personalizzati definiti dall’utente.

Leggi di più sui token nativi e come si confrontano con ada ed ERC20 e guarda il nostro video esplicativo sui token nativi

Contabilizzazione di un singolo asset

I libri mastri di criptovalute che tracciano esattamente un tipo di attività sono chiamati libri mastri ad asset singolo.

Supporto multi-asset (MA)

Si dice che una blockchain, un libro mastro o una criptovaluta abbia il supporto multi-asset (MA) quando la rete o il libro mastro supporta il tracciamento del trasferimento e della proprietà di diversi tipi di beni sul suo libro mastro. Nell’ambiente Cardano, questa funzionalità è fornita dalla caratteristica nativa dei token.

Questa funzione estende l’infrastruttura contabile esistente definita nel modello di libro mastro, che è progettata per l’elaborazione di transazioni di solo ada, per accogliere le transazioni che utilizzano contemporaneamente una serie di attività. Queste attività includono ada e una varietà di tipi di token personalizzati definiti dall’utente.

Supporto MA nativo e non nativo

Alcuni libri mastri di criptovalute hanno un supporto integrato per tracciare la proprietà e il trasferimento di più di un tipo di asset. Questo tipo di supporto MA è chiamato nativo. La funzionalità MA di Cardano è nativa.

Se una piattaforma di criptovaluta ha una funzionalità di contratto intelligente sufficientemente potente, è possibile tracciare i beni per i quali non esiste un supporto contabile del libro mastro. Questo viene fatto con una soluzione layer-2 costruita utilizzando i contratti intelligenti. Questo tipo di supporto MA non è nativo.

Asset e token

Asset

Un asset è un oggetto che rappresenta un valore sulla blockchain. Questi oggetti possono essere una varietà di cose, come un asset digitale come ada, un ruolo, una credenziale, o una quantità di beni.

Il termine asset può riferirsi sia a:

• l’identificatore di una classe di oggetti, come “ada” o “couttscoins”; o
• una quantità particolare di un oggetto specifico, come “100 lovelace”, “24 couttscoins”, “questa casa” o “queste 10 tonnellate di caffè”

Una risorsa è identificata in modo univoco da un ID risorsa, che è una coppia tra l’ID della politica e il nome della risorsa. È importante notare che, sebbene l’ada possa agire come un asset, non è rappresentato utilizzando un ID di politica esplicito.

I token che hanno lo stesso asset ID hanno la proprietà di essere fungibili tra loro, e non sono fungibili con token che hanno un asset ID diverso. Un asset ID è un identificatore unico per una collezione di token fungibili.

• PolicyID - l’identificatore unico che è associato a una politica di conio. Diamo un’occhiata a due esempi di ID di politica: NFLPlayerCardsPolicyID e RushConcertPolicyID. L’ID è calcolato applicando una funzione hash alla politica stessa, ed è quindi una sequenza di lettere e numeri. Per esempio:

NFLPlayerCardsPolicyID = e0d123e5f316bef7

• Nome della risorsa - una proprietà (immutabile) di una risorsa che è usata per distinguere diverse risorse all’interno della stessa politica. A differenza del policyID, il nome della risorsa non si riferisce a nessun codice o insieme di regole e può essere costituito da parole comuni, come “tickets” o “VIPTickets”, per esempio. Tuttavia, la policy sotto la quale una risorsa ha lo scope può specificare alcuni vincoli sui nomi validi delle risorse.

Politiche diverse possono usare gli stessi nomi di risorse per diversi token. Per esempio, il pacchetto di token:

FAKERushConcertPolicyID { (Tickets, 500),
                           (VIPTickets, 50)}

contiene i nomi delle risorse Tickets e VIPTickets, ma questi non sono fungibili con i biglietti RushConcertPolicyID che sono stati definiti in un altro bundle di token, poiché sono compresi in politiche diverse.

Token

Un token è un termine abbreviato per “asset token”, che è la rappresentazione on-chain di un asset e la sua unità contabile di base. Un token può rappresentare un ada, una casa, o il valore di dieci tonnellate di caffè, per esempio.

Valute

La valuta è un mezzo di scambio per beni e servizi che si riferisce comunemente a un’unità di pagamento. Cardano supporta valute come ada e token nativi, che agiscono in modo simile nella rete.

Tuttavia, ada è la valuta principale che, in questo momento, è accettata come pagamento delle commissioni, per effettuare depositi, ed è anche l’unica valuta in cui vengono distribuite le ricompense. Questa proprietà di ada (e di nessun altro tipo di asset) è dovuta alla costruzione del protocollo di consenso sottostante.

I token nativi rappresentano un certo valore e fungono da unità contabile, che può essere utilizzata per i pagamenti, le transazioni e può essere inviata a un indirizzo di scambio. Nativo significa che questi token sono supportati dal libro mastro contabile di Cardano senza la necessità di ulteriori contratti intelligenti, in quanto il libro mastro dispone di un supporto integrato per tenere traccia della proprietà e del trasferimento di più di un tipo di attività.

Mentre sia i token ada che quelli nativi detengono valore e fungono da unità di pagamento e transazione, solo ada è utilizzato per le commissioni e i premi, mentre solo i token nativi possono essere creati su misura.

Utilizzo di ada per le operazioni amministrative

Ada è la valuta principale di Cardano. È essenziale possedere ada (oltre ad altre valute) per trasferire token multi-asset tra indirizzi, poiché ogni indirizzo deve possedere un valore minimo di ada (min-ada-value, attualmente fissato a 1 ada).

Come conseguenza di questo design, si applica quanto segue:

1. È impossibile creare uscite che contengano solo token personalizzati.
2. Il numero di ogni tipo di token in un output non influenza il min-ada-value dell’output, ma il numero di tipi di token contenuti in un output aumenta il min-ada-value. (La ragione di questo è che i nomi e gli ID delle politiche di ogni tipo di token occupano spazio aggiuntivo nell’output).
3. L’invio di token personalizzati ad un indirizzo comporta sempre l’invio del min-ada-value di ada a quell’indirizzo insieme ai token personalizzati (includendo l’ada nello stesso output). Se l’indirizzo non è spendibile dall’utente che sta inviando i token, l’ada inviato insieme ai token non appartiene più al mittente.

Nota: Prima di trasferire i token personalizzati, gli utenti possono scegliere di utilizzare la comunicazione off-chain per negoziare chi fornisce l’ada per coprire il valore min-ada nell’uscita fatta dalla transazione di trasferimento.

1. Per recuperare l’ada memorizzato insieme ai token personalizzati in un output O, l’utente deve o:

• spendere l’output O e bruciare i token personalizzati che vi sono memorizzati
• Spendere un output O e un output O’, e consolidare i token in esso contenuti con la stessa collezione di tipi di token personalizzati memorizzati in un altro output (speso all’interno della stessa transazione)

Per esempio: (CryptoDoggiesPolicy, poodle, 1) contenuto in O può essere consolidato con (CryptoDoggiesPolicy, poodle, 3) in O’, per un totale di (CryptoDoggiesPolicy, poodle, 4) in una nuova uscita che viene fatta dalla transazione consolidante.

1. Dividere i token personalizzati in più output di quelli in cui erano contenuti prima che la transazione fosse elaborata richiede più ada totali per coprire il valore min-ada, poiché alcuni ada devono essere forniti in ogni output.

Fasci di gettoni

Un bundle di token è una collezione eterogenea (“mista”) di token. Qualsiasi token può essere raggruppato insieme. I pacchetti di token sono il modo standard - e l’unico - per rappresentare e memorizzare beni sulla blockchain di Cardano.

I bundle di token organizzano i token in un particolare tipo di struttura dati (vedi esempio e spiegazione qui sotto), in modo che quali token sono fungibili con quali altri token aderisce esplicitamente a questa organizzazione.

Nelle versioni precedenti del libro mastro di Cardano, gli importi ada erano specificati nelle transazioni e negli output UTxO. Con l’introduzione del supporto multi-asset, questi importi sono stati estesi con i pacchetti di token, che possono specificare un importo ada insieme a quantità di altri asset in un singolo output.

I pacchetti di token sono contenuti nelle uscite e nei campi menta delle transazioni, e le uscite nel set UTxO tracciato dal libro mastro. Si noti che alcuni campi di una transazione devono ancora specificare esplicitamente gli importi ada, come il campo tassa.

Esempio di pacchetto di token

Ecco un esempio di un pacchetto di token, chiamiamolo TB_Example:

{
NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1), 
                        (SomeOtherNFLPlayerCard, 1),
                        (YetAnotherNFLPlayerCard, 1)}


RushConcertPolicyID {(Tickets, 500),
                     (VIPTickets, 50)}
}

Come e dove sono conservati i pacchetti di token?

I bundle di token possono essere trovati:

1. Come campo di menta di una transazione, indicando che la transazione sta creando i token nel bundle.
2. In un output di una transazione o un output nell’UTXO corrente tracciato dal ledger, accanto all’indirizzo dell’output, ad esempio Multi { MyAddress, value: TB_Example }

Dividere e combinare i pacchetti di token

Le transazioni possono arbitrariamente dividere e combinare i bundle di token in diversi bundle. Per esempio, possiamo dividere il bundle TB_Example in due:

TB_Example_Part1:

NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1)}


RushConcertPolicyID {(Tickets, 200),
                     (VIPTickets, 20)}

TB_ExamplePart2:

NFLPlayerCardsPolicyID {(SomeOtherNFLPlayerCard, 1),
                        (YetAnotherNFLPlayerCard, 1)}
 
RushConcertPolicyID {(Tickets, 300),
                     (VIPTickets, 30)}

Confronto con i token ERC20

ERC20 è uno standard di token di Ethereum, ampiamente utilizzato per l’emissione di token su varie piattaforme oggi. La peculiarità di questo tipo di token sta nel fatto che può rappresentare un valore e servire per scopi quali pagamenti, trasferimento di valore, scambio, premi o incentivi, accesso a servizi e prodotti, rappresentare diritti di voto, ecc. Inoltre, questi token possono contenere sia caratteristiche di utilità che di sicurezza, il che apre una gamma di possibili casi d’uso per le aziende, le applicazioni e le imprese.

Su Cardano, gli utenti possono creare token nativi che serviranno agli scopi di cui sopra e, inoltre, è possibile creare beni unici (non fungibili) che rappresentano un valore come beni immobili o diritti intellettuali, per esempio (in Ethereum, questa funzionalità richiede uno standard separato, ERC721).

A differenza dei token ERC20, il monitoraggio e la contabilità dei token nativi sono supportati dal ledger in modo nativo (i token ERC20 richiedono contratti intelligenti per ottenere la stessa cosa). Un importante vantaggio dell’uso dei token nativi è che non richiedono contratti intelligenti per trasferire il loro valore e possono essere trasferiti insieme ad altri tipi di token. Inoltre, a differenza di ERC20, i token nativi non richiedono commissioni di trasferimento speciali o una logica di gestione degli eventi aggiuntiva per tracciare le transazioni.

Un altro vantaggio dei token nativi rispetto all’ERC20 è la sicurezza. I token ERC20 si sono dimostrati vulnerabili ad una vasta gamma di problemi di sicurezza. Questo è condizionato dal fatto che la creazione di token ERC20 richiede la modifica manuale dello standard del contratto, che può comportare errori e possibili bug. La creazione e la transazione di token in modo nativo rimuove la possibilità di errore umano, poiché il libro mastro stesso gestisce la logica del token. Inoltre, le vulnerabilità di over-flow e under-flow che sono presenti per ERC20 sono eliminate per i token nativi, poiché il linguaggio di scripting di Cardano non ha numeri interi a dimensione fissa e il libro mastro stesso (piuttosto che il codice utente ERC20) traccia il movimento dei token.

Politica di conio

Panoramica

Una politica di conio è l’insieme delle regole che governano il conio e la masterizzazione dei beni che rientrano in tale politica. Lo scopo di una politica di conio è quello di specificare le condizioni in cui i token vengono coniati (o bruciati). Per esempio, le regole potrebbero specificare chi ha il controllo sulla fornitura di asset attraverso il conio e la masterizzazione.

Le politiche di conio sono definite dagli utenti che vogliono creare un nuovo asset. Per esempio, un utente potrebbe voler permettere solo a se stesso di coniare ancora un certo tipo di token. Questo verrebbe specificato nella politica.

Le regole di conio possono essere espresse:

Come un insieme molto semplice di regole che si compone di (AND e OR di):

1. Una specifica di quali firme sono necessarie per permettere il conio (ad esempio, una specifica multisig, dove non è necessario alcun codice).
2. Una specificazione di durante quale slot lo script può essere speso (ad esempio, dopo lo slot 15 e prima dello slot 20) Con uno script Plutus Core.

L’aderenza alle politiche di conio è controllata dal nodo nel momento in cui una transazione viene elaborata, eseguendo il codice o controllando le relative firme. Le transazioni devono aderire a tutte le politiche di conio di tutti gli asset che la transazione sta tentando di coniare.

Punti importanti sulle politiche di conio e gli asset

• Tutti gli asset hanno necessariamente una politica di conio. Per esempio, la politica di conio di ada è “nuovi ada non possono mai essere coniati”.
• Un token è associato con (ad esempio, sottoposta a) esattamente una politica di conio.
• Una singola politica specifica sia le condizioni di conio che di masterizzazione dei token che rientrano in essa. L’aderenza ad essa è controllata sia al momento del conio che della masterizzazione.
• Una risorsa non può mai cambiare la sua politica di conio associata. Questa associazione è permanente. In altre parole, i token esistenti non possono essere associati ad una nuova politica. Gli utenti possono, tuttavia, riacquistare e bruciare tutti i token esistenti e coniarne di nuovi, con una nuova politica di conio. Si noti che questa è una caratteristica, non un bug!
• Se un asset esistente sul libro mastro è sotto una particolare politica, è garantito che è stato originariamente coniato secondo quella politica.
• A meno che i token di una data politica siano coniati in una transazione, la politica effettiva è irrilevante. Viene solo usata come identificatore dell’asset.
• Gli asset associati a diverse politiche di conio non sono mai fungibili tra loro. Possono essere scambiati nello stesso modo in cui si può usare l’USD per comprare il CAD: la quantità di CAD che si può comprare con una quantità fissa di USD dipende dal tasso di cambio del luogo in cui si effettua lo scambio.

Associazione tra un asset e la sua politica di conio

L’associazione tra un asset e la sua politica di conio è permanente per motivi di sicurezza: questa caratteristica protegge gli utenti e il sistema da token coniati illegittimamente.

Se la politica di conio di un token cambia, non è più lo stesso token, e il suo valore non può essere paragonato a quello del token originale. Questo schema di associazione permanente asset-policy è parte integrante della definizione di politiche ad alta garanzia. Allentare questa identificazione apre il nostro schema MA a vari attacchi. Avere un’associazione permanente tra questi ci permette di garantire che ogni token è stato coniato in accordo con la sua politica di conio, e non con qualsiasi altra politica a cui potrebbe essere stato precedentemente associato.

Si noti che questo non è così restrittivo come sembra. In un parallelo con la politica monetaria degli Stati Uniti, possiamo dire che la politica è “il governo e le leggi stabiliscono la politica”, e questa è una politica che richiede la ricerca delle leggi attuali (che potrebbero cambiare), e solo la coniazione di denaro in aderenza ad esse.

Esempi di politica di conio

• Politica del singolo emittente
• Politica della zecca a tempo
• Politica di zecca unica

Nota: ci sono molti altri tipi di politiche di conio.

Politica a singolo emittente

Una politica di conio a singolo emittente specifica che solo l’entità che possiede un particolare set di chiavi è autorizzata a coniare token di un particolare gruppo di asset. Per esempio, il set di chiavi specificato nella politica di conio deve aver firmato la transazione di conio.

Un esempio di un gruppo di beni che userebbe una politica di conio singolo sarebbe quello dei gettoni che rappresentano carte da baseball. L’azienda che produce carte da collezione legittime pubblicherebbe le chiavi richieste dalla politica di conio per coniare nuove carte da baseball. Questo significherebbe che nessun nuovo gettone di carta da baseball può essere coniato senza la firma dell’azienda. Questo tipo di politica può essere implementata senza contratti intelligenti Plutus.

Politica di conio a tempo (token-locking)

Questo tipo di politica può essere usato per specificare quando i token possono essere spesi da un indirizzo. In particolare,

• solo in o dopo una determinata fascia oraria
• solo prima di una determinata fascia oraria

Questo tipo di policy di solito non è usato da solo. Di solito, è in congiunzione con la politica della multisignature o del singolo emittente, ad es. Questa uscita può essere spesa dopo lo slot s e solo da una transazione firmata dalla chiave k.

Questo tipo di politica può essere implementato senza contratti intelligenti Plutus.

Politica di conio una tantum

In una politica di conio una tantum, l’intero set di token di un dato gruppo di asset è coniato da una specifica transazione. Questo significa che non verranno mai più coniati altri token di quel particolare gruppo di attività. Questo tipo di politica ha bisogno di contratti intelligenti Plutus per essere implementata.

Le politiche di conio di un tipo sarebbero utili per generare gettoni di biglietti per un concerto specifico, per esempio. La capacità del locale è nota in anticipo, quindi non ci sarà mai bisogno di permettere che vengano coniati più biglietti.

Transazioni di conio

Per introdurre nuove quantità di nuovi gettoni nel libro mastro (conio) o per rimuovere i gettoni esistenti (masterizzazione), ogni transazione presenta un campo di conio. Le transazioni in cui il campo di conio non è vuoto sono note come transazioni di conio. L’uso di questo campo deve essere strettamente controllato per assicurare che il conio e la masterizzazione dei token avvengano secondo la politica di conio del token

Oltre al campo di conio, le transazioni di conio devono anche portare le politiche di conio per i token che stanno coniando, in modo che questi token possano essere controllati durante la convalida.

Il risultato dell’elaborazione di una transazione di conio è che il libro mastro conterrà gli asset inclusi nel campo di conio, che è incluso nel bilanciamento della transazione: se il campo è positivo, allora gli output della transazione devono contenere più asset di quelli forniti dagli input; se è negativo allora devono contenerne di meno.

È importante sottolineare che una singola transazione potrebbe coniare token associati a più e distinte politiche di conio. Per esempio, (Policy1, SomeTokens) o (Policy2, SomeOtherTokens). Inoltre, una transazione potrebbe coniare simultaneamente alcuni token e bruciarne altri.

Il ciclo di vita del token nativo

Il ciclo di vita del token nativo consiste in cinque fasi principali:

1. conio
2. emissione
3. utilizzo
4. riscatto
5. masterizzazione

Il seguente diagramma delinea l’interazione tra i componenti del sistema:

Ognuna di queste fasi logiche comporta transazioni sulla blockchain di Cardano, che possono comportare commissioni in ada. I principali gruppi di attori sono:

Controllori di asset, che definiscono la politica per la classe di asset, e autorizzano gli emittenti di token a coniare/bruciare token. Possono anche mantenere i diritti di co-firma per qualsiasi token che viene emesso/combustione.

Emittenti di token, che coniano nuovi token, mantengono la riserva di token in circolazione, li emettono ai possessori di token e bruciano i token quando non sono più utili.

I detentori di token, che detengono i token, li inviano ad altri utenti, li usano per il pagamento, e che possono riscattarli presso gli emittenti quando hanno finito di usarli. Gli utenti di token possono includere utenti normali, scambi, ecc.

Il ciclo di vita dei token multi-asset inizia con la loro creazione - minting, che si riferisce al processo in cui nuovi token vengono creati da uno o più emittenti di token in conformità con lo script di politica monetaria che il controllore degli asset ha definito. I nuovi token saranno di solito creati per soddisfare scopi specifici. Per esempio, i token fungibili o non fungibili (unici) possono essere creati per essere usati per specifiche esigenze di pagamento, acquisto o scambio. Quando un nuovo token viene coniato, la fornitura totale di token per quel token aumenta, ma non c’è impatto sulla fornitura di ada. Coniare monete e trasferirle a nuovi indirizzi può richiedere il pagamento di un deposito ada, che può essere proporzionale al numero di token diversi che sono detenuti, per esempio.

I possessori di token terranno i token nei loro portafogli, possono passarli ad altri utenti, scambiarli con oggetti di valore (compresi i token non nativi), ecc. esattamente nello stesso modo in cui possono usare ada. Quando un utente ha finito di usare il token, può scegliere di riscattarlo. Questo significa che i token vengono restituiti a un emittente (forse in cambio di un prodotto, un servizio o qualche altra valuta, per esempio). Una volta riscattati, i token potrebbero essere riemessi ad altri utenti secondo necessità. I possessori di token dovranno mantenere alcuni ada nei loro portafogli per pagare le spese di transazione.

Quando i token diventano ridondanti, possono essere bruciati, se lo si desidera, in conformità con lo script di politica monetaria sottostante. Il processo di combustione distrugge questi token (li rimuove dalla circolazione), e la fornitura totale di token diminuisce. Qualsiasi deposito sarà restituito a questo punto. Il processo di combustione è identico per i token fungibili e non fungibili.

Nota: Il ciclo di vita del token multi-asset permette potenzialmente ai token di essere ottenuti e riemessi da altre parti - detentori di token che agiscono come riemittenti per il token. Questo può essere fatto, ad esempio, per consentire il trading in più classi di asset, mantenere la liquidità in uno o più token (agendo come broker), o per eliminare lo sforzo/costo della coniazione dei token, dell’emissione o della manutenzione del server dei metadati. Quindi, sia i riemittenti che gli emittenti possono guadagnare da un tale accordo - eliminando costi e sforzi, mantenendo la separazione e l’integrità, e iniettando valore nella classe di attività.