Guide de mise en œuvre des smart contracts pour les émetteurs de stablecoin à Hong Kong

Première partie Infrastructure et stratégie de conformité

1. Choix du registre distribué sous-jacent

Guide de mise en œuvre

• Prioriser les blockchains publiques matures : il est conseillé de privilégier des blockchains publiques matures et sécurisées telles qu'Ethereum, Arbitrum, etc. Ces réseaux, grâce à leur résilience éprouvée, leur vaste réseau de validateurs et leur surveillance publique continue, possèdent un avantage naturel. Le coût élevé des attaques peut répondre directement aux préoccupations réglementaires concernant la résistance aux attaques de 51 % et la garantie de la finalité des transactions.

• Évaluation rigoureuse des alternatives : Si l'on envisage d'adopter une blockchain de consortium ou d'autres types de registres distribués, il est nécessaire de réaliser une analyse comparative rigoureuse et quantifiable pour prouver que ses normes de sécurité ne sont pas inférieures, voire supérieures, à celles des blockchains publiques mainstream.

• Document d'évaluation des risques : le rapport d'évaluation doit couvrir de manière exhaustive la capacité à résister aux attaques courantes, le type d'algorithme de consensus, ainsi que les risques associés aux défauts de code, aux vulnérabilités, aux exploitations et à d'autres menaces, et analyser en détail comment ces risques peuvent avoir un impact potentiel sur l'émission, le rachat et les opérations quotidiennes du stablecoin. Ce document est un document clé pour prouver la prudence du choix technologique auprès des autorités de régulation.

2. Standards de jetons principaux et extension des fonctions de régulation

Guide de mise en œuvre

• Standard de base : utilisation de l'ERC-20 comme standard de base pour garantir l'homogénéité des jetons et leur interopérabilité au sein d'un écosystème plus large.

