Tokenizzazione

La tokenizzazione è un processo in cui gli asset fisici o digitali sono rappresentati da token, che possono essere trasferiti, tracciati e memorizzati su una blockchain.

Rappresentando gli asset come token, puoi utilizzare il registro blockchain per stabilire lo stato e la proprietà di un asset e utilizzare le funzioni standard della piattaforma blockchain per trasferire la proprietà di un asset.

Blockchain App Builder include il supporto per la tokenizzazione: le classi e i metodi token vengono generati automaticamente e vengono forniti metodi token aggiuntivi in modo che gli sviluppatori possano creare una logica aziendale complessa per i token. Il progetto generato automaticamente contiene classi e funzioni del ciclo di vita dei token, metodi CRUD e metodi SDK token aggiuntivi e supporta la convalida automatica di argomenti, marshalling/unmarshalling e funzionalità di persistenza trasparente. È possibile utilizzare questi metodi controller per inizializzare i token, controllare l'accesso, impostare gli account, gestire i ruoli e gestire il ciclo di vita dei token.

Il diagramma seguente mostra l'architettura del token implementata da Blockchain App Builder, inclusa l'API del token e l'SDK del token. Diagramma dell'architettura token

API Token generato automaticamente: Blockchain App Builder genera automaticamente metodi per supportare token e cicli di vita dei token. È possibile utilizzare questi metodi per inizializzare i token, gestire ruoli e account e completare altri task del ciclo di vita dei token senza alcuna codifica aggiuntiva.
SDK token: L'SDK token include metodi che consentono di sviluppare una logica aziendale complessa per le applicazioni token.
Ottimizzazione MVCC (Multiversion Concurrency Control): L'ottimizzazione MVCC per il codice concatenato dei token può ridurre gli errori relativi alle operazioni di trasferimento, menta, masterizzazione e blocco.

Token e modello di conto/saldo

Blockchain App Builder supporta token fungibili e non fungibili.

I token fungibili hanno un valore intercambiabile. Qualsiasi quantità di token fungibili ha lo stesso valore di qualsiasi altra quantità uguale della stessa classe di token. I token non fungibili sono univoci. I token possono anche essere interi o frazionari. I token frazionari possono essere suddivisi in parti più piccole, in base a un numero specificato di posizioni decimali.

I token possono anche essere descritti da comportamenti. I comportamenti supportati per i token fungibili includono: mintable, transferable, divisible, holdable, burnable e roles (minter, burner e holder). I comportamenti supportati per i token non fungibili includono: mintable, transferable, singleton, indivisible, burnable e roles (minter e burner).

La funzione di tokenizzazione utilizza un modello di conto/saldo per rappresentare i cespiti tokenizzati come saldi in un conto. I conti sono simili ai conti bancari tipici, in cui depositi e trasferimenti e altre transizioni statali influiscono sul saldo di un conto. Il saldo di ogni conto viene tracciato a livello globale per garantire la validità degli importi delle transazioni. Vengono monitorati anche il saldo in sospeso (per i token fungibili) e la cronologia delle transazioni.

Qualsiasi utente che possiede token o completa operazioni correlate al token in qualsiasi momento deve avere un account sulla rete. Ogni account è identificato da un ID univoco (account_id). L'ID account viene creato combinando un nome utente o un ID e-mail (user_id) del proprietario dell'istanza o dell'utente che ha eseguito il login all'istanza con l'ID provider di servizi di appartenenza (org_id) dell'utente nell'organizzazione di rete corrente. Per la creazione dell'account vengono forniti metodi pronti all'uso. Poiché l'ID account include l'ID organizzazione, gli utenti possono essere supportati in più organizzazioni.

Standard token

Blockchain App Builder estende gli standard e le classificazioni del Token Taxonomy Framework, dello standard ERC-721 e dello standard ERC-1155 per definire l'anatomia e il comportamento dei token.

ERC-1155 è uno standard che supporta token sia fungibili che non fungibili (NFT). ERC-721 è uno standard per NFT. Il Token Taxonomy Framework è stato sviluppato dall'iniziativa Tassonomia token. Per ulteriori informazioni, vedere Token Taxonomy Framework.

Nella tabella seguente vengono descritti i tipi di token supportati da Blockchain App Builder:

Standard	Tipi di token supportati
Framework tassonomia token	gettoni fungibili frazionari
ERC-721	token interi non fungibili
ERC-1155	gettoni fungibili interi gettoni fungibili frazionari token interi non fungibili token non fungibili frazionari

Flusso di generazione token

Poiché Blockchain App Builder supporta la tokenizzazione estendendo la sintassi del file delle specifiche di input, si creano progetti specifici del token nello stesso modo in cui si creano altri progetti, utilizzando l'interfaccia CLI o Visual Studio Code.

