Introdução:

Recentemente, Vitalik e vários acadêmicos publicaram em conjunto um novo artigo que aborda como o Tornado Cash implementa seu esquema anti-lavagem de dinheiro (essencialmente permitindo que o sacador prove que seu histórico de depósitos pertence a um conjunto que não inclui fundos contaminados). No entanto, o artigo carecia de uma explicação detalhada da lógica e princípios de negócios do Tornado Cash, deixando alguns leitores com apenas uma compreensão superficial.

Vale ressaltar que projetos como Tornado, que representam empreendimentos de privacidade, realmente utilizam o aspecto de conhecimento zero do algoritmo ZK-SNARK. Enquanto isso, a maioria das soluções que ostentam a bandeira ZK, como Rollups, apenas aproveitam a concisão do ZK-SNARK. Muitas vezes, as pessoas tendem a confundir a Prova de Validade com ZK, e o Tornado serve como um excelente exemplo para esclarecer a aplicação do conhecimento zero no mundo real.

O autor deste artigo havia escrito um texto sobre os princípios do Tornado em 2022 para a Pesquisa Web3Caff. Hoje, extraímos e expandimos certas seções desse trabalho original para fornecer uma compreensão sistemática do Tornado Cash.

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

O Princípio do “Tornado”

O Tornado Cash utiliza a prova de conhecimento zero como seu protocolo de mistura. Enquanto sua versão mais antiga foi lançada em 2019, uma versão beta do modelo atualizado foi lançada no final de 2021. A versão anterior do Tornado alcançou um bom nível de descentralização, com contratos on-chain sendo de código aberto e livres de controles de várias assinaturas. Além disso, o código frontend era de código aberto e tinha backup na rede IPFS. Devido à simplicidade da versão mais antiga do Tornado, este artigo se concentra em explicá-la.

A abordagem principal do Tornado é misturar numerosas ações de depósito e saque juntas. Após depositar Tokens no Tornado, os depositantes apresentam uma Prova ZK para verificar seu depósito anterior e depois sacam usando um novo endereço, quebrando assim a conexão entre os endereços de depósito e saque.

Para ser mais sucinto, imagine o Tornado como uma caixa de vidro cheia de moedas (Coins) depositadas por muitos indivíduos. Podemos ver quem depositou as moedas, mas essas moedas são altamente homogêneas. Se alguém não familiarizado pegasse uma moeda da caixa, seria difícil rastrear quem originalmente colocou aquela moeda lá.

（图源：rareskills）

Tais cenários parecem comuns. Quando TROCAMOS alguns ETHs de uma pool Uniswap, é impossível determinar de quem recebemos os ETHs, dado o grande número de provedores de liquidez para Uniswap. No entanto, a diferença está no processo. Com Uniswap, trocar Tokens requer outro Token de valor equivalente, e os fundos não podem ser transferidos de forma “privada”. Em contraste, um mixer simplesmente requer que o sacador apresente seu recibo de depósito.

Para tornar as ações de depósito e saque homogêneas, o pool Tornado mantém consistência nos valores de depósito e saque. Por exemplo, se um pool tem 100 depositantes e 100 sacadores, mesmo que as ações sejam publicamente visíveis, não parece haver conexão entre elas. Todos depositam e sacam a mesma quantia, tornando difícil rastrear o movimento dos fundos. Claramente, isso fornece uma vantagem inata para a lavagem de dinheiro.

A questão chave surge: ao efetuar saques, como se comprova o depósito prévio? O endereço que inicia o saque não está vinculado a nenhum endereço de depósito, então como se verifica o direito de sacar? O método mais direto seria o sacador revelar seu registro de depósito, mas isso exporia sua identidade. É aí que entram as provas de conhecimento zero.

Com uma Prova ZK, um retirante pode confirmar que tem um registro de depósito no contrato Tornado e que este depósito ainda não foi retirado. A beleza das provas de conhecimento zero é que elas preservam a privacidade. O público só sabe que o retirante de fato fez um depósito, mas não pode determinar sua identidade específica.

Para provar "Eu depositei no pool Tornado" pode ser traduzido como "Meu registro de depósito pode ser encontrado no contrato Tornado." Se Cn denota um registro de depósito, então dado o conjunto de registros de depósito do Tornado como {C1, C2,…C100…}, Bob precisa provar que usou sua chave privada para gerar um registro neste conjunto sem revelar qual Cn específico é. Isso utiliza as propriedades únicas da Prova de Merkle.

