Guia de implementação de contratos inteligentes para emissores de moeda estável em Hong Kong

Primeira Parte Infraestrutura e Estratégias de Conformidade

1. Escolha do livro-razão distribuído subjacente

Guia de Implementação

• Preferir cadeias públicas maduras: recomenda-se priorizar o uso de cadeias de blocos públicas maduras e com alta segurança, como Ethereum e Arbitrum. Essas redes têm vantagens naturais devido à sua resiliência comprovada, vasta rede de nós de validação e supervisão pública contínua. O alto custo de ataques pode responder diretamente às preocupações regulatórias sobre a defesa contra ataques de 51% e a garantia da finalização das transações.

• Avaliação rigorosa de alternativas: se considerar a adoção de uma cadeia de consórcio ou outro tipo de livro-razão distribuído, deve-se realizar uma análise comparativa rigorosa e quantificável para provar que seus padrões de segurança não são inferiores, ou mesmo superiores, aos das principais cadeias públicas.

• Documento de avaliação de risco: O relatório de avaliação deve abranger de forma abrangente a capacidade de resistir a ataques comuns, o tipo de algoritmo de consenso, bem como os riscos relacionados a falhas de código, vulnerabilidades, exploração de vulnerabilidades e outras ameaças, e analisar detalhadamente como esses riscos podem impactar potencialmente a emissão, o resgate e a operação diária da moeda estável. Este documento é um documento chave para demonstrar a prudência na escolha tecnológica às autoridades regulatórias.

2. Padrão de token central e expansão de funções regulatórias

Guia de Implementação

• Padrão básico: utiliza o ERC-20 como padrão básico para garantir a homogeneidade dos tokens e a interoperabilidade em um ecossistema mais amplo.

• Extensão de funcionalidades: deve integrar os seguintes módulos funcionais para satisfazer os requisitos regulatórios:

  • Pausable: utilizado para implementar a funcionalidade de pausa e retoma global em todas as atividades da moeda, sendo esta a ferramenta central para lidar com eventos de segurança significativos.

  • Mintable: utilizado para implementar que o emissor licenciado deve cunhar novos tokens através de um processo controlado, garantindo que a emissão de tokens corresponda estritamente a ativos de reserva em moeda fiduciária.

  • Burnable: fornece a funcionalidade de queimar tokens. Na implementação específica, esta função será controlada por permissões rigorosas, em vez de permitir que usuários aleatórios queimem por conta própria.

  • Freezable: utilizado para pausar a funcionalidade de transferência de moedas de contas específicas ( em caso de transações suspeitas ).

  • Whitelist: utilizado para implementar medidas de segurança adicionais, permitindo apenas que endereços que passaram pela devida diligência e aprovação participem das operações principais (, como receber novos tokens emitidos ).

  • Lista negra: utilizada para implementar proibições de transações para endereços envolvidos em atividades ilegais (, como lavagem de dinheiro e fraude ), proibindo o envio/receção de moedas. A gestão da lista negra deve estar integrada com o sistema AML/CFT, monitorizando em tempo real transações suspeitas.

  • AccessControl: Esta é a base para a implementação de um sistema de gestão de permissões baseado em funções e de forma granular. Todas as funcionalidades de gestão devem passar por este módulo para controlo de permissões, a fim de satisfazer os requisitos de separação de funções.

3. Principais modos de conformidade: seleção de lista negra e lista branca

Guia de Implementação

• Modo de lista negra ( plano de recomendação padrão ):

  • Vantagens: possui maior utilidade, podendo interagir de forma fluida com o vasto ecossistema financeiro descentralizado (DeFi), proporcionando aos usuários uma barreira de entrada mais baixa e uma experiência mais suave.

  • Desvantagens: A conformidade depende fortemente de uma capacidade de análise de monitoramento off-chain robusta e em tempo real, para detectar e bloquear endereços ilegais de forma oportuna.

  • Modo de implementação: na função de transferência dos contratos inteligentes, adicionar uma verificação lógica para garantir que os endereços do remetente (from) e do destinatário (to) não estejam registrados na lista negra.

• Modo de lista branca

  • Vantagens: oferece o mais alto nível de controle AML/CFT, implementando a prevenção antecipada, em vez de remediação posterior.

  • Desvantagens: limita enormemente a universalidade e a taxa de adoção das moedas estáveis, trazendo grandes custos operacionais para a gestão da lista branca, o que pode dificultar que se torne um meio de troca amplamente aceito.

  • Modo de implementação: na função de transferência dos contratos inteligentes, adicionar verificações lógicas, exigindo que os endereços do remetente (from) e do destinatário (to) estejam ambos na lista branca. Recomenda-se desenvolver um sistema de backend Web dedicado para facilitar as operações.

Segunda Parte Contratos Inteligentes Implementação

1. Sistema de controle de acesso com design detalhado

Guia de Implementação

