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

Il est conseillé de privilégier des blockchains publiques matures et hautement sécurisées telles qu'Ethereum ou Arbitrum. Ces réseaux bénéficient d'avantages naturels grâce à leur résilience éprouvée, à leur vaste réseau de nœuds de validation et à la surveillance continue du public. Le coût élevé des attaques peut directement répondre aux préoccupations réglementaires concernant la résistance aux attaques à 51 % et la garantie de la finalité des transactions.

Si l'on envisage d'adopter une chaîne de consortium ou un autre type de registre distribué, il est nécessaire de mener une analyse comparative rigoureuse et quantifiable pour prouver que ses normes de sécurité ne sont pas inférieures, voire supérieures, à celles des chaînes publiques majeures.

Le rapport d'évaluation des risques doit couvrir de manière exhaustive la capacité de 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, à l'exploitation des vulnérabilités et à d'autres menaces, et analyser en détail comment ces risques peuvent avoir un impact potentiel sur l'émission, le rachat et l'exploitation quotidienne du stablecoin. Ce document est un document clé pour prouver la prudence du choix technologique aux organismes de réglementation.

2. Normes de jetons principaux et élargissement des fonctions de régulation

Il est recommandé d'adopter l'ERC-20 comme norme de base pour garantir l'homogénéité des jetons et leur interopérabilité dans un écosystème plus large.

Il est nécessaire d'intégrer les modules fonctionnels suivants pour répondre aux exigences réglementaires :

