Conversión en tokens

La tokenización es un proceso en el que los activos físicos o digitales están representados por tokens, que se pueden transferir, rastrear y almacenar en una cadena de bloques.

Al representar activos como tokens, puede usar el libro mayor de blockchain para establecer el estado y la propiedad de un activo, y usar las funciones estándar de la plataforma de blockchain para transferir la propiedad de un activo.

Blockchain App Builder incluye soporte de tokenización: las clases y los métodos de token se generan automáticamente y se proporcionan métodos de token adicionales para que los desarrolladores puedan crear una lógica de negocio compleja para los tokens. El proyecto generado automáticamente contiene funciones y clases de ciclo de vida de token, métodos CRUD y métodos SDK de token adicionales, y soporta la validación automática de argumentos, la canalización/anulación de canalización y la capacidad de persistencia transparente. Puede utilizar estos métodos de controlador para inicializar tokens, controlar el acceso, configurar cuentas, gestionar roles y gestionar el ciclo de vida de los tokens.

En el siguiente diagrama se muestra la arquitectura de token implementada por Blockchain App Builder, incluida la API de token y el SDK de token. Diagrama de arquitectura de token

API de token generada automáticamente: Blockchain App Builder genera automáticamente métodos para admitir tokens y ciclos de vida de tokens. Puede utilizar estos métodos para inicializar tokens, gestionar roles y cuentas, y completar otras tareas del ciclo de vida del token sin ninguna codificación adicional.
SDK de token: El SDK de token incluye métodos que ayudan a desarrollar una lógica de negocio compleja para las aplicaciones de token.
Optimización del control de simultaneidad de multiversión (MVCC): La optimización de MVCC para el código de cadena de token puede reducir los errores de las operaciones de transferencia, menta, grabación y retención.

Tokens y modelo de cuenta/saldo

Blockchain App Builder es compatible con tokens fungibles y no fungibles.

Los tokens fungibles tienen un valor intercambiable. Cualquier cantidad de tokens fungibles tiene el mismo valor que cualquier otra cantidad igual de la misma clase de token. Los tokens no fungibles son únicos. Los tokens también pueden ser completos o fraccionarios. Los tokens fraccionarios se pueden subdividir en partes más pequeñas, en función de un número especificado de decimales.

Los tokens también pueden ser descritos por comportamientos. Los comportamientos admitidos para tokens fungibles incluyen: mintable, transferable, divisible, holdable, burnable y roles (minter, burner y holder). Los comportamientos admitidos para tokens no fungibles incluyen: mintable, transferable, singleton, indivisible, burnable y roles (minter y burner).

La función de tokenización utiliza un modelo de cuenta/saldo para representar activos tokenizados como saldos en una cuenta. Las cuentas son similares a las cuentas bancarias típicas, donde los depósitos y transferencias y otras transiciones estatales afectan el saldo de una cuenta. El seguimiento del saldo de cada cuenta se realiza de forma global para garantizar que los importes de transacción sean válidos. También se realiza un seguimiento del saldo retenido (para tokens fungibles) y del historial de transacciones.

Cualquier usuario que posea tokens o complete operaciones relacionadas con tokens en cualquier momento debe tener una cuenta en la red. Cada cuenta se identifica mediante un ID único (account_id). El ID de cuenta se crea combinando un nombre de usuario o un ID de correo electrónico (user_id) del propietario de la instancia o del usuario que está conectado a la instancia con el ID de proveedor de servicios de afiliación (org_id) del usuario de la organización de red actual. Se proporcionan métodos listos para usar para la creación de cuentas. Dado que el ID de cuenta incluye el ID de organización, los usuarios se pueden admitir en varias organizaciones.

Estándares de token

Blockchain App Builder amplía los estándares y clasificaciones del Token Taxonomy Framework, el estándar ERC-721 y el estándar ERC-1155 para definir la anatomía y el comportamiento de los tokens.

ERC-1155 es un estándar que admite tokens fungibles y no fungibles (NFT). ERC-721 es un estándar para las NFT. El Marco de Taxonomía de Token fue desarrollado por la Iniciativa de Taxonomía de Token. Para obtener más información, consulte Marco de taxonomía de token.

En la siguiente tabla se describen los tipos de token que admite Blockchain App Builder:

Estándar	Tipos de token soportados
Marco de taxonomía de token	fichas fungibles fraccionadas
ERC-721	tokens no fungibles completos
ERC-1155	fichas fungibles completas fichas fungibles fraccionadas tokens no fungibles completos tokens fraccionarios no fungibles

