Alguns meses atrás, a equipe de criptografia da a16z publicou o Desafio NakamotoUma lista dos problemas mais importantes a resolver em blockchain. O quarto, em particular, chamou nossa atenção: "Privacidade Programável Conforme", pois temos pensado ativamente sobre isso há algum tempo. Hoje, estamos propondo uma primeira solução usando encriptação homomórfica e nosso protocolo de contrato inteligente confidencial fhEVM (se você não está familiarizado com o fhEVM, pode ler nossos artigos sobre confidencialToken ERC20eleilões cegos).

O fhEVM é um EVM regular com algumas pré-compilações que permite a computação em estados criptografados usando nossa biblioteca de criptografia homomórfica TFHE-rs. Da perspectiva do desenvolvedor, não há criptografia envolvida: eles simplesmente escrevem o código Solidity usando os tipos de dados criptografados que fornecemos (euint32, ebool, etc). Uma das grandes vantagens do fhEVM em relação a outras soluções de privacidade é que todos os dados e computação acontecem onchain. Isso significa que você pode ter o mesmo nível de capacidade de composição e disponibilidade de dados que os contratos regulares de texto sem formatação.

Essa propriedade é fundamental para a construção de privacidade programável, pois toda a lógica de controle de acesso pode ser definida no próprio contrato. Não há nada que precise ser codificado no protocolo, e nada que o usuário precise fazer offchain para estar em conformidade. O aplicativo pode impor a conformidade diretamente, com apenas algumas linhas de código Solidity!

Neste artigo, vamos mostrar como construir um token ERC20 conforme, usando DIDs onchain. O código-fonte para este tutorial pode ser encontrado no pasta de exemplosdo repositório fhEVM.

Abstração de identidade via DIDs confidenciais na cadeia

Um Identificador Descentralizado (DID) é uma identidade digital única emitida por uma entidade como um governo, um registrador, uma empresa ou o próprio usuário. Este DID pode estar vinculado a uma chave criptográfica que comprova que o usuário é o proprietário do DID, como uma carteira EVM. Mas também pode armazenar uma série de atributos, como a idade do usuário, nacionalidade, número de segurança social, etc. Esses atributos, por sua vez, podem ser usados para comprovar que você atende a alguma condição (chamada de “atestado”), como ter mais de 18 anos ou não ser cidadão de Nárnia.

A maioria dos DIDs é implementada do lado do cliente e usa provas de conhecimento zero para gerar certificações. Embora isso seja bom em muitos casos, rapidamente se torna complicado quando você tem vários usuários envolvidos em uma transação, quando precisa aplicar regras complexas ao DID ou quando precisa manter um conjunto comum de regras para todos seguirem. Essencialmente, é o mesmo compromisso que em aplicações de borda versus nuvem.

Ter um registro DID centralizado, no entanto, resolveria esses problemas, pois você poderia simplesmente pedir ao registro para verificar se todos estão em conformidade. Também tornaria mais simples acompanhar as regulamentações, pois você só precisaria implementá-las em um único lugar. Um blockchain seria uma infraestrutura perfeita para isso, pois permitiria a composabilidade entre DIDs e aplicativos que exigem conformidade, bem como a composabilidade entre as próprias regulamentações.

Problema: todos veriam a identidade de todos!

Felizmente, temos uma solução: a encriptação homomórfica e, mais especificamente, o fhEVM! Graças à capacidade de ter composabilidade em estado criptografado, podemos hospedar os DIDs do usuário diretamente na cadeia em forma criptografada e ter aplicativos conformes verificando atributos usando uma chamada de contrato simples. A capacidade de gerenciar uma identidade por meio de um contrato inteligente, que chamamos de 'Abstração de Identidade', é semelhante à forma como se pode gerenciar fundos por meio de um contrato inteligente com Abstração de Conta.

Este tutorial tem 3 partes:

• A Abstração de Identidade é feita por meio de um contrato de registro responsável por gerenciar identidades e atestações. Aqui assumimos que os DIDs são IDs oficiais do governo. O próprio registro é gerenciado por uma autoridade central (por exemplo, a AFNIC) que pode criar registradores (por exemplo, empresas de KYC como Onfido, Jumio, etc.) que por sua vez podem criar DIDs de usuário. O usuário então passa por seu registrador para gerenciar e atualizar seus DIDs.
• A regulamentação é definida em um contrato que codifica um conjunto de regras para transferências de tokens entre indivíduos, com base nas informações contidas em seus DIDs. Basicamente, impõe a regulamentação no nível do contrato, em vez do nível do usuário.
• As Transferências Confidenciais Conformes são implementadas em um contrato ERC20 conforme que utiliza o contrato de regulamento para impor conformidade nas transferências de tokens, sem quaisquer alterações na própria API ERC20. Neste exemplo, usamos um contrato ERC20 confidencial, onde saldos e quantias estão ocultos, mas funcionaria tão bem com um token ERC20 regular e em texto simples.

Arquitetura do nosso Protocolo Onchain Confidential DID

O contrato de registro de identidade

O contrato IdentityRegistry é um registro de DIDs de usuário que são emitidos por registradores e incluem um conjunto de identificadores criptografados, como sua nacionalidade, idade, número de segurança social, etc. Esses identificadores são armazenados como valores criptografados de 32 bits (euint32).

O contrato também lida com permissões, tais como:

• Permitindo que o proprietário do contrato (por exemplo, AFNIC) adicione, remova ou atualize registradores.
• Permitir que os registradores adicionem, removam ou atualizem os DIDs de usuário que criaram.
• Permitindo que os usuários concedam acesso a contratos inteligentes a atributos específicos de seus DIDs. É importante notar aqui que o usuário é responsável por não conceder acesso a contratos maliciosos, assim como é responsável por não permitir que contratos maliciosos gastem seus tokens.

Como primeiro passo, vamos implementar a lógica para criar e gerenciar DIDs:

Agora, o próximo passo é implementar a lógica para identificadores e controle de acesso.

Um identificador é simplesmente uma string (por exemplo, "data de nascimento") e um valor de 32 bits criptografado. Ele só pode ser criado ou atualizado pelo registrador. Um usuário não pode criar seus próprios identificadores, pois queremos que eles sejam certificados pelo registrador.

Uma vez que os identificadores estão encriptados, o usuário precisa dar permissão a um contrato para acessar valores específicos, o que lidaremos por meio de um mecanismo simples de controle de acesso semelhante a como você pode permitir que um contrato gaste seus tokens ERC20.

contrato IdentityRegistry é EIP712WithModifier, Ownable

Agora podemos concluir nosso contrato de registro de identidade adicionando os getters necessários, com algumas condições e tratamento de erros.

contrato IdentityRegistry é EIP712WithModifier, Ownable

O contrato de regulação

O próximo passo é criar o nosso contrato de regulação.

Ao implementar um conjunto de regras para transferências entre duas pessoas, é importante reconhecer que essas regras podem evoluir ao longo do tempo. Ter um único contrato inteligente definindo toda a regulamentação para um determinado contexto, como transferência de dinheiro, significa que os contratos ERC20 não precisam acompanhar a regulamentação por conta própria. Os governos podem simplesmente atualizar este contrato, e ele se propagará automaticamente para todos os tokens que o implementaram.

No núcleo, o contrato de regulamentação é apenas um conjunto de condições que são correspondidas a atributos de identidade criptografados. Para evitar o uso indevido, os usuários não concedem acesso diretamente ao contrato de regulamentação, mas sim concedem acesso ao contrato de token ERC20, que então realiza uma chamada de delegado ao contrato de regulamentação. Essa abordagem garante que apenas o contrato ERC20, no qual o usuário confia, possa acessar suas informações. Tenha em mente que tanto o remetente quanto o destinatário devem ter concedido permissão ao contrato ERC20 antes que uma transferência possa ocorrer entre eles.

Neste exemplo, implementaremos algumas regras básicas:

• As transferências dentro de um país são ilimitadas, mas as transferências para um país estrangeiro estão limitadas a 10.000 tokens.
• Um usuário na lista negra não pode transferir ou receber tokens.
• Um usuário não pode transferir tokens para um país na lista negra.

Em vez de falhar na transação, o que poderia revelar informações sensíveis, simplesmente definiremos o valor da transferência como 0 se uma das condições não for atendida. Isso usa um operador ternário homomórfico chamado cmux: valor = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse

O contrato ERC20 confidencial e em conformidade

Agora que temos um registro de identidade e um contrato de regulamentação, finalmente podemos criar nosso contrato de token compatível e preservador da privacidade. Este contrato será chamado CompliantERC20 e terá as seguintes características principais:

• O saldo do usuário e o valor da transferência estão encriptados.
• A conformidade é aplicada nas transferências ao chamar o contrato de regulamentação.
• A visibilidade de certos saldos pode ser concedida a endereços na lista branca (por exemplo, reguladores)

O contrato de regulamentação é invocado através de uma chamada simples. Isso implica que os usuários devem fornecer acesso ao contrato ERC20 antes de iniciar qualquer transferência; caso contrário, a transferência será revertida.

Finalmente, agora podemos criar nosso contrato ERC20:

Da mesma forma que os usuários concedem permissões aos protocolos DeFi para gastar seus tokens, eles precisarão conceder permissão ao contrato para acessar os identificadores necessários pelo contrato de regulamentação. Isso é feito por meio de uma chamada para Identity.grantAccess(contractAddress, identifiers), que pode ser obtida chamando o método de visualização ERC20.identifiers(). Esta lista vem diretamente do contrato ERC20Rules para permitir a atualização das propriedades.

Conformidade e privacidade podem coexistir!

Esperamos que este tutorial tenha mostrado que a conformidade não é algo difícil de construir se as ferramentas corretas estiverem disponíveis. Enquanto inicialmente construímos o fhEVM para possibilitar a privacidade na blockchain, rapidamente percebemos que essa tecnologia poderia ser usada para o gerenciamento de identidade e, portanto, conformidade programável.

O design proposto aquiestá longe de ser perfeito, mas acreditamos que pode ser facilmente melhorado e lançado como um caso de uso do mundo real, para que a conformidade não precise mais ser sinônimo de vigilância!

Links adicionais

• EstrelaRepositório do Github fhEVM da Zamapara endossar nosso trabalho.
• Revisar Documentação fhEVM da Zama.
• Obtenha suporte em nosso canais da comunidade.
• Ajude a avançar o espaço FHE com o Programa de Recompensas Zama: Criar um jogo on-chain que mantém estados privados ocultos usando a privacidade programável fhEVM da Zama (15.000€ em prêmio).

Aviso legal：

1. Este artigo é reimpresso de [zama]。 Todos os direitos autorais pertencem ao autor original [fhEVM]. Se houver objeções a esta reimpressão, entre em contato com o Portão Aprenderequipe e eles resolverão isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.