Asset On-chain
Qual è la definizione di supporto ‘multi-asset (MA)’ e Cardano la possiede?
Il supporto multi-asset (MA) è il nome di una serie di caratteristiche (funzionalità) che un ledger (/blockchain/wallet/cryptocurrency/banking platform) può fornire, il che gli permette di fare contabilità o transazioni con più di un tipo di asset.
La funzione di supporto MA di Cardano si chiama Native Tokens. MA permette agli utenti di interagire con ada ed un numero illimitato di token definiti dall’utente. Questo supporto è nativo, il che significa che i token possono essere transati con (tracciati/sentiti/ricevuti) utilizzando il sistema di contabilità definito come parte della funzionalità ledger della criptovaluta, senza la necessità di smart contract per abilitare questa funzionalità.
Cos’è la tokenizzazione (degli asset)?
Tokenizzare un asset significa creare una rappresentazione on-chain di quell’asset.
Coniare (Minting)
Cosa significa “coniare” un token?
La “coniazione” si riferisce al processo con cui vengono creati o distrutti nuovi token. Cioè, la quantità totale in circolazione (cioè sommata a tutti gli indirizzi sul ledger) del tipo di token che viene coniato aumenta o diminuisce. Coniare una quantità positiva di token è la creazione di token, e coniare una quantità negativa è la distruzione di token.
Cosa significa “bruciare” un token?
“Bruciare” si riferisce al processo con cui i gettoni vengono distrutti. È sinonimo di “conio negativo”.
Che cos’è il riscatto dei token?
Il riscatto dei token è l’azione di rimandare i token all’emittente per essere bruciati. Questo viene fatto di solito quando i token che vengono riscattati non hanno più uno scopo nel ledger, e l’utente o il contratto in possesso di essi non è in grado (non autorizzato dalla politica di conio) di bruciare i token.
Non ci può essere alcun compenso offerto per riscattare i token (la decisione di questo spetta all’emittente del token / minting policy), ma l’utente può scegliere di farlo comunque per evitare di avere token inutilizzabili nel proprio portafoglio.
Cos’è una transazione di conio?
Le transazioni hanno una struttura diversa nelle ere Shelley, ShelleyMA e Goguen, ma questa struttura è la stessa all’interno di una singola era. Le transazioni Shelley+MA e Goguen possono contenere dati che specificano quali token stanno coniando. Le transazioni in cui questo frammento di dati della transazione (chiamato campo mint) non vuoto è chiamato transazione di conio. Queste transazioni devono anche portare le politiche di conio per i token che stanno coniando, in modo che possano essere controllate durante la convalida.
Il risultato dell’elaborazione di una transazione di conio è che il ledger ora conterrà anche gli asset inclusi nel campo di conio (minting field) della transazione. Se la quantità di un particolare bene nel campo di conio è negativa, il risultato è che dopo l’elaborazione della transazione, la quantità totale di quel bene specifico sul ledger sarà ridotta della quantità riflessa nel campo di conio.
Si noti che una singola transazione può coniare gettoni associati a più politiche di conio distinte, ad esempio (Policy1, alcuni token), (Policy2, alcuni altri token). Si noti anche che una transazione potrebbe simultaneamente coniare alcuni gettoni e bruciarne altri.
Cos’è una politica di conio?
Una politica di conio è un insieme di regole usate per regolare il conio di asset associati ad essa (valutati sotto di essa). Per esempio, chi ha il controllo (e a quali condizioni) sulla fornitura della valuta, e sul suo conio e la sua combustione. Queste regole riguardano il contenuto dei dati della transazione che sta tentando il conio. Ad esempio, una politica di conio può richiedere un particolare insieme di chiavi per firmare la transazione di conio.
Questo insieme di regole è definito dall’utente che desidera creare il nuovo bene. Per esempio, un utente potrebbe voler lasciare che solo lui stesso possa coniare questo particolare tipo di token. In questo caso, lo stabilirebbe nella policy. Il nodo controlla la conformità alle politiche di conio quando una transazione viene elaborata eseguendo il codice o controllando le firme pertinenti. I dati della transazione devono soddisfare tutte le politiche di conio di tutti gli asset che la transazione sta tentando di coniare.
Cos’è un generatore di token e qual è la sua funzionalità?
Un token builder è un software che permette all’utente di definire i token da coniare e includerli in una transazione di conio. Assicura anche che i dati aggiuntivi appropriati necessari per verificare che la transazione sia autorizzata a eseguire il conio siano inclusi nella transazione (vedi la domanda sulla politica di conio più avanti).
Esempi e modi di definire la policy
Cos’è il “multisig” e come è collegato alle policy di conio?
Il linguaggio di scripting multisig (che esisteva prima dell’introduzione della funzionalità MA su Cardano) specifica un insieme minimo di firme necessarie per consentire a una transazione di eseguire una certa azione, di solito per spendere una voce UTxO.
Gli script Multisig possono anche essere utilizzati per specificare le policy di conio più elementari, cioè le politiche che richiedono un insieme specifico di chiavi per firmare la transazione di conio. Per esempio, una policy di conio a singolo emittente può essere espressa usando uno script multisig. Si noti che le policies di conio sono gli unici tipi di policy che possono essere espressi utilizzando multisig.
Senza la capacità dello smart contract Plutus, o qualsiasi altra estensione del linguaggio delle policy di conio, multisig è l’unico modo per specificare una policy di conio.
Cosa hanno a che fare gli smart contract Plutus con i Native Token?
Le policy di conio possono essere scritte nel linguaggio degli smart contract di Plutus. Questo permette agli utenti di esprimere una gamma molto più ampia di policy rispetto alla sola policy del singolo emittente esprimibile utilizzando multisig. La policy di conio una tantum, per esempio, può essere espressa in Plutus (ma non solo come multisig).
Cos’è una policy di conio a singolo emittente?
Una policy di conio a singolo emittente specifica che solo l’entità in possesso di un particolare insieme di chiavi è autorizzata a coniare token sotto una particolare policy. Per esempio, l’insieme di chiavi specificato nella policy di conio deve aver firmato la transazione di conio. Questo tipo di policy può essere specificata usando multisig.
Un esempio di un caso d’uso di policy di conio singolo potrebbe essere quello di gettoni che rappresentano carte da baseball. Questo significherebbe che nessun nuovo token di carte da baseball potrebbe essere coniato senza la firma dell’azienda. Al contrario, la policy dimostra che tutte le carte esistenti sotto questa policy sono state legittimamente coniate dalla società di carte da baseball.
Cos’è una policy di conio una tantum?
In una policy di conio una tantum, l’intero set di token che rientrano in questa policy sono coniati da una transazione specifica. Questo significa che non verranno mai più coniati altri token sotto quella policy. Questo tipo di policy richiede smart contract e non può essere espressa usando multisig.
Un caso d’uso di una policy di conio una tantum potrebbe essere la coniazione di gettoni di biglietti per un concerto specifico. La capacità del locale è nota in anticipo, quindi non ci sarà mai bisogno di permettere che vengano coniati più biglietti.
Struttura, rappresentazione e proprietà dei multi-asset
Cos’è la fungibilità e la non fungibilità?
La fungibilità è una relazione tra due asset/token. I gettoni si dicono fungibili tra loro quando sono intercambiabili. Per esempio, il denaro fiat è fungibile in quanto una banconota da 10 dollari è intercambiabile con tutte le altre (reali) banconote da 10 dollari (e tutti i 10 set di banconote da 1 dollaro, e tutte le coppie di 5 dollari).
I beni non fungibili non sono intercambiabili tra loro. Per esempio, due diamanti, o due gettoni on-chain che rappresentano i due diamanti del mondo reale. Se non ci sono altri beni con cui un token è fungibile - come un token che rappresenta una casa - il token è considerato unico (non fungibile).
Cos’è un gruppo di token?
Una collezione mista di gettoni sotto una o più politiche di conio. Qualsiasi token può essere raggruppato insieme.
Per maggiori dettagli, vedi la sezione sui gruppi di token.
Operare con i token nativi
Come appaiono i token nativi nel portafoglio di un utente?
Prima dell’introduzione della funzionalità MA nel sistema Cardano, il portafoglio di un utente contiene sia uscite con indirizzi che appartengono all’utente, sia le quantità di ada che questi indirizzi detengono. Per esempio, (users_address1, someAdaAmount)
Con il supporto MA, il portafoglio dell’utente sarà in grado di contenere più tipi di beni in una singola emissione, cioè il portafoglio può contenere un pacchetto di token. Questo significa che i portafogli possono contenere:
- Asset che rientrano in diverse policy in una singola UTxO (incluso ada)
- Asset coperti da una policy, distribuiti su più UTxO
Il portafoglio di un utente potrebbe contenere informazioni del tipo:
(users_address1, (adaPolicy, someAdaTokens)) (users_address1, (cryptoDoggie, someDoggies), (adaPolicy, moreAdaTokens)) (users_address2, (cryptoDoggie, otherDoggies), (cryptoBirds, justCockatoos))
In questo esempio, ci sono 3 policy: adaPolicy , cryptoDoggie , and cryptoBirds .
I token nativi hanno identificatori leggibili dall’uomo e altri metadati?
I nomi leggibili dall’uomo per le attività (invece delle lunghe stringhe alfanumeriche di ID della policy e dei nomi delle attività) possono essere registrati su un server di metadati. Se un utente sta usando un portafoglio integrato con un server di metadati, sarà in grado di visualizzare i nomi leggibili dall’uomo quando guarda le sue risorse.
Gli utenti saranno in grado di caricare i nomi per i loro token, insieme a qualsiasi altro metadato relativo ai token specifici, su un server di metadati. Ci potrebbe essere più di un server di metadati operativo alla volta (incluso uno gestito da Cardano), quindi gli utenti dovranno scegliere quale server(i) caricare i loro metadati, o da cui scaricare i loro metadati.
Gli utenti potrebbero anche scegliere di aggiungere nomi e altri metadati direttamente nel campo dei metadati della transazione. Questo aumenterà i costi della transazione in proporzione alla dimensione dei metadati aggiuntivi.
Quali sono i costi relativi al conio e al commercio di token nativi?
I costi relativi ai multi asset possono essere divisi in due categorie:
Commissioni: L’invio e il conio di token influisce sulle commissioni che l’autore della transazione deve pagare. Come con un ledger Ada, le commissioni sono calcolate in base alla dimensione totale della transazione. Ci potrebbero essere anche delle commissioni per il controllo delle policy di conio, ma inizialmente sono supportate solo le policy multisig, che non comportano ulteriori commissioni oltre a quelle basate sulla dimensione della transazione.
Min-Ada-Value: Ogni output creato da una transazione deve includere una quantità minima di ada, che è calcolata in base alla dimensione dell’output (cioè, il numero di diversi tipi di token in esso, e la lunghezza dei loro nomi).
Ricordiamo che gli output possono contenere una collezione eterogenea di token, inclusa ada che è una risorsa limitata nel sistema Cardano. Richiedere che una certa quantità di ada sia inclusa in ogni output sul ledger (dove questa quantità è basata sulla dimensione dell’output, in byte) protegge la dimensione del ledger di Cardano dal crescere in modo insostenibile. Per una spiegazione dettagliata del valore min-ada, vedere “Minimum Ada Value Requirement”.
Quali tipi di asset posso usare per coprire i costi associati ai token nativi?
Attualmente, solo gli ada possono essere utilizzati per effettuare pagamenti di commissioni o per soddisfare il vincolo del valore min-ada.
Come funziona la selezione delle monete per i token nativi personalizzati?
Dal punto di vista degli utenti, è simile alla selezione delle monete ada, cioè l’utente seleziona i token e le quantità che desidera spendere, e il portafoglio sceglie gli input appropriati e copre le commissioni.
È possibile inviare token a un indirizzo?
Sì, l’invio di token nativi a un indirizzo viene fatto allo stesso modo dell’invio di ada a un indirizzo, cioè inviando una transazione con uscite contenenti i gruppi di token che l’autore della transazione desidera inviare, insieme agli indirizzi a cui vengono inviati.
Che controllo ha l’utente sugli asset token personalizzati?
Gli utenti possono spendere, inviare, scambiare o ricevere tutti i tipi di token MA allo stesso modo di ada. A differenza di ada, gli utenti possono anche coniare e bruciare token nativi.
Spendere token : Gli utenti possono spendere i token nel loro portafoglio, o token in uscita bloccati da script che permettono a questo utente di spendere il risultato.
Inviare token ad altri utenti: gli utenti possono inviare i token nei loro portafogli (o qualsiasi token che possono spendere) a qualsiasi indirizzo.
Coniare token: gli utenti possono coniare token personalizzati secondo la policy associata a questo asset. La transazione di conio può mettere questi token nell’indirizzo dell’utente o di chiunque altro. Se necessario, la policy può limitare l’esatta posizione di emissione dei token.
Si noti che anche se l’utente ha definito una policy, l’utente potrebbe non essere in grado di coniare o bruciare asset sotto questa policy, a seconda delle regole della policy. Una policy di conio controlla il conio di tutti gli asset che rientrano in essa, indipendentemente dall’identità dell’utente che ha definito la policy.
Bruciare i token: anche bruciare i token è controllato dalla policy associata all’asset. Oltre ad avere il permesso di bruciare i token (sempre in conformità con la policy di conio), l’utente deve anche essere in grado di spendere i token che sta cercando di bruciare. Per esempio, se i token sono nel loro portafoglio).
Gli utenti non possono bruciare token sui quali non hanno controllo, come i token nel portafoglio di qualcun altro, anche se la policy di conio lo permette specificamente.
Esiste uno scambio distribuito (DEX) per i token nativi di Cardano?
No. Il ledger Cardano non supporta di per sé la funzionalità DEX. Tuttavia, quando la funzionalità di smart contract è disponibile, è possibile pubblicare beni non in ada per lo scambio o la vendita sul libro mastro utilizzando un smart contract.
C’è un registro degli asset per i Cardano Native Token?
No. L’implementazione della funzione Native Tokens su Cardano non richiede un registro degli asset. Tuttavia, il server dei metadati (vedi “Gli asset hanno identificatori leggibili dall’uomo e altri metadati?”) può essere utilizzato per elencare i token che un utente ha coniato, se lo desidera.
Token nativi Cardano vs ERC
Differenze tra i token nativi di Cardano rispetto ai token personalizzati ERC-721 e ERC-20 di Ethereum?
L’approccio di Cardano alla creazione di token personalizzati differisce da un’implementazione non nativa di token personalizzati, come ERC-721 o ERC-20, dove i token personalizzati sono implementati utilizzando la funzionalità smart contract per simulare il trasferimento di asset personalizzati (cioè un sistema di contabilità ledger). Il nostro approccio per creare token personalizzati non richiede smart contract, in quanto l’implementazione del ledger stesso supporta la contabilità su asset non nativi.
Un’altra differenza chiave è che il ledger multi-asset Cardano supporta sia token fungibili che non fungibili senza smart contract specializzati (a differenza di ERC-721 o ERC-20), ed è abbastanza versatile da includere una combinazione di diversi tipi di token fungibili e non fungibili in una singola emissione.
Traduzione di FAQ : Native Tokens (Cardano’s Multi-Asset Support Feature)