Prise en charge de la segmentation en unités à l'aide du générateur d'applications de chaîne de blocs

Segmentation en unités

La segmentation en unités est un processus où les actifs physiques ou numériques sont représentés par des jetons, qui peuvent être transférés, suivis et stockés sur une chaîne de blocs. En représentant les immobilisations sous forme de jetons, vous pouvez utiliser le grand livre de la chaîne de blocs pour établir l'état et la propriété d'une immobilisation, et utiliser les fonctions de plate-forme de chaîne de blocs standard pour transférer la propriété d'une immobilisation.

Le générateur d'applications de chaîne de blocs prend en charge la segmentation en unités : les classes et méthodes de jeton sont générées automatiquement et des méthodes de jeton supplémentaires sont fournies afin que les développeurs puissent créer une logique applicative complexe pour les jetons. Le projet généré automatiquement contient des classes et des fonctions de cycle de vie de jeton, des méthodes CRUD et des méthodes supplémentaires de trousse SDK de jeton, et prend en charge la validation automatique des arguments, la conversion de paramètres/déconversion des paramètres et la capacité de persistance transparente. Vous pouvez utiliser ces méthodes de contrôleur pour initialiser des jetons, contrôler l'accès, configurer des comptes, gérer des rôles et gérer le cycle de vie des jetons.

Le diagramme suivant présente l'architecture de jeton mise en oeuvre par Blockchain App Builder, y compris l'API de jeton et la trousse SDK de jeton. Diagramme d'architecture de jeton

API de jeton générée automatiquement: Blockchain App Builder génère automatiquement des méthodes pour prendre en charge les jetons et les cycles de vie des jetons. Vous pouvez utiliser ces méthodes pour initialiser des jetons, gérer des rôles et des comptes et effectuer d'autres tâches de cycle de vie des jetons sans codage supplémentaire.
Trousse SDK de jeton: La trousse SDK de jeton inclut des méthodes qui vous aident à développer une logique applicative complexe pour les applications de jeton.
Optimisation du contrôle d'accès simultané à plusieurs versions (MVCC): L'optimisation MVCC pour le code de chaîne de jeton peut réduire les erreurs pour les opérations de transfert, de menthe, de gravure et de blocage.

Jetons et modèle de compte/solde

Blockchain App Builder prend en charge les jetons fongibles et non fongibles. Les jetons fongibles ont une valeur interchangeable. Toute quantité de jetons fongibles a la même valeur que toute autre quantité égale de la même classe de jetons. Les jetons non fongibles sont uniques. Les jetons peuvent également être entiers ou fractionnaires. Les jetons fractionnaires peuvent être subdivisés en parties plus petites, en fonction d'un nombre spécifié de décimales.

Les jetons peuvent également être décrits par des comportements. Les comportements pris en charge pour les jetons fongibles sont les suivants : mintable, transferable, divisible, holdable, burnable et roles (minter, burner et holder). Les comportements pris en charge pour les jetons non fongibles sont les suivants : mintable, transferable, singleton, indivisible, burnable et roles (minter et burner).

La fonction de segmentation en unités utilise un modèle de compte/solde pour représenter les immobilisations segmentées en unités en tant que soldes dans un compte. Les comptes sont similaires aux comptes bancaires typiques, où les dépôts et les transferts et autres transitions d'état affectent le solde d'un compte. Le solde de chaque compte fait l'objet d'un suivi global afin de garantir la validité des montants de transaction. Le solde bloqué (pour les jetons fongibles) et l'historique des transactions sont également suivis.

Tout utilisateur qui possède des jetons ou effectue des opérations liées aux jetons à tout moment doit avoir un compte sur le réseau. Chaque compte est identifié par un ID unique (account_id). L'ID compte est créé en combinant un nom d'utilisateur ou un ID courriel (user_id) du responsable de l'instance ou de l'utilisateur connecté à l'instance avec l'ID fournisseur de services d'adhésion (org_id) de l'utilisateur dans l'organisation réseau courante. Des méthodes prêtes à l'emploi sont fournies pour la création de compte. Comme l'ID compte inclut l'ID organisation, les utilisateurs peuvent être pris en charge dans plusieurs organisations.

Normes de jeton

Blockchain App Builder étend les normes et les classifications du Token Taxonomy Framework, de la norme ERC-721 et de la norme ERC-1155 pour définir l'anatomie et le comportement des jetons. ERC-1155 est une norme qui prend en charge les jetons fongibles et non fongibles (NFT). ERC-721 est une norme pour les NFT. Le cadre de taxonomie de jetons a été développé par l'initiative de taxonomie de jetons. Pour plus d'informations, voir Cadre de taxonomie de jetons.

Le tableau suivant décrit les types de jeton pris en charge par Blockchain App Builder :

Standard	Types de jeton pris en charge
Cadre de taxonomie de jetons	Jetons fongibles fractionnaires
MODÈLE:ERC-721	jetons non fongibles entiers
ERC-1155	jetons fongibles entiers Jetons fongibles fractionnaires jetons non fongibles entiers Jetons fractionnaires non fongibles

