Soporte de tokenización mediante Blockchain App Builder

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 los activos como tokens, puede utilizar el libro mayor de blockchain para establecer el estado y la propiedad de un activo, y utilizar 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 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 clases y funciones 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, canalización/anulación de canalización y 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 generado 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 realizar otras tareas del ciclo de vida del token sin necesidad de codificación adicional.
SDK de token: El SDK de token incluye métodos que le ayudan a desarrollar una lógica de negocio compleja para aplicaciones de token.
Optimización del control de simultaneidad 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 admite 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 enteros o fraccionarios. Los tokens fraccionales se pueden subdividir en partes más pequeñas, en función de un número especificado de posiciones decimales.

Los tokens también se pueden describir mediante comportamientos. Los comportamientos soportados para los tokens fungibles incluyen: mintable, transferable, divisible, holdable, burnable y roles (minter, burner y holder). Los comportamientos soportados para los 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. Se realiza un seguimiento global del saldo de cada cuenta para garantizar que los importes de las transacciones 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 conectado a la instancia con el ID de proveedor de servicios de miembros (org_id) del usuario en la organización de red actual. Se proporcionan métodos listos para usar para la creación de cuentas. Puesto 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 extiende los estándares y clasificaciones de 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 NFTs. 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 soporta Blockchain App Builder:

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

Flujo de tokenización

Puesto que Blockchain App Builder soporta la tokenización mediante la ampliación de la sintaxis del archivo de especificación de entrada, se crean proyectos específicos de token de la misma forma que se crean otros proyectos, ya sea mediante la CLI o en Visual Studio Code. Para obtener más información, 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 desea 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.
Anclar el proyecto de código de cadenas del archivo de especificación de entrada. Esto crea un proyecto en andamio, incluido un modelo que contiene la definición del 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 y 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, se deben agregar roles a los usuarios antes de que puedan completar 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 especificados 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 el acceso de los usuarios a los activos de los que no son propietarios. 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 los métodos, consulte las entradas individuales de los métodos documentados en los siguientes temas:

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

Administrador de tokens: Los usuarios de Token Admin se pueden asignar cuando se despliega un código de cadena de token. La información del 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, burner o notary a cualquier usuario.
Administrador de organización: Los métodos del marco de taxonomía de token ampliado 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, burner o notary pueden asignar ese rol a otros usuarios de su organización.
Token Minter: Un usuario que tiene asignado el rol minter es Token Minter y puede acuñar tokens.
Quemador de tokens: Un usuario que tiene asignado el rol de quemador es Token Burner y puede grabar tokens.
Notario de token: Un usuario que tiene asignado el rol de notario es Token Notary. Un Token Notary actúa como un tercero en las transacciones entre pagadores y beneficiarios. Un Token Notary puede activar la finalización de una transferencia de token de un pagador a un beneficiario o, en su lugar, puede devolver los tokens a la cuenta del pagador.
Gestor de almacenes: Un usuario que tiene asignado el rol de almacén es Vault Manager. Vault Manager puede desbloquear una NFT bloqueada. El rol de almacén solo se aplica a 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.

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

Propietario de Cuenta: Cualquier usuario que tenga una cuenta es Account Owner.
Propietario de token: Cualquier usuario que actualmente posee 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 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 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 de minter crea un token no fungible (NFT), se convierte en el propietario del 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 propiedad, el nuevo propietario ahora puede actualizar un valor de propiedad personalizada, pero el propietario anterior ya no puede. Debido al control de acceso basado en roles, el propietario anterior aún puede importar una 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 del 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 la incoherencia de datos y los gastos dobles. Cuando se actualiza el mismo estado, una nueva versión del registro sobrescribe la versión antigua. 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 para 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 correspondiente.

CLI: especifique el parámetro booleano -m o --enable_mvcc_optimization con el comando ochain init. Por defecto, el parámetro está definido 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, realice 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 cadenas para definir enableMvccOptimization en true.
Sincronice el código de cadenas, que agrega la optimización y crea dos carpetas nuevas en la carpeta raíz del código de cadenas: 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 errores de MVCC_READ_CONFLICT, como hacer que la aplicación cliente vuelva a intentar solicitudes cuando se genere este error o utilizar 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 Semántica de juego de lectura y escritura 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 y Hyperledger Fabric, ni para pruebas en una red Hyperledger Fabric local. No active la optimización de MVCC en redes híbridas, ya que esto puede generar inconsistencias entre pares.