• Extensions de fonctionnalités : il est nécessaire d'intégrer les modules fonctionnels suivants pour satisfaire aux exigences réglementaires :

  • Pausable : utilisé pour réaliser une suspension et une reprise globales de toutes les activités de jeton, c'est un outil essentiel pour faire face à des événements de sécurité majeurs.

  • Mintable : utilisé pour permettre aux émetteurs agréés de frapper de nouveaux jetons via un processus contrôlé, tout en s'assurant que l'émission de jetons correspond strictement aux actifs de réserve en monnaie fiduciaire.

  • Brûlable : fournit la possibilité de détruire des jetons. Dans la mise en œuvre spécifique, cette fonctionnalité sera strictement contrôlée par des permissions, plutôt que de permettre à n'importe quel utilisateur de détruire à sa guise.

  • Gelable : utilisé pour suspendre la fonction de transfert de jetons d'un compte spécifique ( en cas de transactions suspectes ).

  • Liste blanche : utilisée pour mettre en œuvre des mesures de sécurité supplémentaires, n'autorisant que les adresses ayant fait l'objet d'une due diligence et d'une approbation à participer aux opérations clés ( telles que la réception de nouveaux jetons émis ).

  • Liste noire : utilisée pour mettre en œuvre une interdiction de transaction sur les adresses impliquées dans des activités illégales ( telles que le blanchiment d'argent et la fraude ), interdisant l'envoi/réception de jetons. La gestion de la liste noire doit être liée au système AML/CFT, surveillant en temps réel les transactions suspectes.

  • AccessControl : C'est la base d'un système de gestion des permissions basé sur des rôles et à granularité fine. Toutes les fonctions d'administration doivent passer par ce module pour le contrôle des permissions, afin de satisfaire aux exigences de séparation des responsabilités.

3. Modèles de conformité principaux : choix de la liste noire et de la liste blanche

Guide de mise en œuvre

• Mode liste noire ( plan recommandé par défaut ) :

  • Avantages : offre une plus grande utilité, capable d'interopérer sans couture avec l'écosystème de finance décentralisée (DeFi), offrant aux utilisateurs un seuil d'utilisation plus bas et une expérience plus fluide.

  • Inconvénients : La conformité dépend fortement d'une capacité d'analyse de surveillance hors chaîne robuste et en temps réel, afin de détecter et de bloquer rapidement les adresses illégales.

  • Méthode de mise en œuvre : dans la fonction de transfert des smart contracts, ajouter une vérification logique pour s'assurer que les adresses de l'expéditeur (from) et du destinataire (to) ne sont pas enregistrées sur la liste noire.

• Mode liste blanche

  • Avantages : offre le plus haut niveau de contrôle AML/CFT, permettant une prévention en amont plutôt qu'une remédiation en aval.

  • Inconvénients : cela limite considérablement la universalité et le taux d'adoption des stablecoins, engendrant d'énormes coûts opérationnels pour la gestion des listes blanches, ce qui pourrait rendre difficile leur acceptation en tant que moyen d'échange largement utilisé.

  • Mode de réalisation : dans la fonction de transfert des smart contracts, ajouter une vérification logique, exigeant que l'adresse de l'expéditeur (from) et celle du destinataire (to) soient toutes deux présentes dans la liste blanche. Il est conseillé de développer un système de backend utilisateur Web dédié pour effectuer les opérations, afin d'augmenter la commodité des opérations.

Deuxième partie mise en œuvre des smart contracts

1. Système de contrôle d'accès conçu de manière précise

Guide de mise en œuvre

Il est nécessaire de définir une série de rôles clairs et d'attribuer ces rôles à différentes entités ou employés contrôlés par des portefeuilles multi-signatures afin de réaliser une séparation des responsabilités et de minimiser le risque de point de défaillance unique ou de manipulation collusoire. Chaque rôle doit se limiter à des fonctions spécifiques, toutes les opérations doivent nécessiter une autorisation multi-signature, et il doit être garanti qu'aucun employé unique ne détient simultanément plusieurs rôles à haut risque. Toutes les opérations doivent être enregistrées dans un journal et faire l'objet d'un audit tiers annuel, la répartition des droits étant supervisée par l'administrateur ou le conseil d'administration.

• MINTER_ROLE : Responsable du traitement de l'émission du stablecoin ( mint ), y compris la création d'unités de jeton après réception d'une demande d'émission valide, et s'assurant que l'émission correspond à l'augmentation correspondante du pool d'actifs de réserve.

• BURNER_ROLE : responsable du traitement de l'émission de stablecoin (burn), y compris la destruction des unités de jeton après réception d'une demande de rachat valide.

• PAUSER_ROLE : responsable de la pause de (pause) des opérations des stablecoins, par exemple, en cas de détection d'événements anormaux ( tels que des menaces de sécurité ), arrêt temporaire des transferts, de l'émission ou du rachat.

• RESUME_ROLE : responsable de la reprise de l'opération de (resume) stablecoin, par exemple, réactiver les transferts, l'émission ou le rachat après la résolution d'un événement de suspension.

• FREEZER_ROLE : responsable de l'émission de (freeze) et de la levée de l'émission de (remove freeze) pour des portefeuilles ou jetons spécifiques, par exemple, geler temporairement des actifs lorsqu'une activité suspecte ( telle qu'un risque de blanchiment d'argent ) est détectée.

• WHITELISTER_ROLE : responsable de la gestion de la whitelist (whitelist), y compris l'ajout ou le retrait des adresses de portefeuille autorisées, par exemple, limiter l'émission des jetons uniquement aux adresses de la whitelist.

• BLACKLISTER_ROLE : responsable de la gestion de la liste noire (blacklist) et de la suppression de la liste noire (remove blacklist), par exemple en ajoutant des portefeuilles suspects à la liste noire pour empêcher les transferts.

• UPGRADER_ROLE : Si un modèle évolutif est adopté, responsable de l'upgrade (upgrade) des smart contracts, par exemple mettre à jour le code du contrat pour corriger des vulnérabilités ou ajouter des fonctionnalités.

2. émission ( jeton ) mécanisme

Guide de mise en œuvre

Vérification préalable : la fonction doit vérifier si l'adresse cible to est sur la liste noire ou est gelée avant d'exécuter l'émission des jetons.

Processus d'opération :

• Due diligence hors chaîne : les clients doivent compléter tous les processus nécessaires d'identification des clients hors chaîne ( KYC ) et de diligence raisonnable des clients ( CDD ). De plus, les réglementations AML/CFT exigent que pour établir une relation d'affaires ou pour des transactions occasionnelles dépassant un seuil spécifique ( tel que 8 000 HKD ), le CDD doit être exécuté.
• Réception des fonds : le client transfère des fonds en monnaie fiduciaire équivalents sur le compte bancaire désigné par l'émetteur.
• Validation interne : le système interne de l'émetteur confirme la réception des fonds et met à jour en conséquence les enregistrements comptables des actifs de réserve.
• Exécution sur la chaîne : l'équipe opérationnelle crée et signe une transaction à signatures multiples, appelle la fonction de création de jetons des smart contracts, et envoie les stablecoins nouvellement émis à l'adresse du portefeuille préenregistrée et vérifiée du client.

3. Rachat ( destruction ) mécanisme

Guide de mise en œuvre

Préparation au rachat : l'utilisateur doit d'abord transférer le jeton à racheter à l'adresse désignée contrôlée par l'émetteur.

Processus d'opération :

• Demande hors chaîne : L'utilisateur soumet une demande de rachat hors chaîne via la plateforme de l'émetteur. Avant de traiter la demande, l'émetteur doit effectuer une diligence raisonnable appropriée sur le client (CDD).
• Vérification du système : le système de l'émetteur vérifie la validité de la demande de vérification et s'assure que l'utilisateur a effectué les opérations de transfert de jeton correspondantes sur la chaîne.
• Paiement en fiat : L'émetteur transférera un montant équivalent en fiat sur le compte bancaire que l'utilisateur a préalablement enregistré et vérifié.
• Destruction sur la chaîne : après avoir confirmé le succès du transfert de fiat, un portefeuille multi-signature détenant le RÔLE_BURNER appelle la fonction de destruction pour détruire la quantité correspondante de jetons à partir de l'adresse spécifiée.

4. Mise en œuvre du contrôle d'urgence : suspension et gel

Guide de mise en œuvre

Fonction de suspension : appelée uniquement par un portefeuille multi-signatures détenant le PAUSER_ROLE, utilisée pour interrompre globalement les fonctionnalités des contrats. Les conditions de déclenchement incluent la détection d'événements anormaux ( tels qu'une attaque réseau ou un désalignement d'actifs de réserve ), nécessitant l'approbation du conseil d'administration ou de la direction supérieure. La fonction de reprise est gérée par un RESUME_ROLE indépendant, afin de réaliser une séparation des responsabilités.

Fonction de gel : appelée par un portefeuille multisignature détenant le FREEZER_ROLE, utilisée pour limiter les transferts vers des adresses spécifiques. Les conditions de déclenchement incluent des activités suspectes ( telles qu'une alerte AML ou un ordre du tribunal ), à exécuter après vérification hors chaîne. Le dégel est géré par le même rôle, mais nécessite une vérification d'audit supplémentaire, ainsi que la publication d'annonces connexes, afin de prévenir les abus.

5. Filtrage d'adresses et mécanisme de liste noire

Guide de mise en œuvre

• Implémentation de la fonction : fonction pour ajouter et supprimer des adresses de la liste noire, pouvant être appelée uniquement par un portefeuille multisignature détenant le rôle BLACKLISTER_ROLE.
• Limite de transfert : les adresses sur liste noire ne peuvent pas transférer/recevoir des jetons.
• Processus opérationnel : L'outil d'analyse émet une alerte, déclenchant un examen de conformité interne. Après confirmation par l'équipe de conformité, une transaction d'ajout à la liste noire est initiée par le portefeuille multi-signatures BLACKLISTER_ROLE.

6. L'évolutivité des smart contracts

Guide de mise en œuvre

• Modèle de proxy : Pour les contrats intelligents de type EVM, il est possible d'utiliser le modèle de proxy ERC-1967 éprouvé pour réaliser des mises à niveau.
• Contrôle d'accès : La fonction de mise à niveau ne doit être appelée que par un portefeuille multi-signatures détenant le rôle UPGRADER_ROLE.
• Processus de gestion des changements : Conformément aux exigences réglementaires, avant de proposer toute mise à niveau, un processus de gestion des changements rigoureux doit être complété, y compris un audit de sécurité complet et indépendant des nouveaux contrats logiques.

7. Journaux d'événements on-chain pour l'analyse et le rapport

Guide de mise en œuvre

En plus des exigences de transfert (Transfer) et d'approbation (Approval) du standard ERC-20, le contrat doit définir et émettre des événements personnalisés pour toutes les actions de gestion et les changements d'état :

• Émission/Destruction de jetons ( Minted/Burned ) événement
• Contrat suspendu/repris ( Paused/Resume ) événement
• Ajout/Retrait de la liste noire ( BlacklistAdded/BlacklistRemoved ) événement
• Ajout/Suppression de la liste blanche (WhitelistAdded/WhitelistRemoved) événement
• Gel de l'adresse/Dégel de l'adresse (AddressFrozen/AddressUnfrozen ) événement
• Changement de rôle privilégié ( RoleGranted/RoleRevoked ) événement
• Événement de mise à niveau des smart contracts (Upgraded)

Troisième partie Sécurité opérationnelle et gestion du cycle de vie

1. Architecture de gestion des clés de sécurité

Guide de mise en œuvre

• Génération de clés : doit être effectuée par un "rituel de clés" documenté en détail (key ceremony), dans un environnement à air gap physiquement sécurisé et complètement isolé des réseaux externes.
• Stockage des clés : tous les rôles de gestion doivent être contrôlés par des portefeuilles multi-signatures. Les clés privées utilisées par les signataires de ces portefeuilles multi-signatures doivent être stockées dans un HSM ou d'autres portefeuilles matériels sécurisés. Pour les rôles les plus critiques, les clés correspondantes doivent être conservées dans un système isolé, physiquement séparé de tout environnement en ligne.
• Utilisation des clés : il est nécessaire d'appliquer une stratégie de signature multiple. Pour les signatures de transaction impliquant des "clés privées importantes", il peut être nécessaire que les personnes concernées soient présentes pour effectuer l'opération.
• Sauvegarde et restauration : La sauvegarde des fragments de clé ou des phrases mnémotechniques doit être stockée dans plusieurs emplacements sûrs et géographiquement dispersés à Hong Kong ( ou dans des lieux approuvés par les régulateurs ), et doit être protégée par un emballage anti-manipulation.

2. Un processus de déploiement complet et une surveillance en temps réel

Guide de mise en œuvre

Avant le déploiement officiel, il est impératif d'élaborer et de suivre strictement une "liste de contrôle avant déploiement" :

• Test complet : assurer une couverture des tests unitaires de plus de 95 %, une couverture du code principal de 100 %, et garantir la sortie d'un rapport de couverture des tests unitaires.
• Audit indépendant : obtenir un rapport d'audit de sécurité indépendant émis par au moins une, de préférence deux, sociétés d'audit réputées.
• Gel de code : Après l'audit, le code est gelé jusqu'au lancement, sans aucune modification du code.
• Tests de régression : exécuter des tests unitaires et effectuer des tests de régression avant le déploiement officiel.
• Approbation de conformité : obtenir l'approbation officielle de l'équipe de conformité interne, confirmant que la logique du contrat respecte toutes les exigences réglementaires pertinentes.
• Déploiement : Préparez un script de déploiement détaillé et effectuez-le sur un réseau de test complètement identique à l'environnement principal.