Supporto della generazione di token mediante Blockchain App Builder

Tokenizzazione

La tokenizzazione è un processo in cui gli asset fisici o digitali sono rappresentati da token, che possono essere trasferiti, tracciati e archiviati 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 di token vengono generati automaticamente e vengono forniti metodi di token aggiuntivi in modo che gli sviluppatori possano creare complesse business logic per i token. Il progetto generato automaticamente contiene classi e funzioni del ciclo di vita dei token, metodi CRUD e metodi SDK di token aggiuntivi e supporta la convalida automatica di argomenti, marshalling/unmarshalling e funzionalità di persistenza trasparente. È possibile utilizzare questi metodi del controller per inizializzare i token, controllare l'accesso, impostare gli account, gestire i ruoli e gestire il ciclo di vita dei token.

Il diagramma riportato di seguito mostra l'architettura dei token implementata da Blockchain App Builder, inclusi l'API token e l'SDK token. Diagramma dell'architettura dei token

API token generata automaticamente: Blockchain App Builder genera automaticamente metodi per supportare i token e i 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: Token SDK include metodi che consentono di sviluppare business logic complessa per le applicazioni token.
Ottimizzazione di Multiversion Concurrency Control (MVCC): L'ottimizzazione MVCC per il codice concatenato di token può ridurre gli errori per le operazioni di trasferimento, zecca, masterizzazione e blocco.

Token e modello 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 dai 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 generazione token utilizza un modello di conto/saldo per rappresentare i cespiti con generazione token come saldi in un conto. I conti sono simili ai conti bancari tipici, in cui depositi e trasferimenti e altre transizioni statali influenzano il saldo di un conto. Il saldo di ogni conto viene tracciato a livello globale per garantire la validità degli importi delle transazioni. Vengono inoltre registrati il saldo bloccato (per i token fungibili) e la cronologia delle transazioni.

Qualsiasi utente che possiede token o completa operazioni relative ai 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 di posta elettronica (user_id) del proprietario dell'istanza o dell'utente che ha eseguito il login all'istanza con l'ID del 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, è possibile supportare gli utenti in più organizzazioni.

Standard token

Blockchain App Builder estende gli standard e le classificazioni del Token Taxonomy Framework, lo standard ERC-721 e lo standard ERC-1155 per definire l'anatomia e il comportamento dei token. ERC-1155 è uno standard che supporta sia i token fungibili che non fungibili (NFT). ERC-721 è uno standard per NFT. Il framework tassonomia token è stato sviluppato dall'iniziativa tassonomia token. Per ulteriori informazioni, vedere Token Taxonomy Framework.

Nella tabella riportata di seguito vengono descritti i tipi di token supportati da Blockchain App Builder.

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

Flusso di generazione token

Poiché Blockchain App Builder supporta la tokenizzazione estendendo la sintassi del file di specifica di input, è possibile creare progetti specifici del token nello stesso modo in cui si creano altri progetti, utilizzando l'interfaccia CLI o Visual Studio Code. Per ulteriori informazioni, vedere File di specifica di input.

Un tipico flusso di tokenizzazione segue questi passaggi di base:

Decidere lo standard del token 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 delle specifiche di input. Questo crea un progetto impalcato, incluso un modello che contiene la definizione dell'asset token e le relative proprietà e un controller che contiene il comportamento e i metodi del token.
Distribuire e testare il progetto con codice concatenato.

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

Viene distribuito un codice concatenato di token e gli utenti nella lista 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 di token.
Gli account devono essere creati per ogni utente che possiede token o completa operazioni relative ai token.
Se per il token è specificato il comportamento roles, i ruoli devono essere aggiunti agli utenti prima di poter completare le operazioni relative al token.
È quindi possibile utilizzare i metodi del ciclo di vita dei token, in base ai comportamenti specificati per l'asset token. Ad esempio, è possibile chiamare un metodo per coniare i token per un account.

