Guia de implementação de contratos inteligentes para emissores de moeda estável de Hong Kong
Com a aprovação oficial do "Regulamento das Moedas Estáveis", a Autoridade Monetária de Hong Kong publicou em 26 de maio de 2025 o "Guião de Supervisão para Emissores de Moedas Estáveis Licenciados (Rascunho)", com o objetivo de garantir a operação estável, segura e em conformidade do ecossistema local de moedas estáveis. Este guiã detalha os requisitos regulatórios e os padrões operacionais que os emissores de moedas estáveis licenciados devem cumprir continuamente.
Recentemente, cada vez mais instituições têm consultado a equipe de segurança sobre a questão da implementação em conformidade dos contratos inteligentes. Para ajudar os emissores a entenderem e implementarem melhor um sistema de contratos inteligentes em conformidade, publicamos este guia de implementação, a fim de fornecer um caminho técnico claro e recomendações práticas, apoiando o desenvolvimento saudável do ecossistema de moeda estável em Hong Kong.
Primeira Parte Infraestrutura e Estratégia de Conformidade
Esta parte visa estabelecer a base da arquitetura de alto nível para o sistema de moeda estável, cujas decisões de arquitetura são totalmente impulsionadas pelos requisitos fundamentais do quadro da Autoridade Monetária de Hong Kong. As escolhas feitas aqui determinarão todo o caminho de implementação, garantindo que a conformidade esteja profundamente integrada na pilha tecnológica desde o início do design.
1. Escolha do livro-razão distribuído subjacente
instrução regulatória
Os licenciados devem avaliar a robustez da tecnologia de livro-razão distribuído subjacente que utilizam (DLT). Esta avaliação abrange a infraestrutura de segurança, a capacidade de resistir a ataques comuns (como o ataque de 51%), a garantia de finalização das transações e a fiabilidade do algoritmo de consenso.
Interpretação Técnica
Esta não é uma simples escolha de preferência técnica, mas uma tarefa central de conformidade. A escolha da blockchain subjacente deve passar por uma devida diligência formal, e todo o processo de avaliação deve ser devidamente documentado para fornecer justificativa adequada durante a revisão regulatória. O processo de escolha do livro-razão subjacente estabelece na verdade o tom para a segurança e estabilidade de todo o sistema de moeda estável.
A ênfase do Banco da China em Hong Kong na robustez do livro-razão está, na verdade, a aconselhar os emissores a evitar a adoção de blockchains emergentes que não foram validadas pelo mercado, que têm um nível de centralização excessivo ou cuja segurança é questionável. A responsabilidade de provar sua segurança e estabilidade recai completamente sobre os emissores. Se os emissores escolherem uma cadeia cuja segurança ainda não foi amplamente verificada, deverão projetar e implementar medidas de controle compensatórias adicionais.
Guia de Implementação
Priorizar blockchains públicos maduros: recomenda-se optar prioritariamente por blockchains públicos maduros e altamente seguros, 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. Seu elevado custo de ataque (segurança econômica) pode responder diretamente às preocupações regulatórias sobre a resistência a ataques de 51% e a garantia da finalização das transações.
Avaliação rigorosa de alternativas: ao considerar a adoção de uma blockchain de consórcio ou outro tipo de livro-razão distribuído, deve ser realizada uma análise comparativa rigorosa e quantificável, como auditoria de segurança, para provar que seus padrões de segurança não são inferiores, ou até superiores, aos das blockchains públicas mainstream.
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 algoritmos de consenso, bem como os riscos associados a falhas de código, vulnerabilidades, explorações 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 da tecnologia às entidades reguladoras.
2. Padrões de tokens principais e expansão de funções regulatórias
diretivas de supervisão
Os documentos regulatórios não especificaram um padrão de moeda específico (como ERC-20). No entanto, os documentos exigem a implementação de uma série de funções de gestão essenciais, incluindo emissão (mint), destruição (burn), atualização (upgrade), pausa (pause), retomar (resume), congelar (freeze), lista negra (blacklist), lista branca (whitelist) e outras operações.
Interpretação Técnica
A Autoridade Monetária de Hong Kong definiu, na verdade, um padrão de "moeda regulamentada melhorada" que possui funcionalidades que vão muito além do padrão ERC-20. Este padrão não apenas exige a presença de funções básicas de circulação de moeda, mas também enfatiza a segurança operacional, a controlabilidade de permissões e a rastreabilidade de riscos. Para maximizar a segurança enquanto se atende aos requisitos de conformidade, o caminho de desenvolvimento mais eficiente e seguro é utilizar uma biblioteca padrão amplamente auditada e reconhecida pela comunidade (como OpenZeppelin) e, a partir daí, realizar a expansão de funcionalidades.
Guia de Implementação
Padrão base: utiliza ERC-20 como padrão base para garantir a homogeneidade dos tokens e a interoperabilidade em um ecossistema mais amplo.
Expansão de funcionalidades: devem ser integrados os seguintes módulos de funcionalidade para cumprir os requisitos regulatórios:
Pausable：utilizado para implementar a funcionalidade de pausa e recuperação global de todas as atividades de moeda, que é uma ferramenta central para lidar com eventos de segurança significativos.
Mintable: utilizado para permitir que emissores licenciados criem novos tokens através de um processo controlado, garantindo que a quantidade de tokens emitidos corresponda estritamente a ativos de reserva em moeda fiduciária.
Burnable: fornece a funcionalidade de destruir moeda. Na implementação específica, esta funcionalidade será controlada por permissões rigorosas, em vez de permitir que qualquer usuário a destrua por conta própria.
Freezable: utilizado para suspender a funcionalidade de transferência de moedas de contas específicas (como em transações suspeitas).
Whitelist: usado 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 novas moedas emitidas).
Lista negra: utilizada para implementar proibições de transação em endereços envolvidos em atividades ilegais (como lavagem de dinheiro, fraude), proibindo-os de enviar/receber moedas. A gestão da lista negra deve ser integrada com o sistema AML/CFT, monitorando transações suspeitas em tempo real.
AccessControl: esta é a base para implementar um sistema de gestão de permissões baseado em funções e detalhado. Todas as funções de gestão devem passar por este módulo para controle de permissões, a fim de atender aos requisitos de separação de funções.
3. Principais modos de conformidade: escolha de listas negras e listas brancas
diretiva regulatória
O documento de consulta sobre monitorização contínua, luta contra a lavagem de dinheiro/combate ao financiamento do terrorismo ( AML/CFT ) propôs várias medidas, incluindo "colocar em lista negra endereços de carteira identificados como sancionados ou relacionados a atividades ilegais", ou adotar um "sistema de lista branca para endereços de carteira de detentores de moeda estável, ou um modelo de circuito fechado".
Interpretação técnica
Este é o ponto de decisão mais crítico em toda a arquitetura do sistema, que determina diretamente a abertura, a utilidade e a complexidade das operações de conformidade da moeda estável.
Modo de lista negra: um modo "default aberto". Todos os endereços podem transacionar livremente por padrão, apenas aqueles que são explicitamente identificados e adicionados à lista negra na blockchain serão restringidos.
Modo de lista branca: um modo de "fechado por padrão". Qualquer endereço, a menos que tenha passado pela devida diligência e aprovação explícitas do emissor, e seja adicionado à lista branca na cadeia, não pode possuir ou receber moedas.
Embora o modo de lista branca ofereça capacidades de controle de AML (anti-lavagem de dinheiro), para uma moeda estável destinada a ser amplamente utilizada, um regime estrito de lista branca significa que a moeda estável só pode circular entre participantes previamente verificados, o que a torna mais parecida com um sistema bancário fechado, em vez de uma moeda digital flexível.
Portanto, o modelo de lista negra, que também é claramente mencionado pela regulamentação, combinado com as poderosas ferramentas de análise off-chain exigidas pela regulamentação, constitui uma solução mais equilibrada. Ela atende aos requisitos regulatórios e, ao mesmo tempo, preserva a utilidade dos ativos.
No design, o sistema pode ser construído como escalável, ou implementar simultaneamente dois modos, de forma a permitir uma transição suave ou mudança para o modo de lista branca no futuro, caso haja um aperto na regulamentação ou alterações no modelo de negócios.
Guia de Implementação
Modo de lista negra (opção recomendada por padrão):
Vantagens: apresenta uma maior utilidade, podendo interagir de forma fluida com o vasto ecossistema de finanças descentralizadas (DeFi), oferecendo aos usuários uma barreira de entrada mais baixa e uma experiência mais suave.
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 de forma oportuna.
Modo de implementação: na função de transferência dos contratos inteligentes, adicionar verificações lógicas para garantir que o endereço do remetente (from) e o endereço 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 antes da ocorrência, em vez de remediação posterior.
Desvantagens: limita bastante a utilidade e a taxa de adoção da moeda estável, trazendo enormes custos operacionais para a gestão da lista de permissões, o que pode dificultar que se torne um meio de troca amplamente aceito.
Método de implementação: na função de transferência do contrato inteligente, adicione uma verificação lógica que exija que os endereços do remetente (from) e do destinatário (to) estejam ambos presentes na lista branca. Recomenda-se desenvolver um sistema de backend web dedicado para usuários para facilitar as operações.
Segunda Parte Contratos Inteligentes
Esta parte fornece um detalhado plano para as funcionalidades principais dos contratos inteligentes, convertendo requisitos regulatórios complexos em lógica de nível de código específica, padrões de segurança e protocolos operacionais.
1. Sistema de controle de acesso com design refinado
instrução de supervisão
O design de operações de alto risco deve "prevenir que qualquer parte única possa executar unilateralmente operações relacionadas (por exemplo, através de protocolos de múltiplas assinaturas)". As responsabilidades de diferentes operações devem ser devidamente isoladas.
Interpretação Técnica
Isto significa que um sistema de controle de acesso robusto e baseado em papéis (RBAC) é obrigatório. Qualquer forma de "proprietário" ou "administrador" de chave privada única é considerada não conforme.
Guia de Implementação
Devem ser definidos uma série de papéis claros e atribuídos a diferentes entidades ou funcionários controlados por carteiras multi-assinatura, para alcançar 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 multi-assinada, e garantir que nenhum funcionário tenha simultaneamente múltiplos papéis de alto risco. Todas as operações devem ser registadas em log e sujeitas a auditoria de terceiros anual, a atribuição de permissões deve ser supervisionada por um administrador ou conselho.
MINTER_ROLE: responsável por lidar com a emissão de moeda estável (mint), incluindo a criação de unidades de token após receber um pedido de emissão válido, e garantir que a emissão corresponda ao aumento correspondente do pool de ativos de reserva.
BURNER_ROLE: responsável por lidar com a destruição da moeda estável (burn) operação, incluindo a destruição de unidades de moeda após receber uma solicitação de resgate válida.
PAUSER_ROLE: responsável por pausar (pause) a operação da moeda estável, como interromper temporariamente transferências, emissão ou resgates quando um evento anômalo (como uma ameaça à segurança) for detectado.
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 eventos 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 gerenciar a lista branca (whitelist), incluindo adicionar ou remover endereços de carteira permitidos, como restringir a emissão de moeda apenas a endereços na lista branca.
BLACKLISTER_ROLE: responsável por gerenciar a lista negra (blacklist) e remover a lista negra (remove blacklist), como colocar carteiras suspeitas na lista negra para impedir transferências.
UPGRADER_ROLE: Se um modelo atualizável for adotado, é responsável pela atualização (upgrade) contratos inteligentes, por exemplo, atualizar o código do contrato para corrigir vulnerabilidades ou adicionar funcionalidades.
Tabela 1: Matriz de Controle de Acesso Baseada em Funções ( Matriz RBAC )
A tabela abaixo fornece uma norma clara e intuitiva para uso por desenvolvedores e auditores, mapeando claramente cada operação privilegiada para seu papel e tipo de controle necessários.
| Ação | Papel Necessário | Tipo de Controle |
|------|----------|----------|
| moeda | MINTER_ROLE | múltipla assinatura |
| destruição | BURNER_ROLE | multiassinatura |
| Pausar | PAUSER_ROLE | Múltiplas assinaturas |
| Recuperar | RESUME_ROLE | Multiassinatura |
| Congelado | FREEZER_ROLE | Múltipla assinatura |
| descongelar | FREEZER_ROLE | múltiplas assinaturas |
| Adicionar à lista branca | WHITELISTER_ROLE | Multisig |
| Remover da lista branca | WHITELISTER_ROLE | Multi-assinatura |
| Adicionar à lista negra |
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
12 Curtidas
Recompensa
12
5
Repostar
Compartilhar
Comentário
0/400
SighingCashier
· 08-10 15:32
A regulamentação chegou! Só em Hong Kong é que se pode entender isso.
Ver originalResponder0
NotGonnaMakeIt
· 08-10 01:51
O dólar de Hong Kong já tem moeda estável? Para ser honesto, essa notícia é muito intensa.
Ver originalResponder0
Deconstructionist
· 08-10 01:51
Boa regulamentação traz informação favorável.
Ver originalResponder0
HashBard
· 08-10 01:49
ngmi lol... hong kong está apenas a seguir o manual de singapura
Ver originalResponder0
MintMaster
· 08-10 01:27
Ir à lua? Para de brincadeira, manter a calma é o caminho certo!
Guia de implementação da conformidade de contratos inteligentes para a emissão de moeda estável em Hong Kong
Guia de implementação de contratos inteligentes para emissores de moeda estável de Hong Kong
Com a aprovação oficial do "Regulamento das Moedas Estáveis", a Autoridade Monetária de Hong Kong publicou em 26 de maio de 2025 o "Guião de Supervisão para Emissores de Moedas Estáveis Licenciados (Rascunho)", com o objetivo de garantir a operação estável, segura e em conformidade do ecossistema local de moedas estáveis. Este guiã detalha os requisitos regulatórios e os padrões operacionais que os emissores de moedas estáveis licenciados devem cumprir continuamente.
Recentemente, cada vez mais instituições têm consultado a equipe de segurança sobre a questão da implementação em conformidade dos contratos inteligentes. Para ajudar os emissores a entenderem e implementarem melhor um sistema de contratos inteligentes em conformidade, publicamos este guia de implementação, a fim de fornecer um caminho técnico claro e recomendações práticas, apoiando o desenvolvimento saudável do ecossistema de moeda estável em Hong Kong.
Primeira Parte Infraestrutura e Estratégia de Conformidade
Esta parte visa estabelecer a base da arquitetura de alto nível para o sistema de moeda estável, cujas decisões de arquitetura são totalmente impulsionadas pelos requisitos fundamentais do quadro da Autoridade Monetária de Hong Kong. As escolhas feitas aqui determinarão todo o caminho de implementação, garantindo que a conformidade esteja profundamente integrada na pilha tecnológica desde o início do design.
1. Escolha do livro-razão distribuído subjacente
instrução regulatória
Os licenciados devem avaliar a robustez da tecnologia de livro-razão distribuído subjacente que utilizam (DLT). Esta avaliação abrange a infraestrutura de segurança, a capacidade de resistir a ataques comuns (como o ataque de 51%), a garantia de finalização das transações e a fiabilidade do algoritmo de consenso.
Interpretação Técnica
Esta não é uma simples escolha de preferência técnica, mas uma tarefa central de conformidade. A escolha da blockchain subjacente deve passar por uma devida diligência formal, e todo o processo de avaliação deve ser devidamente documentado para fornecer justificativa adequada durante a revisão regulatória. O processo de escolha do livro-razão subjacente estabelece na verdade o tom para a segurança e estabilidade de todo o sistema de moeda estável.
A ênfase do Banco da China em Hong Kong na robustez do livro-razão está, na verdade, a aconselhar os emissores a evitar a adoção de blockchains emergentes que não foram validadas pelo mercado, que têm um nível de centralização excessivo ou cuja segurança é questionável. A responsabilidade de provar sua segurança e estabilidade recai completamente sobre os emissores. Se os emissores escolherem uma cadeia cuja segurança ainda não foi amplamente verificada, deverão projetar e implementar medidas de controle compensatórias adicionais.
Guia de Implementação
Priorizar blockchains públicos maduros: recomenda-se optar prioritariamente por blockchains públicos maduros e altamente seguros, 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. Seu elevado custo de ataque (segurança econômica) pode responder diretamente às preocupações regulatórias sobre a resistência a ataques de 51% e a garantia da finalização das transações.
Avaliação rigorosa de alternativas: ao considerar a adoção de uma blockchain de consórcio ou outro tipo de livro-razão distribuído, deve ser realizada uma análise comparativa rigorosa e quantificável, como auditoria de segurança, para provar que seus padrões de segurança não são inferiores, ou até superiores, aos das blockchains públicas mainstream.
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 algoritmos de consenso, bem como os riscos associados a falhas de código, vulnerabilidades, explorações 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 da tecnologia às entidades reguladoras.
2. Padrões de tokens principais e expansão de funções regulatórias
diretivas de supervisão
Os documentos regulatórios não especificaram um padrão de moeda específico (como ERC-20). No entanto, os documentos exigem a implementação de uma série de funções de gestão essenciais, incluindo emissão (mint), destruição (burn), atualização (upgrade), pausa (pause), retomar (resume), congelar (freeze), lista negra (blacklist), lista branca (whitelist) e outras operações.
Interpretação Técnica
A Autoridade Monetária de Hong Kong definiu, na verdade, um padrão de "moeda regulamentada melhorada" que possui funcionalidades que vão muito além do padrão ERC-20. Este padrão não apenas exige a presença de funções básicas de circulação de moeda, mas também enfatiza a segurança operacional, a controlabilidade de permissões e a rastreabilidade de riscos. Para maximizar a segurança enquanto se atende aos requisitos de conformidade, o caminho de desenvolvimento mais eficiente e seguro é utilizar uma biblioteca padrão amplamente auditada e reconhecida pela comunidade (como OpenZeppelin) e, a partir daí, realizar a expansão de funcionalidades.
Guia de Implementação
Padrão base: utiliza ERC-20 como padrão base para garantir a homogeneidade dos tokens e a interoperabilidade em um ecossistema mais amplo.
Expansão de funcionalidades: devem ser integrados os seguintes módulos de funcionalidade para cumprir os requisitos regulatórios:
Pausable：utilizado para implementar a funcionalidade de pausa e recuperação global de todas as atividades de moeda, que é uma ferramenta central para lidar com eventos de segurança significativos.
Mintable: utilizado para permitir que emissores licenciados criem novos tokens através de um processo controlado, garantindo que a quantidade de tokens emitidos corresponda estritamente a ativos de reserva em moeda fiduciária.
Burnable: fornece a funcionalidade de destruir moeda. Na implementação específica, esta funcionalidade será controlada por permissões rigorosas, em vez de permitir que qualquer usuário a destrua por conta própria.
Freezable: utilizado para suspender a funcionalidade de transferência de moedas de contas específicas (como em transações suspeitas).
Whitelist: usado 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 novas moedas emitidas).
Lista negra: utilizada para implementar proibições de transação em endereços envolvidos em atividades ilegais (como lavagem de dinheiro, fraude), proibindo-os de enviar/receber moedas. A gestão da lista negra deve ser integrada com o sistema AML/CFT, monitorando transações suspeitas em tempo real.
AccessControl: esta é a base para implementar um sistema de gestão de permissões baseado em funções e detalhado. Todas as funções de gestão devem passar por este módulo para controle de permissões, a fim de atender aos requisitos de separação de funções.
3. Principais modos de conformidade: escolha de listas negras e listas brancas
diretiva regulatória
O documento de consulta sobre monitorização contínua, luta contra a lavagem de dinheiro/combate ao financiamento do terrorismo ( AML/CFT ) propôs várias medidas, incluindo "colocar em lista negra endereços de carteira identificados como sancionados ou relacionados a atividades ilegais", ou adotar um "sistema de lista branca para endereços de carteira de detentores de moeda estável, ou um modelo de circuito fechado".
Interpretação técnica
Este é o ponto de decisão mais crítico em toda a arquitetura do sistema, que determina diretamente a abertura, a utilidade e a complexidade das operações de conformidade da moeda estável.
Modo de lista negra: um modo "default aberto". Todos os endereços podem transacionar livremente por padrão, apenas aqueles que são explicitamente identificados e adicionados à lista negra na blockchain serão restringidos.
Modo de lista branca: um modo de "fechado por padrão". Qualquer endereço, a menos que tenha passado pela devida diligência e aprovação explícitas do emissor, e seja adicionado à lista branca na cadeia, não pode possuir ou receber moedas.
Embora o modo de lista branca ofereça capacidades de controle de AML (anti-lavagem de dinheiro), para uma moeda estável destinada a ser amplamente utilizada, um regime estrito de lista branca significa que a moeda estável só pode circular entre participantes previamente verificados, o que a torna mais parecida com um sistema bancário fechado, em vez de uma moeda digital flexível.
Portanto, o modelo de lista negra, que também é claramente mencionado pela regulamentação, combinado com as poderosas ferramentas de análise off-chain exigidas pela regulamentação, constitui uma solução mais equilibrada. Ela atende aos requisitos regulatórios e, ao mesmo tempo, preserva a utilidade dos ativos.
No design, o sistema pode ser construído como escalável, ou implementar simultaneamente dois modos, de forma a permitir uma transição suave ou mudança para o modo de lista branca no futuro, caso haja um aperto na regulamentação ou alterações no modelo de negócios.
Guia de Implementação
Modo de lista negra (opção recomendada por padrão):
Vantagens: apresenta uma maior utilidade, podendo interagir de forma fluida com o vasto ecossistema de finanças descentralizadas (DeFi), oferecendo aos usuários uma barreira de entrada mais baixa e uma experiência mais suave.
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 de forma oportuna.
Modo de implementação: na função de transferência dos contratos inteligentes, adicionar verificações lógicas para garantir que o endereço do remetente (from) e o endereço 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 antes da ocorrência, em vez de remediação posterior.
Desvantagens: limita bastante a utilidade e a taxa de adoção da moeda estável, trazendo enormes custos operacionais para a gestão da lista de permissões, o que pode dificultar que se torne um meio de troca amplamente aceito.
Método de implementação: na função de transferência do contrato inteligente, adicione uma verificação lógica que exija que os endereços do remetente (from) e do destinatário (to) estejam ambos presentes na lista branca. Recomenda-se desenvolver um sistema de backend web dedicado para usuários para facilitar as operações.
Segunda Parte Contratos Inteligentes
Esta parte fornece um detalhado plano para as funcionalidades principais dos contratos inteligentes, convertendo requisitos regulatórios complexos em lógica de nível de código específica, padrões de segurança e protocolos operacionais.
1. Sistema de controle de acesso com design refinado
instrução de supervisão
O design de operações de alto risco deve "prevenir que qualquer parte única possa executar unilateralmente operações relacionadas (por exemplo, através de protocolos de múltiplas assinaturas)". As responsabilidades de diferentes operações devem ser devidamente isoladas.
Interpretação Técnica
Isto significa que um sistema de controle de acesso robusto e baseado em papéis (RBAC) é obrigatório. Qualquer forma de "proprietário" ou "administrador" de chave privada única é considerada não conforme.
Guia de Implementação
Devem ser definidos uma série de papéis claros e atribuídos a diferentes entidades ou funcionários controlados por carteiras multi-assinatura, para alcançar 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 multi-assinada, e garantir que nenhum funcionário tenha simultaneamente múltiplos papéis de alto risco. Todas as operações devem ser registadas em log e sujeitas a auditoria de terceiros anual, a atribuição de permissões deve ser supervisionada por um administrador ou conselho.
MINTER_ROLE: responsável por lidar com a emissão de moeda estável (mint), incluindo a criação de unidades de token após receber um pedido de emissão válido, e garantir que a emissão corresponda ao aumento correspondente do pool de ativos de reserva.
BURNER_ROLE: responsável por lidar com a destruição da moeda estável (burn) operação, incluindo a destruição de unidades de moeda após receber uma solicitação de resgate válida.
PAUSER_ROLE: responsável por pausar (pause) a operação da moeda estável, como interromper temporariamente transferências, emissão ou resgates quando um evento anômalo (como uma ameaça à segurança) for detectado.
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 eventos 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 gerenciar a lista branca (whitelist), incluindo adicionar ou remover endereços de carteira permitidos, como restringir a emissão de moeda apenas a endereços na lista branca.
BLACKLISTER_ROLE: responsável por gerenciar a lista negra (blacklist) e remover a lista negra (remove blacklist), como colocar carteiras suspeitas na lista negra para impedir transferências.
UPGRADER_ROLE: Se um modelo atualizável for adotado, é responsável pela atualização (upgrade) contratos inteligentes, por exemplo, atualizar o código do contrato para corrigir vulnerabilidades ou adicionar funcionalidades.
Tabela 1: Matriz de Controle de Acesso Baseada em Funções ( Matriz RBAC )
A tabela abaixo fornece uma norma clara e intuitiva para uso por desenvolvedores e auditores, mapeando claramente cada operação privilegiada para seu papel e tipo de controle necessários.
| Ação | Papel Necessário | Tipo de Controle | |------|----------|----------| | moeda | MINTER_ROLE | múltipla assinatura | | destruição | BURNER_ROLE | multiassinatura | | Pausar | PAUSER_ROLE | Múltiplas assinaturas | | Recuperar | RESUME_ROLE | Multiassinatura | | Congelado | FREEZER_ROLE | Múltipla assinatura | | descongelar | FREEZER_ROLE | múltiplas assinaturas | | Adicionar à lista branca | WHITELISTER_ROLE | Multisig | | Remover da lista branca | WHITELISTER_ROLE | Multi-assinatura | | Adicionar à lista negra |