Todos os registros de depósito do Tornado são agregados em uma Árvore de Merkle construída na cadeia. A maioria dessas folhas (cerca de 2^20, mais de 1 milhão) permanece em branco (com um valor inicial). Cada novo depósito atualiza uma folha de compromisso correspondente e, em seguida, a raiz da árvore.

Por exemplo, se o depósito de Bob foi o de número 10.000 na história do Tornado, o valor associado Cn seria a 10.000ª folha da árvore, ou seja, C10000 = Cn. O contrato então calcularia automaticamente a nova Raiz.

（图源：RareSkills）

A própria Prova de Merkle é concisa e eficiente. Para provar que uma transação TD existe dentro de uma Árvore de Merkle, é necessário apenas fornecer a Prova de Merkle associada, que permanece compacta mesmo que a Árvore de Merkle seja vasta.

Para validar que uma transação, digamos H3, está de fato incluída na Árvore de Merkle, é necessário provar que usando H3 e outros dados da Árvore de Merkle é possível gerar a Raiz. Estes dados (incluindo Td) constituem a Prova de Merkle. Quando Bob quer sacar, ele precisa verificar duas coisas:

·Cn está na Árvore de Merkle construída on-chain pela Tornado, para a qual ele pode construir uma Prova de Merkle contendo Cn;

·Cn está relacionado ao comprovante de depósito de Bob.

Lógica de Negócios do Tornado Explicada

No código frontend da interface do usuário do Tornado, inúmeras funcionalidades foram pré-implementadas. Quando um depositante abre a página da Tornado Cash e clica no botão de depósito, o código frontend anexado gera dois números aleatórios, K e r, localmente. Em seguida, calcula o valor de Cn=Hash(K, r), passando Cn (referido como o compromisso no diagrama abaixo) para o contrato Tornado a ser incorporado em sua Árvore de Merkle. Simplificando, K e r agem como chaves privadas. Eles são cruciais, e os usuários são aconselhados a guardá-los com segurança, pois serão necessários novamente durante o processo de retirada.

Uma “encryptedNote” é um recurso opcional que permite aos usuários criptografar as credenciais K e r com uma chave privada e armazená-las na cadeia para evitar esquecimentos.

É digno de nota que todas as operações acima ocorrem off-chain, ou seja, nem o contrato Tornado nem quaisquer observadores externos estão cientes de K e r. Se K e r forem expostos, é como ter a chave privada da carteira roubada.

Ao receber um depósito do usuário e o Cn computado=Hash(K, r), o contrato Tornado coloca Cn no nível base da Árvore de Merkle, transformando-o em um novo nó folha e atualizando subsequentemente o valor da raiz. No entanto, é importante entender que as folhas desta Árvore de Merkle não são registradas no status do contrato, mas são registradas apenas como parâmetros de evento em blocos passados. O contrato Tornado registra apenas a raiz de Merkle. Durante a retirada, os usuários podem provar, via Prova de Merkle, que o registro de depósito corresponde à raiz de Merkle atual, um conceito que se assemelha de alguma forma às retiradas de ponte entre clientes leves de cadeia cruzada. Este design revela a engenhosidade do Tornado: para economizar nos custos de gás, a árvore de Merkle completa não é registrada no status do contrato, apenas sua raiz é. As folhas da árvore são simplesmente registradas em registros de bloco históricos, um mecanismo um tanto análogo ao princípio de economia de gás do Rollup (embora os detalhes difiram).

Durante o processo de saque, o sacador insere as credenciais/chaves privadas (números aleatórios K e r gerados durante o depósito) na página da web frontend. O código frontend do Tornado Cash utiliza K e r, Cn=Hash(K, r), e a Prova de Merkle correspondente a Cn para gerar uma Prova de ZK, confirmando assim que Cn corresponde a um registro de depósito na Árvore de Merkle e que K e r são as credenciais válidas para Cn. Essa etapa essencialmente comprova o conhecimento das chaves de um registro de depósito na Árvore de Merkle. Quando a Prova de ZK é submetida ao contrato Tornado, todos os quatro parâmetros são ocultados, garantindo que os outsiders, incluindo o próprio contrato Tornado, permaneçam inconscientes, protegendo assim a privacidade do usuário.