Controllo dell'accesso

Il supporto della tokenizzazione include una funzione di controllo dell'accesso che supporta sia i meccanismi di controllo basati sul ruolo che quelli basati sulla proprietà. Con il controllo basato sui ruoli, gli utenti possono chiamare metodi specifici con un ruolo associato, ad esempio Token Admin o Token Minter. Grazie al controllo basato sulla proprietà, puoi impedire agli utenti di accedere ad asset di cui non sono proprietari. Con il controllo dell'accesso basato sulla proprietà, gli utenti proprietari degli asset possono chiamare metodi specifici, ad esempio Token Owner o Account Owner. Per informazioni specifiche sul controllo dell'accesso per i metodi, vedere le singole voci per i metodi documentati nei seguenti argomenti:

Il controllo dell'accesso basato su ruoli supporta le persone indicate di seguito.

Amministratore token: Gli utenti Token Admin possono essere assegnati quando viene distribuito un codice concatenato di token. Le informazioni 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, burner 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 saldi conto, ma solo per gli utenti della propria organizzazione. Org Admin Gli utenti che dispongono di un ruolo di minter, burner o notaio possono assegnare tale ruolo ad altri utenti della propria organizzazione.
Minter token: Un utente a cui è assegnato il ruolo minter è un Token Minter e può coniare i token.
Bruger token: Un utente a cui è assegnato il ruolo di bruciatore è un Token Burner e può masterizzare i token.
Notaio del token: Un utente a cui è assegnato il ruolo notarile è un Token Notary. Un Token Notary funge da 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 al conto del pagatore.
Gestione del vault: Un utente a cui è assegnato il ruolo vault è Vault Manager. Vault Manager può sbloccare un NFT bloccato. Il ruolo 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. Il ruolo vault può essere assegnato a un solo utente per codice concatenato.

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

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

In alcuni metodi vengono combinati anche il controllo dell'accesso basato su ruoli e il controllo dell'accesso basato su proprietà. Ad esempio, il controllo dell'accesso basato sui ruoli consente a un utente con il ruolo minter di creare i 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 di minter crea un token non fungibile (NFT), diventa il proprietario dell'NFT. In qualità di 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 trasferisce 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ò ancora coniare un NFT, ma il nuovo utente non può.

È 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 della concorrenza multi-versione (MVCC) per evitare doppie spese e incongruenze dei dati. Quando viene aggiornato lo stesso stato, una nuova versione del record sovrascrive la versione precedente. Se sono presenti richieste concorrenti per aggiornare la stessa chiave in un blocco, potrebbe essere generato un errore MVCC_READ_CONFLICT.

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

CLI: specificare il parametro booleano -m o --enable_mvcc_optimization con il comando ochain init. L'impostazione predefinita del parametro è false. Per abilitare l'ottimizzazione, aggiungere -m true alla riga di comando ochain init.
Visual Studio Code: 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, attenersi alla procedura riportata di seguito.

Dopo aver installato la versione più recente di Blockchain App Builder, aggiornare il codice concatenato come descritto in Aggiornamento dei progetti Chaincode nell'interfaccia CLI e Aggiornamento dei progetti Chaincode 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 Sincronizzazione delle modifiche ai file di specifica con il codice sorgente generato e Sincronizzazione delle modifiche ai file di specifica con il codice sorgente generato.

Altri metodi per ovviare agli errori di MVCC_READ_CONFLICT, tra cui la richiesta di nuovi tentativi da parte 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 in lettura-scrittura nella documentazione di Hyperledger Fabric.

Nota

L'ottimizzazione MVCC non funziona su reti ibride che includono sia Oracle Blockchain Platform che Hyperledger Fabric peer, né per i test su una rete Hyperledger Fabric locale. Non abilitare l'ottimizzazione MVCC sulle reti ibride, in quanto ciò potrebbe causare incongruenze tra peer.