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

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

1. Choix de la blockchain distribuée sous-jacente

Il est conseillé de privilégier des blockchains publiques matures et sûres telles qu'Ethereum, Arbitrum, etc. Ces réseaux disposent d'une résilience éprouvée, d'un vaste réseau de nœuds de validation et d'une supervision publique continue, leur conférant un avantage naturel. Envisageant d'adopter une chaîne de consortium ou d'autres types de registres distribués, il est impératif de mener une analyse comparative rigoureuse pour prouver que leurs normes de sécurité ne sont pas inférieures à celles des chaînes publiques mainstream.

Le rapport d'évaluation doit couvrir de manière exhaustive la capacité à résister aux attaques courantes, les types d'algorithmes de consensus, ainsi que les risques liés aux défauts de code, aux vulnérabilités, aux exploitations et à d'autres menaces, et analyser en détail comment ces risques affectent l'émission, le rachat et les opérations quotidiennes des stablecoins. Ce document est un élément clé pour prouver la prudence du choix technologique auprès des régulateurs.

2. Norme de jeton de base et extension des fonctions de régulation

Utiliser l'ERC-20 comme norme de base pour garantir l'homogénéité des jetons et l'interopérabilité dans un écosystème plus large. Les modules fonctionnels suivants doivent être intégrés :

• Pausable : implémenter une fonction de pause et de reprise globale pour toutes les activités de jetons.
• Mintable: émettre de nouveaux jetons par un processus contrôlé
• Brûlable : fournit la fonctionnalité de destruction de jetons
• Freezable : suspendre la fonction de transfert de jetons d'un compte spécifique
• Whitelist: seuls les adresses approuvées par la diligence raisonnable peuvent participer aux opérations centrales
• Liste noire : imposer une interdiction de transaction aux adresses impliquées dans des activités illégales
• AccessControl : mise en œuvre d'un système de gestion des droits basé sur des rôles et précis

3. Principaux modes de conformité : choix de la liste noire et de la liste blanche

Il est conseillé d'adopter le mode liste noire comme solution par défaut :

• Avantages : offre une plus grande utilité, peut interopérer sans solution de continuité avec l'écosystème DeFi, offrant aux utilisateurs des barrières d'entrée plus faibles et une expérience fluide.
• Inconvénient : La conformité dépend fortement d'une capacité d'analyse de surveillance hors chaîne puissante et en temps réel.
• Réaliser : dans la fonction de transfert des smart contracts, ajouter une vérification logique pour s'assurer que les adresses de l'expéditeur et du destinataire de la transaction ne sont pas enregistrées sur la liste noire.

Deuxième partie mise en œuvre des smart contracts

1. Système de contrôle d'accès conçu avec précision

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 multisignatures, afin d'assurer la séparation des responsabilités. Chaque rôle doit être limité à des fonctions spécifiques, toutes les opérations nécessitant une autorisation multisignature. Les principaux rôles comprennent :

• MINTER_ROLE: responsable du traitement de l'émission des stablecoins
• BURNER_ROLE: responsable du traitement de l'émission des stablecoins
• PAUSER_ROLE: responsable de la pause des opérations de stablecoin
• RESUME_ROLE: responsable de la récupération des opérations de stablecoin
• FREEZER_ROLE: responsable du gel et du dégel de portefeuilles ou de jetons spécifiques
• WHITELISTER_ROLE: responsable de la gestion de la liste blanche
• BLACKLISTER_ROLE: responsable de la gestion de la liste noire
• UPGRADER_ROLE: responsable de la mise à niveau des smart contracts

2. émission ( jeton ) mécanisme

Processus d'opération:

1. Due diligence hors chaîne : le client complète tous les processus KYC et CDD nécessaires.
2. Réception des fonds : Le client transfère des fonds équivalents en monnaie fiduciaire sur le compte bancaire désigné par l'émetteur.
3. Vérification interne : le système interne de l'émetteur confirme la réception des fonds et met à jour les enregistrements comptables des actifs de réserve.
4. Exécution sur la chaîne : l'équipe de fonctionnement crée et signe une transaction à signatures multiples, appelle la fonction de création de jetons des smart contracts, et envoie le stablecoin nouvellement émis à l'adresse de portefeuille vérifiée du client.

3. Rachat ( mécanisme de destruction )

Processus opérationnel :

1. Demande hors chaîne : L'utilisateur soumet une demande de rachat hors chaîne via la plateforme de l'émetteur. L'émetteur doit effectuer une CDD appropriée sur le client.
2. Vérification du système : le système de l'émetteur vérifie la validité de la demande de vérification et vérifie si l'utilisateur a déjà effectué l'opération de transfert de jeton sur la chaîne.
3. Paiement en monnaie fiduciaire : l'émetteur transférera l'équivalent en monnaie fiduciaire sur le compte bancaire préalablement enregistré et vérifié de l'utilisateur.
4. Destruction sur la chaîne : après confirmation du transfert de la monnaie fiduciaire, le portefeuille multi-signatures détenant le rôle BURNER_ROLE 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