Per ulteriori informazioni sulla creazione di progetti con Blockchain App Builder, vedere File di specifica di input.

Un tipico flusso di tokenizzazione segue questi passaggi di base:

Decidere il token standard da utilizzare.
Decidere i comportamenti dei token da specificare (mintable, transferable, divisible, indivisible, singleton, holdable, burnable e roles).
Definire l'asset token e le relative proprietà nel file di specifica di input.
Impalcatura del progetto codice concatenato dal file della specifica di input. Questo crea un progetto impalcato, tra cui un modello che contiene la definizione dell'asset token e le sue proprietà e un controller che contiene il comportamento e i metodi del token.
Distribuire e sottoporre a test il progetto di codice concatenato.

Dopo aver distribuito un progetto basato su token, il flusso tipico per la creazione di token e il completamento delle operazioni del ciclo di vita segue i passi riportati di seguito.

Viene distribuito un codice concatenato di token; gli utenti nell'elenco passati al metodo di inizializzazione diventano utenti Token Admin del codice concatenato.
Viene inizializzato un asset tokenizzato, che crea token_id, un identificativo univoco per quella particolare istanza del token.
È necessario creare account per ogni utente che disporrà di token o completerà operazioni correlate ai token.
Se per il token è stato specificato il funzionamento roles, è necessario assegnare i ruoli agli utenti prima di poter completare le operazioni correlate al token.
I metodi del ciclo di vita del token possono quindi essere utilizzati in base ai comportamenti specificati per l'asset token. Ad esempio, è possibile chiamare un metodo per creare token per un account.

Controllo dell'accesso

Il supporto della tokenizzazione include una funzione di controllo dell'accesso che supporta meccanismi di controllo basati su ruoli e proprietà.

Con il controllo basato sui ruoli, gli utenti possono chiamare metodi specifici con un ruolo associato, ad esempio Token Admin o Token Minter. Con il controllo basato sulla proprietà, è possibile limitare gli utenti dall'accesso agli asset di cui non sono proprietari. Con il controllo dell'accesso basato sulla proprietà, gli utenti proprietari degli asset possono utilizzare metodi specifici, ad esempio Token Owner o Account Owner. Per informazioni specifiche sul controllo dell'accesso per i metodi, vedere le singole voci relative ai metodi documentati negli argomenti riportati di seguito.

Il controllo dell'accesso basato sui ruoli supporta le figure riportate di seguito.

Amministratore token: Gli utenti Token Admin possono essere assegnati quando viene distribuito un codice concatenato di token. Le informazioni sull'utente Token Admin vengono salvate nel database di stato. Un utente Token Admin può concedere e rimuovere i privilegi Token Admin per altri utenti. Un utente Token Admin non può rimuovere i propri privilegi Token Admin. Un utente Token Admin può assegnare il ruolo Org Admin, minter, masterizzatore o notaio a qualsiasi utente.
Amministratore organizzazione: I metodi Extended Token Taxonomy Framework supportano il ruolo Org Admin. Un utente Token Admin può assegnare il ruolo Org Admin a qualsiasi utente. Gli utenti Org Admin dispongono dei privilegi di amministrazione, ma solo all'interno dell'organizzazione. Possono creare conti o visualizzare i saldi dei conti, ma solo per gli utenti dell'organizzazione. Gli utenti di Org Admin con ruolo Minter, Burner o Notaio possono assegnare tale ruolo ad altri utenti dell'organizzazione.
Minter token: Un utente a cui è assegnato il ruolo più piccolo è un utente Token Minter e può utilizzare i token.
Bruciatore token: Un utente a cui è assegnato il ruolo di burner è un utente Token Burner e può masterizzare i token.
Token notaio: Un utente a cui è assegnato il ruolo notarile è un utente Token Notary. Un Token Notary agisce come una terza parte nelle transazioni tra pagatori e beneficiari. Un Token Notary può attivare il completamento di un trasferimento di token da un pagatore a un beneficiario oppure può invece restituire i token all'account del pagatore.
Gestore dei vault: Un utente a cui è assegnato il ruolo vault è Vault Manager. Vault Manager può sbloccare un NFT bloccato. Il ruolo di vault è applicabile solo per gli standard ERC-721 e ERC-1155 estesi. L'assegnazione del ruolo vault a un utente è un prerequisito per il blocco di NFT. È possibile assegnare il ruolo vault a un solo utente per codice concatenato.
Auditor token: Solo Digital Assets Edition: i metodi Extended Token Taxonomy Framework supportano il ruolo Token Auditor. Questo ruolo è simile al ruolo Token Admin, ma è disponibile solo in lettura.
Org Auditor: Solo Digital Assets Edition: i metodi Extended Token Taxonomy Framework supportano il ruolo Org Auditor. Questo ruolo è simile al ruolo Org Admin, ma è disponibile solo in lettura.

