Segmentation en sèmes

La segmentation en jetons 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 blockchain.

En représentant les actifs en tant que jetons, vous pouvez utiliser le registre blockchain pour établir l'état et la propriété d'un actif, et utiliser les fonctions standard de la plate-forme blockchain pour transférer la propriété d'un actif.

Blockchain App Builder inclut la prise en charge de la tokenisation : les classes et les méthodes de token sont générées automatiquement, et des méthodes de token supplémentaires sont fournies afin que les développeurs puissent créer une logique métier complexe pour les tokens. 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 SDK de jeton supplémentaires, et prend en charge la validation automatique des arguments, la sérialisation/désérialisation et la 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 implémentée par Blockchain App Builder, y compris l'API de jeton et le 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 de jeton sans codage supplémentaire.
SDK pour jeton: Le kit SDK de jeton comprend des méthodes qui vous aident à développer une logique métier complexe pour les applications de jeton.
Optimisation du contrôle de simultanéité multiversion (MVCC): L'optimisation MVCC pour le code chaîne de jetons peut réduire les erreurs liées aux opérations de transfert, de mint, 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 jeton. 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 tokenisation utilise un modèle de compte/solde pour représenter les actifs tokenisés en tant que soldes dans un compte. Les comptes sont similaires aux comptes bancaires classiques, 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 s'assurer que les montants de transaction sont valides. 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 de compte est créé en combinant un nom d'utilisateur ou un ID de courriel (user_id) du propriétaire de l'instance ou de l'utilisateur qui est connecté à l'instance avec l'ID de fournisseur de services d'adhésion (org_id) de l'utilisateur dans l'organisation réseau actuelle. Des méthodes prêtes à l'emploi sont fournies pour la création de compte. Etant donné que l'ID de compte inclut l'ID d'organisation, les utilisateurs peuvent être pris en charge dans plusieurs organisations.

Normes relatives aux jetons

Blockchain App Builder étend les normes et les classifications de Token Taxonomy Framework, la norme ERC-721 et 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. La structure de taxonomie de jeton a été développée par l'initiative de taxonomie de jeton. Pour plus d'informations, reportez-vous à Structure de taxonomie de jeton.

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

Standard	Types de jeton pris en charge
Structure de taxonomie de jeton	jetons fongibles fractionnaires
ERC-721	tokens non fongibles entiers
ERC-1155	jetons fongibles entiers jetons fongibles fractionnaires tokens non fongibles entiers jetons non fongibles fractionnaires

Flux de tokenisation

Etant donné que Blockchain App Builder prend en charge la segmentation en jetons en étendant la syntaxe du fichier de spécification d'entrée, vous créez des projets spécifiques aux jetons de la même manière que vous créez d'autres projets, soit à l'aide de la CLI, soit dans Visual Studio Code.

Pour plus d'informations sur la création de projets avec Blockchain App Builder, reportez-vous à la rubrique Fichier de spécification d'entrée.

Un flux de tokenisation standard suit les étapes de base suivantes :

