Introdução: Recentemente, Vitalik e alguns académicos co-publicaram um novo artigo, mencionando como a Tornado Cash implementa um esquema contra a lavagem de dinheiro (permitindo essencialmente ao sacador provar que o seu registo de depósito pertence a um conjunto que não contém dinheiro sujo), mas o artigo carece de uma interpretação detalhada da lógica de negócios e dos princípios da Tornado Cash, deixando alguns leitores perplexos.

Vale a pena mencionar que os projetos de privacidade representados pelo Tornado são aqueles que realmente utilizam a propriedade de conhecimento zero do algoritmo ZK-SNARK, enquanto a maioria dos projetos rotulados com ZK só usam a concisão do ZK-SNARK. As pessoas frequentemente confundem a diferença entre a Prova de Validade e ZK, e o Tornado serve como um excelente caso para entender a aplicação do ZK. O autor deste artigo havia escrito sobre os princípios do Tornado em 2022 para a pesquisa Web3Caff e hoje seleciona e expande algumas seções desse artigo, organizando-o neste texto para entender sistematicamente o Tornado Cash.

Link do Artigo Original: https://research.web3caff.com/zh/archives/2663?ref=157

O princípio do "Tornado"

O Tornado Cash utiliza um protocolo de mistura de moedas baseado em provas de conhecimento zero, com sua versão mais antiga lançada em 2019 e uma nova versão beta lançada no final de 2021. A versão mais antiga do Tornado alcançou um alto nível de descentralização, com seus contratos on-chain sendo de código aberto e não controlados por nenhum mecanismo de multiassinatura, e seu código frontend também sendo de código aberto e apoiado na rede IPFS. Devido à estrutura mais simples e compreensível da versão antiga do Tornado, este artigo se concentra em explicá-lo. A ideia principal por trás do Tornado é misturar um grande número de ações de depósito e retirada. Depois de depositar tokens no Tornado, os depositantes apresentam uma prova ZK para provar que fizeram um depósito e, em seguida, retiram para um novo endereço, cortando assim a ligação entre os endereços de depósito e retirada.

Mais especificamente, o Tornado atua como uma caixa de vidro cheia de moedas depositadas por muitas pessoas. Podemos ver quem depositou as moedas, mas como as moedas são altamente homogeneizadas, é difícil rastrear qual moeda foi depositada por quem se alguém desconhecido retirar uma moeda.

(Fonte: rareskills)Este cenário é algo comum; por exemplo, quando trocamos ETH numa pool Uniswap, não podemos saber de quem estamos a receber ETH porque muitos forneceram liquidez à Uniswap. No entanto, a diferença é que sempre que troca tokens na Uniswap, precisa de utilizar outros tokens como custo equivalente e não pode transferir fundos de forma "privada" para outra pessoa; enquanto que, com um mixer, só precisa de mostrar uma prova de depósito para retirar. Para que as ações de depósito e retirada pareçam homogêneas, cada depósito numa pool Tornado e cada retirada dela são mantidos consistentes em termos de montante. Por exemplo, se houver 100 depositantes e 100 retirantes numa pool, embora visíveis, eles parecem desvinculados, e o montante depositado e retirado por cada um é o mesmo.

Isso pode obscurecer a rastreabilidade das transferências de fundos, oferecendo uma conveniência natural para a anonimização das transações. A questão chave é: como é que um retirante prova que fez um depósito?

O endereço que faz a retirada não está ligado a nenhum endereço de depósito, então como pode ser determinada a sua elegibilidade para a retirada? O método mais direto parece ser o retirante divulgar qual registo de depósito é o seu, mas isso revelaria diretamente a sua identidade. É aqui que entram em jogo as provas de conhecimento zero. Ao apresentar uma Prova de ZK de que têm um registo de depósito no contrato Tornado que ainda não foi retirado, um retirante pode iniciar com sucesso uma retirada. As provas de conhecimento zero protegem a privacidade de forma inerente, revelando apenas que a pessoa efetivamente fez um depósito no fundo, sem divulgar a qual depositante corresponde.

