Guía de implementación de contratos inteligentes para emisores de moneda estable en Hong Kong

Parte Uno Infraestructura y Estrategia de Cumplimiento

1. Elección del libro mayor distribuido de base

Se recomienda optar preferentemente por blockchain públicos maduros y altamente seguros como Ethereum, Arbitrum, entre otros. Estas redes, gracias a su resistencia probada, su vasta red de nodos de validación y la supervisión pública continua, poseen ventajas inherentes. Su alto costo de ataque puede responder directamente a las preocupaciones regulatorias sobre la resistencia a ataques del 51% y la garantía de la finalización de las transacciones.

Si se considera adoptar una cadena de consorcio u otro tipo de libro mayor distribuido, se debe llevar a cabo un análisis comparativo riguroso y cuantificable para demostrar que sus estándares de seguridad no son inferiores, e incluso son superiores a los de las cadenas públicas más populares.

El informe de evaluación de riesgos debe cubrir de manera integral su capacidad para resistir ataques comunes, el tipo de algoritmo de consenso, así como los riesgos relacionados con defectos de código, vulnerabilidades, explotación de vulnerabilidades y otras amenazas, y analizar en detalle cómo estos riesgos pueden influir potencialmente en la emisión, el canje y las operaciones diarias de la moneda estable. Este documento es un archivo clave para demostrar a las autoridades reguladoras la prudencia en la selección tecnológica.

2. Estándares de tokens centrales y expansión de funciones regulatorias

Se sugiere adoptar ERC-20 como estándar básico para garantizar la homogeneidad de la moneda y la interoperabilidad en un ecosistema más amplio.

Debemos integrar los siguientes módulos funcionales para cumplir con los requisitos regulatorios:

• Pausable: utilizado para implementar una función de pausa y reanudación global para todas las actividades de moneda, que es una herramienta clave para abordar eventos de seguridad importantes.
• Mintable: utilizado para implementar que los emisores autorizados deben acuñar nuevos tokens a través de un proceso controlado y garantizar que la cantidad de tokens emitidos corresponda estrictamente a los activos de reserva en moneda fiduciaria.
• Burnable: proporciona la función de destruir monedas. En la implementación específica, esta función estará controlada por permisos estrictos, en lugar de permitir que cualquier usuario las destruya por su cuenta.
• Congelable: se utiliza para pausar la función de transferencia de moneda de cuentas específicas ( en caso de transacciones sospechosas ).
• Whitelist: se utiliza para implementar medidas de seguridad adicionales, permitiendo solo que las direcciones aprobadas y verificadas participen en operaciones centrales ( como la recepción de nuevas monedas emitidas ).
• Lista negra: utilizada para implementar una prohibición de transacciones para direcciones involucradas en actividades ilegales ( como lavado de dinero, fraude ), prohibiendo el envío/recepción de monedas. La gestión de la lista negra debe estar vinculada al sistema AML/CFT, monitoreando en tiempo real transacciones sospechosas.
• AccessControl: Esta es la base para implementar un sistema de gestión de permisos basado en roles y con alta granularidad. Todas las funciones de gestión deben ser controladas por este módulo para cumplir con los requisitos de separación de funciones.

3. Principales modos de cumplimiento: selección de listas negras y listas blancas

Se sugiere adoptar el modo de lista negra como la opción recomendada por defecto:

• Ventajas: tiene una mayor utilidad, puede interoperar sin problemas con el amplio ecosistema de finanzas descentralizadas (DeFi), ofreciendo a los usuarios una barrera de entrada más baja y una experiencia más fluida.
• Desventajas: la conformidad depende en gran medida de una sólida capacidad de análisis de monitoreo fuera de la cadena en tiempo real, para detectar y bloquear direcciones ilegales de manera oportuna.
• Modo de implementación: en la función de transferencia de contratos inteligentes, agregar una verificación lógica para asegurar que las direcciones del remitente (from) y del destinatario (to) no estén registradas en la lista negra.

Segunda parte: implementación de contratos inteligentes

1. Sistema de control de acceso diseñado de manera detallada

Es necesario definir una serie de roles claros y asignar estos roles a diferentes entidades o empleados controlados por una billetera de múltiples firmas, para lograr la separación de responsabilidades y minimizar el riesgo de un único punto de falla o manipulación en conspiración. Cada rol debe limitarse a funciones específicas, todas las operaciones requieren autorización de múltiples firmas, y se debe asegurar que ningún empleado tenga simultáneamente múltiples roles de alto riesgo. Todas las operaciones deben registrarse en un registro y someterse a una auditoría anual de terceros, la asignación de permisos debe ser supervisada por un administrador o una junta directiva.

Definición de roles:

• MINTER_ROLE: Responsable de manejar la emisión de moneda estable (mint) operación
• BURNER_ROLE: responsable de manejar la emisión de la moneda estable (burn) operación
• PAUSER_ROLE: Responsable de pausar (pause) la operación de moneda estable
• RESUME_ROLE: Responsable de la operación de la moneda estable (resume)
• FREEZER_ROLE: Responsable de congelar (freeze) y descongelar (remove freeze) operaciones de billeteras o monedas específicas
• WHITELISTER_ROLE: responsable de gestionar la moneda estable ( whitelist )
• BLACKLISTER_ROLE: responsable de gestionar la lista negra ( blacklist ) y eliminar la lista negra ( remove blacklist )
• UPGRADER_ROLE: Si se adopta un modelo actualizable, es responsable de la emisión (upgrade) contratos inteligentes

2. emisión ( moneda ) mecanismo

Verificación previa: antes de ejecutar la emisión, la función debe comprobar si la dirección objetivo to está en la lista negra o en estado congelado.

Proceso de operación:

1. Diligencia debida fuera de la cadena: el cliente completa todos los procesos necesarios de identificación de cliente fuera de la cadena (KYC) y diligencia debida del cliente (CDD).
2. Recepción de fondos: El cliente transferirá fondos en moneda fiduciaria equivalentes a la cuenta bancaria designada por el emisor.
3. Verificación interna: el sistema interno del emisor confirma la recepción de fondos y actualiza en consecuencia los registros contables de los activos de reserva.
4. Ejecución en la cadena: el equipo de operaciones crea y firma una transacción de múltiples firmas, llama a la función de emisión de tokens del contrato inteligente y envía la nueva moneda estable acuñada a la dirección de la billetera registrada y verificada previamente del cliente.

3. Redención ( mecanismo de destrucción )

Preparación para el reembolso: El usuario debe transferir primero la moneda que desea reembolsar a la dirección designada controlada por el emisor.

Proceso de operación:

1. Solicitud fuera de la cadena: El usuario presenta una solicitud de recompra fuera de la cadena a través de la plataforma del emisor. Antes de procesar la solicitud, el emisor debe realizar la debida diligencia del cliente adecuada (CDD).
2. Verificación del sistema: El sistema del emisor verifica la validez de la solicitud de verificación y comprueba si el usuario ha completado la operación de transferencia de moneda correspondiente en la cadena.
3. Pago en moneda fiat: el emisor transferirá el equivalente en moneda fiat a la cuenta bancaria que el usuario haya registrado y verificado previamente.
4. Quema en la cadena: Después de confirmar el éxito de la transferencia de moneda fiduciaria, una billetera multisig que tenga el ROL_DE_QUEMA llama a la función de quema para destruir la cantidad correspondiente de moneda desde la dirección especificada.

4. Implementar control de emergencia: suspender y congelar

Función de pausa: solo puede ser llamada por una billetera multifirma que posea el PAUSER_ROLE, utilizada para detener globalmente las funciones del contrato. Las condiciones que desencadenan esto incluyen la detección de eventos anómalos ( como ataques a la red o desajustes en los activos de reserva ), lo que requiere la aprobación de la junta o la alta dirección. La función de reanudación es manejada por un RESUME_ROLE independiente, para lograr la separación de funciones.

Función de congelación: llamada por una cartera multi-firma que posee el rol FREEZER_ROLE, utilizada para limitar transferencias hacia direcciones específicas. Las condiciones de activación incluyen actividades sospechosas ( como alertas de AML o órdenes judiciales ), que deben ejecutarse después de una verificación fuera de la cadena. El desbloqueo es manejado por el mismo rol, pero necesita una verificación de auditoría adicional, publicando un anuncio relacionado, para prevenir abusos.

5. Filtrado de direcciones y mecanismo de lista negra

• Implementación de funciones: implementar funciones para añadir y eliminar de la lista negra, y que solo puedan ser llamadas por un monedero multifirma que posea el BLACKLISTER_ROLE.
• Límite de transferencia: se prohíbe que las direcciones en la lista negra transfieran/reciban monedas.
• Proceso de operación: la herramienta de análisis emite una alerta, se activa la revisión de cumplimiento interno, después de la confirmación del equipo de cumplimiento, se inicia la transacción de adición a la lista negra desde la cartera multifirma BLACKLISTER_ROLE.

6. La capacidad de actualización de los contratos inteligentes

• Modelo de proxy: Para los contratos inteligentes de tipo EVM, se puede utilizar el modelo de proxy ERC-1967 maduro para lograr la capacidad de actualización.
• Control de permisos: la función de actualización debe ser llamada únicamente por una billetera multi-firma que posea el ROL_DE_ACTUALIZADOR.
• Proceso de gestión de cambios: De acuerdo con los requisitos regulatorios, antes de proponer cualquier actualización, se debe completar un estricto proceso de gestión de cambios, que incluye una auditoría de seguridad completa e independiente de terceros para los nuevos contratos inteligentes.