Choisissez la norme de jeton à utiliser.
Déterminez les comportements de jeton à indiquer (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.
Échafaudage du projet de code 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 ressource de jeton et ses propriétés et un contrôleur qui contient le comportement et les méthodes du jeton.
Déployez et testez le projet de code chaîne.

Une fois que vous avez déployé un projet basé sur des jetons, le flux standard de création de jetons et d'exécution des opérations de cycle de vie suit les étapes suivantes :

Un code chaîne de jeton est déployé. Les utilisateurs de la liste transmise à la méthode d'initialisation deviennent des utilisateurs Token Admin du code chaîne.
Une ressource segmentée en jetons est initialisée, ce qui crée l'identificateur unique token_id pour cette instance de jeton particulière.
Des comptes doivent être créés pour chaque utilisateur qui possédera des jetons ou effectuera des opérations liées aux jetons.
Si le comportement roles est indiqué pour le jeton, des rôles doivent être affectés aux utilisateurs pour qu'ils puissent effectuer des opérations liées au jeton.
Les méthodes de cycle de vie de jeton peuvent ensuite être utilisées, en fonction des comportements indiqués pour la ressource de jeton. Par exemple, vous pouvez appeler une méthode pour extraire des jetons pour un compte.

Contrôle d'accès

La prise en charge de la segmentation en jetons inclut une fonctionnalité 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. Avec le contrôle basé sur la propriété, vous pouvez empêcher les utilisateurs d'accéder aux ressources qu'ils ne possèdent pas. Avec le contrôle d'accès basé sur la propriété, des méthodes spécifiques peuvent être appelées par les utilisateurs propriétaires des ressources, tels que Token Owner ou Account Owner. Pour plus d'informations sur le contrôle d'accès des méthodes, reportez-vous aux entrées individuelles des méthodes documentées dans les rubriques suivantes :

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

Administrateur de jeton: Les utilisateurs Token Admin peuvent être affectés lorsqu'un code chaîne de jeton est déployé. Les informations utilisateur Token Admin sont enregistrées dans la base de données d'état. Un utilisateur Token Admin peut accorder et enlever des privilèges Token Admin à d'autres utilisateurs. Un utilisateur Token Admin ne peut pas enlever ses propres privilèges Token Admin. Un utilisateur Token Admin peut affecter le rôle Org Admin, mineur, brûleur ou notaire à n'importe quel utilisateur.
Administration des organisations: Les méthodes étendues de structure 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 consulter les soldes des comptes, mais uniquement pour les utilisateurs de leur organisation. Les utilisateurs Org Admin disposant d'un rôle de mineur, de brûleur ou de notaire peuvent affecter ce rôle à d'autres utilisateurs de leur organisation.
Minter de jeton: Un utilisateur auquel le rôle minter est affecté est un Token Minter et peut extraire 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. Une valeur Token Notary agit en tant que tiers dans les transactions entre les payeurs et les bénéficiaires. Une valeur Token Notary peut déclencher le transfert d'un jeton d'un payeur à un bénéficiaire ou plutôt renvoyer les jetons au compte du payeur.
Gestionnaire de pannes: Un utilisateur auquel le rôle de coffre est affecté est Vault Manager. Vault Manager peut déverrouiller un NFT verrouillé. Le rôle de coffre ne s'applique qu'aux normes étendues ERC-721 et ERC-1155. L'affectation du rôle de coffre à un utilisateur est un prérequis pour le verrouillage des NFT. Un seul utilisateur par code chaîne peut être affecté au rôle de coffre.
Auditeur de jeton: Edition de ressources numériques uniquement : les méthodes étendues de structure de taxonomie de jeton prennent en charge le rôle Token Auditor. Ce rôle est similaire au rôle Token Admin, mais avec accès en lecture seule.
Auditeur d'organisation: Edition de ressources numériques uniquement : les méthodes étendues de structure de taxonomie de jeton prennent en charge le rôle Org Auditor. Ce rôle est similaire au rôle Org Admin, mais avec accès en lecture seule.

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

Propriétaire de compte: Tout utilisateur disposant d'un compte est un Account Owner.
Propriétaire 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 basé sur les rôles et le contrôle d'accès basé sur la 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 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 de 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 désormais mettre à jour une valeur de propriété personnalisée, mais le propriétaire précédent ne le peut plus. En raison du contrôle d'accès basé sur les rôles, le propriétaire précédent peut toujours effectuer une opération NFT, mais le nouvel utilisateur ne le 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 illustré dans les exemples suivants.

TypeScript:

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

Exécuter

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

Remarques :

Pour enlever la fonction de contrôle d'accès générée automatiquement, enlevez 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 de simultanéité multi-version (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 simultanées de mise à jour de la même clé dans un bloc, une erreur MVCC_READ_CONFLICT peut être générée.

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

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

Pour utiliser l'optimisation avec le code chaîne créé dans les versions précédentes de Blockchain App Builder, procédez comme suit :

Une fois la dernière version de Blockchain App Builder installée, mettez à niveau le code chaîne comme décrit dans Mise à niveau des projets de code chaîne dans l'interface de ligne de commande et Mise à niveau des projets de code chaîne dans Visual Studio Code.
Modifiez le fichier .ochain.json dans le dossier racine du code chaîne afin de définir enableMvccOptimization sur true.
Synchronisez le code chaîne, qui ajoute l'optimisation et crée deux nouveaux dossiers dans le dossier racine du code chaîne : statedb et tokens. Pour plus d'informations sur la synchronisation, reportez-vous aux rubriques Synchronisation des modifications de fichier de spécification avec le code source généré et Synchronisation des modifications de fichier de spécification avec le code source généré.

D'autres méthodes pour contourner les erreurs MVCC_READ_CONFLICT incluent la demande de nouvelle tentative de l'application client lorsque cette erreur est générée ou l'utilisation d'une file d'attente pour capturer les demandes simultanées avant qu'elles ne soient envoyées au réseau de chaîne de blocs. Pour plus d'informations, reportez-vous à la section Read-Write set semantics dans la documentation Hyperledger Fabric.

Remarques :

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