Il controllo dell'accesso basato sulla proprietà supporta le figure riportate di seguito.

Proprietario account: Qualsiasi utente con un account è un Account Owner.
Proprietario token: Qualsiasi utente attualmente proprietario di un token non fungibile è il Token Owner di tale token.

In alcuni metodi vengono inoltre combinati il controllo dell'accesso basato sui ruoli e il controllo dell'accesso basato sulla proprietà. Ad esempio, il controllo dell'accesso basato su ruoli consente a un utente con il ruolo minore di creare token. Con il controllo dell'accesso basato sulla proprietà, un proprietario di token non fungibile può modificare le proprietà personalizzate di un token, ma non può modificare i metadati del token. Quando un utente con il ruolo minter crea un token non fungibile (NFT), diventa il proprietario del NFT. Come proprietario di tale NFT, possono modificare le proprietà personalizzate (per un token di raccolta arte, il prezzo del token è una proprietà personalizzata). Dopo che il creatore del token ha trasferito l'NFT a un altro utente, il secondo utente diventa il proprietario e l'utente che ha creato il token non è più il proprietario del token. A causa del controllo dell'accesso basato sulla proprietà, il nuovo proprietario ora può aggiornare un valore di proprietà personalizzato, ma il proprietario precedente non può più farlo. A causa del controllo dell'accesso basato sui ruoli, il proprietario precedente può comunque creare un NFT, ma il nuovo utente non può farlo.

È inoltre possibile scrivere le proprie funzioni di controllo dell'accesso o disabilitare il controllo dell'accesso. Il codice generato automaticamente che controlla l'accesso viene mostrato negli esempi riportati di seguito.

TypeScript:

await this.Ctx.<Token Standard>Auth.checkAuthorization(...)

Vai:

auth, err := t.Ctx.<Token Standard>Auth.CheckAuthorization(...)

Nota

Per rimuovere la funzione di controllo dell'accesso generata automaticamente, rimuovere la riga di codice precedente dal progetto TypeScript o Vai.

Ottimizzazione MVCC

I database Hyperledger Fabric utilizzano il controllo multivaluta (MVCC) per evitare doppie spese e incoerenze nei dati.

Quando viene aggiornato lo stesso stato, una nuova versione del record sovrascrive la vecchia versione. In caso di richieste concorrenti di aggiornamento della stessa chiave in un blocco, è possibile che venga generato un errore MVCC_READ_CONFLICT.

Per ridurre gli errori MVCC per le operazioni di trasferimento, menta, masterizzazione e blocco, è possibile abilitare l'ottimizzazione MVCC per il codice concatenato del token. Questa ottimizzazione funziona solo su Oracle Blockchain Platform. Per impostazione predefinita, l'ottimizzazione è disabilitata. Per abilitare l'ottimizzazione, completare il passo successivo applicabile.

CLI: specificare il parametro booleano -m o --enable_mvcc_optimization con il comando ochain init. Per impostazione predefinita, il parametro è impostato su false. Per abilitare l'ottimizzazione, aggiungere -m true alla riga di comando ochain init.
Codice di Visual Studio: quando si crea un codice concatenato, selezionare Abilita ottimizzazione MVCC nella finestra Crea codice concatenato.

Per utilizzare l'ottimizzazione con il codice concatenato creato nelle versioni precedenti di Blockchain App Builder, completare i passi riportati di seguito.

Dopo aver installato la versione più recente di Blockchain App Builder, eseguire l'upgrade del codice concatenato come descritto in Aggiornamento dei progetti del codice concatenato nell'interfaccia CLI e Aggiornamento dei progetti del codice concatenato in Visual Studio Code.
Modificare il file .ochain.json nella cartella radice del codice concatenato per impostare enableMvccOptimization su true.
Sincronizzare il codice concatenato, che aggiunge l'ottimizzazione e crea due nuove cartelle nella cartella radice del codice concatenato: statedb e tokens. Per ulteriori informazioni sulla sincronizzazione, vedere Sincronizza modifiche file specifica con codice origine generato e Sincronizza modifiche file specifica con codice origine generato.

Altri metodi per aggirare gli errori di MVCC_READ_CONFLICT includono la richiesta di nuovi tentativi dell'applicazione client quando viene generato questo errore o l'utilizzo di una coda per acquisire le richieste concorrenti prima che vengano inviate alla rete blockchain. Per ulteriori informazioni, vedere la semantica dei set di lettura-scrittura nella documentazione di Hyperledger Fabric.

Nota

L'ottimizzazione MVCC non funziona su reti ibride che includono sia i peer di Oracle Blockchain Platform che di Hyperledger Fabric o quando si esegue il test su una rete Hyperledger Fabric locale. Non abilitare l'ottimizzazione MVCC su reti ibride, in quanto ciò potrebbe portare a incoerenze tra peer.