É necessário definir uma série de papéis claros e atribuí-los a diferentes entidades ou funcionários controlados por carteiras de múltiplas assinaturas, a fim de implementar a separação de funções e minimizar o risco de um único ponto de falha ou manipulação conivente. Cada papel deve ser limitado a funções específicas, todas as operações devem ter autorização de múltiplas assinaturas e garantir que nenhum funcionário individual detenha simultaneamente vários papéis de alto risco. Todas as operações devem ser registradas em log e sujeitas a auditoria anual por terceiros, com a atribuição de permissões supervisionada por um administrador ou conselho.

• MINTER_ROLE: responsável por lidar com a emissão da moeda estável (mint), incluindo a criação de unidades de moeda após receber um pedido de emissão válido, e garantindo que a emissão corresponda ao aumento correspondente do pool de ativos de reserva.

• BURNER_ROLE: responsável por lidar com a emissão da moeda estável (burn), incluindo a destruição da unidade de moeda após receber um pedido de resgate válido.

• PAUSER_ROLE: responsável por pausar (pause) a operação da moeda estável, como interromper temporariamente transferências, emissão ou resgate ao detectar eventos anormais (, como ameaças à segurança ).

• RESUME_ROLE: responsável por restaurar a operação da moeda estável (resume), como reativar transferências, emissão ou resgate após a resolução de um evento de pausa.

• FREEZER_ROLE: responsável por congelar (freeze) e descongelar (remove freeze) operações de carteiras ou moedas específicas, como congelar temporariamente ativos ao detectar atividades suspeitas (, como risco de lavagem de dinheiro ).

• WHITELISTER_ROLE: responsável pela gestão da lista branca (whitelist), incluindo adicionar ou remover endereços de carteira permitidos, por exemplo, restringir a emissão apenas a endereços na lista branca.

• BLACKLISTER_ROLE: responsável por gerenciar a emissão (blacklist) e remover a emissão (remove blacklist), por exemplo, colocando carteiras suspeitas na emissão para impedir transferências.

• UPGRADER_ROLE: Se um modelo atualizável for adotado, é responsável pela atualização (upgrade) dos contratos inteligentes, como atualizar o código do contrato para corrigir vulnerabilidades ou adicionar funcionalidades.

2. emissão ( moeda ) mecanismo

Guia de Implementação

Verificação prévia: a função deve verificar se o endereço de destino to está na lista negra ou em estado congelado antes de executar a emissão.

Processo de operação:

• Due diligence off-chain: O cliente conclui todos os processos necessários de identificação de cliente off-chain ( KYC ) e due diligence do cliente ( CDD ). Além disso, as regulamentações AML/CFT exigem que, para estabelecer uma relação comercial ou realizar transações ocasionais acima de um determinado limite (, como 8.000 dólares de Hong Kong ), o CDD deve ser executado.
• Recebimento de fundos: O cliente transfere fundos em moeda fiduciária equivalentes para a conta bancária designada pelo emissor.
• Verificação interna: o sistema interno do emissor confirma o recebimento de fundos e atualiza os registros contábeis dos ativos em reserva.
• Execução em cadeia: a equipe de operações cria e assina uma transação de múltiplas assinaturas, chamando a função de emissão de tokens dos contratos inteligentes, enviando a nova moeda estável para o endereço da carteira previamente registrado e verificado do cliente.

3. Redenção ( mecanismo de destruição )

Guia de Implementação

Preparação para o resgate: Os usuários precisam primeiro transferir a moeda que desejam resgatar para um endereço designado sob o controle do emissor.

Processo de operação:

• Pedido off-chain: O usuário submete um pedido de resgate off-chain através da plataforma do emissor. Antes de processar o pedido, o emissor deve realizar a devida diligência do cliente.
• Verificação do sistema: o sistema do emissor valida a solicitação de verificação e verifica se o usuário já completou a operação de transferência de moeda correspondente na cadeia.
• Pagamento em moeda fiduciária: o emissor transferirá o valor equivalente em moeda fiduciária para a conta bancária previamente registrada e verificada pelo usuário.
• Destruição em cadeia: Após a confirmação da transferência de moeda fiduciária, a carteira multi-assinatura com o papel BURNER_ROLE chama a função de destruição, destruindo a quantidade correspondente de tokens a partir do endereço especificado.

( 4. Implementar controlo de emergência: suspender e congelar

)# Guia de Implementação

Função de pausa: apenas pode ser chamada por uma carteira de múltiplas assinaturas que detém o PAUSER_ROLE, utilizada para interromper globalmente as funções do contrato. As condições de ativação incluem a detecção de eventos anómalos ###, como ataques de rede ou incompatibilidade de ativos de reserva ###, necessitando de aprovação do conselho ou da alta administração. A função de retomar é tratada por um RESUME_ROLE independente, para garantir a separação de deveres.

