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

Primera parte Infraestructura y estrategia de cumplimiento

1. Elección de la contabilidad distribuida de base

Guía de implementación

• Priorizar cadenas de bloques públicas maduras: se recomienda optar preferentemente por cadenas de bloques públicas maduras y de alta seguridad, como Ethereum y Arbitrum. Estas redes, gracias a su resistencia probada, su vasta red de nodos validadores y su supervisión pública continua, cuentan con ventajas naturales. Su alto costo de ataque puede responder directamente a las preocupaciones regulatorias sobre la defensa contra ataques del 51% y la garantía de la finalización de las transacciones.

• Evaluación rigurosa de alternativas: Si se considera la adopción de 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 convencionales.

• Documento de evaluación de riesgos: El informe de evaluación debe cubrir de manera integral la capacidad de 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 impactar potencialmente la emisión, redención y operación diaria de la moneda estable. Este documento es clave para demostrar a las autoridades regulatorias la prudencia en la elección de la tecnología.

2. Estándar de token central y expansión de funciones regulatorias

Guía de implementación

• Estándar básico: se utiliza ERC-20 como estándar básico para garantizar la homogeneidad de la moneda y la interoperabilidad en un ecosistema más amplio.

• Expansión de funciones: se deben integrar los siguientes módulos funcionales para cumplir con los requisitos regulatorios:

  • Pausable: utilizado para implementar la función de pausa y recuperación global de todas las actividades de la moneda, esta es una herramienta clave para hacer frente a eventos de seguridad importantes.

  • Mintable: se utiliza para que los emisores licenciados puedan 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 funcionalidad de quemar monedas. En la implementación específica, esta función estará sujeta a un control de permisos estricto, en lugar de permitir que cualquier usuario la queme por su cuenta.

  • Congelable: utilizado para pausar la función de transferencia de monedas de cuentas específicas ( en caso de transacciones sospechosas ).

  • Whitelist: se utiliza para implementar medidas de seguridad adicionales, permitiendo únicamente la participación en operaciones centrales (, como la recepción de nueva moneda emitida ), a través de direcciones que han pasado la debida diligencia y aprobación.

  • Lista negra: se utiliza para implementar una prohibición de transacciones en direcciones que involucren actividades ilegales ( como el 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 las transacciones sospechosas.

  • AccessControl: Esta es la base para implementar un sistema de gestión de permisos basado en roles y con un nivel de detalle. Todas las funciones de gestión deben pasar por este módulo para el control de permisos, a fin de cumplir con los requisitos de separación de funciones.

3. Principales modos de cumplimiento: selección de lista negra y lista blanca

Guía de implementación

• Modo de lista negra ( esquema recomendado por defecto ):

  • Ventajas: posee una mayor utilidad, capaz de 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 la capacidad de análisis de monitoreo fuera de la cadena, fuerte y en tiempo real, para detectar y bloquear direcciones ilegales de manera oportuna.

  • Método de implementación: en la función de transferencia de contratos inteligentes, agregar una verificación lógica para asegurar que la dirección del remitente (from) y la dirección del receptor (to) no estén registradas en la lista negra.

• modo de lista blanca

  • Ventajas: proporciona el más alto nivel de control AML/CFT, logrando la prevención previa, en lugar de la remediación posterior.

  • Desventajas: limita enormemente la universalidad y la tasa de adopción de la moneda estable, genera grandes costos operativos para la gestión de la lista blanca, lo que puede dificultar que se convierta en un medio de intercambio ampliamente aceptado.

  • Modo de implementación: en la función de transferencia de los contratos inteligentes, agregar una verificación lógica que requiera que las direcciones del remitente (from) y del destinatario (to) deben existir en la lista blanca. Se sugiere desarrollar un sistema de backend web dedicado para facilitar las operaciones.

Segunda parte Contratos inteligentes implementación

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

Guía de implementación

Es necesario definir una serie de roles claros y asignar estos roles a diferentes entidades o empleados controlados por una billetera multifirma, con el fin de lograr la separación de funciones y minimizar el riesgo de puntos únicos de falla o manipulación colusoria. Cada rol debe limitarse a funciones específicas, todas las operaciones requieren autorización multifirma 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 estar sujetas a una auditoría anual por parte de terceros, la asignación de permisos será supervisada por un administrador o una junta directiva.

• MINTER_ROLE: Responsable de manejar la emisión de moneda estable (mint), incluyendo la creación de unidades de tokens tras recibir una solicitud de emisión válida, y asegurando que la emisión coincida con el aumento correspondiente en la reserva de activos.

• BURNER_ROLE: Responsable de manejar la operación de quema de moneda estable (burn), que incluye la destrucción de unidades de moneda después de recibir una solicitud de redención válida.

• PAUSER_ROLE: Responsable de pausar (pause) la operación de la moneda estable, por ejemplo, detener temporalmente las transferencias, la emisión o el canje al detectar eventos anómalos ( como amenazas de seguridad ).

• RESUME_ROLE: Responsable de restaurar la operación de (resume) moneda estable, como reactivar transferencias, emisión o redención después de resolver el evento de pausa.

• FREEZER_ROLE: Responsable de congelar (freeze) y descongelar (remove freeze) operaciones de billeteras o monedas específicas, por ejemplo, congelar temporalmente activos al detectar actividades sospechosas ( como riesgos de lavado de dinero ).

• WHITELISTER_ROLE: responsable de gestionar la moneda estable (whitelist), incluyendo agregar o eliminar direcciones de billetera permitidas, por ejemplo, restringir la emisión de moneda únicamente a las direcciones de la lista blanca.

• BLACKLISTER_ROLE: responsable de gestionar la emisión (blacklist) y eliminar la emisión (remove blacklist), por ejemplo, incluir billeteras sospechosas en la emisión para evitar transferencias.

• UPGRADER_ROLE: Si se utiliza un modelo actualizable, se encarga de la emisión (upgrade) contratos inteligentes, por ejemplo, actualizar el código del contrato para corregir vulnerabilidades o agregar funciones.

2. emisión ( moneda ) mecanismo

Guía de implementación

Verificación previa: antes de ejecutar la emisión de moneda, se debe verificar si la dirección de destino to está en la lista negra o en estado congelado.

Proceso de operación:

• Diligencia debida fuera de la cadena: el cliente completa todos los procesos necesarios de identificación del cliente fuera de la cadena ( KYC ) y diligencia debida del cliente ( CDD ). Además, las regulaciones de AML/CFT requieren que, para establecer una relación comercial o realizar transacciones ocasionales que superen un umbral específico ( como 8,000 HKD ), se debe llevar a cabo CDD.
• Recepción de fondos: el cliente transferirá la cantidad equivalente de fondos en moneda fiduciaria a la cuenta bancaria designada por el emisor.
• Validació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.
• Ejecución en cadena: el equipo de operaciones crea y firma una transacción de múltiples firmas, llamando a la función de emisión de tokens de los contratos inteligentes, enviando la moneda estable recién emitida a la dirección de billetera registrada y verificada por el cliente.

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

Guía de implementación

Preparativos para el reembolso: el usuario primero necesita transferir los tokens que desea reembolsar a la dirección designada controlada por el emisor.

Proceso de operación:

• Solicitud fuera de la cadena: El usuario presenta una solicitud de rescate fuera de la cadena a través de la plataforma del emisor. Antes de procesar la solicitud, el emisor debe llevar a cabo la debida diligencia del cliente adecuada (CDD).
• 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 correspondiente operación de transferencia de monedas en la cadena.
• Pago en moneda fiduciaria: el emisor transferirá el equivalente en moneda fiduciaria a la cuenta bancaria registrada y verificada previamente por el usuario.
• Quema en la cadena: después de confirmar que la transferencia de moneda fiduciaria fue exitosa, la billetera multisig que tiene el ROL_DE_QUEMA llama a la función de quema para destruir la cantidad correspondiente de monedas desde la dirección especificada.

4. Implementar control de emergencia: suspender y congelar

Guía de implementación

Función de pausa: solo puede ser llamada por una billetera multifirma que posea el PAUSER_ROLE, utilizada para la interrupción global de funciones de contratos inteligentes. Las condiciones de activación incluyen la detección de eventos anómalos ( como ataques de red o desajuste de activos de reserva ), que requieren 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 responsabilidades.

Función de congelación: llamada por una billetera multisig que tiene el rol FREEZER_ROLE, utilizada para limitar transferencias a direcciones específicas. Las condiciones de activación incluyen actividades sospechosas ( como alertas de AML o órdenes judiciales ), que deben ser verificadas fuera de la cadena antes de su ejecución. La descongelación es manejada por el mismo rol, pero requiere una verificación adicional de auditoría, y se debe emitir un anuncio relacionado para prevenir abusos.

5. Filtrado de direcciones y mecanismo de lista negra

Guía de implementación

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

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

Guía de implementación

• Modelo de proxy: Para los contratos inteligentes 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 cartera multisig que posea el ROL_DE_ACTUALIZACIÓN.
• 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 incluya una auditoría de seguridad exhaustiva e independiente de los nuevos contratos inteligentes.

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

Guía de implementación

Además de las transferencias requeridas por el estándar ERC-20 (Transfer) y los eventos de autorización (Approval), 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
• Contratos inteligentes pausados/reanudados ( Paused/Resume ) 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 ( DirecciónCongelada/DirecciónDescongelada ) evento
• Cambio de rol privilegiado ( RolConcedido/RolRevocado ) evento
• Actualización de contratos inteligentes ( Upgraded ) evento

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

1. Arquitectura de gestión de claves de seguridad

Guía de implementación

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

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

Guía de implementación

Antes de la implementación oficial, se debe elaborar y aplicar estrictamente una "lista de verificación previa a la implementación":

• Pruebas completas: asegurar una cobertura de pruebas unitarias del 95% o más, una cobertura de código central del 100%, y garantizar la salida de un informe de cobertura de pruebas unitarias.
• Auditoría independiente: presentar al menos un informe de auditoría de seguridad independiente emitido por una empresa de auditoría de buena reputación, preferiblemente dos.
• Congelación de código: Después de completar la auditoría, se congela el código hasta el lanzamiento, sin realizar ningún cambio en el código.
• Pruebas de regresión: Antes de la implementación oficial, ejecute pruebas unitarias y realice pruebas de regresión.
• 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 guion de despliegue detallado y realizarlo en una red de pruebas que sea completamente consistente con el entorno de la red principal.