Para provar 'Fiz um depósito no pool de fundos do Tornado' pode ser traduzido para 'O meu registo de depósito pode ser encontrado no contrato do Tornado.' Se usarmos Cn para representar um registo de depósito, o problema torna-se: dado que o conjunto de registos de depósito do Tornado é {C1, C2, …C100…}, o retirante, Bob, prova que usou a sua chave para gerar alguns Cn nos registos de depósito sem revelar qual Cn específico é. Isto envolve a propriedade especial de Prova de Merkle. Todos os registos de depósito do Tornado são incorporados numa Árvore de Merkle construída on-chain, com estes registos como nós folha de nível inferior. O número total de folhas é cerca de 2^20 > 1 milhão, a maioria das quais está num estado em branco (atribuído um valor inicial). Sempre que ocorre um novo depósito, o contrato regista o seu valor único, Compromisso, numa folha e depois atualiza a raiz da Árvore de Merkle.

Por exemplo, se o depósito de Bob foi o 10.000º na história do Tornado, o valor característico Cn associado a este depósito seria inserido no 10.000º nó folha da Árvore de Merkle, ou seja, C10000 = Cn. O contrato então calcula automaticamente uma nova Raiz e atualiza-a. Para poupar recursos computacionais, o contrato Tornado armazena em cache dados de um lote de nós alterados anteriormente, como Fs1, Fs2 e Fs0 no diagrama abaixo.

(Fonte: RareSkills)

A Prova de Merkle, por sua natureza, é concisa e leve, tirando partido da simplicidade das estruturas de dados em árvore nos processos de pesquisa/rastreio. Para provar externamente que uma transação TD existe numa Árvore de Merkle, só é necessário fornecer uma Prova de Merkle correspondente à Raiz, o que é bastante simples. Se a Árvore de Merkle for especialmente grande, com 2^20 folhas no nível inferior (ou seja, 1 milhão de registos de depósitos), uma Prova de Merkle só precisaria de incluir os valores de 21 nós, o que é muito curto.

Para provar que uma transação H3 está realmente contida dentro de uma Árvore de Merkle, é necessário demonstrar que, usando H3 e outras partes de dados na Árvore de Merkle, a Raiz pode ser gerada, e os dados necessários para gerar a Raiz (incluindo Td) constituem a Prova de Merkle. Quando o Bob faz um saque, ele precisa provar que o seu certificado corresponde a um hash de depósito Cn registrado na Árvore de Merkle no livro-razão da Tornado. Em outras palavras, ele deve provar duas coisas: Cn existe dentro da Árvore de Merkle fictícia da Tornado na cadeia, especificamente construindo uma Prova de Merkle contendo Cn; Cn está associado ao certificado de depósito do Bob.

A lógica de negócios da Tornado explicada

No código frontend da interface de usuário do Tornado, muitas funcionalidades são pré-implementadas. Quando um depositante abre a página do Tornado Cash e clica no botão de depósito, o código frontend que o acompanha gera dois números aleatórios, K e r, localmente. Em seguida, calcula o valor de Cn=Hash(K, r) e passa Cn (referido como o compromisso no diagrama abaixo) para o contrato Tornado, que o insere na Árvore Merkle registrada por este último. Essencialmente, K e r atuam como chaves privadas. Eles são cruciais, e o sistema solicita que os usuários os salvem com segurança. K e r são necessários novamente durante a retirada.

(A opção de encryptedNote permite aos utilizadores encriptar o credencial K e r com uma chave privada e guardá-la na blockchain para evitar esquecimentos) Importante, todas estas operações ocorrem off-chain, significando que o contrato Tornado e observadores externos não têm conhecimento de K e r. Se K e r forem divulgados, é semelhante ao roubo das chaves privadas da carteira.

Ao receber um depósito de um utilizador e a submissão de Cn=Hash(K, r), o contrato Tornado regista Cn na camada inferior da Árvore de Merkle como um novo nó folha, atualizando também o valor da Raiz. Portanto, Cn está diretamente ligado à ação de depósito do utilizador, permitindo que terceiros saibam qual utilizador corresponde a cada Cn, quem depositou tokens no misturador e os registos de depósito Cn de cada depositante.

Durante o processo de levantamento, o levantador insere a credencial/chave privada (os números aleatórios K e r gerados durante o depósito) na página web frontal. O programa no código frontal do Tornado Cash utiliza K e r, Cn=Hash(K, r), e a Prova de Merkle correspondente a Cn como parâmetros de entrada para gerar uma Prova de Conhecimento Zero. Isso prova que Cn existe na Árvore de Merkle como um registo de depósito, e K e r são as credenciais correspondentes a Cn. Este passo prova essencialmente: eu sei a chave correspondente a um registo de depósito na Árvore de Merkle. Quando a Prova de Conhecimento Zero é submetida ao contrato Tornado, esses quatro parâmetros são ocultados, protegendo a privacidade. A geração da Prova de Conhecimento Zero envolve parâmetros adicionais, incluindo a raiz de Merkle registada no contrato Tornado no momento do levantamento, um endereço de destinatário personalizado A e um identificador nf para evitar ataques de repetição. Estes três parâmetros são publicados no blockchain, o que não compromete a privacidade.

