> O desenvolvedor ameen.eth combina o conceito de "Prova de Inocência" com Tornado Cash para fornecer outra direção de que "privacidade não é igual a crime".
Escrito por: Albert Lin
Prefácio
TornadoCash é um conhecido serviço de transações anônimas no mundo das criptomoedas. O TornadoCash usa a tecnologia ZKP (Zero-Knowledge Proof) para ocultar a origem dos fundos. O governo dos EUA argumentou que tal mecanismo facilitava atividades ilícitas de fluxo financeiro e acabou sendo sancionado pelo Departamento do Tesouro dos EUA em agosto de 2022 e forçado a retirá-lo das prateleiras. A proteção da privacidade e a lavagem de dinheiro sempre parecem andar de mãos dadas em muitos casos. Ao buscar privacidade, os criminosos costumam usar esses recursos de privacidade para lavar fundos ilegais. Pode-se encontrar uma maneira de permitir que as pessoas tenham privacidade enquanto reduz efetivamente a lavagem de dinheiro? Privacy-Pools de ameen.eth, um dos primeiros desenvolvedores do TornadoCash, pode dar uma direção. (Apenas o site front-end e o Repositório GitHub são afetados pela parte de exclusão, e a parte do contrato não é afetada porque está no blockchain. Finalmente, o GitHub restaurou o Repositório sob os esforços da Electronic Frontier Foundation. Para detalhes, por favor consulte aqui)
Introdução Princípio TornadoCash
Antes de introduzir o Privacy-Pools, você precisa entender os princípios de design relacionados ao TornadoCash. Para uma introdução detalhada, consulte meu artigo anterior "Breaking Down TornadoCash: um guia para iniciantes para explicar sua funcionalidade aos amigos". Aqui está uma breve revisão dos princípios de design do TornadoCash.
A TornadoCash usa recibos (compromissos) para controlar o acesso. O recibo é gerado pelo hash do segredo (valor do segredo) e do anulador (código de logout), e cada recibo só pode ser retirado uma vez. Use Merkle Tree (hash tree) para registrar informações de depósito, use recibo como nó folha e calcule Merkle Root (hash tree root). O usuário só precisa fornecer os dados da folha para a raiz para provar se os dados são uma das folhas da Merkle Tree e, indiretamente, provar que houve depósito de fundos no TornadoCash antes. Use a prova de conhecimento zero para ocultar a origem do depósito e use o anulador para evitar o ataque de retirada dupla.
O recibo da TornadoCash tem dois significados
Prova de que o remetente depositou fundos antes
Certifique-se de que cada destinatário só possa reivindicar fundos uma vez
「Prova de Inocência」
De acordo com o princípio de design do TornadoCash, só se pode saber que os fundos recebidos devem vir de um depósito anterior, mas não se sabe de qual depósito veio. Este é o principal objetivo dos criminosos que usam o TornadoCash para atividades ilegais de lavagem de dinheiro e também é a razão pela qual o governo dos EUA regula o TornadoCash. Se pudermos propor outra Prova (ZKP) para provar que os fundos recebidos não são dos depósitos na lista de rejeição, se puder provar que o pagamento não é de criminosos, isso é "Prova de Inocência" (" Prova de inocência") conceito central.
O conceito de "Prova de Inocência" pode ser dividido em duas direções
Comprovação de que os recursos recebidos são provenientes da arrecadação de fundos depositados na lista permitida (lista permitida)
Evidência de que os fundos retirados não vieram do conjunto de fundos de depósito na lista de rejeição (lista de rejeição)
Ambos os métodos podem provar que os fundos de retirada não são dos depósitos na lista de rejeição. A abordagem na figura abaixo é usar a lista de rejeição para provar que os fundos recebidos não vêm do depósito (vermelho) na lista de rejeição.
fonte:
Princípio de design de pools de privacidade
Privacy-Pools adiciona o conceito de "prova de inocência" ao TornadoCash. Além do significado original do recibo TorandoCash, o recibo de pagamento Privacy-Pools tem um terceiro significado: "para provar que os fundos recebidos vêm dos depósitos na lista permitida".
Recibo de Privacy-Pools significa:
Prova de que o remetente depositou fundos antes
Certifique-se de que cada destinatário só possa reivindicar fundos uma vez
Comprovação de que os recursos a serem sacados provêm de depósitos na lista permitida
Aqui usamos o Allow Merkle Tree para explicar como o Privacy-Pools usa "Proof-of-Inocence" neste sistema (Allow Merkle Tree é o conceito de usar a lista de permissões). Em primeiro lugar, Allow Merkle Tree tem várias características
Permitir Árvore Merkle como o nome sugere é uma Árvore Merkle
A altura da árvore e o número de nós são os mesmos da Árvore Merkle de Deposito de Privacy-Pools.
*Todas as folhas da Allow Merkle Tree correspondem à posição Deposit Merkle Tree leaf (depósito).
Permitir que os dados da folha da Árvore Merkle possam ser divididos nas duas categorias a seguir:
permitido: Indica que o depósito neste local é permitido. (Posições que ainda não foram depositadas também são permitidas por padrão)
*bloqueado: Indica que o depósito neste local foi rejeitado.
Conforme mostrado na figura abaixo, as posições de índice 0 e 1 são ambos fundos legais na Merkle Tree Deposit, e as posições correspondentes da folha Allow Merkle Tree também são permitidas.
Supondo que hoje um criminoso deseja realizar atividades de lavagem de dinheiro, ele deposita os fundos ilegais obtidos após o ataque em Privacy-Pools, e o local de depósito é Deposit Merkle Tree index: 2. Sabemos que são fundos ilegais, então atualizamos para bloqueados no índice correspondente da Árvore Merkle: 2 posição.
Situação de Coleta de Lista de Permissões
Supondo que hoje, um usuário que deposita na lista de permitidos do governo dos EUA deseja sacar fundos, ele precisa fornecer "prova de que o depósito está na árvore Dposit Merkle" e "prova de que o que está na lista de permitidos dos EUA é permitido". A prova correspondente à lista de permissões dos EUA inclui o Allow Merkle Root (fornecido pelo usuário, subetRoot no código) e o valor do nó que será passado no caminho. Quando o Privacy-Pools verifica o estágio ZKP, ele usará o valor da folha conforme permitido (keccak256 (permitido) no código real) e o valor do nó fornecido para passar para construir um Merkle Root. Verifique se este Merkle Root é o mesmo que Allow Merkle Root fornecido pelo usuário. Se a verificação do mesmo representante for aprovada, significa que o fundo para o saque é de um depósito que existe na lista de permissões do governo dos EUA.
Situação de coleta de lista de rejeição
Hoje, um usuário que não está na lista permitida do governo dos EUA deseja retirar fundos, e o local de depósito correspondente é marcado como bloqueado na lista permitida do governo dos EUA. Isso fará com que o usuário não consiga usar o Allow Merkle Root da lista de permissões do governo dos EUA para retirar fundos, porque a prova correspondente não pode ser gerada e a verificação falhará (porque o Privacy-Pools usa o valor permitido para folha para fazer cálculos, e a lista de permissões do governo dos EUA será O local está marcado como bloqueado, portanto, o mesmo Merkle Root não pode ser calculado).
Tal design força o usuário a fornecer outro Permitir Merkle Root para retirar fundos (outras Árvores Permitir Merkle precisam marcar o local do depósito como permitido para calcular o mesmo Permitir que Merkle Root passe na verificação). Esta outra Árvore Permitir Merkle pode ser mantida por outros governos ou instituições, ou mesmo gerada por este próprio usuário. Hoje, o governo dos EUA pode usar o Allow Merkle Root usado ao retirar para determinar se os fundos do usuário estão em conformidade com as leis e regulamentos do governo dos EUA, de modo a atingir o objetivo de rastreamento. Se o usuário estiver usando o Allow Merkle Tree gerado por ele mesmo ou não for confiável, basicamente o fundo de retirada provavelmente virá de um depósito problemático (toda árvore Allow Merkle de terceiros confiável marca o local do depósito como bloqueado).
Perguntas frequentes
**P: Se o Allowroot for fornecido pelo sacador, é possível falsificar um Allow Merkle Root falso para provar que a folha é um depósito na lista permitida, isso significa que o dinheiro ainda pode ser retirado? **
R: A resposta é sim, é realmente possível retirar o dinheiro. O autor apontou especificamente que tal mecanismo não é para proibir os criminosos de retirar o dinheiro, mas mesmo que possam retirá-lo, saber-se-á que os fundos estão na lista de rejeição. Quando o desistente fornece um Permitir Merkle Root não convincente, basicamente pode ser considerado como se retirando da lista de rejeição. O autor supõe que a razão para permitir isso é manter a natureza descentralizada desse serviço. Porque cada Allow Merkle Tree precisa de certo gerenciamento de autoridade para atualizar o status de cada folha. Se uma determinada raiz de árvore de permissão for obrigatória, isso significa que alguém tem certa autoridade para controlar a retirada de fundos, o que não está de acordo com o espírito de descentralização.
**P: Quem decidirá se a transação é de fundos da lista de rejeição? **
R: A parte que vi não foi mencionada especificamente, e entendo que esta parte deve ser feita por cada agência reguladora. Supondo que hoje o governo dos EUA queira verificar o dinheiro sujo do Privacy-Pools, ele pode verificar se é dinheiro sujo verificando o Allow Merkle Root de cada transação. Quanto ao tipo de Allow Merkle Root permitido, cabe a cada agência reguladora julgar por si mesma.
Código de pools de privacidade
O código principal e os comentários do próprio autor estão anexados aqui, esperando ajudar a todos a entender a lógica principal do código.
// circuitos/retirada_from_subset.circom
modelo WithdrawFromSubset(níveis, valor esperado) {
// público
raiz de entrada de sinal;
entrada de sinal subsetRoot;
anulador de entrada de sinal;
entrada de sinal assetMetadata; // abi.encode(token, amount).snarkHash();
sinal de entrada pullMetadata; // abi.encode(destinatário, reembolso, retransmissor, taxa).snarkHash();
// privado
segredo de entrada de sinal;
caminho de entrada do sinal; // Indica se os dados representam a folha esquerda ou a folha direita.
entrada de sinal mainProof [levels] ; // Constrói os dados necessários para a raiz do depósito.
entrada de sinal subsetProof [levels] ; // Constrói os dados necessários para permitir o root.
// Calcula o anulador e o compromisso.
componente hasher = CommitmentNullifierHasher();
hasher.secret <== segredo;
hash.caminho <== caminho;
hasher.assetMetadata <== assetMetadata;
nullifier === hasher.nullifier;
// valor esperado: keccak256("permitido") % p
componente doubleTree = DoubleMerkleProof(níveis, valor esperado);
doubleTree.leaf <== hasher.commitment;
// Converte o caminho em bits para especificar se é a folha esquerda ou a folha direita.
// Pode-se observar que a árvore de depósito e a árvore de permissão compartilham o mesmo caminho.
doubleTree.path <== caminho;
for ( i = 0; i < níveis; i++) {
doubleTree.mainProof [i] <== mainProof [i] ;
doubleTree.subsetProof [i] <== subsetProof [i] ;
}
root === doubleTree.root; // Verifica a raiz do depósito.
subsetRoot === doubleTree.subsetRoot; // Verifique o root permitido.
"Comprovante de Inocência" é usar outro Comprovante para provar que o pagamento é proveniente do depósito na lista permitida. A "prova de inocência" pode ser construída a partir de duas perspectivas: lista de permissões e lista de negações.
Privacy-Pools sobrepõe o conceito de "Proof-of-Inocence" com base no TornadoCash. O recibo original representa um terceiro significado: "Prova de que os fundos recebidos provêm dos depósitos na lista permitida."
A existência da árvore Allow Merkle pode provar que a retirada de fundos existe na lista permitida. A posição da folha da Allow Merkle Tree corresponde à posição da folha de depósito da Deposit Merkle Tree. Permitir que os dados da folha da árvore Merkle sejam permitidos e bloqueados.
Além das informações necessárias para construir o Deposit Merkle Root, o destinatário também precisa fornecer o Allow Merkle Root e as informações de construção Allow Merkle Root para provar que a retirada de fundos existe na lista permitida.
Como o Allow Merkle Root é fornecido pelo destinatário, os criminosos ainda têm uma maneira de retirar os fundos ilegais por meio do falso Allow Merkle Root. O falso Allow Merkle Root ainda aparecerá na rede e será considerado por outros como duvidoso sobre o pagamento, a fim de rastrear o fluxo de fundos ilegais.
O desenvolvedor ameen.eth combina o conceito de "Prova de Inocência" com TornadoCash para fornecer outra direção de que "privacidade não é igual a crime". O autor acha interessante usar outro ZKP para provar outro fato, que é um pouco como a adição do ZKP. Esta forma de utilização será mais simples e eficiente do que construir um ZKP maior e mais complexo. Em relação à escolha da Allow Merkle Tree, sinto que ela será construída por uma unidade mais justa no futuro, que será mais persuasiva para os outros.
Finalmente, obrigado a Chih-Cheng Liang e Ping Chen por ajudar a revisar o artigo e dar opiniões valiosas!
> Referência:
> Endereço furtivo
> Análise da instância do Tornado Cash
> Introdução ao desenvolvimento de ZKP e contratos inteligentes
> [Clube de Leitura ZKP] TornadoCash
> Tornado Cash — Como Funciona | DeFi + prova de conhecimento zero
> Entendimento profundo dos detalhes técnicos do TornadoCash
> 0xhhh Tópico apresentando novos recursos e seus princípios
> vídeo de demonstração
> Palestra de Vitalik sobre como melhorar o Tornadov2
> piscinas de privacidade v0tweet
> Apresentando a Prova de Inocência construída no TornadoCash
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Explique o princípio de design do Tornado Cash V2 em detalhes
> O desenvolvedor ameen.eth combina o conceito de "Prova de Inocência" com Tornado Cash para fornecer outra direção de que "privacidade não é igual a crime".
Escrito por: Albert Lin
Prefácio
TornadoCash é um conhecido serviço de transações anônimas no mundo das criptomoedas. O TornadoCash usa a tecnologia ZKP (Zero-Knowledge Proof) para ocultar a origem dos fundos. O governo dos EUA argumentou que tal mecanismo facilitava atividades ilícitas de fluxo financeiro e acabou sendo sancionado pelo Departamento do Tesouro dos EUA em agosto de 2022 e forçado a retirá-lo das prateleiras. A proteção da privacidade e a lavagem de dinheiro sempre parecem andar de mãos dadas em muitos casos. Ao buscar privacidade, os criminosos costumam usar esses recursos de privacidade para lavar fundos ilegais. Pode-se encontrar uma maneira de permitir que as pessoas tenham privacidade enquanto reduz efetivamente a lavagem de dinheiro? Privacy-Pools de ameen.eth, um dos primeiros desenvolvedores do TornadoCash, pode dar uma direção. (Apenas o site front-end e o Repositório GitHub são afetados pela parte de exclusão, e a parte do contrato não é afetada porque está no blockchain. Finalmente, o GitHub restaurou o Repositório sob os esforços da Electronic Frontier Foundation. Para detalhes, por favor consulte aqui)
Introdução Princípio TornadoCash
Antes de introduzir o Privacy-Pools, você precisa entender os princípios de design relacionados ao TornadoCash. Para uma introdução detalhada, consulte meu artigo anterior "Breaking Down TornadoCash: um guia para iniciantes para explicar sua funcionalidade aos amigos". Aqui está uma breve revisão dos princípios de design do TornadoCash.
A TornadoCash usa recibos (compromissos) para controlar o acesso. O recibo é gerado pelo hash do segredo (valor do segredo) e do anulador (código de logout), e cada recibo só pode ser retirado uma vez. Use Merkle Tree (hash tree) para registrar informações de depósito, use recibo como nó folha e calcule Merkle Root (hash tree root). O usuário só precisa fornecer os dados da folha para a raiz para provar se os dados são uma das folhas da Merkle Tree e, indiretamente, provar que houve depósito de fundos no TornadoCash antes. Use a prova de conhecimento zero para ocultar a origem do depósito e use o anulador para evitar o ataque de retirada dupla.
O recibo da TornadoCash tem dois significados
「Prova de Inocência」
De acordo com o princípio de design do TornadoCash, só se pode saber que os fundos recebidos devem vir de um depósito anterior, mas não se sabe de qual depósito veio. Este é o principal objetivo dos criminosos que usam o TornadoCash para atividades ilegais de lavagem de dinheiro e também é a razão pela qual o governo dos EUA regula o TornadoCash. Se pudermos propor outra Prova (ZKP) para provar que os fundos recebidos não são dos depósitos na lista de rejeição, se puder provar que o pagamento não é de criminosos, isso é "Prova de Inocência" (" Prova de inocência") conceito central.
O conceito de "Prova de Inocência" pode ser dividido em duas direções
Ambos os métodos podem provar que os fundos de retirada não são dos depósitos na lista de rejeição. A abordagem na figura abaixo é usar a lista de rejeição para provar que os fundos recebidos não vêm do depósito (vermelho) na lista de rejeição.
Princípio de design de pools de privacidade
Privacy-Pools adiciona o conceito de "prova de inocência" ao TornadoCash. Além do significado original do recibo TorandoCash, o recibo de pagamento Privacy-Pools tem um terceiro significado: "para provar que os fundos recebidos vêm dos depósitos na lista permitida".
Recibo de Privacy-Pools significa:
Aqui usamos o Allow Merkle Tree para explicar como o Privacy-Pools usa "Proof-of-Inocence" neste sistema (Allow Merkle Tree é o conceito de usar a lista de permissões). Em primeiro lugar, Allow Merkle Tree tem várias características
Permitir que os dados da folha da Árvore Merkle possam ser divididos nas duas categorias a seguir:
Conforme mostrado na figura abaixo, as posições de índice 0 e 1 são ambos fundos legais na Merkle Tree Deposit, e as posições correspondentes da folha Allow Merkle Tree também são permitidas.
Supondo que hoje um criminoso deseja realizar atividades de lavagem de dinheiro, ele deposita os fundos ilegais obtidos após o ataque em Privacy-Pools, e o local de depósito é Deposit Merkle Tree index: 2. Sabemos que são fundos ilegais, então atualizamos para bloqueados no índice correspondente da Árvore Merkle: 2 posição.
Situação de Coleta de Lista de Permissões
Supondo que hoje, um usuário que deposita na lista de permitidos do governo dos EUA deseja sacar fundos, ele precisa fornecer "prova de que o depósito está na árvore Dposit Merkle" e "prova de que o que está na lista de permitidos dos EUA é permitido". A prova correspondente à lista de permissões dos EUA inclui o Allow Merkle Root (fornecido pelo usuário, subetRoot no código) e o valor do nó que será passado no caminho. Quando o Privacy-Pools verifica o estágio ZKP, ele usará o valor da folha conforme permitido (keccak256 (permitido) no código real) e o valor do nó fornecido para passar para construir um Merkle Root. Verifique se este Merkle Root é o mesmo que Allow Merkle Root fornecido pelo usuário. Se a verificação do mesmo representante for aprovada, significa que o fundo para o saque é de um depósito que existe na lista de permissões do governo dos EUA.
Situação de coleta de lista de rejeição
Hoje, um usuário que não está na lista permitida do governo dos EUA deseja retirar fundos, e o local de depósito correspondente é marcado como bloqueado na lista permitida do governo dos EUA. Isso fará com que o usuário não consiga usar o Allow Merkle Root da lista de permissões do governo dos EUA para retirar fundos, porque a prova correspondente não pode ser gerada e a verificação falhará (porque o Privacy-Pools usa o valor permitido para folha para fazer cálculos, e a lista de permissões do governo dos EUA será O local está marcado como bloqueado, portanto, o mesmo Merkle Root não pode ser calculado).
Tal design força o usuário a fornecer outro Permitir Merkle Root para retirar fundos (outras Árvores Permitir Merkle precisam marcar o local do depósito como permitido para calcular o mesmo Permitir que Merkle Root passe na verificação). Esta outra Árvore Permitir Merkle pode ser mantida por outros governos ou instituições, ou mesmo gerada por este próprio usuário. Hoje, o governo dos EUA pode usar o Allow Merkle Root usado ao retirar para determinar se os fundos do usuário estão em conformidade com as leis e regulamentos do governo dos EUA, de modo a atingir o objetivo de rastreamento. Se o usuário estiver usando o Allow Merkle Tree gerado por ele mesmo ou não for confiável, basicamente o fundo de retirada provavelmente virá de um depósito problemático (toda árvore Allow Merkle de terceiros confiável marca o local do depósito como bloqueado).
Perguntas frequentes
**P: Se o Allowroot for fornecido pelo sacador, é possível falsificar um Allow Merkle Root falso para provar que a folha é um depósito na lista permitida, isso significa que o dinheiro ainda pode ser retirado? **
R: A resposta é sim, é realmente possível retirar o dinheiro. O autor apontou especificamente que tal mecanismo não é para proibir os criminosos de retirar o dinheiro, mas mesmo que possam retirá-lo, saber-se-á que os fundos estão na lista de rejeição. Quando o desistente fornece um Permitir Merkle Root não convincente, basicamente pode ser considerado como se retirando da lista de rejeição. O autor supõe que a razão para permitir isso é manter a natureza descentralizada desse serviço. Porque cada Allow Merkle Tree precisa de certo gerenciamento de autoridade para atualizar o status de cada folha. Se uma determinada raiz de árvore de permissão for obrigatória, isso significa que alguém tem certa autoridade para controlar a retirada de fundos, o que não está de acordo com o espírito de descentralização.
**P: Quem decidirá se a transação é de fundos da lista de rejeição? **
R: A parte que vi não foi mencionada especificamente, e entendo que esta parte deve ser feita por cada agência reguladora. Supondo que hoje o governo dos EUA queira verificar o dinheiro sujo do Privacy-Pools, ele pode verificar se é dinheiro sujo verificando o Allow Merkle Root de cada transação. Quanto ao tipo de Allow Merkle Root permitido, cabe a cada agência reguladora julgar por si mesma.
Código de pools de privacidade
O código principal e os comentários do próprio autor estão anexados aqui, esperando ajudar a todos a entender a lógica principal do código.
// circuitos/retirada_from_subset.circom
modelo WithdrawFromSubset(níveis, valor esperado) {
// público
raiz de entrada de sinal;
entrada de sinal subsetRoot;
anulador de entrada de sinal;
entrada de sinal assetMetadata; // abi.encode(token, amount).snarkHash();
sinal de entrada pullMetadata; // abi.encode(destinatário, reembolso, retransmissor, taxa).snarkHash();
// privado
segredo de entrada de sinal;
caminho de entrada do sinal; // Indica se os dados representam a folha esquerda ou a folha direita.
entrada de sinal mainProof [levels] ; // Constrói os dados necessários para a raiz do depósito.
entrada de sinal subsetProof [levels] ; // Constrói os dados necessários para permitir o root.
// Calcula o anulador e o compromisso.
componente hasher = CommitmentNullifierHasher();
hasher.secret <== segredo;
hash.caminho <== caminho;
hasher.assetMetadata <== assetMetadata;
nullifier === hasher.nullifier;
// valor esperado: keccak256("permitido") % p
componente doubleTree = DoubleMerkleProof(níveis, valor esperado);
doubleTree.leaf <== hasher.commitment;
// Converte o caminho em bits para especificar se é a folha esquerda ou a folha direita.
// Pode-se observar que a árvore de depósito e a árvore de permissão compartilham o mesmo caminho.
doubleTree.path <== caminho;
for ( i = 0; i < níveis; i++) {
doubleTree.mainProof [i] <== mainProof [i] ;
doubleTree.subsetProof [i] <== subsetProof [i] ;
}
root === doubleTree.root; // Verifica a raiz do depósito.
subsetRoot === doubleTree.subsetRoot; // Verifique o root permitido.
sinal de retiradaMetadataSquare;
RetiradaMetadataSquare <== RetiradaMetadata * RetiradaMetadata;
}
TLDR
O desenvolvedor ameen.eth combina o conceito de "Prova de Inocência" com TornadoCash para fornecer outra direção de que "privacidade não é igual a crime". O autor acha interessante usar outro ZKP para provar outro fato, que é um pouco como a adição do ZKP. Esta forma de utilização será mais simples e eficiente do que construir um ZKP maior e mais complexo. Em relação à escolha da Allow Merkle Tree, sinto que ela será construída por uma unidade mais justa no futuro, que será mais persuasiva para os outros.
Finalmente, obrigado a Chih-Cheng Liang e Ping Chen por ajudar a revisar o artigo e dar opiniões valiosas!
> Referência:
> Endereço furtivo
> Análise da instância do Tornado Cash
> Introdução ao desenvolvimento de ZKP e contratos inteligentes
> [Clube de Leitura ZKP] TornadoCash
> Tornado Cash — Como Funciona | DeFi + prova de conhecimento zero
> Entendimento profundo dos detalhes técnicos do TornadoCash
> 0xhhh Tópico apresentando novos recursos e seus princípios
> vídeo de demonstração
> Palestra de Vitalik sobre como melhorar o Tornadov2
> piscinas de privacidade v0tweet
> Apresentando a Prova de Inocência construída no TornadoCash