Privacidade programável: como poderia ser mais favorável à conformidade para o mundo Web3

Na Ola, concordamos fortemente com a declaração do a16z em seu artigo " Alcançando privacidade criptográfica e conformidade regulatória " sobre web3:

“O desenvolvimento e a regulamentação de web3 – uma evolução da Internet alimentada por criptografia – deve atingir dois objetivos que muitas vezes estão em tensão. Objetivo 1: Preservar a privacidade do consumidor, apesar da natureza transparente padrão dos blockchains . Objectivo 2: Reduzir o risco de financiamento ilícito no interesse da segurança nacional.”

Esta visão está alinhada com o que Ola descreveu no artigo " Ola – Molde sua própria jornada na Web3 ". Além disso, a ênfase no alto rendimento é um recurso que Ola está atualmente trabalhando arduamente para implementar.

Quer se trate de cenários privados ou não privados, a programabilidade é um atributo extremamente importante. No domínio da privacidade programável, além de Ola, tanto Aztec quanto Miden estão trabalhando para o mesmo objetivo.

Artigo de Ola, " Sin7y Tech Review (35): Hybrid Rollup – A infraestrutura de próxima geração - HackMD ," descreve as diferenças entre essas três soluções.

Neste artigo, nos concentraremos mais em explicar o design do Ola em termos de compatibilidade com a conformidade . Conforme descrito no artigo a16z, a privacidade deve abranger dois atributos simultaneamente:

1. Obtenha proteção de privacidade nativa para proteger as informações do usuário.

   
   

2. Garanta a conformidade regulatória para rastrear atividades ilícitas.

O primeiro ponto é relativamente simples de realizar. Em relação ao segundo, cada projeto tem as suas próprias considerações e compromissos. Iremos nos aprofundar principalmente no processo de pensamento e design de Ola em relação à conformidade regulatória.

Abordando isto da perspectiva da resolução de problemas do mundo real, vamos primeiro examinar os desafios que vários projectos de privacidade enfrentam em termos de conformidade regulamentar. Conforme descrito no capítulo "Desanonimização seletiva involuntária" do artigo " Soluções regulatórias de proteção de privacidade usando provas de conhecimento zero: artigo completo - criptografia a16z ”, a questão central é: “ Quem mantém a chave privada para desbloquear a rastreabilidade? "

Por que precisamos de uma chave privada para desbloquear a rastreabilidade?

A necessidade de uma chave privada para alcançar a rastreabilidade está relacionada aos atuais projetos de privacidade.

Como quase todas as soluções de privacidade atualmente baseadas na tecnologia zk (conhecimento zero) foram inspiradas no Zcash, discutiremos diretamente o design do Zcash, conforme ilustrado abaixo:

No artigo " Sin7y Tech Review (33): Princípios de transações privadas e questões de conformidade regulatória - HackMD ", você pode encontrar os princípios de design por trás das transações privadas. Explicaremos brevemente como a privacidade é mantida sob esse design e como ela aborda questões regulatórias:

1. Ocultar o iniciador da transação ou o remetente : Isso é conseguido através de uma assinatura única, conforme detalhado na seção 4.1.7.1 do protocolo zcash-sapling .

   
   

2. Ocultar o destinatário da transação ou o destinatário : Isso é dividido em dois cenários:

   
   

ⅰ. A ocultação de terceiros é conseguida criptografando as informações da transação usando o endereço público do destinatário. Consulte a seção 4.19.1 do protocolo zcash-sapling . O receptor então analisa as transações usando uma chave privada (conhecida como chave de visualização de entrada) para descriptografar e filtrar as transações enviadas a eles, conforme descrito na seção 4.19.2 do protocolo zcash-sapling . O conteúdo da transação em si não contém nenhuma informação sobre o destinatário.

ⅱ. A ocultação do mesmo remetente é realizada usando um endereço público único.

3. Para a ocultação de informações de transações : A abordagem envolve o uso de provas de conhecimento zero e esquemas secretos compartilhados. Consulte as seções 4.17 e 4.19 do protocolo zcash-sapling .

   
   

