4 API de activos digitales

Oracle Blockchain Platform Enterprise Edition para Besu proporciona API de activos digitales que puede utilizar para trabajar con contratos inteligentes.

Las API de activos digitales son componentes reutilizables y basados en Solidity para desarrollar, probar e implementar contratos inteligentes de activos digitales en Besu. Puede utilizar las API para implantar aplicaciones de token específicas del dominio, al tiempo que conserva enfoques coherentes para la configuración de token, los controles de identidad y acceso, la capacidad de actualización y la gobernanza.

El núcleo de cualquier aplicación de Oracle Blockchain Platform Besu son uno o más contratos inteligentes que definen los estados de un activo digital y las reglas de negocio que rigen cómo se crea, transfiere, retiene, canjea y gestiona. Debido a que estas reglas afectan directamente al ciclo de vida de los activos, los contratos se deben diseñar, revisar y probar antes del despliegue. Cada una de las dos API soporta un estándar de token diferente.

Estándar de token	Uso principal	Ejemplos de casos de uso
ERC-20	Activos fungibles donde cada token es intercambiable con cada otro token.	Pagos, monedas estables, tokens de depósito, tokens de liquidación y activos mayoristas de CBDC.
ERC-1155	Activos fungibles y activos no fungibles (NFT). En el mismo contrato inteligente se admiten varios tipos de token. Se admiten tokens fraccionarios (recursos compartidos).	Activos convertidos en tokens, recopilaciones y activos digitales únicos.

Las API proporcionan contratos base configurables y bibliotecas de soporte que puede heredar o componer en sus propios contratos de Solidity. Según el modelo de token seleccionado, las aplicaciones pueden incorporar capacidades como acuñación y grabación, transferencias controladas, retenciones, aprobaciones, permisos conscientes de la identidad y aplicación de políticas. Las API también soportan patrones de contrato actualizables y operaciones de ciclo de vida controladas por gobernanza si una aplicación las necesita.

El siguiente diagrama ilustra las capacidades de las implementaciones estándar de token ERC-20 ampliadas.

El siguiente diagrama ilustra las capacidades de las implementaciones estándar ampliadas de ERC-1155token.

Módulos de control de acceso conectables

Puede seleccionar módulos de cuentas y políticas para alinear las operaciones de token con el modelo de control de acceso de una aplicación. En concreto, la API incluye versiones de contratos y cuentas para los modelos de permisos ERC-5982 y EIP-6617. Estos módulos conectan los contratos de token a gateways de identidad y política, lo que permite a las aplicaciones aplicar autorizaciones conscientes de los roles y de la organización sin incorporar una única implantación de control de acceso en cada contrato de token.

Puede elegir la variante de cuenta y las capacidades de política que se adapten a su aplicación y, a continuación, utilizar las interfaces de cuenta comunes de los contratos de token. Esta separación mantiene la lógica de negocio de tokens centrada en el ciclo de vida de los activos, al tiempo que permite configurar, ampliar o intercambiar políticas de acceso a medida que evolucionan los requisitos de las aplicaciones.

Modelo de composición de contrato

La capa de tokenización Solidity utiliza un modelo de composición por contrato. Puede seleccionar una base de tokens actualizable, agregar los módulos de comportamiento necesarios para el ciclo de vida del activo y, a continuación, emparejar el token con una cuenta y un módulo de control de acceso adecuados. Este modelo admite capacidades como acuñar, grabar, retener y aprobar sin necesidad de que cada token exponga cada operación. Puede utilizar composición estricta o composición mixin/compatibilidad.

La composición estricta es adecuada cuando las operaciones de token soportadas se conocen en el momento del diseño. Los desarrolladores heredan de un contrato base estrecho que solo admite capacidades específicas. En la autofactura del contrato solo se incluyen las operaciones seleccionadas. Durante la inicialización, la configuración del token se valida con respecto al perfil de capacidad seleccionado, de modo que se rechazan los comportamientos incompatibles o los modos de acuñación y grabación.

La composición mixina/compatibilidad es apropiada cuando la flexibilidad de tiempo de ejecución y un conjunto más amplio y reutilizable de operaciones de token son más importantes. Los desarrolladores heredan de un contrato base más completo, con indicadores de comportamiento de tiempo de ejecución que determinan qué políticas opcionales están activas. La ABI completa permanece disponible, mientras que las operaciones específicas del comportamiento aplican la configuración activada cuando se las llama.

Elija la composición más estrecha que cumpla con los requisitos de su producto y, a continuación, combínela con el módulo de cuenta de control de acceso necesario y la lógica de negocio específica del producto. La composición estricta produce un ABI más pequeño e intencional y evita que se expongan operaciones no admitidas. La composición mixin/compatibilidad proporciona una base más amplia para las aplicaciones cuyo comportamiento se debe configurar en tiempo de ejecución.

