4 API de ressources numériques

Oracle Blockchain Platform Enterprise Edition for Besu fournit des API de ressources numériques que vous pouvez utiliser pour travailler avec des contrats intelligents.

Les API d'actifs numériques sont des composants réutilisables basés sur Solidity pour le développement, le test et le déploiement de contrats intelligents d'actifs numériques sur Besu. Vous pouvez utiliser les API pour implémenter des applications de jeton propres à un domaine tout en conservant des approches cohérentes en matière de configuration de jeton, de contrôle des identités et des accès, de mise à niveau et de gouvernance.

Le cœur de toute application Oracle Blockchain Platform Besu est un ou plusieurs contrats intelligents qui définissent les états d'une ressource numérique et les règles métier qui régissent sa création, son transfert, son placement, son rachat et sa gestion. Etant donné que ces règles affectent directement le cycle de vie des actifs, les contrats doivent être conçus, révisés et testés avant le déploiement. Chacune des deux API prend en charge une norme de jeton différente.

Standard de jeton	Utilisation principale	Exemples de cas d'emploi
ERC-20	Immobilisations fongibles où chaque jeton est interchangeable avec tous les autres jetons.	Paiements, stablecoins, jetons de dépôt, jetons de règlement et actifs CBDC en gros.
ERC-1155	Actifs non fongibles et actifs non fongibles (NFT). Plusieurs types de jeton sont pris en charge dans le même contrat intelligent. Les jetons fractionnaires (partages) sont pris en charge.	Ressources segmentées, collections et ressources numériques uniques.

Les API fournissent des contrats de base configurables et des bibliothèques de prise en charge dont vous pouvez hériter ou composer dans vos propres contrats Solidity. Selon le modèle de jeton sélectionné, les applications peuvent intégrer des fonctionnalités telles que la frappe et la gravure, les transferts contrôlés, les blocages, les approbations, les autorisations tenant compte des identités et l'application de stratégies. Les API prennent également en charge les modèles de contrat pouvant être mis à niveau et les opérations de cycle de vie contrôlées par la gouvernance si elles sont requises par une application.

Le schéma suivant illustre les capacités des implémentations standard étendues de jetons ERC-20.

Le schéma suivant illustre les capacités des implémentations étendues de la norme ERC-1155token.

Modules de contrôle d'accès enfichables

Vous pouvez sélectionner des modules de compte et de stratégie pour aligner les opérations de jeton sur le modèle de contrôle d'accès d'une application. Plus précisément, l'API inclut les versions de contrat et de compte pour les modèles d'autorisation ERC-5982 et EIP-6617. Ces modules connectent les contrats de jeton aux passerelles d'identité et de stratégie, ce qui permet aux applications d'appliquer une autorisation tenant compte des rôles et de l'organisation sans intégrer une implémentation de contrôle d'accès unique dans chaque contrat de jeton.

Vous pouvez choisir les fonctionnalités de variante de compte et de stratégie qui conviennent à votre application, puis utiliser les interfaces de compte communes des contrats de jeton. Cette séparation permet de concentrer la logique métier des jetons sur le cycle de vie des ressources tout en permettant de configurer, d'étendre ou d'échanger des stratégies d'accès au fur et à mesure de l'évolution des exigences des applications.

Modèle de composition de contrat

La couche de tokenisation Solidity utilise un modèle de composition de contrat. Vous sélectionnez une base de jetons pouvant être mise à niveau, ajoutez les modules de comportement requis par le cycle de vie de la ressource, puis associez le jeton à un compte et un module de contrôle d'accès appropriés. Ce modèle prend en charge des fonctionnalités telles que la frappe, la gravure, les blocages et les approbations sans que chaque jeton soit nécessaire pour exposer chaque opération. Vous pouvez utiliser la composition stricte ou la composition mixte/compatibilité.

Une composition stricte est appropriée lorsque les opérations de jeton prises en charge sont connues au moment de la conception. Les développeurs héritent d'un contrat de base étroit qui ne prend en charge que des capacités spécifiques. Seules les opérations sélectionnées sont incluses dans le contrat ABI. Au cours de l'initialisation, la configuration du jeton est validée par rapport au profil de capacité sélectionné, de sorte que les comportements incompatibles ou les modes de frappe et de gravure sont rejetés.

La composition de mélange / compatibilité est appropriée lorsque la flexibilité d'exécution et un ensemble plus large et réutilisable d'opérations de jeton sont plus importants. Les développeurs héritent d'un contrat de base plus complet, avec des indicateurs de comportement d'exécution déterminant quelles stratégies facultatives sont actives. L'ABI complet reste disponible, tandis que les opérations propres au comportement appliquent la configuration activée lorsqu'elles sont appelées.

