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
Privilégiez les blockchains publiques matures : il est recommandé de privilégier des blockchains publiques matures et hautement sécurisées comme Ethereum, Arbitrum, etc.
Évaluation rigoureuse des alternatives : Si l'on envisage d'adopter une chaîne de consortium ou d'autres types de registres distribués, 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 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 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 peuvent avoir un impact potentiel sur l'émission, le rachat et l'exploitation quotidienne des stablecoins.
2. Normes de jeton de base et extension des fonctions de régulation
Guide de mise en œuvre
Standard de base : adoption 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.
Extension de fonctionnalités : 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 pause et de reprise globale pour 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 à un montant suffisant d'actifs de réserve en monnaie fiduciaire.
Brûlable : Fournit la fonction de destruction de jetons. Dans la mise en œuvre spécifique, cette fonction sera strictement contrôlée par des permissions, plutôt que de 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 ).
Whitelist : utilisé pour mettre en œuvre des mesures de sécurité supplémentaires, n'autorisant que les adresses approuvées et ayant passé la diligence raisonnable à participer aux opérations essentielles ( 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, 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: Ceci est la base d'un système de gestion des permissions basé sur les rôles et affiné. Toutes les fonctions de gestion doivent passer par ce module pour le contrôle des permissions, afin de répondre aux exigences de séparation des responsabilités.
3. Principaux modèles de conformité : choix de la liste noire et de la liste blanche
Guide de mise en œuvre
Mode liste noire ( proposition par défaut ):
Avantages : offre une plus grande utilité, capable d'interopérer sans faille avec l'écosystème de finance décentralisée (DeFi) vaste, offrant aux utilisateurs un seuil d'utilisation plus bas et une expérience plus fluide.
Inconvénients : La conformité dépend fortement de la 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 l'adresse de l'expéditeur (from) et l'adresse du destinataire (to) ne sont pas enregistrées sur la liste noire.
Mode liste blanche
Avantages: fournit le plus haut niveau de contrôle AML/CFT, réalisant la prévention à l'avance, plutôt que la remédiation a posteriori.
Inconvénients : limite considérablement l'universalité et le taux d'adoption des stablecoins, entraîne 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 accepté.
Mode de réalisation : dans la fonction de transfert des smart contracts, ajouter une vérification logique, exigeant que les adresses de l'expéditeur (from) et du destinataire (to) doivent toutes deux figurer sur la liste blanche. Il est conseillé de développer un système de backend Web dédié pour faciliter les opérations.
Deuxième partie mise en œuvre des smart contracts
1. Système de contrôle d'accès conçu avec précision
Guide de mise en œuvre
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 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 être limité à des fonctions spécifiques, toutes les opérations doivent être autorisées par multi-signature, et il doit être assuré qu'aucun employé unique ne détient simultanément plusieurs rôles à haut risque. Toutes les opérations doivent être enregistrées dans des journaux et être soumises à un audit tiers annuel, l'attribution des droits étant supervisée par un administrateur ou un conseil d'administration.
MINTER_ROLE: Responsable du traitement des opérations d'émission de 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 la destruction des stablecoins (burn), y compris la destruction des unités de jetons après réception d'une demande de rachat valide.
PAUSER_ROLE: responsable de la pause de (pause) des opérations de stablecoin, comme par exemple arrêter temporairement les transferts, l'émission ou le rachat lors de la détection d'événements anormaux ( tels que des menaces de sécurité ).
RESUME_ROLE: Responsable de la reprise de l'opération de la 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 la congélation de )freeze( et de la levée de la congélation de )remove freeze( des opérations sur des portefeuilles ou des jetons spécifiques, par exemple, congeler temporairement des actifs en cas d'activités suspectes ) telles que des risques de blanchiment d'argent (.
WHITELISTER_ROLE: responsable de la gestion de la whitelist )whitelist(, y compris l'ajout ou la suppression des adresses de portefeuille autorisées, par exemple, en limitant l'émission de 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 : avant d'exécuter l'émission de jetons, la fonction doit vérifier si l'adresse cible to est sur la liste noire ou est en état gelé.
Processus d'opération:
Due diligence hors chaîne : le client doit 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 qu'une diligence raisonnable (CDD) soit effectuée pour les clients établissant une relation d'affaires ou effectuant des transactions occasionnelles dépassant un seuil spécifique ) tel que 8 000 HKD (.
Réception des fonds : le client transfère des fonds en monnaie fiduciaire équivalente 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 chaîne : l'équipe opérationnelle crée et signe une transaction multi-signature, appelant la fonction de jeton d'émission des smart contracts, pour envoyer le stablecoin 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 qu'il souhaite racheter à l'adresse désignée contrôlée par l'émetteur.
Processus opérationnel :
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 vérifie si l'utilisateur a déjà effectué l'opération de transfert de jeton correspondante sur la chaîne.
Paiement en monnaie fiduciaire : l'émetteur transfère une monnaie fiduciaire équivalente sur le compte bancaire préalablement enregistré et vérifié de l'utilisateur.
Destruction sur la chaîne : après avoir confirmé le succès du transfert de monnaie fiduciaire, le portefeuille multi-signatures détenant le RÔLE_DE_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 de contrôles d'urgence : suspension et gel
Guide de mise en œuvre
Fonction de pause : uniquement appelée par un portefeuille multi-signatures détenant le PAUSER_ROLE, utilisée pour suspendre globalement les fonctions du contrat. Les conditions de déclenchement incluent la détection d'événements anormaux ### tels qu'une attaque réseau ou un décalage dans les actifs de réserve (, nécessitant l'approbation du conseil d'administration ou de la haute direction. 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 multisignature détenant le rô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 (, nécessitant une vérification hors chaîne avant exécution. Le dégel est traité par le même rôle, mais nécessite une validation d'audit supplémentaire, ainsi que la publication d'annonces pertinentes, afin de prévenir les abus.
) 5. Filtrage d'adresse 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, qui ne peut être appelée que par un portefeuille multi-signatures détenant le BLACKLISTER_ROLE.
Limite de transfert : les adresses figurant sur la liste noire ne peuvent pas transférer/recevoir des jetons.
Processus d'opération : l'outil d'analyse émet une alerte, déclenchant un examen de conformité interne, après confirmation de l'équipe de conformité, la transaction d'ajout au blacklist est lancé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 smart contracts de type EVM, il est possible d'adopter le modèle de proxy ERC-1967 éprouvé pour permettre la mise à niveau.
Contrôle des autorisations : La fonction de mise à niveau ne peut ê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 achevé, comprenant 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
Guide de mise en œuvre
En plus des exigences de transfert selon la norme ERC-20 ###Transfer(, de l'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 ) Minted/Burned ( événement
Contrat suspendu/repris)Paused/Resume(événement
Ajouter/retirer à la liste noire ) BlacklistAdded/BlacklistRemoved ( événement
Ajout/retrait de la liste blanche ) WhitelistAdded/WhitelistRemoved ( é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é
Guide de mise en œuvre
Génération de clé : doit être réalisée à travers une "cérémonie de clé" documentée en détail ###key ceremony(, dans un environnement physique sécurisé, complètement isolé des réseaux extérieurs.
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: une stratégie de signature multiple doit être appliquée de manière stricte. Pour la signature des transactions 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 mots de passe doit être stockée dans plusieurs emplacements sécurisés et géographiquement dispersés à Hong Kong ) ou à des emplacements approuvés par les régulateurs (, et doit être protégée par un emballage anti-sabotage.
) 2. Processus de déploiement complet et surveillance en temps réel
Guide de mise en œuvre
Avant le déploiement officiel, il est nécessaire d'élaborer et de mettre en œuvre 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 au moins un, de préférence deux, rapports d'audit de sécurité indépendants émis par des sociétés d'audit réputées.
Gel de code : une fois l'audit terminé, le code est gelé jusqu'au lancement, 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 formelle 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 un script de déploiement détaillé et effectuer un exercice de déploiement complet sur un réseau de test entièrement 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 mises en place pour atténuer rapidement l'utilisation des rôles privilégiés ainsi que les menaces émergentes :
Surveillance des activités sur la chaîne : surveillance du rôle de gestion
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
12 J'aime
Récompense
12
4
Partager
Commentaire
0/400
LiquidityNinja
· Il y a 12h
Pourquoi courir si vite, que veux-tu faire ? Hksb, attends un peu.
Guide de mise en œuvre des contrats intelligents des émetteurs de stablecoin à Hong Kong : architecture, conformité et sécurité
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
2. Normes de jeton de base et extension des fonctions de régulation
Guide de mise en œuvre
Standard de base : adoption 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.
Extension de fonctionnalités : 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 pause et de reprise globale pour 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 à un montant suffisant d'actifs de réserve en monnaie fiduciaire.
Brûlable : Fournit la fonction de destruction de jetons. Dans la mise en œuvre spécifique, cette fonction sera strictement contrôlée par des permissions, plutôt que de 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 ).
Whitelist : utilisé pour mettre en œuvre des mesures de sécurité supplémentaires, n'autorisant que les adresses approuvées et ayant passé la diligence raisonnable à participer aux opérations essentielles ( 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, 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: Ceci est la base d'un système de gestion des permissions basé sur les rôles et affiné. Toutes les fonctions de gestion doivent passer par ce module pour le contrôle des permissions, afin de répondre aux exigences de séparation des responsabilités.
3. Principaux modèles de conformité : choix de la liste noire et de la liste blanche
Guide de mise en œuvre
Mode liste noire ( proposition par défaut ):
Avantages : offre une plus grande utilité, capable d'interopérer sans faille avec l'écosystème de finance décentralisée (DeFi) vaste, offrant aux utilisateurs un seuil d'utilisation plus bas et une expérience plus fluide.
Inconvénients : La conformité dépend fortement de la 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 l'adresse de l'expéditeur (from) et l'adresse du destinataire (to) ne sont pas enregistrées sur la liste noire.
Mode liste blanche
Avantages: fournit le plus haut niveau de contrôle AML/CFT, réalisant la prévention à l'avance, plutôt que la remédiation a posteriori.
Inconvénients : limite considérablement l'universalité et le taux d'adoption des stablecoins, entraîne 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 accepté.
Mode de réalisation : dans la fonction de transfert des smart contracts, ajouter une vérification logique, exigeant que les adresses de l'expéditeur (from) et du destinataire (to) doivent toutes deux figurer sur la liste blanche. Il est conseillé de développer un système de backend Web dédié pour faciliter les opérations.
Deuxième partie mise en œuvre des smart contracts
1. Système de contrôle d'accès conçu avec précision
Guide de mise en œuvre
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 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 être limité à des fonctions spécifiques, toutes les opérations doivent être autorisées par multi-signature, et il doit être assuré qu'aucun employé unique ne détient simultanément plusieurs rôles à haut risque. Toutes les opérations doivent être enregistrées dans des journaux et être soumises à un audit tiers annuel, l'attribution des droits étant supervisée par un administrateur ou un conseil d'administration.
MINTER_ROLE: Responsable du traitement des opérations d'émission de 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 la destruction des stablecoins (burn), y compris la destruction des unités de jetons après réception d'une demande de rachat valide.
PAUSER_ROLE: responsable de la pause de (pause) des opérations de stablecoin, comme par exemple arrêter temporairement les transferts, l'émission ou le rachat lors de la détection d'événements anormaux ( tels que des menaces de sécurité ).
RESUME_ROLE: Responsable de la reprise de l'opération de la 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 la congélation de )freeze( et de la levée de la congélation de )remove freeze( des opérations sur des portefeuilles ou des jetons spécifiques, par exemple, congeler temporairement des actifs en cas d'activités suspectes ) telles que des risques de blanchiment d'argent (.
WHITELISTER_ROLE: responsable de la gestion de la whitelist )whitelist(, y compris l'ajout ou la suppression des adresses de portefeuille autorisées, par exemple, en limitant l'émission de 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 : avant d'exécuter l'émission de jetons, la fonction doit vérifier si l'adresse cible to est sur la liste noire ou est en état gelé.
Processus d'opération:
) 3. Rachat ### destruction ( mécanisme
)# Guide de mise en œuvre
Préparation au 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 :
) 4. Mise en œuvre de contrôles d'urgence : suspension et gel
Guide de mise en œuvre
Fonction de pause : uniquement appelée par un portefeuille multi-signatures détenant le PAUSER_ROLE, utilisée pour suspendre globalement les fonctions du contrat. Les conditions de déclenchement incluent la détection d'événements anormaux ### tels qu'une attaque réseau ou un décalage dans les actifs de réserve (, nécessitant l'approbation du conseil d'administration ou de la haute direction. 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 multisignature détenant le rô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 (, nécessitant une vérification hors chaîne avant exécution. Le dégel est traité par le même rôle, mais nécessite une validation d'audit supplémentaire, ainsi que la publication d'annonces pertinentes, afin de prévenir les abus.
) 5. Filtrage d'adresse et mécanisme de liste noire
Guide de mise en œuvre
6. L'évolutivité des smart contracts
Guide de mise en œuvre
7. Journaux d'événements on-chain pour l'analyse et le reporting
Guide de mise en œuvre
En plus des exigences de transfert selon la norme ERC-20 ###Transfer(, de l'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.
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
) 2. Processus de déploiement complet et surveillance en temps réel
Guide de mise en œuvre
Avant le déploiement officiel, il est nécessaire d'élaborer et de mettre en œuvre strictement une "liste de contrôle avant déploiement" :
Après le déploiement, des mesures de surveillance appropriées doivent être mises en place pour atténuer rapidement l'utilisation des rôles privilégiés ainsi que les menaces émergentes :