Utilice las API como puntos de partida en lugar de como aplicaciones fijas. Normalmente, un equipo selecciona la base ERC-20 o ERC-1155 que coincide con el modelo de activos necesario, configura el comportamiento y los controles de acceso y, a continuación, implanta una lógica de negocio específica para soportar el ciclo de vida de los activos. Esto permite una base de contratos común y, al mismo tiempo, permite que cada aplicación refleje sus propios participantes, reglas de autorización y procesos operativos.

Las API son para desarrolladores de Solidity que trabajan directamente con las fuentes de contrato ERC-20 y ERC-1155. Puede desarrollar y probar aplicaciones mediante Hardhat y, a continuación, desplegarlas en un entorno de Oracle Blockchain Platform mediante el enfoque de despliegue adecuado para la aplicación.

Flujo de gobernanza para desplegar y actualizar contratos

Controla cuándo se puede utilizar un contrato desplegado y qué actualizaciones de implementación del UUPS se autorizan. Los proyectos compuestos despliegan y conectan los proxies de cuenta y token y, a continuación, asocian ambos a un UUID de gobernanza y un contrato de gobernanza. Los proxies están deliberadamente inactivos hasta que el flujo de gobernanza configurado los activa, como se muestra en el siguiente ciclo de vida:

1. Desplegar proxies del UUPS de cuentas y tokens.
2. Definir contexto de cuenta/token y contexto de gobernanza. Los representantes permanecen inactivos.
3. Enviar la intención de despliegue con componentes de proxy, implantación y hash de código.
4. • Sin opción: se acepta inmediatamente, los componentes se activan.
   • Gobernado: recopila aprobaciones de políticas y, a continuación, los componentes se activan después de la aprobación.

Modelos de gobernanza

Los dos modelos de gobernanza soportados son No-Op y Governed.

No-Op no elimina el ciclo de vida de gobernanza de la aplicación. Implementa la misma interfaz de gobernanza, registra la intención y aprueba las comprobaciones de despliegue y cambio de versión automáticamente. No utilice el modelo sin operador como mecanismo de aprobación de producción.

El modelo controlado no permite que el desplegador, el creador de aplicaciones de blockchain ni un script de CLI omitan a los aprobadores. Los aprobadores, el umbral, la fecha límite y el proceso de aprobación necesarios se definen mediante la configuración de políticas y gobernanza desplegada.

En la siguiente tabla, se resume el comportamiento de los dos modelos de gobernanza.

Modelo de gobernanza	Finalidad	Comportamiento de despliegue	Comportamiento de actualización
No Operativo	Desarrollo local, demostraciones y otras situaciones en las que la aprobación de la gobernanza se omite intencionalmente.	La función proposeDeployIntent acepta la intención y activa sus componentes inmediatamente.	La intención de actualización se acepta sin la aprobación de la política; el operador aún ejecuta el paso de ejecución upgradeToAndCall preparado.
Gobernados	Entornos que requieren revisión y aprobación basadas en políticas.	La intención permanece pendiente hasta que la política configurada recibe las aprobaciones necesarias antes de la fecha límite; solo entonces se activan los componentes.	La implementación propuesta y su hash de código deben recibir la autorización necesaria antes de que el paso de ejecución pueda consumir la implementación y actualizar el proxy.

Al crear un proyecto con Blockchain App Builder, ya se proporcionan los siguientes componentes básicos de gobernanza:

• La interfaz IDAContractGovernance y las implantaciones NoOpGovernance y GovernedGovernance.
• Contexto de gobernanza y soporte de activación en bases de contratos de cuentas y tokens generadas, incluidos los métodos setGovernanceContext, getGovernanceContext y activateFromGovernance.
• Autorización de actualización del UUPS mediante el método UpgradeAuthorizationLib de la API, que llama al contrato de gobernanza configurado durante el proceso _authorizeUpgrade.
• Scripts de despliegue y actualización generados que definen el contexto de gobernanza, preparan datos de intención, registran manifiestos y envían solicitudes de intención.

Debido a que estos bloques de construcción ya se suministran, un proyecto compuesto estándar no requiere que escriba enlaces de gobernanza de Solidity adicionales para sus contratos de token y cuenta generados. Aún debe elegir y desplegar u obtener el contrato de gobernanza adecuado, configurar el UUID y la política, proporcionar sus direcciones al flujo de trabajo de despliegue/actualización y someterse al proceso de aprobación para entornos controlados. Para una red de Oracle Blockchain Platform Besu, se despliega un contrato de gobernanza como parte del aprovisionamiento de instancias.