Choisissez la composition la plus étroite qui répond aux exigences de votre produit, puis combinez-la avec le module de compte de contrôle d'accès requis et la logique métier propre au produit. La composition stricte produit un ABI plus petit et plus intentionnel et empêche les opérations non supportées d'être exposées. La composition mixte/compatibilité fournit une base plus large pour les applications dont le comportement doit être configuré lors de l'exécution.

Utilisez les API comme points de départ plutôt que comme applications fixes. En général, une équipe sélectionne la base ERC-20 ou ERC-1155 qui correspond au modèle d'immobilisation requis, configure le comportement et les contrôles d'accès, puis implémente une logique métier spécifique pour prendre en charge le cycle de vie des immobilisations. Cela permet une base de contrat commune tout en permettant à chaque application de refléter ses propres participants, règles d'autorisation et processus opérationnels.

Les API sont destinées aux développeurs Solidity qui travaillent directement avec les sources contractuelles ERC-20 et ERC-1155. Vous pouvez développer et tester des applications à l'aide de Hardhat, puis les déployer dans un environnement Oracle Blockchain Platform à l'aide de l'approche de déploiement appropriée pour l'application.

Flux de gouvernance pour le déploiement et la mise à niveau de contrats

La gouvernance contrôle le moment où un contrat déployé devient utilisable et les mises à niveau d'implémentation UUPS autorisées. Les projets composés déploient et connectent les proxies de compte et de jeton, puis les associent à un contrat de gouvernance et à un UUID de gouvernance. Les proxies sont volontairement inactifs jusqu'à ce que le flux de gouvernance configuré les active, comme indiqué dans le cycle de vie suivant :

1. Déployez des proxies UUPS de compte et de jeton.
2. Définir le contexte de compte/jeton et le contexte de gouvernance. Les mandataires restent inactifs.
3. Soumettre l'intention de déploiement avec des composants proxy, d'implémentation et de hachage de code.
4. • No-Op : Accepté immédiatement, composants activés.
   • Régi : collecte les approbations de stratégie, puis les composants sont activés après approbation.

Modèles de gouvernance

Les deux modèles de gouvernance pris en charge sont No-Op et Governed.

No-Op n'enlève pas le cycle de vie de gouvernance de l'application. Il implémente la même interface de gouvernance, enregistre l'intention et approuve automatiquement les vérifications de déploiement et de mise à niveau. N'utilisez pas le modèle No-Op comme mécanisme d'approbation de production.

Le modèle gouverné ne permet pas au déployeur, au générateur d'applications Blockchain ou à un script CLI de contourner les approbateurs. Les approbateurs, le seuil, la date limite et le processus d'approbation requis sont définis par la configuration de gouvernance et de stratégie déployée.

Le tableau suivant récapitule le comportement des deux modèles de gouvernance.

Modèle de gouvernance	Objectif	Comportement de déploiement	Comportement de mise à niveau
Opération nulle (no-op)	Développement local, démonstrations et autres situations où l'approbation de la gouvernance est volontairement contournée.	La fonction proposeDeployIntent accepte l'intention et active immédiatement ses composants.	L'intention de mise à niveau est acceptée sans approbation de stratégie ; l'opérateur exécute toujours l'étape d'exécution upgradeToAndCall préparée.
Gouverné	Environnements nécessitant une révision et une approbation basées sur des stratégies.	L'intention reste en attente jusqu'à ce que la stratégie configurée reçoive les approbations requises avant la date limite ; seuls les composants sont alors activés.	L'implémentation proposée et son hachage de code doivent recevoir l'autorisation requise pour que l'étape d'exécution puisse consommer l'implémentation et mettre à niveau le proxy.

Lorsque vous créez un projet avec Blockchain App Builder, les blocs de construction de gouvernance suivants sont déjà fournis :

• Interface IDAContractGovernance et implémentations NoOpGovernance et GovernedGovernance.
• Prise en charge du contexte de gouvernance et de l'activation sur les bases de contrats de jeton et de compte générées, notamment les méthodes setGovernanceContext, getGovernanceContext et activateFromGovernance.
• Autorisation de mise à niveau UUPS via la méthode UpgradeAuthorizationLib de l'API, qui appelle le contrat de gouvernance configuré au cours du processus _authorizeUpgrade.
• Scripts de déploiement et de mise à niveau générés qui définissent le contexte de gouvernance, préparent les données d'intention, enregistrent les manifestes et soumettent les demandes d'intention.

Comme ces blocs de construction sont déjà fournis, un projet composé standard ne vous oblige pas à écrire des hooks de gouvernance Solidity supplémentaires pour ses contrats de jeton et de compte générés. Vous devez toujours choisir et déployer ou obtenir le contrat de gouvernance approprié, configurer l'UUID et la stratégie, fournir leurs adresses au workflow de déploiement/mise à niveau et soumettre le processus d'approbation pour les environnements gouvernés. Pour un réseau Oracle Blockchain Platform Besu, un contrat de gouvernance est déployé dans le cadre du provisionnement d'instance.