• Fonction de suspension : uniquement appelée par un portefeuille multi-signatures détenant le rôle PAUSER_ROLE, utilisée pour interrompre globalement les fonctions du contrat. Les conditions de déclenchement incluent la détection d'événements anormaux, nécessitant l'approbation du conseil d'administration ou de la direction supérieure.
• Fonction de gel : appelée par un portefeuille multi-signatures détenant le rôle FREEZER_ROLE, utilisée pour restreindre les transferts vers des adresses spécifiques. Les conditions de déclenchement incluent des activités suspectes, nécessitant une vérification hors chaîne avant exécution.

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

• Implémentation de fonction : fonction d'ajout et de suppression de la liste noire, appelée uniquement par un portefeuille multi-signature détenant le rôle BLACKLISTER_ROLE.
• Limite de transfert : Les adresses figurant sur la liste noire ne peuvent pas transférer/recevoir des jetons.
• Processus opérationnel : l'outil d'analyse émet une alerte, déclenche une revue de conformité interne, après confirmation de l'équipe de conformité, une transaction d'ajout à la liste noire est initiée par le portefeuille multi-signature BLACKLISTER_ROLE.

6. La capacité de mise à niveau des smart contracts

• Modèle de proxy : Pour les contrats intelligents de type EVM, un modèle de proxy ERC-1967 éprouvé peut être utilisé pour réaliser la montée en version.
• Contrôle d'accès : La fonction de mise à niveau doit être appelée uniquement par un portefeuille multi-signature détenant le rôle UPGRADER_ROLE.
• Processus de gestion des changements : 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 smart contracts.

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

En plus des événements Transfer et Approval requis par la norme 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, y compris :

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

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

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

• Génération de clés : doit être effectuée par un "rituel de clés" documenté en détail, dans un environnement de cloisonnement 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 multisignatures. Les clés privées utilisées par les signataires de ces portefeuilles multisignatures doivent être stockées dans des HSM ou d'autres portefeuilles matériels sécurisés.
• Utilisation des clés : une politique de signatures multiples doit être appliquée de manière stricte. Pour les signatures de transactions impliquant des "clés privées importantes", il peut être nécessaire que les personnes concernées soient présentes en personne.
• Sauvegarde et restauration : la sauvegarde des fragments de clé ou des phrases mnémotechniques doit être stockée à plusieurs emplacements sécurisés et géographiquement dispersés à Hong Kong, et doit être protégée par un emballage anti-manipulation.

2. Processus de déploiement complet et surveillance en temps réel

Liste de vérification avant déploiement :

• Test complet : s'assurer que la couverture des tests unitaires est supérieure à 95 %, et que la couverture du code principal est de 100 %.
• Audit indépendant : obtenir au moins un, de préférence deux rapports d'audit de sécurité indépendants fournis par des entreprises d'audit réputées.
• Gel de code : après l'audit, le code est gelé jusqu'à la mise en ligne, sans modification de code.
• Tests de régression : exécuter des tests unitaires et effectuer des tests de régression avant le déploiement officiel.
• Approbation de la conformité : obtenir l'approbation officielle de l'équipe de conformité interne, confirmant que la logique du contrat respecte toutes les exigences réglementaires pertinentes.
• Exercices de déploiement : préparer des scripts de déploiement détaillés et effectuer un exercice de déploiement complet sur le réseau de test.
• Déploiement autorisé : effectué par le portefeuille autorisé pour exécuter l'opération de déploiement finale.

Mesures de surveillance après déploiement:

• Surveillance des activités sur la chaîne : surveiller l'utilisation des rôles de gestion, détecter rapidement les situations non autorisées.
• Surveillance des menaces: détecter en temps opportun les nouvelles menaces et analyser les renseignements sur les menaces afin de pouvoir mettre en œuvre des mesures d'atténuation en temps utile.

3. Fournir un soutien technique pour la continuité des affaires et le plan de sortie

Élaborer un plan de sortie des affaires : couvrir les diverses situations pouvant conduire à une cessation ordonnée, y compris les mesures de surveillance pour la survenance réelle ou potentielle de ces situations.

Processus de retrait sur la chaîne :

• Suspendre les smart contracts pour arrêter toutes les actions de transfert de jetons, garantir la maximisation des bénéfices de liquidation des actifs de réserve et minimiser l'impact sur la stabilité globale du marché.
• En s'appuyant sur la fonction de rachat et la fonction de liste blanche, aider les détenteurs de stablecoin à soumettre une demande de rachat.