• Pausable : utilisé pour mettre en œuvre une fonction de suspension et de reprise globale de toutes les activités de jetons, c'est un outil clé 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 garantissant que l'émission de jetons correspond strictement aux actifs de réserve en monnaie fiduciaire.
• Brûlable : fournit la fonction de destruction des jetons. Dans la mise en œuvre spécifique, cette fonction sera soumise à un contrôle strict des autorisations, et non pas permettre à n'importe quel utilisateur de détruire à sa guise.
• Freezable : 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 ).
• Liste noire : utilisée pour imposer une interdiction de transaction sur les adresses impliquées dans des activités illégales ( telles que le blanchiment d'argent, 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 droits d'accès fin et basé sur les rôles. Toutes les fonctions de gestion doivent passer par ce module pour le contrôle des droits, afin de répondre aux exigences de séparation des responsabilités.

3. Principaux modèles de conformité : choix des listes noires et blanches

Il est recommandé d'adopter le mode liste noire comme solution par défaut.

• Avantages : offre une plus grande utilité, capable d'interopérer sans couture avec l'écosystème financier décentralisé (DeFi), offrant aux utilisateurs des barrières à l'entrée plus faibles et une expérience plus fluide.
• Inconvénients : la conformité dépend fortement de la capacité d'analyse de surveillance hors chaîne 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 l'adresse de l'expéditeur (from) et celle du destinataire (to) 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 de manière détaillée

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

Définition de rôle :

• MINTER_ROLE: responsable du traitement de l'émission de stablecoin (mint) opérations
• BURNER_ROLE: responsable du traitement de l'émission des stablecoins (burn) opérations
• PAUSER_ROLE: responsable de la pause de (pause) des opérations de stablecoin
• RESUME_ROLE: Responsable de la récupération de l'opération du stablecoin (resume)
• FREEZER_ROLE: responsable de geler (freeze) et de dégel (remove freeze) des opérations sur des portefeuilles ou jetons spécifiques.
• WHITELISTER_ROLE : responsable de la gestion de la whitelist ( whitelist )
• BLACKLISTER_ROLE : responsable de la gestion de la liste noire ( blacklist ) et de la suppression de la liste noire ( remove blacklist )
• UPGRADER_ROLE : Si un modèle évolutif est adopté, responsable de l'upgrade ( upgrade ) smart contracts

2. émission ( jeton ) mécanisme

Vérification préalable : avant d'exécuter l'émission de jetons, il est nécessaire de vérifier si l'adresse cible to est sur la liste noire ou dans un état gelé.

Processus d'opération:

1. Due diligence hors chaîne : le client termine tous les processus nécessaires d'identification des clients hors chaîne ( KYC ) et de diligence raisonnable sur les clients ( CDD ).
2. Réception des fonds : Le client doit transférer des fonds en monnaie fiduciaire équivalente sur le compte bancaire désigné par l'émetteur.
3. 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.
4. Exécution sur la chaîne : l'équipe opérationnelle crée et signe une transaction multi-signature, appelle la fonction d'émission de jetons des smart contracts, et envoie le stablecoin nouvellement émis à l'adresse du portefeuille préenregistrée et vérifiée du client.

3. Rachat de ( et mécanisme de destruction de )

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

Processus opérationnel :

1. 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 due diligence appropriée sur le client (CDD).
2. Validation du système : Le système de l'émetteur vérifie la validité de la demande de validation et vérifie si l'utilisateur a déjà effectué l'opération de transfert de jetons correspondante sur la chaîne.
3. Paiement en fiat : L'émetteur transférera une somme équivalente en fiat sur le compte bancaire de l'utilisateur préalablement enregistré et vérifié.
4. Destruction sur la chaîne : après avoir confirmé le succès du transfert de fiat, le portefeuille multi-signature détenant le RÔLE_DE_BRÛLAGE 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 : appelée uniquement par un portefeuille multi-signatures détenant le PAUSER_ROLE, utilisée pour interrompre globalement les fonctions du contrat. Les conditions de déclenchement incluent la détection d'un événement anormal ( tel qu'une attaque réseau ou un désalignement des 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 garantir la séparation des responsabilités.

Fonction de gel : appelée par un portefeuille multsignature 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 ( telles que des alertes AML ou des ordonnances judiciaires ), nécessitant une vérification hors chaîne avant exécution. 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 pertinentes pour éviter les abus.

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

• Mise en œuvre de fonction : fonction pour ajouter et retirer des adresses de la liste noire, pouvant être appelée uniquement par un portefeuille multi-signature détenant le rôle BLACKLISTER_ROLE.
• Limites de transfert : les adresses figurant sur la liste noire ne peuvent pas transférer/reçevoir des jetons.
• Processus opérationnel : les outils d'analyse émettent des alertes, déclenchant un examen de conformité interne, après confirmation de l'équipe de conformité, la transaction d'ajout à la liste noire est initiée par le portefeuille multi-signatures BLACKLISTER_ROLE.

6. La montée en version des smart contracts

• Modèle d代理 : Pour les smart contracts de type EVM, le modèle d代理 ERC-1967 mature peut être utilisé pour réaliser l'évolutivité.
• 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é, incluant 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 rapport

En plus des exigences de transfert de la norme ERC-20 (Transfer) et des événements d'autorisation (Approval), 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
• Adresse gelée/Débloquée ( AddressFrozen/AddressUnfrozen ) événement
• Changement de rôle privilégié ( Rôle accordé/Rôle révoqué ) événement
• Événement de mise à niveau des contrats (Upgraded)

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é" documenté en détail (key ceremony), dans un environnement de sécurité physique complètement isolé des réseaux externes.
• Stockage des clés : Tous les rôles de gestion doivent être contrôlés par un portefeuille à signatures multiples. Les clés privées utilisées par les signataires de ces portefeuilles multisignatures doivent être stockées dans un HSM ou un autre portefeuille matériel sécurisé. 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 de la clé : Une politique de signature multiple 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 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 enveloppée de manière à résister à la falsification.

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

Avant le déploiement officiel, il est nécessaire d'élaborer et d'appliquer rigoureusement 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 au moins un, de préférence deux rapports d'audit de sécurité indépendants émis 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 aucune modification du code.
• Tests de régression : avant le déploiement officiel, exécutez des tests unitaires et effectuez des tests de régression.
• Approbation de conformité : obtenir l'approbation officielle de l'équipe de conformité interne, confirmant que la logique du contrat satisfait à toutes les exigences réglementaires pertinentes.
• Simulation de déploiement : préparer un script de déploiement détaillé et effectuer une simulation de déploiement complète sur un réseau de test complètement identique à l'environnement de la chaîne principale.
• Déploiement autorisé : effectué par le portefeuille autorisé pour exécuter l'opération de déploiement finale.

Après le déploiement, des mesures de surveillance appropriées doivent être prises pour atténuer rapidement l'utilisation des rôles privilégiés ainsi que les nouvelles menaces qui apparaissent :

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

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

Élaborer un plan de sortie d'entreprise : le plan couvre divers scénarios pouvant conduire à une cessation ordonnée et comprend des mesures de suivi concernant la survenance réelle ou potentielle de ces scénarios.

Processus de retrait on-chain:

• Il est recommandé de suspendre les smart contracts pour arrêter tous les transferts de jetons, afin de maximiser les rendements de la monétisation des actifs de réserve et de 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.