4. Para a implementação de não rastreável : A abordagem é baseada no design da árvore de compromisso (doravante denominada "CM") e da árvore anuladora (doravante denominada "NF"). Este design atende aos seguintes propósitos:

   
   

ⅰ. Cada UTXO (Unspent Transaction Output) corresponde a um CM e um NF, mas não há ligação direta entre os dois.

ⅱ. Tanto a árvore CM quanto a árvore NF são árvores somente anexadas.

ⅲ. A árvore CM é usada para provar a validade do UTXO, enquanto a árvore NF evita o gasto duplo do UTXO.

Com base no design de privacidade acima, os usuários podem se beneficiar dos seguintes recursos de proteção de privacidade:

1. Cada transação permanece invisível para partes externas.

   
   

2. As conexões entre as transações são indetectáveis.

   
   

Parece um design de proteção de privacidade impecável para os usuários. No entanto, quando fundamentados na realidade, nem todos os utilizadores operam com intenções genuínas e legais. Devem existir mecanismos para divulgar partes ou todos os detalhes da transação privada para alcançar a rastreabilidade quando necessário.

Isso ajuda os órgãos reguladores a tomar medidas contra usuários mal-intencionados. Caso contrário, esta forma de privacidade poderá tornar-se uma ferramenta para agentes mal-intencionados prejudicarem os utilizadores comuns.

O design de privacidade acima mencionado permite que as autoridades reguladoras rastreiem convenientemente as transações e apliquem regulamentos? A resposta é não. Conforme ilustrado no diagrama fornecido (que é referenciado, mas não mostrado), o design de privacidade atual requer uma chave de visualização para desbloquear a rastreabilidade da transação.

No entanto, esta chave de visualização é mantida pelo usuário, tornando-a inacessível diretamente aos reguladores. Isso está relacionado às questões descritas nas seções 13/14 intituladas "Desanonimização seletiva voluntária" e "Desanonimização seletiva involuntária" do artigo " Soluções regulatórias de proteção de privacidade usando provas de conhecimento zero: artigo completo - criptografia a16z. "

Vamos nos aprofundar. Por que a chave de visualização é tão sensível que os usuários hesitam em fornecê-la aos reguladores?

1. Em primeiro lugar, é fundamental esclarecer que a chave de visualização não é a chave privada utilizada para assinaturas de transações; ele não pode ser usado para assinar transações diretamente e, portanto, não pode ser usado para roubar ativos do usuário.

   
   

2. Uma vez exposta a chave de visualização, os reguladores podem ver todas as transações privadas iniciadas por um usuário em texto simples. Os usuários devem confiar nos reguladores que: (1) a chave de visualização não será vazada; e (2) os detalhes da transação não serão divulgados.

   
   

3. É claro que os utilizadores com propósitos perversos não estarão dispostos a fornecer a sua chave de visão, deixando os reguladores impotentes.

   
   

Com base na análise acima, a solução de privacidade ideal deve :

1. Continue a ocultar o conteúdo de cada transação, garantindo que a privacidade do usuário permaneça intacta.

   
   

2. Obtenha rastreabilidade sem permissão entre transações, o que significa que a rastreabilidade pode ser realizada sem o fornecimento obrigatório de informações extras .

Esta é a visão que Ola está se esforçando para alcançar: privacidade programável que incorpora rastreabilidade nativamente!

Como a Ola introduz a rastreabilidade nativa na privacidade programável?

Enfrentando os desafios regulatórios encontrados pelas soluções de privacidade acima, Ola aventurou-se corajosamente a fazer uma tentativa e delineou um design específico. Os principais pontos tecnológicos podem ser resumidos como:

1. A árvore anuladora não é mais introduzida para alcançar a impossibilidade de rastreabilidade das transações. No design de Ola, as transações são rastreáveis, mas isso é feito sob criptografia, sem comprometer os atributos de privacidade das próprias transações.

   
   

2. A árvore de compromissos restante é transferida do modo original somente de acréscimo para um modo atualizável, introduzindo declarações de prova adicionais para evitar ataques de gastos duplos no mesmo compromisso. Isso é ilustrado na Figura 2:

   
   