Função de congelamento: chamada pela carteira de múltiplas assinaturas que possui o papel FREEZER_ROLE, utilizada para limitar transferências de endereços específicos. As condições de ativação incluem atividades suspeitas (, como alertas de AML ou ordens judiciais ), que devem ser verificadas fora da cadeia antes da execução. O descongelamento é tratado pelo mesmo papel, mas requer uma verificação de auditoria adicional e a publicação de anúncios relevantes para evitar abusos.

( 5. Filtragem de endereços e mecanismo de lista negra

)# Guia de Implementação

• Implementação da função: implementar funções para adicionar e remover da lista negra, que só podem ser chamadas por uma carteira multi-assinatura que detenha o papel BLACKLISTER_ROLE.
• Limitações de transferência: endereços na lista negra estão proibidos de transferir/receptar moedas.
• Fluxo de operação: a ferramenta de análise emite um alerta, acionando uma revisão de conformidade interna, após a confirmação da equipe de conformidade, a adição ao blacklist é iniciada pela carteira multi-assinada do BLACKLISTER_ROLE.

6. A escalabilidade dos contratos inteligentes

Guia de Implementação

• Modelo de Proxy: Para contratos inteligentes do tipo EVM, pode-se utilizar o modelo de proxy ERC-1967 maduro para implementar a capacidade de atualização.
• Controle de permissões: a função de atualização deve ser chamada apenas por uma carteira multiassinada que possua o UPGRADER_ROLE.
• Processo de gestão de mudanças: de acordo com os requisitos regulamentares, deve ser concluído um rigoroso processo de gestão de mudanças antes de propor qualquer atualização, que inclua uma auditoria de segurança abrangente e independente de contratos inteligentes novos.

7. Registros de eventos on-chain para análise e relatório

Guia de Implementação

Além dos requisitos de transferência ###Transfer### e autorização (Approval) exigidos pelo padrão ERC-20, o contrato deve definir e emitir eventos personalizados para todas as ações de gerenciamento e mudanças de estado:

• Emissão/Queima(Minted/Burned)evento
• Pausar/Retomar ( Pausado/Retomar ) evento
• Adicionar/Remover da lista negra ( BlacklistAdded/BlacklistRemoved ) evento
• Adicionar/Remover da lista branca (WhitelistAdded/WhitelistRemoved) evento
• Congelamento de endereço/Descongelamento de endereço(AddressFrozen/AddressUnfrozen)evento
• Alteração de papel privilegiado ( RoleGranted/RoleRevoked ) evento
• Atualização de contratos inteligentes ( Upgraded ) evento

Terceira Parte Segurança Operacional e Gestão do Ciclo de Vida

( 1. Estrutura de gestão de chaves de segurança

)# Guia de Implementação

• Geração de chaves: deve ser realizada através de uma "cerimônia de chaves" documentada em detalhe ###key ceremony###, em um ambiente de espaço isolado fisicamente e completamente separado de redes externas.
• Armazenamento de chaves: Todos os papéis de gestão devem ser controlados por carteiras multi-assinatura. As chaves privadas utilizadas pelos signatários dessas carteiras multi-assinatura devem ser armazenadas em HSM ou em outras carteiras de hardware seguras. Para os papéis mais críticos, as chaves correspondentes devem ser mantidas em sistemas isolados, fisicamente separados de qualquer ambiente online.
• Uso de chaves: uma política de múltiplas assinaturas deve ser aplicada obrigatoriamente. Para a assinatura de transações que envolvem "chaves privadas importantes", pode ser necessário que as partes relevantes estejam presentes pessoalmente para a operação.
• Backup e Recuperação: O backup das partes da chave ou da frase de recuperação deve ser armazenado em múltiplos locais seguros e geograficamente dispersos dentro de Hong Kong ( ou em locais aprovados pela regulamentação ), e deve utilizar embalagens à prova de violação.

( 2. Processo de implantação completo e monitorização em tempo de execução

)# Guia de Implementação

Antes da implementação oficial, deve ser elaborada e rigorosamente executada uma "lista de verificação pré-implementação":

• Testes abrangentes: garantir uma cobertura de testes unitários superior a 95%, cobertura de código central de 100%, garantir a produção de relatórios de cobertura de testes unitários.
• Auditoria independente: concluir pelo menos um, de preferência dois relatórios de auditoria de segurança independentes emitidos por empresas de auditoria de boa reputação.
• Congelamento de código: após a conclusão da auditoria, o código será congelado até o lançamento, sem quaisquer alterações no código.
• Testes de regressão: Execute testes unitários e testes de regressão antes da implementação oficial.
• Aprovacao de conformidade: obter a aprovação formal da equipe de conformidade interna, confirmando que a lógica do contrato atende a todos os requisitos regulatórios relevantes.
• Exercício de implantação: preparar um script de implantação detalhado e testá-lo em uma rede de testes que seja totalmente consistente com o ambiente da mainnet.