Flujo de tokenización

Debido a que Blockchain App Builder admite la tokenización mediante la ampliación de la sintaxis del archivo de especificación de entrada, puede crear proyectos específicos de token de la misma manera que crea otros proyectos, ya sea mediante la CLI o en Visual Studio Code.

Para obtener más información sobre la creación de proyectos con Blockchain App Builder, consulte Archivo de especificación de entrada.

Un flujo de tokenización típico sigue estos pasos básicos:

Decida qué estándar de token utilizar.
Decida qué comportamientos de token debe especificar (mintable, transferable, divisible, indivisible, singleton, holdable, burnable y roles).
Defina el activo de token y sus propiedades en el archivo de especificación de entrada.
Anidar el proyecto de código de cadenas desde el archivo de especificación de entrada. Esto crea un proyecto de andamiaje, incluido un modelo que contiene la definición de activo de token y sus propiedades, y un controlador que contiene el comportamiento y los métodos del token.
Despliegue y pruebe el proyecto de código de cadenas.

Después de desplegar un proyecto basado en token, el flujo típico para crear tokens y completar operaciones de ciclo de vida sigue estos pasos:

Se despliega un código de cadena de token; los usuarios de la lista transferidos al método de inicialización se convierten en usuarios Token Admin del código de cadena.
Se inicializa un activo con token, que crea token_id, un identificador único para esa instancia concreta de token.
Se deben crear cuentas para cada usuario que posea tokens o complete operaciones relacionadas con tokens.
Si se especifica el comportamiento roles para el token, los roles se deben asignar a los usuarios antes de que puedan completar las operaciones relacionadas con el token.
A continuación, se pueden utilizar métodos de ciclo de vida de token, en función de los comportamientos que se hayan especificado para el activo de token. Por ejemplo, puede llamar a un método para acuñar tokens para una cuenta.

Control de Acceso

El soporte de tokenización incluye una función de control de acceso que admite mecanismos de control basados en roles y en propiedad.

Con el control basado en roles, los usuarios pueden llamar a métodos específicos con un rol asociado, como Token Admin o Token Minter. Con el control basado en la propiedad, puede restringir que los usuarios accedan a activos que no les pertenecen. Con el control de acceso basado en la propiedad, los usuarios propietarios de los activos pueden llamar a métodos específicos, como Token Owner o Account Owner. Para obtener información específica sobre el control de acceso para métodos, consulte las entradas individuales para los métodos documentados en los siguientes temas:

El control de acceso basado en roles admite las siguientes personas:

Administración de token: Los usuarios Token Admin se pueden asignar cuando se despliega un código de cadena de token. La información de usuario Token Admin se guarda en la base de datos de estado. Un usuario Token Admin puede otorgar y eliminar privilegios Token Admin para otros usuarios. Un usuario Token Admin no puede eliminar sus propios privilegios Token Admin. Un usuario Token Admin puede asignar el rol Org Admin, minter, quemador o notario a cualquier usuario.
Administración de organización: Los métodos extendidos de Token Taxonomy Framework soportan el rol Org Admin. Un usuario Token Admin puede asignar el rol Org Admin a cualquier usuario. Los usuarios de Org Admin tienen privilegios administrativos, pero solo dentro de su organización. Pueden crear cuentas o ver saldos de cuenta, pero solo para los usuarios de su organización. Los usuarios de Org Admin que tienen un rol de minter, quemador o notario pueden asignar ese rol a otros usuarios de su organización.
Minter de token: Un usuario al que se le asigna el rol minter es Token Minter y puede acuñar tokens.
Grabador de tokens: Un usuario al que se le asigna el rol de quemador es Token Burner y puede grabar tokens.
Notario de token: Un usuario al que se le asigna el rol de notario es Token Notary. Un Token Notary actúa como tercero en las transacciones entre pagadores y receptores de pago. Un Token Notary puede disparar la finalización de una transferencia de token de un pagador a un receptor de pago o, en su lugar, puede devolver los tokens a la cuenta del pagador.
Gestor de almacenes: Un usuario al que se le asigna el rol de almacén es Vault Manager. Vault Manager puede desbloquear una NFT bloqueada. El rol de almacén solo es aplicable para los estándares ERC-721 y ERC-1155 ampliados. La asignación del rol de almacén a un usuario es un requisito previo para bloquear NFT. Solo se puede asignar el rol de almacén a un usuario por código de cadena.
Auditor de token: Solo Digital Assets Edition: los métodos extendidos de Token Taxonomy Framework soportan el rol Token Auditor. Este rol es similar al rol Token Admin, pero solo tiene acceso de lectura.
Auditor de organización: Solo Digital Assets Edition: los métodos extendidos de Token Taxonomy Framework soportan el rol Org Auditor. Este rol es similar al rol Org Admin, pero solo tiene acceso de lectura.