Flux de segmentation en unités

Comme Blockchain App Builder prend en charge la segmentation en unités en étendant la syntaxe du fichier de spécification d'entrée, vous créez des projets propres à un jeton de la même manière que vous créez d'autres projets, à l'aide de l'interface de ligne de commande ou dans Visual Studio Code. Pour plus d'informations, voir Fichier de spécification d'entrée.

Un flux de segmentation en unités typique suit les étapes de base suivantes :

Déterminez la norme de jeton à utiliser.
Déterminez les comportements de jeton à spécifier (mintable, transferable, divisible, indivisible, singleton, holdable, burnable et roles).
Définissez la ressource de jeton et ses propriétés dans le fichier de spécification d'entrée.
Passer au projet de code de chaîne à partir du fichier de spécification d'entrée. Cela crée un projet échafaudé, y compris un modèle qui contient la définition de la ressource de jeton et ses propriétés et un contrôleur qui contient le comportement et les méthodes du jeton.
Déployer et tester le projet de code de chaîne.

Après le déploiement d'un projet basé sur un jeton, le flux type pour la création de jetons et la fin des opérations de cycle de vie suit les étapes suivantes :

Un code de chaîne de jeton est déployé et les utilisateurs de la liste transmis à la méthode d'initialisation deviennent des utilisateurs Token Admin du code de chaîne.
Une ressource segmentée en unités est initialisée, ce qui crée token_id, un identificateur unique pour cette instance particulière de jeton.
Des comptes doivent être créés pour chaque utilisateur possédant des jetons ou effectuant des opérations liées aux jetons.
Si le comportement roles est spécifié pour le jeton, des rôles doivent être ajoutés aux utilisateurs avant de pouvoir terminer les opérations liées au jeton.
Les méthodes de cycle de vie des jetons peuvent ensuite être utilisées, en fonction des comportements spécifiés pour la ressource de jeton. Par exemple, vous pouvez appeler une méthode pour créer des jetons pour un compte.

Contrôle de l'accès

La prise en charge de la segmentation en unités comprend une fonction de contrôle d'accès qui prend en charge les mécanismes de contrôle basés sur les rôles et sur la propriété. Avec le contrôle basé sur les rôles, les utilisateurs peuvent appeler des méthodes spécifiques avec un rôle associé tel que Token Admin ou Token Minter. Grâce au contrôle basé sur la propriété, vous pouvez empêcher les utilisateurs d'accéder aux ressources dont ils ne sont pas propriétaires. Avec le contrôle d'accès basé sur la propriété, des méthodes spécifiques peuvent être appelées par les utilisateurs qui possèdent les ressources, telles que Token Owner ou Account Owner. Pour des informations spécifiques sur le contrôle d'accès pour les méthodes, voir les entrées individuelles pour les méthodes documentées dans les rubriques suivantes :

Le contrôle d'accès par rôle prend en charge les personas suivants :

Administrateur de jetons: Les utilisateurs Token Admin peuvent être affectés lorsqu'un code de chaîne de jeton est déployé. Les informations sur l'utilisateur Token Admin sont enregistrées dans la base de données d'état. Un utilisateur Token Admin peut accorder et supprimer des privilèges Token Admin pour d'autres utilisateurs. Un utilisateur Token Admin ne peut pas supprimer ses propres privilèges Token Admin. Un utilisateur Token Admin peut affecter le rôle Org Admin, de mineur, de brûleur ou de notaire à n'importe quel utilisateur.
Administrateur de l'organisation: Les méthodes étendues du cadre de taxonomie de jeton prennent en charge le rôle Org Admin. Un utilisateur Token Admin peut affecter le rôle Org Admin à n'importe quel utilisateur. Les utilisateurs Org Admin disposent de privilèges d'administration, mais uniquement au sein de leur organisation. Ils peuvent créer des comptes ou voir les soldes de comptes, mais uniquement pour les utilisateurs de leur organisation. Les utilisateurs Org Admin qui ont un rôle de mineur, de brûleur ou de notaire peuvent affecter ce rôle à d'autres utilisateurs de leur organisation.
Token Minter: Un utilisateur auquel le rôle de mineur est affecté est Token Minter et peut créer des jetons.
Brûleur de jeton: Un utilisateur auquel le rôle de brûleur est affecté est Token Burner et peut graver des jetons.
Notaire de jeton: Un utilisateur auquel le rôle de notaire est affecté est Token Notary. Un Token Notary agit en tant que tierce partie dans les transactions entre les payeurs et les bénéficiaires. Un Token Notary peut soit déclencher l'achèvement d'un transfert de jeton d'un payeur à un bénéficiaire, soit retourner les jetons au compte du payeur.
Gestionnaire de chambre forte: Un utilisateur auquel le rôle de chambre forte est affecté est Vault Manager. Vault Manager peut déverrouiller un fichier NFT verrouillé. Le rôle de coffre-fort s'applique uniquement aux normes étendues ERC-721 et ERC-1155. L'affectation du rôle de coffre-fort à un utilisateur est une condition préalable au verrouillage des fichiers NFT. Un seul utilisateur par code de chaîne peut être affecté au rôle de chambre forte.

