原文：《Privacidade do Blockchain e Conformidade Regulatória: Rumo a um Equilíbrio Prático》
De: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar e Ameen Soleimani
Compilado por: Odaily Planet Daily Husband How
Hoje, Buterin e outros escreveram em conjunto um artigo de pesquisa sobre protocolos de privacidade, intitulado "Privacidade do Blockchain e conformidade regulatória: rumo a um equilíbrio prático".
O artigo descreve um novo protocolo de aumento de privacidade baseado em contratos inteligentes - pool de privacidade, discute suas vantagens e desvantagens e mostra como ele equilibra usuários honestos e usuários desonestos. O protocolo foi projetado para usar provas de conhecimento zero para verificar a legitimidade dos fundos dos usuários sem revelar seu histórico completo de transações, equilibrando requisitos regulatórios e de privacidade enquanto filtra fundos associados a atividades criminosas.
Odaily Planet Daily agora compila a essência do artigo da seguinte forma.
I. Introdução
Blockchains públicos são transparentes por design. A ideia básica é que qualquer pessoa pode optar por verificar as transações sem ter de depender de um terceiro centralizado; ao reduzir as dependências, fornece uma base neutra para uma variedade de aplicações, incluindo, entre outras, finanças e identidade autossoberana.
No entanto, do ponto de vista da privacidade, os conjuntos de dados públicos possuem todas as transações que contêm todos os endereços da blockchain. Sempre que alguém transfere um ativo para outro endereço, ou interage com um contrato inteligente, essa transação estará sempre visível na blockchain. Isto claramente não está de acordo com os requisitos de privacidade.
Exemplo: Alice paga o jantar em um restaurante com uma carteira blockchain. O beneficiário agora conhece o endereço de Alice e pode analisar todas as atividades passadas e futuras nesse endereço. Da mesma forma, Alice agora sabe o endereço da carteira do restaurante e pode usar essas informações para obter os endereços da carteira de outros hóspedes ou para verificar os ganhos do restaurante. Ou um terceiro (como a mídia social) que conhece o restaurante e o endereço da carteira de Alice pode facilmente deduzir o endereço residencial real de Alice e estudar suas transações passadas e futuras.
**O surgimento de protocolos que melhoram a privacidade visa resolver os problemas acima. Ele permite que os usuários depositem fundos no protocolo, usando um endereço, e retirem fundos do protocolo posteriormente, usando outro endereço. Todos os depósitos e retiradas ainda são visíveis na blockchain, mas a correspondência entre transferências e transferências específicas não é mais pública. **
Um dos protocolos de melhoria de privacidade mais conhecidos é o Tornado Cash. Ele resolve com sucesso os problemas acima, permitindo aos usuários manter alguma privacidade. No entanto, além de usuários legítimos que tentam proteger seus dados, o Tornado Cash também é usado por vários malfeitores. Os dados de depósito mostram que o grupo de hackers transferiu fundos através deste protocolo. As evidências sugerem que o grupo de hackers norte-coreano também usou esse protocolo de aprimoramento de privacidade, culminando com a colocação dos endereços de contratos inteligentes do protocolo na Lista de Nacionais Especialmente Designados e Pessoas Bloqueadas (comumente conhecida como Lista SDN) mantida pelo Escritório de Ativos Estrangeiros dos EUA. Controle (OFAC).
**O principal problema do Tornado Cash é a linha tênue entre usuários legítimos e usuários criminosos. **Portanto, o Tornado Cash oferece um recurso de compliance que permite aos usuários criar um comprovante de qual depósito veio de determinado saque. Embora este mecanismo permita às pessoas provar a sua inocência, fá-lo ao custo de ter de confiar num intermediário centralizado e de criar assimetrias de informação. No final das contas, o mecanismo quase não foi utilizado pelos usuários.
Este artigo discute uma extensão desta abordagem que permite aos usuários atestar publicamente informações sobre de quais depósitos podem ter vindo seus saques, sem perder a privacidade. **Privacy Pools propõe um conceito geral: permitir comprovante de adesão (“Certifico que meu saque veio de um desses depósitos”) ou comprovante de exclusão (“Certifico que meu saque não veio de nenhum desses depósitos”). **Este artigo discute esta proposta e explica como ela pode ser usada para alcançar um equilíbrio entre usuários honestos e desonestos.
Observe que os pools de privacidade fornecem opções adicionais ao estender o conjunto de ações do usuário. Eles ainda podem fornecer provas mais detalhadas a uma contraparte específica, se necessário. Em alguns casos, contudo, a prova de adesão ou exclusão pode ser suficiente. Além disso, a opção de divulgar publicamente estas provas tem uma série de vantagens sobre a divulgação bilateral.
2. Antecedentes Técnicos
Nesta seção, fornecemos uma breve visão geral técnica e discutimos os blocos de construção técnicos e os princípios gerais de protocolos como Privacy Pools.
1. Privacidade Blockchain antes dos ZK-SNARKs
Historicamente, os proponentes do blockchain argumentaram que, embora todas as transações sejam transparentes, os blockchains preservam a privacidade porque fornecem anonimato.
Com o advento de ferramentas modernas de agrupamento e análise, esta proteção da privacidade tornou-se insuficiente. Para melhorar a privacidade dos blockchains públicos, foram introduzidas técnicas mais fortes, como token joins e Monero. No entanto, estas tecnologias ainda apresentam o risco de fuga de dados. **
Isto foi seguido por tecnologias de uso geral à prova de conhecimento zero, como Zcash e Tornado Cash, que podem tornar o conjunto de anonimato de cada transação igual ao conjunto total de todas as transações anteriores. Esta técnica é frequentemente referida como ZK-SNARKs.
2、ZK-SNARKs
ZK-SNARKs são uma técnica que permite a um provador provar uma certa afirmação matemática sobre dados públicos e privados, ao mesmo tempo que satisfaz duas propriedades principais: conhecimento zero e simplicidade. **
● Conhecimento zero: Nenhuma informação sobre dados privados será revelada, exceto para provar que esses dados privados estão em conformidade com as reivindicações.
● Sucinta: as provas são curtas e verificáveis rapidamente, mesmo que as afirmações comprovadas exijam cálculos demorados.
Os ZK-SNARKs receberam ampla atenção da comunidade blockchain devido à sua importância na escalabilidade, como os ZK-rollups. Para aplicações de privacidade, a simplicidade não é particularmente importante, mas o conhecimento zero é essencial.
A "afirmação" provada pelos ZK-SNARKs pode ser vista como um tipo de programa denominado "circuito", que calcula o resultado de uma função f(x, w) com entradas públicas e privadas, e então prova que para um determinado público entrada x , existe uma entrada privada w tal que o resultado de f(x, w) é Verdadeiro.
3. Aplicação de ZK-SNARKs em sistemas como Zcash e Tornado Cash
Existem algumas pequenas diferenças entre as diferentes versões do Zcash e sistemas inspirados nele, como o Tornado Cash. No entanto, a lógica subjacente em que se baseiam é muito semelhante. Esta seção descreve uma versão simples que corresponde aproximadamente ao funcionamento desses protocolos.
Os tokens consistem em segredos mantidos por seus proprietários. Dois valores podem ser derivados de s:
● ID do token público L = hash(s + 1)
● anuladorU = hash(s + 2)
Entre eles, hash refere-se à função hash de senha, como SHA 256. Dados s, o ID do token e o zerador podem ser calculados. No entanto, dado um conjunto de zeradores e um ID de token público, o comportamento pseudoaleatório da função hash garante que você não possa determinar qual zerador está associado a qual ID de token, a menos que você conheça os secret s que geraram ambos.
A blockchain rastreia todos os IDs de token que foram “criados”, bem como todos os zeradores que foram “gastos”. Ambos os conjuntos estão em constante crescimento (a menos que o protocolo queira impor quando os tokens devem ser gastos).
Uma coleção de IDs de token é armazenada em uma estrutura de dados chamada árvore Merkle: se a árvore contém N itens, então cada item adjacente é hash (resultando em ⌈ N/2 ⌉ hashes), e cada adjacente Esses hashes são hash novamente (resultando em ⌈ N/4 ⌉ hashes), e assim por diante, até que todos os dados sejam confirmados em um único "hash raiz".
Dado um valor específico em uma árvore e um hash de raiz, você pode fornecer uma ramificação Merkle: "valores irmãos" que são agrupados em hash em cada etapa do caminho desse valor até a raiz. Este ramo Merkle é muito útil porque é um pequeno dado (log 2 (N) hashes) que pode ser usado para provar que qualquer valor específico está realmente na árvore. A figura abaixo mostra um exemplo de árvore Merkle com altura 4.
Quando os usuários enviam moedas para outras pessoas, eles fornecem o seguinte:
● O zerizer U que você deseja gastar
● Token ID L' do novo token que deseja criar (é solicitado que o destinatário forneça isso)
● Um ZK-SNARK.
ZK-SNARK contém as seguintes entradas privadas:
● Segredos do usuário
● Ramificação Merkle na árvore de ID do token, provando que o token com ID do token L = hash(s + 1) foi realmente criado em algum momento no passado
Ele também contém as seguintes entradas públicas:
● U, o zerador do token que está sendo gasto
● R, o hash raiz contra o qual a evidência Merkle está sendo direcionada
ZK-SNARK prova duas propriedades:
● U = hash(s + 2)
● A filial Merkle é válida
Além dos ZK-SNARKs, o protocolo verifica o seguinte:
● R é o hash raiz atual ou histórico da árvore de ID do token
● U não está no conjunto de zeradores gastos
Se a transação for válida, ela adiciona U ao conjunto de zeradores gastos e L' à lista de IDs de token. Mostrar U evita que um único token seja gasto duas vezes. No entanto, nenhuma outra informação será divulgada. **O mundo exterior só pode ver quando as transações são enviadas; eles não conseguem obter um padrão sobre quem envia ou recebe essas transações e não conseguem distinguir a fonte unificada dos tokens. **
Existem duas exceções ao padrão acima: depósitos e retiradas. Nos depósitos, os token IDs podem ser criados sem invalidar um determinado token anterior. Do ponto de vista da preservação da privacidade, os depósitos não são anônimos porque a associação entre um determinado L e um evento externo que permite a adição de L (no Tornado Cash, o depósito de ETH no sistema; no Zcash, a nova mineração de ZEC) é pública.
Em outras palavras, **os depósitos estão vinculados ao seu histórico de transações anteriores. **Em saques, um Zeroizer será consumido sem adição de um novo token ID. Isto pode desconectar os saques dos depósitos correspondentes e indiretamente do histórico de transações anteriores. No entanto, os saques podem estar vinculados a quaisquer transações futuras que ocorram após o evento de saque.
A primeira versão do Tornado Cash não tinha conceito de transferências internas, apenas permitia depósitos e saques. Versões posteriores, ainda em fase experimental, também permitiam transferências internas e moedas de diversos valores, incluindo suporte para operações de “divisão” e “fusão”. Discutiremos como estender o sistema básico de transferência de moedas de privacidade e o pool de privacidade para denominações arbitrárias em capítulos posteriores.
4. ZK-SNARKs no pool de privacidade
**A ideia central do pool de privacidade é que os usuários não apenas provem que o saque está associado a um depósito anterior por meio de prova de conhecimento zero, mas também provem que pertence a um conjunto de associação mais estrito. **A coleção associada pode ser um subconjunto de todos os depósitos feitos anteriormente, uma coleção contendo apenas os depósitos do próprio usuário ou qualquer coisa intermediária. Os usuários especificam o conjunto fornecendo a raiz Merkle do conjunto associado como uma entrada pública.
Como mostrado na figura abaixo, por uma questão de simplicidade, não provamos diretamente que o conjunto associado é de fato um subconjunto dos depósitos feitos anteriormente; em vez disso, apenas exigimos que o usuário use o mesmo ID de moeda que um nó folha para prove dois ramos de Merkle através de conhecimento zero:
● Insira o ramo Merkle da raiz R do conjunto total de IDs de moedas
● Insira a ramificação Merkle do conjunto de associações fornecido RA raiz
A intenção é colocar o conjunto completo de associações em algum lugar (talvez na cadeia). O conceito central é: em vez de exigir que os usuários especifiquem exatamente de qual depósito vieram seus saques ou, no outro extremo, não forneçam qualquer outra informação além de provar que não houve gastos duplos, permitimos que os usuários forneçam um conjunto de opções de quais fundos podem ter vindo, e esse conjunto pode ser tão amplo ou estreito quanto eles desejarem.
Incentivamos um ecossistema que facilite aos usuários a especificação de um conjunto de associações consistentes com suas preferências. O restante deste artigo descreverá apenas a infraestrutura baseada neste mecanismo central simples e suas consequências.
3. Considerações práticas e casos de uso
Analise como os protocolos de melhoria de privacidade são usados na prática do ponto de vista da aplicação.
1. Casos de uso para coleções associativas
Para ilustrar o valor deste programa num ambiente de aplicação da lei, aqui está um exemplo:
Suponha que temos cinco usuários: Alice, Bob, Carl, David, Eve. Os primeiros quatro usuários são honestos, cumpridores da lei, mas preocupados com a privacidade, enquanto Eve é uma ladra. Porque o público sabe que Eva é uma ladra através da informação de que as moedas do endereço marcado “Eva” foram roubadas. Na prática, isso acontece com bastante frequência: em blockchains públicos, os fundos gerados pelas vulnerabilidades exploradas nos protocolos DeFi são rastreados para identificar fundos ilícitos que fluem para o Tornado Cash.
Quando cada um dos cinco usuários faz um saque, eles podem escolher qual conjunto associado especificar. Seu conjunto de associação deve incluir seus próprios depósitos, mas eles são livres para escolher quais dos outros endereços incluir. Os primeiros quatro utilizadores foram motivados, por um lado, por quererem proteger a sua privacidade ao máximo possível. Isso os motiva a tender a aumentar seu conjunto de associações. Por outro lado, eles querem reduzir a chance de suas moedas serem vistas como suspeitas por comerciantes ou bolsas. Há uma maneira fácil de fazer isso: eles não incluem Eva na coleção associada. Portanto, para os quatro, a escolha é clara: deixe o conjunto de associação deles ser {Alice, Bob, Carl, David}.
É claro que Eva também deseja maximizar seu conjunto associativo. Mas ela não pode excluir os seus próprios depósitos, pelo que é forçada a ter o seu conjunto associativo igual ao conjunto de todos os cinco depósitos. A seleção da coleção associada de participantes é mostrada na figura abaixo.
Embora a própria Eva não tenha fornecido nenhuma informação, através de um simples processo de eliminação, podemos tirar uma inferência clara: a retirada do quinto passo só pode vir de Eva.
2. Construção de coleções associadas
A seção anterior ilustrou uma maneira possível de usar conjuntos associados em um protocolo semelhante a um pool de privacidade e como os participantes honestos podem ser separados dos ruins. Observe que o sistema não depende do altruísmo de Alice, Bob, Carl e David; eles têm incentivos claros para justificar a sua separação. Vejamos agora a construção de coleções associadas com mais detalhes. Normalmente, existem duas estratégias principais para gerar coleções de associações. Eles são descritos abaixo e visualizados na imagem abaixo.
● **Inclusão (ou adesão): **Identificar um conjunto específico de depósitos para os quais temos evidências conclusivas de que são de baixo risco e construir um conjunto associado que contenha apenas esses depósitos.
● Exclusão: Identifique um conjunto específico de depósitos para os quais temos evidências conclusivas de que são de alto risco e construa um conjunto associado que inclua todos os depósitos, exceto esses depósitos.
Na prática, os usuários não selecionam manualmente os depósitos para incluir na coleção associada. Em vez disso, os usuários assinarão intermediários que chamamos de Association Collection Providers (ASPs), que geram Association Collections com propriedades específicas. **Em alguns casos, os ASPs podem ser construídos inteiramente em cadeia, sem intervenção humana (ou IA). Em outros casos, os ASPs gerarão coleções de associações de forma independente e publicarão as coleções de associações na rede ou em outro lugar.
Recomendamos fortemente a publicação de pelo menos a raiz Merkle da coleção de associações na cadeia; isso elimina a capacidade de ASPs mal-intencionados de realizar certos tipos de ataques aos usuários (por exemplo, fornecer a diferentes usuários diferentes coleções de associações na tentativa de desanonimizá-los). . Toda a coleção deve ser disponibilizada através de uma API ou, idealmente, através de um sistema de armazenamento descentralizado de baixo custo, como o IPFS.
A possibilidade de descarregar todo o acervo da associação é importante porque permite aos utilizadores gerar localmente o comprovativo de adesão sem revelar qualquer informação adicional à ASP, nem mesmo os depósitos correspondentes aos seus levantamentos.
Veja como os ASPs podem ser estruturados na prática:
● Adição atrasada, excluindo agentes mal-intencionados: qualquer depósito é automaticamente adicionado à coleção associada após um período fixo (por exemplo, 7 dias), mas se o sistema detectar um depósito vinculado a mau comportamento conhecido (por exemplo, roubo em grande escala ou um endereço em uma lista de sanções publicada pelo governo), o depósito nunca será adicionado. Na prática, isto poderia ser alcançado através de coleções organizadas pela comunidade ou de prestadores de serviços de triagem de transações existentes que já realizam trabalho de identificação e rastreamento de depósitos associados a mau comportamento.
● Taxa Mensal para Pessoa Única: Para aderir à coleção associada, o valor do depósito deve ser inferior a um máximo fixo, e o depositante deve provar, com conhecimento zero, que possui algum token de identidade (por exemplo, por um governo. Apoiado sistemas nacionais de identificação ou mecanismos leves, como verificação de contas em redes sociais). Combinado com um parâmetro adicional que representa o mecanismo de scrapper do mês atual para garantir que cada identidade só possa enviar depósitos para a coleção associada uma vez por mês. O design tenta implementar o espírito de muitas regras comuns de AML, segundo as quais os micropagamentos abaixo de um determinado limite permitem um nível mais elevado de privacidade. Observe que isso pode ser implementado inteiramente como um contrato inteligente, sem necessidade de supervisão manual para manter a operação contínua.
● **Taxa mensal para membros da comunidade confiável: **Semelhante à taxa mensal para uma única pessoa, mas mais restritiva: os usuários devem provar que são membros de uma comunidade altamente confiável. Membros da comunidade altamente confiantes concordam em fornecer privacidade uns aos outros.
● **Pontuação em tempo real baseada em IA: **O sistema AI ASP pode fornecer uma pontuação de risco para cada depósito em tempo real, e o sistema produzirá um conjunto associado contendo depósitos com uma pontuação de risco abaixo de um determinado limite. Potencialmente, o ASP poderia gerar vários conjuntos correspondentes a vários limites de pontuação de risco.
4. Descrição técnica adicional
Nesta seção, analisamos como a proposta apoia denominações arbitrárias e discutimos casos especiais, como recertificação, certificação bilateral direta e certificação sequencial.
1. Apoie qualquer denominação
O sistema simplificado de moedas de proteção de privacidade acima só suporta transferências de moedas do mesmo valor. Zcash suporta denominações arbitrárias usando o modelo UTXO. Cada transação pode ter múltiplas entradas (é necessário publicar o zerador de cada entrada) e múltiplas saídas (é necessário publicar o ID do token de cada saída). Cada ID de token criado deve ser acompanhado de um valor de denominação criptográfica. Além de comprovar a validade do zerador, cada transação deve ser acompanhada de prova adicional de que a soma dos valores faciais das moedas criadas não excede a soma dos valores faciais das moedas gastas. A figura abaixo ilustra esta prova adicional.
Este design pode ser estendido para apoiar depósitos e retiradas, tratando os depósitos como entradas (não criptografadas) e as retiradas como saídas (não criptografadas). Além disso, o projeto pode ser restrito para simplificar a análise. Por exemplo, é possível permitir apenas saques parciais, permitindo que uma transação tenha uma entrada criptografada e duas saídas: uma saída não criptografada representando o saque, e uma saída "alteração" criptografada representando os fundos restantes que podem ser usados para saques futuros.
Uma questão natural é como estender esse design para suportar pools de privacidade. Inserí-lo inalterado no pool de privacidade não é o ideal porque o gráfico de transações não é consistente com o que esperamos intuitivamente: se um usuário deposita 10 tokens e depois gasta 1 + 2 + 3 + 4 em quatro tokens de saques consecutivos, queremos tratar cada dessas quatro retiradas como a fonte do depósito original de 10 tokens. Mas o resultado real é mostrado abaixo: a fonte da primeira retirada é o depósito de 10 tokens e, em seguida, a fonte da segunda retirada é a saída de alteração de 9 tokens criada pela primeira retirada, e assim por diante, por analogia. Isto causa problemas na prática porque exige que o ASP valide o depósito intermediário e o adicione à sua coleção associada.
Para que todos os quatro saques neste exemplo possam ter como fonte o depósito original de 10 moedas, precisamos resolver dois problemas:
● Garantir que cada retirada parcial não esteja publicamente vinculada a outras retiradas
● Permitir que cada saque parcial tenha o depósito como membro de seu conjunto associado
Se apoiarmos apenas saques parciais, em vez de transações MIMO mais complexas, e garantirmos que cada saque tenha um único “depósito original” correspondente definido, existem várias maneiras de conseguir isso diretamente. Uma abordagem natural e escalável é espalhar a promessa de algumas informações através de transações. Por exemplo, podemos exigir que a transação contenha um hash de compromisso (coinID+hash®), adicionar algum valor aleatório r para garantir o cegamento e exigir que ZK-SNARK prove que o compromisso na transação é o mesmo que sua transação pai. Se a transação principal for uma retirada, o compromisso será o mesmo que o ID da moeda do depósito original, e se a transação principal for um depósito, o compromisso será o mesmo que o ID da moeda do depósito original. Portanto, cada transação na cadeia deve conter um compromisso com o ID da moeda de depósito original e exigir prova de que esse valor está no conjunto associado fornecido pela transação.
Para melhorar a privacidade contra ataques de agregação de saldo, também podemos apoiar a fusão de moedas. Por exemplo, se eu tiver algumas moedas sobrando, posso fundi-las no meu próximo depósito. Para acomodar isso, podemos exigir que as transações sejam comprometidas com um conjunto de IDs de moedas e exigir que as transações com múltiplas entradas sejam comprometidas com a união de suas transações principais. Um saque conterá prova de que todos os IDs de moedas comprometidos estão em seu conjunto associado.
2. Circunstâncias especiais
● Recertificação: os usuários precisam de informações secretas de depósito para sacar depósitos semelhantes aos protocolos de pool de privacidade. A mesma informação secreta também é usada para construir provas de adesão ao conjunto de associações. Preservar informações secretas permite que os usuários gerem novas provas para ajustar diferentes conjuntos ou conjuntos associados atualizados. Isto dá aos utilizadores maior flexibilidade, mas também pode introduzir riscos adicionais.
● Certificação direta bilateral: Em alguns casos, os usuários podem ser obrigados a divulgar a fonte exata da retirada à outra parte. Os usuários podem criar uma coleção associada contendo apenas seus depósitos e gerar comprovantes dessa coleção. Estas provas são geralmente exceções e só contribuem para a privacidade parcial quando partilhadas entre duas partes. No entanto, a partilha de provas requer o estabelecimento de fortes pressupostos de confiança.
● Prova de Sequência: Em uma economia de transações rápidas que usa um sistema semelhante a um pool de privacidade, o protocolo precisa ser modificado para acomodar esse ambiente. Além dos tipos de transações de depósito e retirada, o protocolo também precisa oferecer suporte a operações de envio internas para maior eficiência. Além disso, ao passar garfos e chaves Merkle, os usuários podem divulgar informações relacionadas ao histórico de transações para que os destinatários possam verificar a origem dos fundos. Isso garante que cada usuário tenha as informações mínimas necessárias para ter confiança nos recursos recebidos.
Na prática, uma moeda pode ter múltiplas “origens”. Por exemplo, Bob é dono de uma cafeteria e recebe 5 fichas de Alice, 4 fichas de Ashley, 7 fichas de Anne e, no final do dia, ele precisa pagar 15 fichas a Carl para pagar o jantar. Em vez disso, David pode ter recebido 15 tokens de Carl, 25 tokens de Chris e querer depositar 30 tokens para Emma (uma troca). Nestes casos mais complexos, seguimos o mesmo princípio: a história que foi adicionada à colecção associada há muito tempo pode ser ignorada, enquanto a história mais recente precisa de ser transmitida.
Cinco, mais detalhes
Um sistema semelhante a um pool de privacidade poderia permitir que os usuários ganhassem mais proteção na privacidade de seus dados de transações financeiras, mantendo ao mesmo tempo a capacidade de provar a separação de atividades ilícitas conhecidas. Esperamos que os utilizadores honestos sejam incentivados a participar em tais esquemas através de uma combinação de dois factores:
● Desejo de privacidade
● Desejo de evitar levantar suspeitas
1. Consenso social e coleta associativa
Se houvesse consenso completo sobre se os fundos eram bons ou maus, o sistema produziria um equilíbrio de separação simples. Todos os usuários com ativos “bons” têm um forte incentivo e capacidade para provar que pertencem a um conjunto de associações “somente bons”. Os maus atores, por outro lado, não serão capazes de fornecer esta prova. Eles ainda podem depositar fundos “ruins” no pool, mas isso não lhes fará nenhum bem. Todos podem facilmente determinar que os fundos foram retirados de um protocolo com maior privacidade e ver que a retirada faz referência a uma coleção associada contendo depósitos de fontes questionáveis. Além do mais, o dinheiro “ruim” não mancha o dinheiro “bom”. Quando os fundos são retirados de depósitos legítimos, seus proprietários podem simplesmente excluir todos os depósitos “ruins” conhecidos de sua coleção associada.
Onde existe consenso global, e onde as conclusões sobre se o financiamento é considerado “bom” ou “mau” dependem da perspectiva social ou da jurisdição, o conjunto de associações pode variar significativamente. Suponha que existam duas jurisdições com conjuntos de regras diferentes. As entidades nas jurisdições A e B podem usar o mesmo acordo de melhoria de privacidade e optar por emitir certificações que atendam aos requisitos de suas respectivas jurisdições. Ambos podem implementar facilmente a privacidade nas suas próprias coleções associadas e excluir retiradas que não cumpram os requisitos das suas respetivas jurisdições. Se necessário, pode ser emitido um comprovativo de adesão para a intersecção de dois conjuntos associados, comprovando assim de forma fiável que os depósitos correspondentes aos seus levantamentos cumprem os requisitos de ambas as jurisdições.
Por conseguinte, a proposta é muito flexível e deve ser considerada uma infra-estrutura neutra. Por um lado, combate a censura. Ele permite que qualquer pessoa participe de uma coleção afiliada de sua escolha e permaneça privada em sua própria comunidade. Por outro lado, terceiros podem solicitar certificação para um conjunto específico de associações que cumpram os seus requisitos regulamentares. Assim, mesmo que exista uma comunidade de maus atores num protocolo de reforço da privacidade, estes não serão capazes de ocultar a origem suspeita dos depósitos, desde que a informação seja refletida com precisão na construção do conjunto associado.
2. Propriedades das coleções associadas
As coleções associativas precisam ter certas propriedades para funcionar. As cobranças precisam ser precisas para que os usuários possam confiar que estão usando os fundos retirados com segurança. Além disso, as propriedades de cada conjunto devem ser estáveis, ou seja, menos propensas a mudar ao longo do tempo. Isso reduz a necessidade de retiradas de revalidação de novas coleções. Finalmente, para alcançar uma protecção significativa da privacidade, o conjunto de associações deve ser suficientemente grande e conter vários tipos de depósitos. No entanto, essas propriedades entram em conflito entre si. Em geral, coleções grandes e diversas podem ter melhores propriedades de privacidade, mas podem ser menos precisas e estáveis, enquanto coleções menores são mais fáceis de manter, mas proporcionam menos privacidade.
3. Considerações práticas e concorrência
As entidades reguladas que aceitam criptoativos devem garantir que as leis e regulamentos a que estão sujeitas permitem a aceitação de tais fundos. Hoje, muitas destas entidades dependem das chamadas ferramentas de triagem de transações: software ou serviços que analisam a blockchain para identificar atividades potencialmente suspeitas, ligações a endereços ilegítimos ou transações não conformes. As ferramentas de triagem muitas vezes expressam o risco associado a cada negociação através de uma pontuação de risco. Esta classificação é baseada no destino dos fundos transferidos e no seu histórico de transações. Os protocolos que melhoram a privacidade podem representar desafios a este respeito. Eliminam a ligação visível entre depósitos e levantamentos. Portanto, na presença de protocolos que melhoram a privacidade, a pontuação de risco precisa levar em conta o atestado e atribuir uma pontuação baseada no conjunto de associações.
Ferramentas e serviços para triagem de transações são fornecidos principalmente por empresas profissionais com experiência em análise de blockchain e áreas jurídicas relacionadas. Idealmente, estas empresas (e qualquer outra pessoa) teriam acesso a todos os certificados de adesão e às suas coleções associadas correspondentes para fornecer pontuações de risco precisas para todas as transações. Portanto, recomendamos que todas as provas sejam armazenadas no blockchain ou em outro repositório de provas acessível ao público. A única exceção é um certificado de adesão de tamanho único compartilhado com uma contraparte específica. Por razões óbvias, estes testemunhos não devem ser tornados públicos.
O armazenamento de provas diretamente na cadeia acrescenta custos de transação adicionais, mas reduz os esforços de coordenação, torna a concorrência mais justa e mitiga os riscos de quase monopólio que os fornecedores de ferramentas de triagem podem criar devido ao conhecimento de provas não públicas.
As configurações gerais de um pool de privacidade são muito flexíveis. O protocolo pode ser personalizado para vários casos de uso, criando coleções específicas de associações. Aqui estão dois exemplos dessas coleções de associações especiais:
● **Alianças de bancos comerciais podem criar uma coleção associada contendo apenas os depósitos de seus clientes. **Isso garante que o comprovante de quaisquer saques criados para a cobrança passou pelos procedimentos Know Your Customer (KYC) e Anti-Lavagem de Dinheiro (AML) em um dos bancos participantes, mas não revela qual saque pertence a qual cliente.
● **Nos casos em que os intermediários financeiros são obrigados a documentar claramente a origem dos fundos, podem exigir que os utilizadores forneçam provas contra um conjunto associado que contenha apenas os depósitos dos utilizadores. **Essa prova será então trocada bilateralmente com o intermediário, permitindo-lhe rastrear os fundos como se o usuário nunca tivesse usado o pool de privacidade. Embora isto exija que os utilizadores confiem no intermediário para não revelar a prova, idealmente permite que os utilizadores cumpram os regulamentos sem revelar a informação ao público.
4. Escolhas e alternativas de design
As configurações baseadas em conjuntos de associação, provas zk e divulgações voluntárias são flexíveis. Embora isto seja muito útil para garantir que a proposta possa ser adaptada a diferentes jurisdições, deve ter-se muito cuidado no que diz respeito às escolhas específicas de concepção. Em particular, existem dois ajustamentos potenciais aos quais nos opomos. Acreditamos que são problemáticos em termos de requisitos de confiança e podem criar estruturas de mercado quase monopolistas. Abaixo descrevemos e discutimos brevemente essas alternativas:
● Acesso centralizado: agências de aplicação da lei, provedores de pontuação de risco de criptografia ou atores semelhantes podem obter acesso para visualizar links entre transações de usuários, mantendo a privacidade de outras pessoas.
● **Lista de permissões em todo o sistema: **Os sistemas de privacidade podem impor restrições aos tipos de usuários que podem depositar moedas em seus pools, exigindo que eles forneçam provas adicionais ou exigindo que os depósitos esperem por um período de tempo durante o qual a pontuação de risco centralizada sistema pode negar depósitos.
Os dois métodos são semelhantes porque concedem privilégios a entidades específicas. Isto levanta questões complexas de governação: Quem tem acesso a esta informação? Quem tem o poder de gerenciar permissões? As empresas privadas não parecem ser uma boa opção, pois quaisquer privilégios podem criar uma estrutura de mercado oligopolista, onde algumas empresas têm acesso aos dados que lhes permitem fornecer estes serviços, enquanto outras não conseguem competir.
Da mesma forma, muitas questões políticas e de governação serão enfrentadas ao delegar poderes a instituições públicas, especialmente em contextos internacionais. Mesmo que uma instituição seja 100% confiável até agora, não abuse do seu poder para prosseguir uma agenda política e não seja dependente de outras entidades que possam obrigá-la a abusar do seu poder, esta situação é uma manifestação de estagnação. Com o tempo, as organizações, os membros, os países e as estruturas políticas dentro das organizações mudam. Poderão existir pressões externas e a existência destes privilégios poderá criar incentivos adicionais para perturbar e ganhar influência sobre o sistema de governação da organização.
Além disso, ataques dentro ou fora da organização, ou erros em nome de uma entidade centralizada, podem ter consequências de longo alcance. Acreditamos que a criação de tais pontos de falha centralizados deve ser evitada.
Dito isto, reconhecemos que diferentes tamanhos e circunstâncias de transações podem exigir diferentes combinações de certificações. Por exemplo, para grandes transações, muitos utilizadores podem acabar por fornecer provas básicas de exclusão na cadeia e fornecer informações mais detalhadas sobre a origem dos fundos às suas contrapartes.
5. Direção da pesquisa aprofundada
Embora este estudo forneça uma visão geral de como os protocolos de aprimoramento de privacidade baseados em zkSNARK podem ser usados em ambientes regulamentados, há vários aspectos que merecem um estudo mais aprofundado.
Primeiro, é preciso perceber que a privacidade obtida através destes protocolos depende de muitos fatores diferentes. Os invasores podem associar retiradas a depósitos específicos com base em um conjunto de associações insuficientemente grande, seleção de raiz inadequada e erro do usuário.
Além disso, as escolhas de outros usuários podem afetar negativamente a sua própria privacidade. Em casos extremos, todos os outros membros do pool publicariam uma prova de adesão de tamanho um, revelando uma ligação direta entre os seus depósitos e levantamentos. Obviamente, isto revelará implicitamente a ligação entre as únicas transações restantes de depósito e retirada. Num exemplo mais subtil, as restrições de várias provas de adesão podem ser utilizadas para extrair informações e potencialmente correlacionar depósitos e levantamentos com alta probabilidade. Uma vez que essas informações atestadas sejam combinadas com os metadados da transação, as propriedades de privacidade do protocolo podem ser comprometidas.
Finalmente, um ASP malicioso poderia optar por compilar o conjunto de associações proposto de uma forma que lhe permitisse maximizar a extração de informações ou aumentar o anonimato percebido, adicionando depósitos onde as retiradas correspondentes são conhecidas. Todas estas questões requerem mais pesquisas para avaliar as propriedades de privacidade fornecidas. Na mesma linha, seria interessante investigar mais aprofundadamente as propriedades de separação de equilíbrios, modelando como os bons e os maus jogadores se comportam sob certas suposições e como a prova pública dos primeiros afeta a privacidade dos últimos.
Os especialistas jurídicos podem pesquisar mais detalhadamente os requisitos de divulgação específicos. Os cenários apresentados neste documento são flexíveis e os insights de especialistas jurídicos podem ajudar a adaptar o acordo e o ecossistema construído em torno dele para garantir a conformidade em diversas jurisdições legais.
6. Conclusão
Em muitos casos, considera-se que a privacidade e a conformidade estão em conflito entre si. Este artigo propõe que este não seja necessariamente o caso se os protocolos de reforço da privacidade permitirem aos utilizadores provar certos atributos da origem dos seus fundos. Por exemplo, presume-se que os utilizadores possam provar que os seus fundos não estão ligados a depósitos de fontes ilícitas conhecidas, ou que os fundos fazem parte de uma coleção específica de depósitos, sem revelar qualquer informação adicional.
Tal configuração pode produzir um equilíbrio de separação no qual os utilizadores honestos são fortemente incentivados a provar que pertencem a algum conjunto de associações compatíveis e a manter a privacidade dentro desse conjunto. Em contrapartida, para utilizadores desonestos, não podem fornecer tal prova. Isso permite que usuários honestos se dissociem de depósitos de terceiros com os quais discordam ou os impeça de usar seus fundos em um ambiente compatível. Acreditamos que a proposta é flexível e pode ser adaptada a vários requisitos regulamentares.
Este artigo deve ser considerado uma contribuição para a potencial coexistência futura de privacidade e regulamentação financeira. Queremos facilitar as discussões e orientar a conversa numa direção mais positiva e construtiva. Será necessária a colaboração entre profissionais, académicos de diversas disciplinas, decisores políticos e reguladores para expandir e rever esta proposta; o objectivo final é criar infra-estruturas que melhorem a privacidade que possam ser utilizadas em ambientes regulamentados.
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.
Artigo mais recente de Buterin: Como o protocolo de pool de privacidade protege a privacidade do usuário e atende aos requisitos de conformidade?
原文：《Privacidade do Blockchain e Conformidade Regulatória: Rumo a um Equilíbrio Prático》
De: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar e Ameen Soleimani
Compilado por: Odaily Planet Daily Husband How
Hoje, Buterin e outros escreveram em conjunto um artigo de pesquisa sobre protocolos de privacidade, intitulado "Privacidade do Blockchain e conformidade regulatória: rumo a um equilíbrio prático".
O artigo descreve um novo protocolo de aumento de privacidade baseado em contratos inteligentes - pool de privacidade, discute suas vantagens e desvantagens e mostra como ele equilibra usuários honestos e usuários desonestos. O protocolo foi projetado para usar provas de conhecimento zero para verificar a legitimidade dos fundos dos usuários sem revelar seu histórico completo de transações, equilibrando requisitos regulatórios e de privacidade enquanto filtra fundos associados a atividades criminosas.
Odaily Planet Daily agora compila a essência do artigo da seguinte forma.
I. Introdução
Blockchains públicos são transparentes por design. A ideia básica é que qualquer pessoa pode optar por verificar as transações sem ter de depender de um terceiro centralizado; ao reduzir as dependências, fornece uma base neutra para uma variedade de aplicações, incluindo, entre outras, finanças e identidade autossoberana.
No entanto, do ponto de vista da privacidade, os conjuntos de dados públicos possuem todas as transações que contêm todos os endereços da blockchain. Sempre que alguém transfere um ativo para outro endereço, ou interage com um contrato inteligente, essa transação estará sempre visível na blockchain. Isto claramente não está de acordo com os requisitos de privacidade.
Exemplo: Alice paga o jantar em um restaurante com uma carteira blockchain. O beneficiário agora conhece o endereço de Alice e pode analisar todas as atividades passadas e futuras nesse endereço. Da mesma forma, Alice agora sabe o endereço da carteira do restaurante e pode usar essas informações para obter os endereços da carteira de outros hóspedes ou para verificar os ganhos do restaurante. Ou um terceiro (como a mídia social) que conhece o restaurante e o endereço da carteira de Alice pode facilmente deduzir o endereço residencial real de Alice e estudar suas transações passadas e futuras.
**O surgimento de protocolos que melhoram a privacidade visa resolver os problemas acima. Ele permite que os usuários depositem fundos no protocolo, usando um endereço, e retirem fundos do protocolo posteriormente, usando outro endereço. Todos os depósitos e retiradas ainda são visíveis na blockchain, mas a correspondência entre transferências e transferências específicas não é mais pública. **
Um dos protocolos de melhoria de privacidade mais conhecidos é o Tornado Cash. Ele resolve com sucesso os problemas acima, permitindo aos usuários manter alguma privacidade. No entanto, além de usuários legítimos que tentam proteger seus dados, o Tornado Cash também é usado por vários malfeitores. Os dados de depósito mostram que o grupo de hackers transferiu fundos através deste protocolo. As evidências sugerem que o grupo de hackers norte-coreano também usou esse protocolo de aprimoramento de privacidade, culminando com a colocação dos endereços de contratos inteligentes do protocolo na Lista de Nacionais Especialmente Designados e Pessoas Bloqueadas (comumente conhecida como Lista SDN) mantida pelo Escritório de Ativos Estrangeiros dos EUA. Controle (OFAC).
**O principal problema do Tornado Cash é a linha tênue entre usuários legítimos e usuários criminosos. **Portanto, o Tornado Cash oferece um recurso de compliance que permite aos usuários criar um comprovante de qual depósito veio de determinado saque. Embora este mecanismo permita às pessoas provar a sua inocência, fá-lo ao custo de ter de confiar num intermediário centralizado e de criar assimetrias de informação. No final das contas, o mecanismo quase não foi utilizado pelos usuários.
Este artigo discute uma extensão desta abordagem que permite aos usuários atestar publicamente informações sobre de quais depósitos podem ter vindo seus saques, sem perder a privacidade. **Privacy Pools propõe um conceito geral: permitir comprovante de adesão (“Certifico que meu saque veio de um desses depósitos”) ou comprovante de exclusão (“Certifico que meu saque não veio de nenhum desses depósitos”). **Este artigo discute esta proposta e explica como ela pode ser usada para alcançar um equilíbrio entre usuários honestos e desonestos.
Observe que os pools de privacidade fornecem opções adicionais ao estender o conjunto de ações do usuário. Eles ainda podem fornecer provas mais detalhadas a uma contraparte específica, se necessário. Em alguns casos, contudo, a prova de adesão ou exclusão pode ser suficiente. Além disso, a opção de divulgar publicamente estas provas tem uma série de vantagens sobre a divulgação bilateral.
2. Antecedentes Técnicos
Nesta seção, fornecemos uma breve visão geral técnica e discutimos os blocos de construção técnicos e os princípios gerais de protocolos como Privacy Pools.
1. Privacidade Blockchain antes dos ZK-SNARKs
Historicamente, os proponentes do blockchain argumentaram que, embora todas as transações sejam transparentes, os blockchains preservam a privacidade porque fornecem anonimato.
Com o advento de ferramentas modernas de agrupamento e análise, esta proteção da privacidade tornou-se insuficiente. Para melhorar a privacidade dos blockchains públicos, foram introduzidas técnicas mais fortes, como token joins e Monero. No entanto, estas tecnologias ainda apresentam o risco de fuga de dados. **
Isto foi seguido por tecnologias de uso geral à prova de conhecimento zero, como Zcash e Tornado Cash, que podem tornar o conjunto de anonimato de cada transação igual ao conjunto total de todas as transações anteriores. Esta técnica é frequentemente referida como ZK-SNARKs.
2、ZK-SNARKs
ZK-SNARKs são uma técnica que permite a um provador provar uma certa afirmação matemática sobre dados públicos e privados, ao mesmo tempo que satisfaz duas propriedades principais: conhecimento zero e simplicidade. **
● Conhecimento zero: Nenhuma informação sobre dados privados será revelada, exceto para provar que esses dados privados estão em conformidade com as reivindicações.
● Sucinta: as provas são curtas e verificáveis rapidamente, mesmo que as afirmações comprovadas exijam cálculos demorados.
Os ZK-SNARKs receberam ampla atenção da comunidade blockchain devido à sua importância na escalabilidade, como os ZK-rollups. Para aplicações de privacidade, a simplicidade não é particularmente importante, mas o conhecimento zero é essencial.
A "afirmação" provada pelos ZK-SNARKs pode ser vista como um tipo de programa denominado "circuito", que calcula o resultado de uma função f(x, w) com entradas públicas e privadas, e então prova que para um determinado público entrada x , existe uma entrada privada w tal que o resultado de f(x, w) é Verdadeiro.
3. Aplicação de ZK-SNARKs em sistemas como Zcash e Tornado Cash
Existem algumas pequenas diferenças entre as diferentes versões do Zcash e sistemas inspirados nele, como o Tornado Cash. No entanto, a lógica subjacente em que se baseiam é muito semelhante. Esta seção descreve uma versão simples que corresponde aproximadamente ao funcionamento desses protocolos.
Os tokens consistem em segredos mantidos por seus proprietários. Dois valores podem ser derivados de s:
● ID do token público L = hash(s + 1)
● anuladorU = hash(s + 2)
Entre eles, hash refere-se à função hash de senha, como SHA 256. Dados s, o ID do token e o zerador podem ser calculados. No entanto, dado um conjunto de zeradores e um ID de token público, o comportamento pseudoaleatório da função hash garante que você não possa determinar qual zerador está associado a qual ID de token, a menos que você conheça os secret s que geraram ambos.
A blockchain rastreia todos os IDs de token que foram “criados”, bem como todos os zeradores que foram “gastos”. Ambos os conjuntos estão em constante crescimento (a menos que o protocolo queira impor quando os tokens devem ser gastos).
Uma coleção de IDs de token é armazenada em uma estrutura de dados chamada árvore Merkle: se a árvore contém N itens, então cada item adjacente é hash (resultando em ⌈ N/2 ⌉ hashes), e cada adjacente Esses hashes são hash novamente (resultando em ⌈ N/4 ⌉ hashes), e assim por diante, até que todos os dados sejam confirmados em um único "hash raiz".
Dado um valor específico em uma árvore e um hash de raiz, você pode fornecer uma ramificação Merkle: "valores irmãos" que são agrupados em hash em cada etapa do caminho desse valor até a raiz. Este ramo Merkle é muito útil porque é um pequeno dado (log 2 (N) hashes) que pode ser usado para provar que qualquer valor específico está realmente na árvore. A figura abaixo mostra um exemplo de árvore Merkle com altura 4.
Quando os usuários enviam moedas para outras pessoas, eles fornecem o seguinte:
● O zerizer U que você deseja gastar
● Token ID L' do novo token que deseja criar (é solicitado que o destinatário forneça isso)
● Um ZK-SNARK.
ZK-SNARK contém as seguintes entradas privadas:
● Segredos do usuário
● Ramificação Merkle na árvore de ID do token, provando que o token com ID do token L = hash(s + 1) foi realmente criado em algum momento no passado
Ele também contém as seguintes entradas públicas:
● U, o zerador do token que está sendo gasto
● R, o hash raiz contra o qual a evidência Merkle está sendo direcionada
ZK-SNARK prova duas propriedades:
● U = hash(s + 2)
● A filial Merkle é válida
Além dos ZK-SNARKs, o protocolo verifica o seguinte:
● R é o hash raiz atual ou histórico da árvore de ID do token
● U não está no conjunto de zeradores gastos
Se a transação for válida, ela adiciona U ao conjunto de zeradores gastos e L' à lista de IDs de token. Mostrar U evita que um único token seja gasto duas vezes. No entanto, nenhuma outra informação será divulgada. **O mundo exterior só pode ver quando as transações são enviadas; eles não conseguem obter um padrão sobre quem envia ou recebe essas transações e não conseguem distinguir a fonte unificada dos tokens. **
Existem duas exceções ao padrão acima: depósitos e retiradas. Nos depósitos, os token IDs podem ser criados sem invalidar um determinado token anterior. Do ponto de vista da preservação da privacidade, os depósitos não são anônimos porque a associação entre um determinado L e um evento externo que permite a adição de L (no Tornado Cash, o depósito de ETH no sistema; no Zcash, a nova mineração de ZEC) é pública.
Em outras palavras, **os depósitos estão vinculados ao seu histórico de transações anteriores. **Em saques, um Zeroizer será consumido sem adição de um novo token ID. Isto pode desconectar os saques dos depósitos correspondentes e indiretamente do histórico de transações anteriores. No entanto, os saques podem estar vinculados a quaisquer transações futuras que ocorram após o evento de saque.
A primeira versão do Tornado Cash não tinha conceito de transferências internas, apenas permitia depósitos e saques. Versões posteriores, ainda em fase experimental, também permitiam transferências internas e moedas de diversos valores, incluindo suporte para operações de “divisão” e “fusão”. Discutiremos como estender o sistema básico de transferência de moedas de privacidade e o pool de privacidade para denominações arbitrárias em capítulos posteriores.
4. ZK-SNARKs no pool de privacidade
**A ideia central do pool de privacidade é que os usuários não apenas provem que o saque está associado a um depósito anterior por meio de prova de conhecimento zero, mas também provem que pertence a um conjunto de associação mais estrito. **A coleção associada pode ser um subconjunto de todos os depósitos feitos anteriormente, uma coleção contendo apenas os depósitos do próprio usuário ou qualquer coisa intermediária. Os usuários especificam o conjunto fornecendo a raiz Merkle do conjunto associado como uma entrada pública.
Como mostrado na figura abaixo, por uma questão de simplicidade, não provamos diretamente que o conjunto associado é de fato um subconjunto dos depósitos feitos anteriormente; em vez disso, apenas exigimos que o usuário use o mesmo ID de moeda que um nó folha para prove dois ramos de Merkle através de conhecimento zero:
● Insira o ramo Merkle da raiz R do conjunto total de IDs de moedas
● Insira a ramificação Merkle do conjunto de associações fornecido RA raiz
A intenção é colocar o conjunto completo de associações em algum lugar (talvez na cadeia). O conceito central é: em vez de exigir que os usuários especifiquem exatamente de qual depósito vieram seus saques ou, no outro extremo, não forneçam qualquer outra informação além de provar que não houve gastos duplos, permitimos que os usuários forneçam um conjunto de opções de quais fundos podem ter vindo, e esse conjunto pode ser tão amplo ou estreito quanto eles desejarem.
Incentivamos um ecossistema que facilite aos usuários a especificação de um conjunto de associações consistentes com suas preferências. O restante deste artigo descreverá apenas a infraestrutura baseada neste mecanismo central simples e suas consequências.
3. Considerações práticas e casos de uso
Analise como os protocolos de melhoria de privacidade são usados na prática do ponto de vista da aplicação.
1. Casos de uso para coleções associativas
Para ilustrar o valor deste programa num ambiente de aplicação da lei, aqui está um exemplo:
Suponha que temos cinco usuários: Alice, Bob, Carl, David, Eve. Os primeiros quatro usuários são honestos, cumpridores da lei, mas preocupados com a privacidade, enquanto Eve é uma ladra. Porque o público sabe que Eva é uma ladra através da informação de que as moedas do endereço marcado “Eva” foram roubadas. Na prática, isso acontece com bastante frequência: em blockchains públicos, os fundos gerados pelas vulnerabilidades exploradas nos protocolos DeFi são rastreados para identificar fundos ilícitos que fluem para o Tornado Cash.
Quando cada um dos cinco usuários faz um saque, eles podem escolher qual conjunto associado especificar. Seu conjunto de associação deve incluir seus próprios depósitos, mas eles são livres para escolher quais dos outros endereços incluir. Os primeiros quatro utilizadores foram motivados, por um lado, por quererem proteger a sua privacidade ao máximo possível. Isso os motiva a tender a aumentar seu conjunto de associações. Por outro lado, eles querem reduzir a chance de suas moedas serem vistas como suspeitas por comerciantes ou bolsas. Há uma maneira fácil de fazer isso: eles não incluem Eva na coleção associada. Portanto, para os quatro, a escolha é clara: deixe o conjunto de associação deles ser {Alice, Bob, Carl, David}.
É claro que Eva também deseja maximizar seu conjunto associativo. Mas ela não pode excluir os seus próprios depósitos, pelo que é forçada a ter o seu conjunto associativo igual ao conjunto de todos os cinco depósitos. A seleção da coleção associada de participantes é mostrada na figura abaixo.
Embora a própria Eva não tenha fornecido nenhuma informação, através de um simples processo de eliminação, podemos tirar uma inferência clara: a retirada do quinto passo só pode vir de Eva.
2. Construção de coleções associadas
A seção anterior ilustrou uma maneira possível de usar conjuntos associados em um protocolo semelhante a um pool de privacidade e como os participantes honestos podem ser separados dos ruins. Observe que o sistema não depende do altruísmo de Alice, Bob, Carl e David; eles têm incentivos claros para justificar a sua separação. Vejamos agora a construção de coleções associadas com mais detalhes. Normalmente, existem duas estratégias principais para gerar coleções de associações. Eles são descritos abaixo e visualizados na imagem abaixo.
● **Inclusão (ou adesão): **Identificar um conjunto específico de depósitos para os quais temos evidências conclusivas de que são de baixo risco e construir um conjunto associado que contenha apenas esses depósitos.
● Exclusão: Identifique um conjunto específico de depósitos para os quais temos evidências conclusivas de que são de alto risco e construa um conjunto associado que inclua todos os depósitos, exceto esses depósitos.
Na prática, os usuários não selecionam manualmente os depósitos para incluir na coleção associada. Em vez disso, os usuários assinarão intermediários que chamamos de Association Collection Providers (ASPs), que geram Association Collections com propriedades específicas. **Em alguns casos, os ASPs podem ser construídos inteiramente em cadeia, sem intervenção humana (ou IA). Em outros casos, os ASPs gerarão coleções de associações de forma independente e publicarão as coleções de associações na rede ou em outro lugar.
Recomendamos fortemente a publicação de pelo menos a raiz Merkle da coleção de associações na cadeia; isso elimina a capacidade de ASPs mal-intencionados de realizar certos tipos de ataques aos usuários (por exemplo, fornecer a diferentes usuários diferentes coleções de associações na tentativa de desanonimizá-los). . Toda a coleção deve ser disponibilizada através de uma API ou, idealmente, através de um sistema de armazenamento descentralizado de baixo custo, como o IPFS.
A possibilidade de descarregar todo o acervo da associação é importante porque permite aos utilizadores gerar localmente o comprovativo de adesão sem revelar qualquer informação adicional à ASP, nem mesmo os depósitos correspondentes aos seus levantamentos.
Veja como os ASPs podem ser estruturados na prática:
● Adição atrasada, excluindo agentes mal-intencionados: qualquer depósito é automaticamente adicionado à coleção associada após um período fixo (por exemplo, 7 dias), mas se o sistema detectar um depósito vinculado a mau comportamento conhecido (por exemplo, roubo em grande escala ou um endereço em uma lista de sanções publicada pelo governo), o depósito nunca será adicionado. Na prática, isto poderia ser alcançado através de coleções organizadas pela comunidade ou de prestadores de serviços de triagem de transações existentes que já realizam trabalho de identificação e rastreamento de depósitos associados a mau comportamento.
● Taxa Mensal para Pessoa Única: Para aderir à coleção associada, o valor do depósito deve ser inferior a um máximo fixo, e o depositante deve provar, com conhecimento zero, que possui algum token de identidade (por exemplo, por um governo. Apoiado sistemas nacionais de identificação ou mecanismos leves, como verificação de contas em redes sociais). Combinado com um parâmetro adicional que representa o mecanismo de scrapper do mês atual para garantir que cada identidade só possa enviar depósitos para a coleção associada uma vez por mês. O design tenta implementar o espírito de muitas regras comuns de AML, segundo as quais os micropagamentos abaixo de um determinado limite permitem um nível mais elevado de privacidade. Observe que isso pode ser implementado inteiramente como um contrato inteligente, sem necessidade de supervisão manual para manter a operação contínua.
● **Taxa mensal para membros da comunidade confiável: **Semelhante à taxa mensal para uma única pessoa, mas mais restritiva: os usuários devem provar que são membros de uma comunidade altamente confiável. Membros da comunidade altamente confiantes concordam em fornecer privacidade uns aos outros.
● **Pontuação em tempo real baseada em IA: **O sistema AI ASP pode fornecer uma pontuação de risco para cada depósito em tempo real, e o sistema produzirá um conjunto associado contendo depósitos com uma pontuação de risco abaixo de um determinado limite. Potencialmente, o ASP poderia gerar vários conjuntos correspondentes a vários limites de pontuação de risco.
4. Descrição técnica adicional
Nesta seção, analisamos como a proposta apoia denominações arbitrárias e discutimos casos especiais, como recertificação, certificação bilateral direta e certificação sequencial.
1. Apoie qualquer denominação
O sistema simplificado de moedas de proteção de privacidade acima só suporta transferências de moedas do mesmo valor. Zcash suporta denominações arbitrárias usando o modelo UTXO. Cada transação pode ter múltiplas entradas (é necessário publicar o zerador de cada entrada) e múltiplas saídas (é necessário publicar o ID do token de cada saída). Cada ID de token criado deve ser acompanhado de um valor de denominação criptográfica. Além de comprovar a validade do zerador, cada transação deve ser acompanhada de prova adicional de que a soma dos valores faciais das moedas criadas não excede a soma dos valores faciais das moedas gastas. A figura abaixo ilustra esta prova adicional.
Este design pode ser estendido para apoiar depósitos e retiradas, tratando os depósitos como entradas (não criptografadas) e as retiradas como saídas (não criptografadas). Além disso, o projeto pode ser restrito para simplificar a análise. Por exemplo, é possível permitir apenas saques parciais, permitindo que uma transação tenha uma entrada criptografada e duas saídas: uma saída não criptografada representando o saque, e uma saída "alteração" criptografada representando os fundos restantes que podem ser usados para saques futuros.
Uma questão natural é como estender esse design para suportar pools de privacidade. Inserí-lo inalterado no pool de privacidade não é o ideal porque o gráfico de transações não é consistente com o que esperamos intuitivamente: se um usuário deposita 10 tokens e depois gasta 1 + 2 + 3 + 4 em quatro tokens de saques consecutivos, queremos tratar cada dessas quatro retiradas como a fonte do depósito original de 10 tokens. Mas o resultado real é mostrado abaixo: a fonte da primeira retirada é o depósito de 10 tokens e, em seguida, a fonte da segunda retirada é a saída de alteração de 9 tokens criada pela primeira retirada, e assim por diante, por analogia. Isto causa problemas na prática porque exige que o ASP valide o depósito intermediário e o adicione à sua coleção associada.
Para que todos os quatro saques neste exemplo possam ter como fonte o depósito original de 10 moedas, precisamos resolver dois problemas:
● Garantir que cada retirada parcial não esteja publicamente vinculada a outras retiradas
● Permitir que cada saque parcial tenha o depósito como membro de seu conjunto associado
Se apoiarmos apenas saques parciais, em vez de transações MIMO mais complexas, e garantirmos que cada saque tenha um único “depósito original” correspondente definido, existem várias maneiras de conseguir isso diretamente. Uma abordagem natural e escalável é espalhar a promessa de algumas informações através de transações. Por exemplo, podemos exigir que a transação contenha um hash de compromisso (coinID+hash®), adicionar algum valor aleatório r para garantir o cegamento e exigir que ZK-SNARK prove que o compromisso na transação é o mesmo que sua transação pai. Se a transação principal for uma retirada, o compromisso será o mesmo que o ID da moeda do depósito original, e se a transação principal for um depósito, o compromisso será o mesmo que o ID da moeda do depósito original. Portanto, cada transação na cadeia deve conter um compromisso com o ID da moeda de depósito original e exigir prova de que esse valor está no conjunto associado fornecido pela transação.
Para melhorar a privacidade contra ataques de agregação de saldo, também podemos apoiar a fusão de moedas. Por exemplo, se eu tiver algumas moedas sobrando, posso fundi-las no meu próximo depósito. Para acomodar isso, podemos exigir que as transações sejam comprometidas com um conjunto de IDs de moedas e exigir que as transações com múltiplas entradas sejam comprometidas com a união de suas transações principais. Um saque conterá prova de que todos os IDs de moedas comprometidos estão em seu conjunto associado.
2. Circunstâncias especiais
● Recertificação: os usuários precisam de informações secretas de depósito para sacar depósitos semelhantes aos protocolos de pool de privacidade. A mesma informação secreta também é usada para construir provas de adesão ao conjunto de associações. Preservar informações secretas permite que os usuários gerem novas provas para ajustar diferentes conjuntos ou conjuntos associados atualizados. Isto dá aos utilizadores maior flexibilidade, mas também pode introduzir riscos adicionais.
● Certificação direta bilateral: Em alguns casos, os usuários podem ser obrigados a divulgar a fonte exata da retirada à outra parte. Os usuários podem criar uma coleção associada contendo apenas seus depósitos e gerar comprovantes dessa coleção. Estas provas são geralmente exceções e só contribuem para a privacidade parcial quando partilhadas entre duas partes. No entanto, a partilha de provas requer o estabelecimento de fortes pressupostos de confiança.
● Prova de Sequência: Em uma economia de transações rápidas que usa um sistema semelhante a um pool de privacidade, o protocolo precisa ser modificado para acomodar esse ambiente. Além dos tipos de transações de depósito e retirada, o protocolo também precisa oferecer suporte a operações de envio internas para maior eficiência. Além disso, ao passar garfos e chaves Merkle, os usuários podem divulgar informações relacionadas ao histórico de transações para que os destinatários possam verificar a origem dos fundos. Isso garante que cada usuário tenha as informações mínimas necessárias para ter confiança nos recursos recebidos.
Na prática, uma moeda pode ter múltiplas “origens”. Por exemplo, Bob é dono de uma cafeteria e recebe 5 fichas de Alice, 4 fichas de Ashley, 7 fichas de Anne e, no final do dia, ele precisa pagar 15 fichas a Carl para pagar o jantar. Em vez disso, David pode ter recebido 15 tokens de Carl, 25 tokens de Chris e querer depositar 30 tokens para Emma (uma troca). Nestes casos mais complexos, seguimos o mesmo princípio: a história que foi adicionada à colecção associada há muito tempo pode ser ignorada, enquanto a história mais recente precisa de ser transmitida.
Cinco, mais detalhes
Um sistema semelhante a um pool de privacidade poderia permitir que os usuários ganhassem mais proteção na privacidade de seus dados de transações financeiras, mantendo ao mesmo tempo a capacidade de provar a separação de atividades ilícitas conhecidas. Esperamos que os utilizadores honestos sejam incentivados a participar em tais esquemas através de uma combinação de dois factores:
● Desejo de privacidade
● Desejo de evitar levantar suspeitas
1. Consenso social e coleta associativa
Se houvesse consenso completo sobre se os fundos eram bons ou maus, o sistema produziria um equilíbrio de separação simples. Todos os usuários com ativos “bons” têm um forte incentivo e capacidade para provar que pertencem a um conjunto de associações “somente bons”. Os maus atores, por outro lado, não serão capazes de fornecer esta prova. Eles ainda podem depositar fundos “ruins” no pool, mas isso não lhes fará nenhum bem. Todos podem facilmente determinar que os fundos foram retirados de um protocolo com maior privacidade e ver que a retirada faz referência a uma coleção associada contendo depósitos de fontes questionáveis. Além do mais, o dinheiro “ruim” não mancha o dinheiro “bom”. Quando os fundos são retirados de depósitos legítimos, seus proprietários podem simplesmente excluir todos os depósitos “ruins” conhecidos de sua coleção associada.
Onde existe consenso global, e onde as conclusões sobre se o financiamento é considerado “bom” ou “mau” dependem da perspectiva social ou da jurisdição, o conjunto de associações pode variar significativamente. Suponha que existam duas jurisdições com conjuntos de regras diferentes. As entidades nas jurisdições A e B podem usar o mesmo acordo de melhoria de privacidade e optar por emitir certificações que atendam aos requisitos de suas respectivas jurisdições. Ambos podem implementar facilmente a privacidade nas suas próprias coleções associadas e excluir retiradas que não cumpram os requisitos das suas respetivas jurisdições. Se necessário, pode ser emitido um comprovativo de adesão para a intersecção de dois conjuntos associados, comprovando assim de forma fiável que os depósitos correspondentes aos seus levantamentos cumprem os requisitos de ambas as jurisdições.
Por conseguinte, a proposta é muito flexível e deve ser considerada uma infra-estrutura neutra. Por um lado, combate a censura. Ele permite que qualquer pessoa participe de uma coleção afiliada de sua escolha e permaneça privada em sua própria comunidade. Por outro lado, terceiros podem solicitar certificação para um conjunto específico de associações que cumpram os seus requisitos regulamentares. Assim, mesmo que exista uma comunidade de maus atores num protocolo de reforço da privacidade, estes não serão capazes de ocultar a origem suspeita dos depósitos, desde que a informação seja refletida com precisão na construção do conjunto associado.
2. Propriedades das coleções associadas
As coleções associativas precisam ter certas propriedades para funcionar. As cobranças precisam ser precisas para que os usuários possam confiar que estão usando os fundos retirados com segurança. Além disso, as propriedades de cada conjunto devem ser estáveis, ou seja, menos propensas a mudar ao longo do tempo. Isso reduz a necessidade de retiradas de revalidação de novas coleções. Finalmente, para alcançar uma protecção significativa da privacidade, o conjunto de associações deve ser suficientemente grande e conter vários tipos de depósitos. No entanto, essas propriedades entram em conflito entre si. Em geral, coleções grandes e diversas podem ter melhores propriedades de privacidade, mas podem ser menos precisas e estáveis, enquanto coleções menores são mais fáceis de manter, mas proporcionam menos privacidade.
3. Considerações práticas e concorrência
As entidades reguladas que aceitam criptoativos devem garantir que as leis e regulamentos a que estão sujeitas permitem a aceitação de tais fundos. Hoje, muitas destas entidades dependem das chamadas ferramentas de triagem de transações: software ou serviços que analisam a blockchain para identificar atividades potencialmente suspeitas, ligações a endereços ilegítimos ou transações não conformes. As ferramentas de triagem muitas vezes expressam o risco associado a cada negociação através de uma pontuação de risco. Esta classificação é baseada no destino dos fundos transferidos e no seu histórico de transações. Os protocolos que melhoram a privacidade podem representar desafios a este respeito. Eliminam a ligação visível entre depósitos e levantamentos. Portanto, na presença de protocolos que melhoram a privacidade, a pontuação de risco precisa levar em conta o atestado e atribuir uma pontuação baseada no conjunto de associações.
Ferramentas e serviços para triagem de transações são fornecidos principalmente por empresas profissionais com experiência em análise de blockchain e áreas jurídicas relacionadas. Idealmente, estas empresas (e qualquer outra pessoa) teriam acesso a todos os certificados de adesão e às suas coleções associadas correspondentes para fornecer pontuações de risco precisas para todas as transações. Portanto, recomendamos que todas as provas sejam armazenadas no blockchain ou em outro repositório de provas acessível ao público. A única exceção é um certificado de adesão de tamanho único compartilhado com uma contraparte específica. Por razões óbvias, estes testemunhos não devem ser tornados públicos.
O armazenamento de provas diretamente na cadeia acrescenta custos de transação adicionais, mas reduz os esforços de coordenação, torna a concorrência mais justa e mitiga os riscos de quase monopólio que os fornecedores de ferramentas de triagem podem criar devido ao conhecimento de provas não públicas.
As configurações gerais de um pool de privacidade são muito flexíveis. O protocolo pode ser personalizado para vários casos de uso, criando coleções específicas de associações. Aqui estão dois exemplos dessas coleções de associações especiais:
● **Alianças de bancos comerciais podem criar uma coleção associada contendo apenas os depósitos de seus clientes. **Isso garante que o comprovante de quaisquer saques criados para a cobrança passou pelos procedimentos Know Your Customer (KYC) e Anti-Lavagem de Dinheiro (AML) em um dos bancos participantes, mas não revela qual saque pertence a qual cliente.
● **Nos casos em que os intermediários financeiros são obrigados a documentar claramente a origem dos fundos, podem exigir que os utilizadores forneçam provas contra um conjunto associado que contenha apenas os depósitos dos utilizadores. **Essa prova será então trocada bilateralmente com o intermediário, permitindo-lhe rastrear os fundos como se o usuário nunca tivesse usado o pool de privacidade. Embora isto exija que os utilizadores confiem no intermediário para não revelar a prova, idealmente permite que os utilizadores cumpram os regulamentos sem revelar a informação ao público.
4. Escolhas e alternativas de design
As configurações baseadas em conjuntos de associação, provas zk e divulgações voluntárias são flexíveis. Embora isto seja muito útil para garantir que a proposta possa ser adaptada a diferentes jurisdições, deve ter-se muito cuidado no que diz respeito às escolhas específicas de concepção. Em particular, existem dois ajustamentos potenciais aos quais nos opomos. Acreditamos que são problemáticos em termos de requisitos de confiança e podem criar estruturas de mercado quase monopolistas. Abaixo descrevemos e discutimos brevemente essas alternativas:
● Acesso centralizado: agências de aplicação da lei, provedores de pontuação de risco de criptografia ou atores semelhantes podem obter acesso para visualizar links entre transações de usuários, mantendo a privacidade de outras pessoas.
● **Lista de permissões em todo o sistema: **Os sistemas de privacidade podem impor restrições aos tipos de usuários que podem depositar moedas em seus pools, exigindo que eles forneçam provas adicionais ou exigindo que os depósitos esperem por um período de tempo durante o qual a pontuação de risco centralizada sistema pode negar depósitos.
Os dois métodos são semelhantes porque concedem privilégios a entidades específicas. Isto levanta questões complexas de governação: Quem tem acesso a esta informação? Quem tem o poder de gerenciar permissões? As empresas privadas não parecem ser uma boa opção, pois quaisquer privilégios podem criar uma estrutura de mercado oligopolista, onde algumas empresas têm acesso aos dados que lhes permitem fornecer estes serviços, enquanto outras não conseguem competir.
Da mesma forma, muitas questões políticas e de governação serão enfrentadas ao delegar poderes a instituições públicas, especialmente em contextos internacionais. Mesmo que uma instituição seja 100% confiável até agora, não abuse do seu poder para prosseguir uma agenda política e não seja dependente de outras entidades que possam obrigá-la a abusar do seu poder, esta situação é uma manifestação de estagnação. Com o tempo, as organizações, os membros, os países e as estruturas políticas dentro das organizações mudam. Poderão existir pressões externas e a existência destes privilégios poderá criar incentivos adicionais para perturbar e ganhar influência sobre o sistema de governação da organização.
Além disso, ataques dentro ou fora da organização, ou erros em nome de uma entidade centralizada, podem ter consequências de longo alcance. Acreditamos que a criação de tais pontos de falha centralizados deve ser evitada.
Dito isto, reconhecemos que diferentes tamanhos e circunstâncias de transações podem exigir diferentes combinações de certificações. Por exemplo, para grandes transações, muitos utilizadores podem acabar por fornecer provas básicas de exclusão na cadeia e fornecer informações mais detalhadas sobre a origem dos fundos às suas contrapartes.
5. Direção da pesquisa aprofundada
Embora este estudo forneça uma visão geral de como os protocolos de aprimoramento de privacidade baseados em zkSNARK podem ser usados em ambientes regulamentados, há vários aspectos que merecem um estudo mais aprofundado.
Primeiro, é preciso perceber que a privacidade obtida através destes protocolos depende de muitos fatores diferentes. Os invasores podem associar retiradas a depósitos específicos com base em um conjunto de associações insuficientemente grande, seleção de raiz inadequada e erro do usuário.
Além disso, as escolhas de outros usuários podem afetar negativamente a sua própria privacidade. Em casos extremos, todos os outros membros do pool publicariam uma prova de adesão de tamanho um, revelando uma ligação direta entre os seus depósitos e levantamentos. Obviamente, isto revelará implicitamente a ligação entre as únicas transações restantes de depósito e retirada. Num exemplo mais subtil, as restrições de várias provas de adesão podem ser utilizadas para extrair informações e potencialmente correlacionar depósitos e levantamentos com alta probabilidade. Uma vez que essas informações atestadas sejam combinadas com os metadados da transação, as propriedades de privacidade do protocolo podem ser comprometidas.
Finalmente, um ASP malicioso poderia optar por compilar o conjunto de associações proposto de uma forma que lhe permitisse maximizar a extração de informações ou aumentar o anonimato percebido, adicionando depósitos onde as retiradas correspondentes são conhecidas. Todas estas questões requerem mais pesquisas para avaliar as propriedades de privacidade fornecidas. Na mesma linha, seria interessante investigar mais aprofundadamente as propriedades de separação de equilíbrios, modelando como os bons e os maus jogadores se comportam sob certas suposições e como a prova pública dos primeiros afeta a privacidade dos últimos.
Os especialistas jurídicos podem pesquisar mais detalhadamente os requisitos de divulgação específicos. Os cenários apresentados neste documento são flexíveis e os insights de especialistas jurídicos podem ajudar a adaptar o acordo e o ecossistema construído em torno dele para garantir a conformidade em diversas jurisdições legais.
6. Conclusão
Em muitos casos, considera-se que a privacidade e a conformidade estão em conflito entre si. Este artigo propõe que este não seja necessariamente o caso se os protocolos de reforço da privacidade permitirem aos utilizadores provar certos atributos da origem dos seus fundos. Por exemplo, presume-se que os utilizadores possam provar que os seus fundos não estão ligados a depósitos de fontes ilícitas conhecidas, ou que os fundos fazem parte de uma coleção específica de depósitos, sem revelar qualquer informação adicional.
Tal configuração pode produzir um equilíbrio de separação no qual os utilizadores honestos são fortemente incentivados a provar que pertencem a algum conjunto de associações compatíveis e a manter a privacidade dentro desse conjunto. Em contrapartida, para utilizadores desonestos, não podem fornecer tal prova. Isso permite que usuários honestos se dissociem de depósitos de terceiros com os quais discordam ou os impeça de usar seus fundos em um ambiente compatível. Acreditamos que a proposta é flexível e pode ser adaptada a vários requisitos regulamentares.
Este artigo deve ser considerado uma contribuição para a potencial coexistência futura de privacidade e regulamentação financeira. Queremos facilitar as discussões e orientar a conversa numa direção mais positiva e construtiva. Será necessária a colaboração entre profissionais, académicos de diversas disciplinas, decisores políticos e reguladores para expandir e rever esta proposta; o objectivo final é criar infra-estruturas que melhorem a privacidade que possam ser utilizadas em ambientes regulamentados.