7. Registros de eventos en cadena para análisis e informes

Además de los eventos de transferencia (Transfer) y autorización (Approval) requeridos por el estándar ERC-20, el contrato debe definir y emitir eventos personalizados para todas las acciones de gestión y cambios de estado:

• Emisión/Quema ( Minted/Burned ) evento
• Pausa/Resume de contratos ( Evento
• Añadir/Quitar a la lista negra )BlacklistAdded/BlacklistRemoved( evento
• Adición/ eliminación de la lista blanca )WhitelistAdded/WhitelistRemoved( evento
• Dirección congelada/descongelada ) AddressFrozen/AddressUnfrozen ( evento
• Cambio de rol privilegiado ) RolConcedido/RolRevocado ( evento
• Actualización de contratos inteligentes ) Upgraded ( evento

![Guía técnica: Guía de implementación de contratos inteligentes para emisores de moneda estable en Hong Kong])https://img-cdn.gateio.im/webp-social/moments-eb42726ba8a93f614dc81b3458b37049.webp(

Parte Tres Seguridad Operativa y Gestión del Ciclo de Vida

) 1. Arquitectura de gestión de claves seguras

• Generación de claves: debe llevarse a cabo a través de una "ceremonia de claves" ###key ceremony( documentada en detalle, en un entorno de aire aislado físicamente y completamente separado de redes externas.
• Almacenamiento de claves: todos los roles de gestión deben ser controlados por una billetera de múltiples firmas. Las claves privadas utilizadas por los firmantes de estas billeteras múltiples deben almacenarse en HSM o en otra billetera de hardware segura. Para los roles más críticos, las claves correspondientes deben guardarse en un sistema aislado, físicamente separado de cualquier entorno en línea.
• Uso de claves: se debe implementar estrictamente una política de múltiples firmas. Para la firma de transacciones que involucren "claves privadas importantes", puede ser necesario que las partes relevantes estén presentes para operar.
• Copia de seguridad y recuperación: la copia de seguridad de las partes de la clave o de la frase mnemotécnica debe almacenarse en múltiples ubicaciones seguras y geográficamente dispersas dentro de Hong Kong ) o en lugares aprobados por el regulador (, y debe utilizar un embalaje a prueba de manipulaciones.

) 2. Proceso de implementación completo y monitoreo en tiempo de ejecución

Antes de la implementación formal, es necesario elaborar y aplicar estrictamente una "lista de verificación previa a la implementación":

• Pruebas completas: asegurar una cobertura de pruebas unitarias de más del 95%, una cobertura de código central del 100%, y garantizar la salida del informe de cobertura de pruebas unitarias.
• Auditoría independiente: completar al menos un informe de auditoría de seguridad independiente emitido por una o dos empresas de auditoría de buena reputación.
• Congelación de código: después de completar la auditoría, congelar el código hasta su lanzamiento, sin realizar ningún cambio en el código.
• Pruebas de regresión: realizar pruebas unitarias y pruebas de regresión antes del despliegue oficial.
• Aprobación de cumplimiento: obtener la aprobación formal del equipo de cumplimiento interno, confirmando que la lógica del contrato cumple con todos los requisitos regulatorios relevantes.
• Ejercicio de despliegue: preparar un script de despliegue detallado y realizar un ejercicio de despliegue completo en una red de pruebas que sea completamente consistente con el entorno de la red principal.
• Despliegue autorizado: la operación final de despliegue es realizada por una billetera autorizada.

Una vez completada la implementación, se deben tomar medidas de monitoreo adecuadas para implementar medidas de mitigación de manera oportuna sobre el uso de roles privilegiados y las amenazas emergentes.

• Monitoreo de actividades en la cadena: monitorear el uso de los roles de gestión y detectar a tiempo la ocurrencia de situaciones no autorizadas.
• Monitoreo de inteligencia de amenazas: se deben detectar a tiempo las nuevas amenazas y analizar la inteligencia de amenazas para poder implementar medidas de mitigación de manera oportuna.

3. Proporcionar soporte técnico para la continuidad del negocio y el plan de salida

Elaborar un plan de salida del negocio: el plan abarca diversas situaciones que podrían llevar a una terminación ordenada e incluye medidas de monitoreo para la ocurrencia real o potencial de estas situaciones.

Proceso de salida en la cadena:

• Se deben suspender los contratos inteligentes para detener todas las transferencias de moneda, con el fin de maximizar los beneficios de la liquidación de activos de reserva y minimizar el impacto en la estabilidad general del mercado.
• A través de la función de redención y la función de lista blanca, se ayuda a los titulares de moneda estable a presentar solicitudes de redención.