Le contrôle d'accès basé sur la propriété prend en charge les personas suivants :

Responsable de compte: Tout utilisateur disposant d'un compte est un utilisateur Account Owner.
Responsable du jeton: Tout utilisateur qui possède actuellement un jeton non fongible est le Token Owner de ce jeton.

Le contrôle d'accès par rôle et le contrôle d'accès par propriété sont également combinés dans certaines méthodes. Par exemple, le contrôle d'accès basé sur les rôles permet à un utilisateur doté du rôle de mineur de créer des jetons. Avec le contrôle d'accès basé sur la propriété, un propriétaire de jeton non fongible peut modifier les propriétés personnalisées d'un jeton, mais ne peut pas modifier les métadonnées du jeton. Lorsqu'un utilisateur doté du rôle de mineur crée un jeton non fongible (NFT), il devient propriétaire du NFT. En tant que propriétaire de cette NFT, ils peuvent modifier les propriétés personnalisées (pour un jeton de collection d'art, le prix du jeton est une propriété personnalisée). Une fois que le créateur du jeton a transféré le NFT à un autre utilisateur, le deuxième utilisateur devient le propriétaire et l'utilisateur qui a créé le jeton n'est plus le propriétaire du jeton. En raison du contrôle d'accès basé sur la propriété, le nouveau propriétaire peut maintenant mettre à jour une valeur de propriété personnalisée, mais le propriétaire précédent ne peut plus le faire. En raison du contrôle d'accès basé sur les rôles, le propriétaire précédent peut toujours frapper un NFT, mais le nouvel utilisateur ne peut pas.

Vous pouvez également écrire vos propres fonctions de contrôle d'accès ou désactiver le contrôle d'accès. Le code généré automatiquement qui contrôle l'accès est présenté dans les exemples suivants.

TypeScript :

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

Go :

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

Note :

Pour supprimer la fonction de contrôle d'accès générée automatiquement, supprimez la ligne de code précédente de votre projet TypeScript ou Go.

Optimisation MVCC

Les bases de données Hyperledger Fabric utilisent le contrôle d'accès simultané à plusieurs versions (MVCC) pour éviter les doubles dépenses et les incohérences de données. Lorsque le même état est mis à jour, une nouvelle version de l'enregistrement remplace l'ancienne version. S'il existe des demandes concurrentes pour mettre à jour la même clé dans un bloc, une erreur MVCC_READ_CONFLICT peut être générée.

Pour réduire les erreurs MVCC pour les opérations de transfert, de menthe, de gravure et de blocage, vous pouvez activer l'optimisation MVCC pour le code de chaîne de jeton. Cette optimisation ne fonctionne que sur Oracle Blockchain Platform. Par défaut, l'optimisation est désactivée. Pour activer l'optimisation, effectuez l'étape suivante applicable.

Interface de ligne de commande : Spécifiez le paramètre booléen -m ou --enable_mvcc_optimization avec la commande ochain init. Par défaut, le paramètre est réglé à false. Pour activer l'optimisation, ajoutez -m true à la ligne de commande ochain init.
Code Visual Studio : Lorsque vous créez un code de chaîne, sélectionnez Activer l'optimisation MVCC dans la fenêtre Créer un code de chaîne.

Pour utiliser l'optimisation avec le code de chaîne créé dans les versions précédentes du générateur d'applications de chaîne de blocs, procédez comme suit :

Après avoir installé la dernière version du générateur d'applications de chaîne de blocs, mettez à niveau le code de chaîne comme décrit sous Mise à niveau des projets de code de chaîne dans l'interface de ligne de commande et Mise à niveau des projets de code de chaîne dans Visual Studio Code.
Modifiez le fichier .ochain.json dans le dossier racine du code de chaîne pour régler enableMvccOptimization à true.
Synchronisez le code de chaîne, qui ajoute l'optimisation et crée deux nouveaux dossiers dans le dossier racine du code de chaîne : statedb et tokens. Pour plus d'informations sur la synchronisation, voir Synchroniser les modifications de fichier de spécification avec le code source généré et Synchroniser les modifications de fichier de spécification avec le code source généré.

Autres méthodes pour contourner les erreurs MVCC_READ_CONFLICT, notamment les demandes de nouvelle tentative de l'application client lorsque cette erreur est générée ou l'utilisation d'une file d'attente pour saisir les demandes concurrentes avant leur envoi au réseau de chaîne de blocs. Pour plus d'informations, voir Sémantique des jeux de lecture-écriture dans la documentation sur Hyperledger Fabric.

Note :

L'optimisation MVCC ne fonctionne pas sur les réseaux hybrides qui incluent à la fois des pairs Oracle Blockchain Platform et Hyperledger Fabric ou pour les tests sur un réseau Hyperledger Fabric local. N'activez pas l'optimisation MVCC sur les réseaux hybrides, car cela pourrait entraîner des incohérences entre pairs.