3. Incorpore um mecanismo de chave de visualização atualizável. Isso significa que quando uma chave de visualização é exposta, os usuários podem atualizar a chave de visualização para garantir que as transações privadas subsequentes criadas após a atualização da chave não possam ser descriptografadas. Conforme ilustrado na Figura 3:

   
   

zkDID/zkKYC equilibra efetivamente privacidade e regulamentação

Os identificadores descentralizados de conhecimento zero (zkDIDs) desempenham um papel crucial nas plataformas de privacidade. Eles têm a capacidade de transformar a identidade legal de um usuário (Legal ID) em um zkDID. Por exemplo, no projeto PSE Anon Aadhar , pessoas com um cartão Aadhaar podem gerar um zkDID.

Para outros, um zkDID é anônimo e não revela as informações reais de identidade do usuário. Esta dupla característica fornece uma ferramenta poderosa para proteção da privacidade.

Quanto aos níveis de implementação do zkDID, pode ocorrer em vários níveis, dependendo do design e dos requisitos da plataforma:

1. Implementação no nível da plataforma : se uma plataforma precisar gerenciar e verificar a identidade de todos os usuários para garantir a segurança e a conformidade, a implementação do zkDID no nível da plataforma pode ser a escolha mais apropriada. Desta forma, a plataforma pode integrar diretamente o zkDID como parte do seu sistema de gestão de identidade, permitindo a verificação e autorização da identidade do utilizador.

   
   

   Essa abordagem permite proteção consistente de identidade e controle de privacidade em toda a plataforma.

   
   

2. Implementação em nível de aplicativo : se uma plataforma prioriza o controle e a flexibilidade do usuário, pode ser preferível implementar o zkDID em um aplicativo de camada superior na plataforma. Este método permite que os usuários escolham se desejam usar zkDID e gerenciar sua identidade conforme necessário.

   
   

   Os usuários podem decidir quando usar o zkDID para equilibrar privacidade e conveniência. Esta abordagem pode ser mais adequada para usuários que desejam ter um controle mais ativo sobre sua identidade. (não nativo).

Dado o design acima, a solução de privacidade da Ola apresenta as seguintes vantagens:

1. Rastreabilidade : Com base nas informações do CM dentro de uma transação, qualquer terceiro pode rastrear o caminho do fluxo do CM, conforme ilustrado na Figura 2.

   
   

2. Privacidade : A privacidade de cada transação permanece intacta; informações sobre o remetente, destinatário e outros aspectos permanecem confidenciais.

   
   

3. Eficiência : Ao manter menos árvores, a sobrecarga do sistema à prova de zk é reduzida.

   
   

4. Chave de visualização atualizável : oferece suporte a atualizações da chave de visualização, garantindo que a privacidade da transação não seja comprometida se a chave de visualização for exposta.

   
   

5. Amigável à conformidade : Sem a necessidade de informações não aplicáveis, os reguladores podem rastrear a linhagem do alvo, por exemplo, dentro das coleções de CM. Embora os reguladores possam temporariamente não ter conhecimento sobre os proprietários destes CMs, eles têm duas opções:

   
   

6. a. Aguarde que o CM seja consumido e transferido para um endereço público, o que é viável, pois, no projeto de Ola, todos os estados privados devem fazer a transição para estados públicos antes de sair do ecossistema.

   
   b. Obtenha informações importantes para descriptografia, um método tradicional usado para rastreabilidade em soluções de proteção de privacidade, como visto em sistemas como Zcash, Aleo, Aztec, Miden e outros.

Além dessas vantagens técnicas, o Ola ainda pode integrar-se com papéis como " Alcançando privacidade criptográfica e conformidade regulatória - criptografia a16z " e " Privacidade Blockchain e Conformidade Regulatória: Rumo a um Equilíbrio Prático " para incorporar mecanismos de lista negra e outras restrições em estágio inicial, refinando o design de todo o sistema de privacidade programável.

Também publicado aqui