Introdução:

Recentemente, Vitalik e vários académicos publicaram em conjunto um novo artigo que aborda como a Tornado Cash implementa o seu esquema anti-lavagem de dinheiro (essencialmente permitindo ao retirante provar que o histórico do seu depósito 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ócio da Tornado Cash, deixando alguns leitores apenas com uma compreensão superficial.

Vale a pena notar que projetos como Tornado, que representam empreendimentos de privacidade, utilizam genuinamente o aspecto de conhecimento zero do algoritmo ZK-SNARK. Entretanto, 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 artigo 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 multi-assinatura. Além disso, o código frontend era de código aberto e armazenado na rede IPFS. Devido à simplicidade da versão anterior do Tornado, este artigo foca em explicá-lo.

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

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

（Fonte da imagem: rareskills）

Tais cenários parecem corriqueiros. Quando TROCAMOS alguns ETHs de um pool Uniswap, é impossível determinar qual ETH recebemos, dados os inúmeros provedores de liquidez para Uniswap. No entanto, a diferença está no processo. Com o Uniswap, a troca de Tokens requer outro Token como valor equivalente, e os fundos não podem ser transferidos "privadamente". Em contrapartida, um misturador simplesmente exige que o sacador apresente o seu recibo de depósito.

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

A questão-chave surge: ao efetuar um levantamento, como se prova o depósito prévio? O endereço que inicia o levantamento não está ligado a nenhum endereço de depósito, então como se verifica o direito de levantamento? O método mais direto seria o levantador revelar o seu registo de depósito, mas isso exporia a sua identidade. É aqui que entram em jogo as provas de conhecimento zero.

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

Para provar que 'Depositei no pool Tornado' pode ser traduzido para 'O meu registo de depósito pode ser encontrado no contrato Tornado.' Se Cn denota um registo de depósito, então dado o conjunto de registos de depósito do Tornado como {C1, C2,…C100…}, o Bob precisa de provar que usou a sua chave privada para gerar um registo neste conjunto sem revelar qual Cn específico é. Isto 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 on-chain. 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 depois 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 Prova de Merkle em si é concisa e eficiente. Para provar que uma transação TD existe dentro de uma Árvore de Merkle, só é necessário 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á realmente 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 deseja efetuar um saque, ele precisa verificar duas coisas:

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

·Cn está relacionado com o voucher de depósito de Bob.

Lógica de Negócios do Tornado Explicada

No código frontend da interface do utilizador do Tornado, inúmeras funcionalidades foram pré-implementadas. Quando um depositante abre a página web do 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) ao contrato Tornado para ser incorporado na sua Árvore de Merkle. Em termos simples, K e r atuam como chaves privadas. São críticas, e os utilizadores são aconselhados a guardá-las com segurança, pois serão necessárias novamente durante o processo de levantamento.

Uma “encryptedNote” é uma funcionalidade opcional que permite aos utilizadores encriptar as credenciais K e r com uma chave privada e armazená-las na cadeia para evitar esquecimentos.

É importante notar que todas as operações acima ocorrem fora da cadeia, o que significa que nem o contrato Tornado nem quaisquer observadores externos estão cientes de K e r. Se K e r forem expostos, é semelhante a ter a chave privada da carteira roubada.

Ao receber o depósito de um usuário e o Cn calculado = 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 posteriormente 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 apenas registradas como parâmetros de eventos em blocos passados. O contrato Tornado apenas registra 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 um pouco às retiradas de ponte entre clientes leves de cadeias cruzadas. 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 sejam diferentes).

Durante o processo de retirada, o retirante insere as credenciais/chaves privadas (números aleatórios K e r gerados durante o depósito) na página 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 registo de depósito na Árvore de Merkle e que K e r são as credenciais válidas para Cn. Este passo prova essencialmente o conhecimento das chaves de um registo de depósito na Árvore de Merkle. Quando a Prova de ZK é submetida ao contrato Tornado, os quatro parâmetros são ocultos, garantindo que os outsiders, incluindo o próprio contrato Tornado, permaneçam inconscientes, protegendo assim a privacidade do utilizador.

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 seguro o suficiente e pode potencialmente ser forçado por tentativa e erro.

Relativamente ao símbolo “A” na ilustração, este representa o endereço que recebe a retirada e é fornecido pelo retirante. Entretanto, “nf” é um identificador estabelecido para evitar ataques de repetição, tendo o seu valor determinado como nf=Hash(K), onde K é um dos dois números aleatórios (K e r) utilizados durante o depósito para gerar Cn. Deste modo, cada Cn tem um nf correspondente, estando os dois ligados de forma única.

Por que a necessidade de prevenir ataques de repetição? Devido às características de design do mixer, durante o saque, não está claro qual depósito na árvore de Merkle corresponde aos fundos sacados. Como a conexão entre o depositante e os valores sacados permanece obscura, usuários maliciosos podem explorar isso e sacar repetidamente do mixer, esgotando 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 prevenir repetições de transações. Após um pedido de levantamento, os utilizadores devem enviar um nf. O sistema verifica se este nf foi usado anteriormente: se foi, o levantamento é invalidado; se não, o levantamento prossegue, e o nf fica registado, garantindo que o seu uso subsequente resultaria em invalidação.

Alguns podem perguntar: Será possível fabricar um nf que o contrato não tenha registado? Isso é improvável. Durante a geração da Prova de Conhecimento Zero (ZK Proof), é essencial garantir que nf=Hash(K), e que o número aleatório K está ligado ao registo do depósito Cn. Se alguém criar arbitrariamente um nf, este não corresponderá a nenhum dos depósitos registados, tornando impossível a geração de uma Prova de Conhecimento Zero válida, o que consequentemente faz com que o processo de levantamento fique bloqueado.

Outros podem questionar: Existe alguma maneira de contornar o uso de nf? Dado que os retirantes devem apresentar uma Prova ZK, que atesta sua conexão com um Cn específico, não seria suficiente verificar se uma Prova ZK correspondente já foi registrada na cadeia? No entanto, os custos associados a essa abordagem são exorbitantes, uma vez que o contrato Tornado Cash não armazena perpetuamente as Provas ZK enviadas anteriormente 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.

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: Os utilizadores submetem a Prova ZK, nf (NullifierHash) = Hash(K), e designam um endereço de destinatário para a retirada. A Prova ZK oculta os valores de Cn, K e r, garantindo que o mundo exterior não consiga determinar a identidade do utilizador. Tipicamente, os destinatários irão especificar um endereço limpo e novo para evitar revelar informações pessoais.

No entanto, surge um desafio menor: quando os utilizadores levantam fundos, por questões de rastreabilidade, muitas vezes utilizam endereços recém-gerados para iniciar a transação de levantamento. Nessas alturas, esses novos endereços não têm ETH para cobrir as taxas de gás. Portanto, durante o levantamento, o endereço deve declarar explicitamente um relayer para cobrir as taxas de gás. Posteriormente, o contrato de mistura deduz uma parte do levantamento do utilizador para compensar o relayer.

Em conclusão, o Tornado Cash pode obscurecer a ligação entre depositantes e sacadores. Quando há uma grande base de usuários, é semelhante a um criminoso se misturando a uma multidão movimentada, tornando difícil para as autoridades rastreá-lo. O processo de retirada emprega ZK-SNARK, com a parte oculta "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.

Aviso legal：

1. Este artigo é reproduzido a partir de [médio]. Todos os direitos de autor 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 Legal: 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 equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.