El control de acceso basado en propiedad admite las siguientes personas:

Propietario de Cuenta: Cualquier usuario que tenga una cuenta es Account Owner.
Propietario del token: Cualquier usuario que actualmente posea un token no fungible es el Token Owner de ese token.

El control de acceso basado en roles y el control de acceso basado en la propiedad también se combinan en algunos métodos. Por ejemplo, el control de acceso basado en roles permite a un usuario con el rol minter crear tokens. Con el control de acceso basado en la propiedad, un propietario de token no fungible puede modificar las propiedades personalizadas de un token, pero no puede modificar los metadatos del token. Cuando un usuario con el rol minter crea un token no fungible (NFT), se convierte en el propietario de la NFT. Como propietario de ese NFT, pueden modificar las propiedades personalizadas (para un token de colección de arte, el precio del token es una propiedad personalizada). Después de que el creador del token transfiera el NFT a otro usuario, el segundo usuario se convierte en el propietario y el usuario que creó el token ya no es el propietario del token. Debido al control de acceso basado en la propiedad, el nuevo propietario ahora puede actualizar un valor de propiedad personalizado, pero el propietario anterior ya no puede. Debido al control de acceso basado en roles, el propietario anterior aún puede acuñar un NFT, pero el nuevo usuario no puede.

También puede escribir sus propias funciones de control de acceso o desactivar el control de acceso. El código generado automáticamente que controla el acceso se muestra en los siguientes ejemplos.

TypeScript:

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

Ir:

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

Note:

Para eliminar la función de control de acceso generada automáticamente, elimine la línea de código anterior de su proyecto TypeScript o Go.

Optimización de MVCC

Las bases de datos de Hyperledger Fabric utilizan el control de simultaneidad de varias versiones (MVCC) para evitar el gasto doble y la inconsistencia de datos.

Cuando se actualiza el mismo estado, una nueva versión del registro sobrescribe la versión anterior. Si hay solicitudes simultáneas para actualizar la misma clave en un bloque, se puede generar un error MVCC_READ_CONFLICT.

Para reducir los errores de MVCC en las operaciones de transferencia, menta, grabación y retención, puede activar la optimización de MVCC para el código de cadena de token. Esta optimización solo funciona en Oracle Blockchain Platform. Por defecto, la optimización está desactivada. Para activar la optimización, complete el siguiente paso aplicable.

CLI: especifique el parámetro booleano -m o --enable_mvcc_optimization con el comando ochain init. Por defecto, el parámetro se define en false. Para activar la optimización, agregue -m true a la línea de comandos ochain init.
Visual Studio Code: al crear un código de cadena, seleccione Activar optimización de MVCC en la ventana Crear código de cadena.

Para utilizar la optimización con código de cadena creado en versiones anteriores de Blockchain App Builder, complete los siguientes pasos:

Después de instalar la última versión de Blockchain App Builder, actualice el código de cadena como se describe en Actualización de proyectos de código de cadena en la CLI y Actualización de proyectos de código de cadena en Visual Studio Code.
Edite el archivo .ochain.json en la carpeta raíz del código de cadena para definir enableMvccOptimization en true.
Sincronice el código de cadena, que agrega la optimización y crea dos nuevas carpetas en la carpeta raíz del código de cadena: statedb y tokens. Para obtener más información sobre la sincronización, consulte Sincronizar cambios de archivo de especificación con código de origen generado y Sincronizar cambios de archivo de especificación con código de origen generado.

Otros métodos para solucionar los errores de MVCC_READ_CONFLICT incluyen que la aplicación cliente vuelva a intentar solicitudes cuando se genere este error o que utilice una cola para capturar solicitudes simultáneas antes de que se envíen a la red de cadenas de bloques. Para obtener más información, consulte Lectura-escritura de semántica de conjuntos en la documentación de Hyperledger Fabric.

Note:

La optimización de MVCC no funciona en redes híbridas que incluyen pares de Oracle Blockchain Platform e Hyperledger Fabric, o cuando se realizan pruebas en una red local de Hyperledger Fabric. No active la optimización de MVCC en redes híbridas, ya que esto podría conducir a inconsistencias entre pares.