Traduzione italiana di “Native tokens on Cardano; core principles and points of difference” scritto da Polina Vinogradova nel blog IOG
Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT 
Token nativi su Cardano; principi fondamentali e punti di differenza
Nel post di ieri abbiamo esaminato lo scopo e il valore dei gettoni su Cardano. Qui, scaviamo più a fondo nei quattro principi che guidano il nostro approccio, e nei vantaggi chiave
Su Ethereum, i token personalizzati (definiti dall’utente) sono implementati utilizzando contratti intelligenti per simulare il trasferimento di beni personalizzati. Il nostro approccio con Cardano non richiede contratti intelligenti, perché il ledger stesso supporta la contabilizzazione dei beni non nativi.
Un’altra differenza è che il ledger multi-asset di Cardano supporta sia token fungibili che unici, non fungibili, senza contratti specializzati (simili a quelli richiesti dai token ERC-20 e ERC-721). Può memorizzare un mix di token sia fungibili che non fungibili in un’unica uscita.
Il framework dei token nativi di Cardano si basa su quattro principi:
- leggerezza
- accessibilità economica
- sicurezza
- processo unificato
Leggerezza
La struttura nativa del token framework si basa su una struttura multi-asset ledger costruita intorno a pacchetti di token (valori), Un pacchetto di token può contenere un mix eterogeneo di ada e altri token. Queste strutture contenenti token sono memorizzate in output sul ledger al posto di ada, come in precedenza. Ogni tipo di token è identificato dal suo asset ID, che include un riferimento hash alla sua politica di conio. La politica di conio in sé è controllata solo durante il conio o la masterizzazione e non è memorizzata sul ledger, il che rende questo approccio piuttosto leggero.
Il rapporto di fungibilità è anche catturato dall’asset ID in modo leggero: i gettoni con lo stesso asset ID sono fungibili tra loro, ma non fungibili con quelli con un asset ID diverso. I gettoni unici hanno una quantità esattamente pari a 1 associata al loro asset ID.
L’asset ID identifica ogni tipo di gettone all’interno di un unico pacchetto di gettoni e su tutto il ledger. Identifica anche il posto del token nella struttura interna a due livelli della mappa del pacchetto di token. Questa struttura interna dei dati permette di rappresentare i token fungibili e non fungibili in modo uniforme. Dà anche una grande flessibilità ai tipi di casi d’uso degli asset che possono essere tokenizzati nel sistema. È semplice rappresentare, ad esempio, le multiproprietà di un singolo bene, o una selezione di opere d’arte uniche che rientrano in un’unica politica di conio controllata dall’artista.
La semplicità intrinseca dei gettoni nativi è ulteriormente evidenziata quando si esamina il funzionamento del trasferimento di beni tra due contratti nell’ERC-20 di Ethereum. In questa situazione, è necessario un codice contrattuale intelligente, che aggiunge complessità, e con esso spazio per gli errori e i costi. La struttura dei pacchetti di token offre un approccio piuttosto leggero al trasferimento di asset, perché diversi tipi di token possono essere trattati in un’unica transazione, con maggiore velocità.
Convenienza
In un ambiente ERC-20, il trasferimento di un numero qualsiasi di token tra due peer richiede l’esecuzione di un contratto intelligente, che comporta una commissione di esecuzione (gas). Al contrario, nell’ecosistema multiasset nativo di Cardano, il trasferimento di beni (token, ada, valute personalizzate, ecc.) non richiede un contratto intelligente e non comporta alcuna commissione di esecuzione, il che significa una maggiore accessibilità economica.
Sicurezza
I gettoni nativi hanno un design più leggero e meno costoso rispetto agli standard ERC-20 ed ERC-721 di Ethereum. Ma queste due caratteristiche non significherebbero nulla senza un robusto strato di sicurezza che garantisca l’integrità del sistema.
Nei token nativi, l’integrità del sistema è costruita intorno alla proprietà del ledger di conservazione del valore (cioè che la somma di tutti gli ingressi è uguale alla somma delle uscite). Tutta la logica di trasferimento dei token nativi è codificata nel ledger, in contrapposizione ai contratti intelligenti definiti dall’utente. Ciò garantisce un comportamento prevedibile e uniforme del sistema, e non richiede agli utenti di comprendere i contratti smart, che spesso possono essere un punto di vulnerabilità.
Mentre la correttezza contabile è garantita dal ledger, il conio e la masterizzazione dei gettoni è regolata dalle loro politiche di conio definite dall’utente. Una politica di conio è permanentemente associata ai gettoni sotto di essa, e non c’è modo di cambiare questa politica. Ciò garantisce che la politica scelta dall’emittente non può mai essere modificata per consentire il conio o la masterizzazione di questo tipo di gettoni non autorizzati dalla politica originale. Ogni volta che una transazione di conio viene aggiunta al ledger, la politica per ogni tipo di gettone che viene coniato viene controllata e deve essere soddisfatta. Ogni gettone in circolazione, ad eccezione dell’ada (in quanto Cardano vieta il conio di ulteriori ada), ha necessariamente una politica di conio ed è garantito che sia stato coniato secondo tale politica.
Pertanto l’unico codice personalizzato richiesto per manipolare i gettoni in Cardano è la politica stessa. Legare l’hash della policy all’identificativo del bene significa che non c’è bisogno di un registro globale dei beni, quindi creare degli asset è facile ed economico. Il sistema rimane semplice, leggero e facile da usare.
Processo unificato
Quando i gettoni nativi saranno implementati come parte di Goguen, il ledger gestirà tutti i token allo stesso modo. E coniare un token potrà essere fatto in un solo modo, per ridurre l’ambiguità e i possibili errori o bug. Questa semplificazione nell’uso di un processo unificato porterà a uno sviluppo più rapido e a una migliore esperienza di sviluppo nel suo complesso.
Ambiente di pre-produzione in arrivo
La capacità del token nativo sarà distribuita sulla rete principale di Cardano a seguito di un aggiornamento del protocollo nel primo trimestre del 2021 (conosciuto internamente con il nome di lavoro ‘Mary’), aprendo un nuovo mondo di casi d’uso e di opportunità. Per i nuovi sviluppatori a bordo in anticipo rispetto a questa data, stiamo ora finalizzando il dispiegamento di un ambiente di pre-produzione per i token nativi. Restate quindi vicini ai nostri canali Social per le ultimissime novità sull’implementazione.
Se sei uno sviluppatore e vuoi essere coinvolto fin da subito, stiamo creando un’area dedicata sul sito degli sviluppatori Cardano, insieme alla documentazione e alle risorse di supporto. Nel corso del tempo aggiungeremo a tutto questo; iscrivetevi al nostro sondaggio per sviluppatori su questa pagina per esprimere il vostro interesse ed essere avvisati non appena tutto sarà disponibile.