Guia de implementação de contratos inteligentes para emissores de moeda estável em Hong Kong
Primeira Parte Infraestrutura e Estratégia de Conformidade
1. Escolha do livro-razão distribuído subjacente
Guia de Implementação
Priorizar blockchains públicas maduras: recomenda-se priorizar o uso de blockchains públicas maduras e altamente seguras, como Ethereum e Arbitrum.
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 até superiores, aos das principais cadeias públicas.
Documento de Avaliação de Risco: O relatório de avaliação deve cobrir de forma abrangente a capacidade de resistir a ataques comuns, o tipo de algoritmo de consenso, bem como os riscos relacionados a defeitos de código, vulnerabilidades, explorações e outras ameaças, e analisar detalhadamente como esses riscos podem impactar potencialmente a emissão, resgate e operação diária da moeda estável.
2. Padrão de token central e expansão de funções de regulação
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.
Expansão de funcionalidades: deve integrar os seguintes módulos de funcionalidade para atender aos requisitos regulatórios:
Pausable: utilizado para implementar a funcionalidade de pausa e restauração global de todas as atividades da moeda, que é uma ferramenta central para lidar com eventos de segurança significativos.
Mintable: utilizado para permitir que emissores licenciados mintem novos tokens através de um processo controlado, assegurando que a quantidade de tokens emitidos corresponda estritamente a ativos de reserva fiduciária adequados.
Burnable: fornece a funcionalidade de destruir tokens. Na implementação específica, essa funcionalidade será controlada por permissões rigorosas, em vez de permitir que qualquer usuário a destrua por conta própria.
Freezable: utilizado para pausar a funcionalidade de transferência de moeda de contas específicas ( em caso de transações suspeitas ).
Whitelist: utilizado para implementar medidas de segurança adicionais, permitindo apenas que endereços aprovados após a devida diligência participem das operações principais (, como receber novos tokens emitidos ).
Lista negra: usada para implementar uma proibição de transações para endereços envolvidos em atividades ilegais (, como lavagem de dinheiro, fraude ), proibindo-os de enviar/receber moedas. A gestão da lista negra deve interagir 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 detalhado. Todas as funcionalidades de gestão devem passar por este módulo para o controle de permissões, a fim de satisfazer os requisitos de separação de funções.
3. Principais modos de conformidade: escolha de lista negra e lista branca
Guia de Implementação
Modo de lista negra ( esquema recomendado por padrão ):
Vantagens: possui maior utilidade, podendo interoperar perfeitamente com o vasto ecossistema de finanças descentralizadas (DeFi), oferecendo aos usuários barreiras de entrada mais baixas e uma experiência mais fluida.
Desvantagens: a conformidade depende fortemente de uma capacidade robusta de análise de monitoramento off-chain em tempo real, para detectar e bloquear endereços ilegais a tempo.
Modo de implementação: Na função de transferência dos contratos inteligentes, adicione 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: fornece o mais alto nível de controle AML/CFT, implementando a prevenção antes do fato, em vez de remediação posterior.
Desvantagens: limita fortemente a versatilidade e a taxa de adoção das moedas estáveis, trazendo enormes custos operacionais para a gestão da lista branca, o que pode dificultar a sua aceitação como um meio de troca amplamente utilizado.
Método de implementação: na função de transferência do contrato inteligente, adicionar uma verificação lógica, exigindo que o endereço do remetente (from) e o endereço do destinatário (to) estejam ambos presentes na lista branca. Recomenda-se desenvolver um sistema de backend Web dedicado para operações, aumentando a conveniência das operações.
Segunda Parte Implementação de Contratos Inteligentes
1. Sistema de controle de acesso projetado de forma detalhada
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 multiassinatura, a fim de implementar a separação de funções e minimizar o risco de pontos únicos de falha ou manipulação conivente. Cada papel deve ser limitado a funções específicas, todas as operações devem ter autorização multiassinatura e garantir que nenhum funcionário mantenha simultaneamente múltiplos papéis de alto risco. Todas as operações devem ser registradas em log e sujeitas a auditoria de terceiros anual, com a alocaçã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 token 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 de moeda estável (burn), incluindo a destruição de unidades de token após receber um pedido de resgate válido.
PAUSER_ROLE: responsável por pausar (pause) a operação da moeda estável, como parar temporariamente transferências, emissão ou resgate ao detectar eventos anormais (, como ameaças de segurança ).
RESUME_ROLE: responsável pela recuperação de (resume) das operações da moeda estável, como reativar transferências, emissão ou resgate após a resolução do evento de suspensão.
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 por gerir a emissão (whitelist), incluindo adicionar ou remover endereços de carteira permitidos, como limitar a emissão de moeda apenas a endereços da lista branca.
BLACKLISTER_ROLE: responsável por gerenciar a lista negra (blacklist) e remover a lista negra (remove blacklist), por exemplo, listar carteiras suspeitas na lista negra para impedir transferências.
UPGRADER_ROLE: Se o modelo for escalável, é responsável por atualizar (upgrade) contratos inteligentes, como atualizar o código do contrato para corrigir falhas 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.
Fluxo de operação:
Due diligence off-chain: O cliente deve concluir todos os procedimentos de identificação do 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 que excedam um determinado limite (, como 8.000 HKD ), o CDD deve ser executado.
Recepção de fundos: O cliente transferirá o valor equivalente em moeda fiduciária para a conta bancária designada pelo emissor.
Validação interna: o sistema interno do emissor confirma a receção de fundos e atualiza, em conformidade, os registos 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 do cliente previamente registrado e verificado.
3. Resgate ( mecanismo de destruição )
Guia de Implementação
Preparação para resgate: os usuários precisam primeiro transferir a moeda que desejam resgatar para o endereço designado controlado pelo emissor.
Fluxo de operação:
Pedido off-chain: O usuário apresenta 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 (CDD).
Verificação do sistema: O sistema do emissor valida a solicitação de verificação e verifica se o usuário concluiu 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.
Queima na blockchain: Após confirmar o sucesso da transferência de moeda fiduciária, a carteira de múltiplas assinaturas que possui o papel BURNER_ROLE chama a função de queima, destruindo a quantidade correspondente de moeda do endereço especificado.
4. Implementar controle de emergência: suspender e congelar
Guia de Implementação
Função de pausa: chamada apenas pela carteira multifirma que possui o PAUSER_ROLE, usada para interromper globalmente a função do contrato. As condições de ativação incluem a detecção de um evento anômalo (, como um ataque à rede ou incompatibilidade de ativos de reserva ), necessitando de aprovação do conselho ou da alta administração. A função de recuperação é gerida por um RESUME_ROLE independente, para garantir a separação de funções.
Função de congelamento: chamada por uma carteira multisig que possui o FREEZER_ROLE, destinada a limitar transferências para endereços específicos. As condições de ativação incluem atividades suspeitas (, como alertas de AML ou ordens judiciais ), que precisam ser verificadas off-chain antes da execução. O descongelamento é tratado pelo mesmo papel, mas requer verificação de auditoria adicional, publicação de anúncios relevantes, para prevenir abusos.
5. Filtragem de endereços e mecanismo de lista negra
Guia de Implementação
Implementação da função: implementar a função de adicionar e remover da lista negra, que só pode ser chamada pela carteira multi-assinatura que detém o BLACKLISTER_ROLE.
Limite de transferência: é proibido transferir/receber moedas de endereços na lista negra.
Processo de operação: a ferramenta de análise emite um alerta, aciona uma revisão de conformidade interna, após a confirmação da equipe de conformidade, a transação de adição à lista negra é iniciada pela carteira multi-assinatura do BLACKLISTER_ROLE.
6. A capacidade de atualização 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 multisig que possua o UPGRADER_ROLE.
Processo de gestão de alterações: de acordo com os requisitos regulamentares, antes de propor qualquer atualização, deve ser concluído um rigoroso processo de gestão de alterações, que inclui uma auditoria de segurança abrangente e independente de terceiros dos novos contratos inteligentes.
7. Registros de eventos on-chain para análise e relatórios
Guia de Implementação
Além dos requisitos de transferência (Transfer) e autorização (Approval) do padrão ERC-20, o contrato deve definir e emitir eventos personalizados para todas as ações de gestão e alterações de estado:
Adicionar/Remover da lista negra ( BlacklistAdded/BlacklistRemoved ) evento
Adição/Remoção de lista branca (WhitelistAdded/WhitelistRemoved) evento
Congelamento/Descongelamento de Endereço(AddressFrozen/AddressUnfrozen)evento
Alteração de papel de privilégio ( RoleGranted/RoleRevoked ) evento
Atualização de contratos (Upgraded) evento
Terceira Parte Segurança Operacional e Gestão do Ciclo de Vida
1. Arquitetura de gestão de chaves de segurança
Guia de Implementação
Geração de chave: deve ser realizada através de uma "cerimônia de chave" documentada em detalhe (key ceremony), em um ambiente fisicamente seguro e completamente isolado da rede externa.
Armazenamento de chaves: todos os papéis de gestão devem ser controlados por carteiras multi-assinatura. As chaves privadas usadas pelos signatários dessas carteiras multi-assinatura devem ser armazenadas em HSM ou 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: deve ser aplicada uma política de múltiplas assinaturas. Para a assinatura de transações que envolvem "chaves privadas importantes", pode ser necessário que as partes relevantes estejam presentes para operar.
Backup e recuperação: o backup de fragmentos da chave ou da frase mnemônica deve ser armazenado em múltiplos locais seguros e geograficamente dispersos dentro de Hong Kong ( ou em locais aprovados pela regulamentação ), utilizando embalagens à prova de violação.
2. Processo de implementação completo e monitorização em tempo de execução
Guia de Implementação
Antes da implementação oficial, deve-se elaborar e executar rigorosamente uma "lista de verificação pré-implementação":
Teste abrangente: 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: completar 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 mais alterações no código.
Teste de regressão: antes da implementação oficial, execute testes unitários e realize testes de regressão.
Aprovação 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 implementação: preparar um script de implementação detalhado e realizar um exercício completo de implementação em uma rede de teste que seja completamente idêntica ao ambiente da mainnet.
Implantação autorizada: a operação final de implantação é executada pela carteira autorizada.
Após a conclusão da implementação, devem ser tomadas medidas de monitorização apropriadas para implementar medidas de mitigação em tempo hábil sobre o uso de funções privilegiadas e novas ameaças que surgem:
Monitorização de atividades na cadeia: Monitorizar o papel de gestão
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
12 gostos
Recompensa
12
4
Partilhar
Comentar
0/400
LiquidityNinja
· 12h atrás
Correndo tão rápido, o que você quer fazer? Hksb, espera mais um pouco.
Ver originalResponder0
SurvivorshipBias
· 12h atrás
Mais uma vez, o Ethereum skr não teve muitas mudanças.
Ver originalResponder0
AlwaysMissingTops
· 12h atrás
ETH é o melhor do mundo
Ver originalResponder0
Ser_This_Is_A_Casino
· 12h atrás
L2 parece ser ainda mais seguro do que a Rede principal
Guia de implementação de contratos inteligentes para emissores de moeda estável em Hong Kong: Estrutura, Conformidade e Segurança
Guia de implementação de contratos inteligentes para emissores de moeda estável em Hong Kong
Primeira Parte Infraestrutura e Estratégia de Conformidade
1. Escolha do livro-razão distribuído subjacente
Guia de Implementação
2. Padrão de token central e expansão de funções de regulação
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.
Expansão de funcionalidades: deve integrar os seguintes módulos de funcionalidade para atender aos requisitos regulatórios:
Pausable: utilizado para implementar a funcionalidade de pausa e restauração global de todas as atividades da moeda, que é uma ferramenta central para lidar com eventos de segurança significativos.
Mintable: utilizado para permitir que emissores licenciados mintem novos tokens através de um processo controlado, assegurando que a quantidade de tokens emitidos corresponda estritamente a ativos de reserva fiduciária adequados.
Burnable: fornece a funcionalidade de destruir tokens. Na implementação específica, essa funcionalidade será controlada por permissões rigorosas, em vez de permitir que qualquer usuário a destrua por conta própria.
Freezable: utilizado para pausar a funcionalidade de transferência de moeda de contas específicas ( em caso de transações suspeitas ).
Whitelist: utilizado para implementar medidas de segurança adicionais, permitindo apenas que endereços aprovados após a devida diligência participem das operações principais (, como receber novos tokens emitidos ).
Lista negra: usada para implementar uma proibição de transações para endereços envolvidos em atividades ilegais (, como lavagem de dinheiro, fraude ), proibindo-os de enviar/receber moedas. A gestão da lista negra deve interagir 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 detalhado. Todas as funcionalidades de gestão devem passar por este módulo para o controle de permissões, a fim de satisfazer os requisitos de separação de funções.
3. Principais modos de conformidade: escolha de lista negra e lista branca
Guia de Implementação
Modo de lista negra ( esquema recomendado por padrão ):
Vantagens: possui maior utilidade, podendo interoperar perfeitamente com o vasto ecossistema de finanças descentralizadas (DeFi), oferecendo aos usuários barreiras de entrada mais baixas e uma experiência mais fluida.
Desvantagens: a conformidade depende fortemente de uma capacidade robusta de análise de monitoramento off-chain em tempo real, para detectar e bloquear endereços ilegais a tempo.
Modo de implementação: Na função de transferência dos contratos inteligentes, adicione 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: fornece o mais alto nível de controle AML/CFT, implementando a prevenção antes do fato, em vez de remediação posterior.
Desvantagens: limita fortemente a versatilidade e a taxa de adoção das moedas estáveis, trazendo enormes custos operacionais para a gestão da lista branca, o que pode dificultar a sua aceitação como um meio de troca amplamente utilizado.
Método de implementação: na função de transferência do contrato inteligente, adicionar uma verificação lógica, exigindo que o endereço do remetente (from) e o endereço do destinatário (to) estejam ambos presentes na lista branca. Recomenda-se desenvolver um sistema de backend Web dedicado para operações, aumentando a conveniência das operações.
Segunda Parte Implementação de Contratos Inteligentes
1. Sistema de controle de acesso projetado de forma detalhada
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 multiassinatura, a fim de implementar a separação de funções e minimizar o risco de pontos únicos de falha ou manipulação conivente. Cada papel deve ser limitado a funções específicas, todas as operações devem ter autorização multiassinatura e garantir que nenhum funcionário mantenha simultaneamente múltiplos papéis de alto risco. Todas as operações devem ser registradas em log e sujeitas a auditoria de terceiros anual, com a alocaçã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 token 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 de moeda estável (burn), incluindo a destruição de unidades de token após receber um pedido de resgate válido.
PAUSER_ROLE: responsável por pausar (pause) a operação da moeda estável, como parar temporariamente transferências, emissão ou resgate ao detectar eventos anormais (, como ameaças de segurança ).
RESUME_ROLE: responsável pela recuperação de (resume) das operações da moeda estável, como reativar transferências, emissão ou resgate após a resolução do evento de suspensão.
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 por gerir a emissão (whitelist), incluindo adicionar ou remover endereços de carteira permitidos, como limitar a emissão de moeda apenas a endereços da lista branca.
BLACKLISTER_ROLE: responsável por gerenciar a lista negra (blacklist) e remover a lista negra (remove blacklist), por exemplo, listar carteiras suspeitas na lista negra para impedir transferências.
UPGRADER_ROLE: Se o modelo for escalável, é responsável por atualizar (upgrade) contratos inteligentes, como atualizar o código do contrato para corrigir falhas 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.
Fluxo de operação:
3. Resgate ( mecanismo de destruição )
Guia de Implementação
Preparação para resgate: os usuários precisam primeiro transferir a moeda que desejam resgatar para o endereço designado controlado pelo emissor.
Fluxo de operação:
4. Implementar controle de emergência: suspender e congelar
Guia de Implementação
Função de pausa: chamada apenas pela carteira multifirma que possui o PAUSER_ROLE, usada para interromper globalmente a função do contrato. As condições de ativação incluem a detecção de um evento anômalo (, como um ataque à rede ou incompatibilidade de ativos de reserva ), necessitando de aprovação do conselho ou da alta administração. A função de recuperação é gerida por um RESUME_ROLE independente, para garantir a separação de funções.
Função de congelamento: chamada por uma carteira multisig que possui o FREEZER_ROLE, destinada a limitar transferências para endereços específicos. As condições de ativação incluem atividades suspeitas (, como alertas de AML ou ordens judiciais ), que precisam ser verificadas off-chain antes da execução. O descongelamento é tratado pelo mesmo papel, mas requer verificação de auditoria adicional, publicação de anúncios relevantes, para prevenir abusos.
5. Filtragem de endereços e mecanismo de lista negra
Guia de Implementação
6. A capacidade de atualização dos contratos inteligentes
Guia de Implementação
7. Registros de eventos on-chain para análise e relatórios
Guia de Implementação
Além dos requisitos de transferência (Transfer) e autorização (Approval) do padrão ERC-20, o contrato deve definir e emitir eventos personalizados para todas as ações de gestão e alterações de estado:
Terceira Parte Segurança Operacional e Gestão do Ciclo de Vida
1. Arquitetura de gestão de chaves de segurança
Guia de Implementação
2. Processo de implementação completo e monitorização em tempo de execução
Guia de Implementação
Antes da implementação oficial, deve-se elaborar e executar rigorosamente uma "lista de verificação pré-implementação":
Após a conclusão da implementação, devem ser tomadas medidas de monitorização apropriadas para implementar medidas de mitigação em tempo hábil sobre o uso de funções privilegiadas e novas ameaças que surgem: