Há alguns meses, a equipa de criptomoeda da a16z publicou o Desafio Nakamoto, uma lista dos problemas mais importantes a resolver na blockchain. O quarto, em particular, chamou a nossa atenção: "Privacidade Programável Conforme", pois temos estado a pensar ativamente nisso há algum tempo. Hoje, estamos a propor uma primeira solução utilizando criptografia homomórfica e o nosso protocolo de contrato inteligente confidencial fhEVM (se não estiver familiarizado com o fhEVM, pode ler os nossos artigos sobre confidencialToken ERC20eleilões cegos).

O fhEVM é um EVM regular com alguns precompilados que permitem computar em estados criptografados usando nossa biblioteca de criptografia homomórfica TFHE-rs. Do ponto de vista do programador, não há criptografia envolvida: eles simplesmente escrevem código Solidity usando os tipos de dados criptografados que fornecemos (euint32, ebool, etc). Uma das grandes vantagens do fhEVM em comparação com outras soluções de privacidade é que todos os dados e cálculos ocorrem na cadeia. Isso significa que você pode ter o mesmo nível de composabilidade e disponibilidade de dados que os contratos regulares em texto simples.

Esta propriedade é fundamental para construir privacidade programável, uma vez que toda a lógica de controlo de acesso pode ser definida no próprio contrato. Não há nada que precise ser codificado no protocolo e nada que o utilizador tenha de fazer offchain para estar em conformidade. A aplicação pode fazer cumprir a conformidade diretamente, com apenas algumas linhas de código Solidity!

Neste artigo, mostraremos como criar um token ERC20 compatível, usando DIDs onchain. O código-fonte deste 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 que é emitida por uma entidade, como um governo, um registrador, uma empresa ou o próprio usuário. Este DID pode ser vinculado a uma chave criptográfica que prova que o usuário possui o 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 provar que você satisfaz 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 utiliza provas de conhecimento zero para gerar atestações. Embora isso seja aceitável em muitos casos, rapidamente se complica quando há vários utilizadores envolvidos numa transação, quando é necessário aplicar regras complexas ao DID ou quando é preciso manter um conjunto comum de regras para todos seguirem. Essencialmente, é o mesmo compromisso que nas aplicações de borda versus nuvem.

No entanto, ter um registo centralizado de DID resolveria esses problemas, pois poderia simplesmente pedir ao registo para verificar se todos estão em conformidade. Também tornaria mais simples acompanhar as regulamentações, uma vez que apenas precisaria de a implementar num único local. Uma blockchain seria uma infraestrutura perfeita para isso, pois permitiria a composição entre DIDs e aplicações que exigem conformidade, bem como a composição entre as próprias regulamentações.

Problema: todos veriam a identidade de todos!

Felizmente, temos uma solução: criptografia homomórfica e, mais especificamente, a fhEVM! Graças à capacidade de ter composabilidade em estado criptografado, podemos hospedar os DIDs do usuário diretamente na cadeia de blocos em forma criptografada e ter aplicações conformes verificando atributos usando uma simples chamada de contrato. 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 contrato inteligente com Abstração de Conta.

Este tutorial tem 3 partes:

• A Abstração de Identidade é feita através de um contrato de registro que é responsável por gerir identidades e atestações. Aqui assumimos que os DIDs são IDs oficiais do governo. O próprio registro é gerido 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 utilizador. O utilizador passa então pelo seu registrador para gerir e atualizar os seus DIDs.
• A regulamentação é definida num contrato que codifica um conjunto de regras para transferências de tokens entre indivíduos, com base nas informações contidas nos seus DIDs. Basicamente, ela aplica regulação ao nível do contrato em vez do nível do utilizador.
• Transferências confidenciais em conformidade são implementadas num contrato ERC20 em conformidade que utiliza o contrato de regulamentação para impor conformidade nas transferências de tokens, sem quaisquer alterações na própria API ERC20. Neste exemplo, utilizamos um contrato ERC20 confidencial, onde os saldos e montantes estão ocultos, mas funcionaria igualmente bem com um token ERC20 regular e em texto simples.

Arquitetura do nosso Protocolo DID Confidencial Onchain

O contrato de registo de identidade

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

O contrato também trata de permissões, como:

• Permitir ao proprietário do contrato (por exemplo, AFNIC) adicionar, remover ou atualizar registradores.
• Permitir que os registradores adicionem, removam ou atualizem os DIDs dos utilizadores que criaram.
• Permitindo que os usuários concedam acesso a contratos inteligentes a atributos específicos de seus DIDs. É importante observar 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 gerir DIDs:

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

Um identificador é simplesmente uma cadeia de caracteres (por exemplo, "data de nascimento") e um valor criptografado de 32 bits. Só pode ser criado ou atualizado pelo agente de registo. 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 utilizador precisa de dar permissão a um contrato para aceder a valores específicos, o que iremos tratar através de um mecanismo simples de controlo de acesso semelhante à forma como pode permitir a um contrato gastar os seus tokens ERC20.

contrato IdentityRegistry é EIP712WithModifier, Ownable

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

contrato IdentityRegistry é EIP712WithModifier, Ownable

O contrato de regulamentaçã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. Os governos podem simplesmente atualizar este contrato, e ele será automaticamente propagado para todos os tokens que o implementaram.

No essencial, o contrato de regulamentação é apenas um conjunto de condições que são correspondidas com atributos de identidade criptografados. Para evitar uso indevido, os utilizadores não concedem acesso diretamente ao contrato de regulamentação, mas sim concedem acesso ao contrato de token ERC20, que em seguida efetua uma chamada de delegação ao contrato de regulamentação. Esta abordagem garante que apenas o contrato ERC20, no qual o utilizador confia, pode aceder às suas informações. Tenha em mente que tanto o remetente como o destinatário têm de ter concedido permissão ao contrato ERC20 antes de uma transferência poder ocorrer entre eles.

Neste exemplo, iremos implementar 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 utilizador não pode transferir tokens para um país em lista negra.

Em vez de falhar a 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 cumprida. Isso usa um operador ternário homomórfico chamado de cmux: valor = TFHE.cmux(condiçãoCriptografada, valorSeVerdadeiro, valorSeFalso

O contrato ERC20 confidencial e conformidade

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

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

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

Finalmente, agora podemos criar o nosso contrato ERC20:

Da mesma forma que os utilizadores concedem permissões aos protocolos DeFi para gastarem os seus tokens, terão de conceder permissão ao contrato para aceder aos identificadores necessários pelo contrato de regulamentação. Isto é feito através de uma chamada a Identity.grantAccess(contractAddress, identifiers), que pode ser recuperada 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 lhe tenha mostrado que a conformidade não é difícil de construir se as ferramentas certas estiverem disponíveis. Embora inicialmente tenhamos construído o fhEVM para permitir a privacidade na blockchain, rapidamente percebemos que esta tecnologia poderia ser usada para a gestão de identidades e, assim, a conformidade programável.

O design propostoaquiestá 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 deixe de ser sinônimo de vigilância!

Links adicionais

• EstrelaRepositório fhEVM do Github de Zamapara endossar o nosso trabalho.
• ReverDocumentação fhEVM da Zama.
• Obtenha suporte sobre o 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 os estados privados ocultos usando a privacidade programável fhEVM da Zama (15,000€ em prémio).

Disclaimer：

1. Este artigo é reproduzido a partir de [zama]。 Todos os direitos autorais pertencem ao autor original [fhEVM]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as 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. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.