Um detalhe a notar é o uso de dois números aleatórios, K e r, para gerar Cn em vez de um único número aleatório, proporcionando maior segurança contra colisões. A representa o endereço do destinatário da retirada, escolhido pelo retirante. O identificador nf, projetado para prevenir ataques de repetição, é calculado como nf=Hash(K), onde K é um dos dois números aleatórios usados na etapa de depósito para gerar Cn. Isso vincula nf diretamente a Cn, estabelecendo uma correlação um-a-um entre cada Cn e seu nf correspondente. O objetivo de prevenir ataques de repetição se deve à característica de design da misturadora, que mantém desconhecida a associação entre os valores retirados e folhas específicas da árvore de Merkle (Cn), permitindo o potencial abuso de retiradas repetidas até que o fundo seja esgotado.

O identificador nf funciona de forma semelhante ao nonce associado a cada endereço Ethereum, evitando repetições de transações. Quando ocorre um levantamento, é feita uma verificação para garantir que o nf submetido não tenha sido usado anteriormente; se não utilizado, o levantamento é válido e o nf é registado. Qualquer tentativa de gerar um nf não associado a qualquer depósito registado Cn resultará numa falha em produzir uma Prova ZK válida, tornando o levantamento mal sucedido.

Se alguém gerar aleatoriamente um contrato não fungível (nf) não registrado, funcionará? Claro que não. Quando o retirante gera uma Prova de Conhecimento Zero (ZK Proof), eles devem garantir que nf seja igual ao Hash (K), onde o número aleatório K está associado ao registro de depósito Cn. Isso significa que nf está ligado a um registro de depósito Cn. Se alguém fabricar um nf arbitrariamente, este nf não corresponderá a nenhum registro de depósito, tornando impossível gerar uma ZK Proof válida. Consequentemente, o processo de retirada não pode ser concluído com sucesso, e a operação de retirada falhará. Alguns podem perguntar: É possível prosseguir sem nf? Como o retirante precisa enviar uma prova ZK durante a retirada para provar sua associação com um determinado Cn, por que não verificar se a Prova ZK correspondente foi enviada para o blockchain sempre que ocorrer uma retirada? No entanto, esta abordagem é muito dispendiosa porque o contrato Tornado Cash não armazena permanentemente as provas ZK anteriores devido ao significativo desperdício de espaço de armazenamento. Comparar cada nova ZK Proof enviada para o blockchain com provas existentes é menos eficiente do que definir um pequeno identificador como nf e armazená-lo permanentemente.

De acordo com o exemplo de código da função de retirada, os parâmetros necessários e a lógica de negócios são os seguintes: O usuário envia uma Prova ZK e nf (NullifierHash) = Hash (K), especifica um endereço de destinatário para a retirada e a Prova ZK oculta os valores de Cn, K e r, tornando impossível para os externos determinarem a identidade do usuário. O destinatário muitas vezes usa um novo endereço limpo, que não revela informações pessoais.

No entanto, existe um problema menor: quando os utilizadores levantam fundos para permanecerem anónimos, muitas vezes iniciam a transação de levantamento a partir de um endereço recém-criado. Neste momento, o novo endereço não tem ETH para pagar as taxas de gás. Portanto, ao iniciar um levantamento, o endereço de levantamento deve declarar explicitamente um intermediário para pagar a taxa de gás em seu nome. Posteriormente, o contrato de mistura deduz uma parte do levantamento do utilizador para compensar o intermediário.

Em resumo, o Tornado Cash pode obscurecer a ligação entre os que retiram e os que depositam. Em situações com uma grande base de utilizadores, é como um criminoso a misturar-se na multidão de uma área movimentada, tornando difícil para a polícia rastreá-lo. O processo de levantamento envolve o uso de ZK-SNARKs, sendo a parte da testemunha oculta contendo informações críticas sobre o que retira, um aspecto chave de todo o mixer. Atualmente, o Tornado parece ser um dos projetos de camada de aplicação mais engenhosos relacionados com ZK.

Aviso legal:

1. Este artigo é reproduzido a partir de [GateGeek Web3], Todos os direitos de autor pertencem ao autor original [Faust, geek web3]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Responsabilidade de Isenção: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.