Um detalhe interessante é que a operação de depósito usa dois números aleatórios, K e r, para gerar Cn em vez de apenas um, porque um único número aleatório pode não ser suficientemente seguro e potencialmente ser quebrado por força bruta.

Quanto ao símbolo 'A' na ilustração, ele representa o endereço que recebe a retirada e é fornecido pelo retirante. Enquanto isso, 'nf' é um identificador estabelecido para evitar ataques de repetição, seu valor determinado como nf=Hash(K), onde K é um dos dois números aleatórios (K e r) usados durante o depósito para gerar Cn. Como tal, cada Cn tem um nf correspondente, e os dois estão vinculados de forma única.

Por que a necessidade de prevenir ataques de repetição? Devido às características de design do mixer, durante a retirada, não está claro qual depósito na Árvore de Merkle corresponde aos fundos retirados. Como a conexão entre o depositante e os valores retirados permanece obscura, os usuários maliciosos podem explorar isso e retirar repetidamente do mixer, esvaziando o pool de tokens.

Aqui, o identificador nf funciona de forma semelhante ao contador de transações "nonce" inerente a cada endereço Ethereum, estabelecido para evitar a repetição de transações. Após uma solicitação de saque, os usuários devem enviar um nf. O sistema verifica se esse nf foi usado anteriormente: se sim, o saque é invalidado; se não, o saque prossegue e o nf é registrado, garantindo que seu uso subsequente resultaria em invalidação.

Alguns podem se perguntar: Alguém pode fabricar um nf que o contrato não registrou? Isso é improvável. Durante a geração da Prova ZK, é essencial garantir nf=Hash(K), e o número aleatório K está vinculado ao registro de depósito Cn. Se alguém criar arbitrariamente um nf, ele não corresponderá a nenhum dos depósitos registrados, tornando impossível a geração de uma Prova ZK válida, e consequentemente, interrompendo o processo de retirada.

Outros podem questionar: Existe alguma maneira de contornar o uso de nf? Dado que os retirantes devem enviar uma Prova ZK, que atesta sua conexão com um Cn específico, não bastaria verificar se uma Prova ZK correspondente já foi registrada na cadeia? No entanto, os custos associados a tal abordagem são exorbitantes, pois o contrato Tornado Cash não armazena perpetuamente as Provas ZK previamente enviadas para evitar o desperdício de armazenamento. Comparar cada nova Prova ZK com as já existentes para garantir consistência é muito mais intensivo em recursos do que simplesmente registrar um identificador compacto como nf.

Conforme o exemplo de código da função de saque, os parâmetros necessários e a lógica de negócios são os seguintes: Os usuários enviam a Prova ZK, nf (NullifierHash) = Hash(K), e designam um endereço de destinatário para o saque. A Prova ZK oculta os valores de Cn, K e r, garantindo que o mundo exterior não possa determinar a identidade do usuário. Tipicamente, os destinatários especificarão um endereço limpo e novo para evitar revelar informações pessoais.

No entanto, surge um desafio menor: quando os usuários realizam saques, em prol da não rastreabilidade, muitas vezes usam endereços recém-gerados para iniciar a transação de saque. Nessas ocasiões, esses novos endereços não possuem ETH suficiente para cobrir as taxas de gás. Portanto, durante o saque, o endereço deve declarar explicitamente um relayer para cobrir as taxas de gás. Posteriormente, o contrato do mixer deduz uma parte do saque do usuário para compensar o relayer.

Em conclusão, o Tornado Cash pode obscurecer a conexão entre depositantes e sacadores. Quando há uma grande base de usuários, é semelhante a um criminoso se misturando em uma multidão movimentada, tornando difícil para as autoridades rastrearem. O processo de retirada emprega ZK-SNARK, com a parte oculta de "testemunha" contendo informações cruciais sobre o retirador. Esta é, sem dúvida, a característica mais vital do misturador. Atualmente, o Tornado pode ser uma das aplicações mais inteligentes relacionadas ao ZK.

Disclaimer：

1. Este artigo é reproduzido de [Gatemédio]. Todos os direitos autorais pertencem ao autor original [Faust, web3 geek]. Se houver objeções a esta reimpressão, entre em contato com a equipe Gate Learn（gatelearn@gate.io), e eles vão lidar com isso 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.