Introducción:

Recientemente, Vitalik y varios académicos publicaron conjuntamente un nuevo documento que aborda cómo Tornado Cash implementa su esquema contra el lavado de dinero (básicamente permitiendo al retirante demostrar que su historial de depósitos pertenece a un conjunto que no incluye fondos contaminados). Sin embargo, el documento carecía de una explicación detallada de la lógica empresarial y los principios de Tornado Cash, lo que dejó a algunos lectores con solo un entendimiento superficial.

Vale la pena destacar que proyectos como Tornado, que representan empresas de privacidad, utilizan genuinamente el aspecto de conocimiento cero del algoritmo ZK-SNARK. Mientras tanto, la mayoría de las soluciones que ostentan la bandera de ZK, como Rollups, simplemente aprovechan la concisión de ZK-SNARK. A menudo, las personas tienden a confundir la Prueba de Validez con ZK, y Tornado sirve como un excelente ejemplo para aclarar la aplicación del conocimiento cero en el mundo real.

El autor de este artículo había escrito un artículo sobre los principios de Tornado en 2022 para la investigación de Web3Caff. Hoy, hemos extraído y ampliado ciertas secciones de ese trabajo original para proporcionar una comprensión sistemática de Tornado Cash.

Enlace del Artículo Original:https://research.web3caff.com/zh/archives/2663?ref=157

El Principio de “Tornado”

Tornado Cash utiliza la prueba de conocimiento cero como su protocolo de mezcla. Mientras que su versión anterior fue lanzada en 2019, una versión beta del modelo actualizado fue lanzada a finales de 2021. La versión anterior de Tornado logró un buen nivel de descentralización con contratos en cadena de bloques siendo de código abierto y libres de controles de firma múltiple. Además, el código frontend era de código abierto y respaldado en la red IPFS. Debido a la simplicidad de la versión anterior de Tornado, este artículo se centra en explicarlo.

El enfoque principal de Tornado es mezclar numerosas acciones de depósito y retiro juntas. Después de depositar Tokens en Tornado, los depositantes presentan una Prueba de Conocimiento Cero (ZK Proof) para verificar su depósito anterior y luego retiran usando una nueva dirección, rompiendo así la conexión entre las direcciones de depósito y retiro.

Para ser más concisos, imagina Tornado como una caja de vidrio llena de monedas (Coins) depositadas por muchas personas. Podemos ver quién depositó las monedas, pero estas monedas son muy homogéneas. Si alguien ajeno tomara una moneda de la caja, sería difícil rastrear quién la puso originalmente allí.

（图源：rareskills）

Tales escenarios parecen comunes. Cuando intercambiamos algunos ETH de un pool de Uniswap, es imposible determinar de quién hemos recibido esos ETH, dadas las numerosas proveedores de liquidez en Uniswap. Sin embargo, la diferencia radica en el proceso. Con Uniswap, intercambiar Tokens requiere otro Token de valor equivalente, y los fondos no pueden ser transferidos de forma 'privada'. En contraste, un mezclador simplemente requiere que el retirante presente su recibo de depósito.

Para que las acciones de depósito y retiro parezcan homogéneas, el pool de Tornado mantiene consistencia en los montos de depósito y retiro. Por ejemplo, si un pool tiene 100 depositantes y 100 retirantes, aunque las acciones son públicamente visibles, parece no haber conexión entre ellas. Todos depositan y retiran la misma cantidad, lo que dificulta rastrear el movimiento de fondos. Claramente, esto proporciona una ventaja innata para el lavado de dinero.

La pregunta clave surge: al retirarse, ¿cómo se prueba su depósito previo? La dirección que inicia el retiro no está vinculada a ninguna dirección de depósito, entonces, ¿cómo se verifica el derecho a retirarse? El método más directo sería que el retirante revele su registro de depósito, pero eso expondría su identidad. Aquí es donde entran en juego las pruebas de conocimiento cero.

Con una Prueba ZK, un retirante puede confirmar que tiene un registro de depósito en el contrato Tornado y que este depósito aún no ha sido retirado. La belleza de las pruebas de conocimiento cero es que preservan la privacidad. El público solo sabe que el retirante hizo un depósito pero no puede determinar su identidad específica.

Para demostrar que 'He depositado en el grupo de Tornado' se puede traducir como 'Mi registro de depósito se puede encontrar en el contrato de Tornado.' Si Cn denota un registro de depósito, entonces, dado que el conjunto de registros de depósito de Tornado es {C1, C2,...,C100...}, Bob necesita demostrar que utilizó su clave privada para generar un registro en este conjunto sin revelar cuál es el Cn específico. Esto utiliza las propiedades únicas de la Prueba de Merkle.

Todos los registros de depósitos de Tornado se agregan en un Árbol de Merkle construido en cadena. La mayoría de estas hojas (alrededor de 2^20, más de 1 millón) permanecen en blanco (con un valor inicial). Cada nuevo depósito actualiza una hoja de compromiso correspondiente y luego la raíz del árbol.

Por ejemplo, si el depósito de Bob fue el décimo milésimo en la historia de Tornado, el valor asociado Cn sería la décima milésima hoja del árbol, es decir, C10000 = Cn. El contrato luego calcularía automáticamente la nueva Raíz.

（Fuente: RareSkills）

La Prueba de Merkle en sí misma es concisa y eficiente. Para demostrar que una transacción TD existe dentro de un Árbol de Merkle, solo es necesario proporcionar la Prueba de Merkle asociada, que sigue siendo compacta incluso si el Árbol de Merkle es vasto.

Para validar que una transacción, digamos H3, está incluida de hecho en el Árbol de Merkle, uno tiene que demostrar que usando H3 y otros datos del Árbol de Merkle se puede generar la Raíz. Estos datos (incluido Td) constituyen la Prueba de Merkle. Cuando Bob quiere retirar, necesita verificar dos cosas:

·Cn está en el Árbol de Merkle construido en la cadena por Tornado, para el cual puede construir una Prueba de Merkle que contiene Cn；

·Cn está relacionado con el comprobante de depósito de Bob.

Lógica empresarial de Tornado explicada

En el código frontend de la interfaz de usuario de Tornado, se han pre-implementado numerosas funcionalidades. Cuando un depositante abre la página web de Tornado Cash y hace clic en el botón de depósito, el código frontend adjunto genera dos números aleatorios, K y r, localmente. Luego calcula el valor de Cn=Hash(K, r), pasando Cn (llamado compromiso en el diagrama a continuación) al contrato de Tornado para ser incorporado en su Árbol de Merkle. En pocas palabras, K y r actúan como claves privadas. Son críticos, y se recomienda a los usuarios que los almacenen de forma segura, ya que serán requeridos nuevamente durante el proceso de retiro.

Una "encryptedNote" es una función opcional que permite a los usuarios cifrar las credenciales K y r con una clave privada y almacenarlas en la cadena para evitar olvidarlas.

Es importante destacar que todas las operaciones anteriores se realizan fuera de la cadena, lo que significa que ni el contrato de Tornado ni ningún observador externo son conscientes de K y r. Si K y r se exponen, es similar a que se haya robado la clave privada de la cartera.

Al recibir el depósito de un usuario y el cálculo Cn=Hash(K, r), el contrato Tornado coloca Cn en el nivel base del Árbol de Merkle, convirtiéndolo en un nuevo nodo hoja y actualizando posteriormente el valor de la raíz. Sin embargo, es importante entender que las hojas de este Árbol de Merkle no se registran en el estado del contrato, sino que solo se registran como parámetros de eventos en bloques anteriores. El contrato Tornado solo registra la raíz de Merkle. Durante la retirada, los usuarios pueden demostrar, a través de una Prueba de Merkle, que el registro de depósito corresponde a la raíz de Merkle actual, un concepto que se asemeja en cierta medida a las retiradas de puentes entre cadenas de clientes ligeros. Este diseño revela la ingeniosidad de Tornado: para ahorrar costos de gas, el árbol de Merkle completo no se registra en el estado del contrato, solo su raíz. Las hojas del árbol se registran simplemente en registros de bloques históricos, un mecanismo algo análogo al principio de ahorro de gas de Rollup (aunque los detalles difieren).

Durante el proceso de retiro, el retirante introduce las credenciales/llaves privadas (números aleatorios K y r generados durante el depósito) en la página web de frontend. El código frontend de Tornado Cash utiliza K y r, Cn=Hash(K, r), y la Prueba de Merkle correspondiente a Cn para generar una Prueba de Conocimiento Cero (ZK Proof), confirmando así que Cn corresponde a un registro de depósito en el Árbol de Merkle y que K y r son las credenciales válidas para Cn. Este paso demuestra esencialmente el conocimiento de las llaves de un registro de depósito en el Árbol de Merkle. Cuando la Prueba de Conocimiento Cero se presenta al contrato de Tornado, los cuatro parámetros están ocultos, asegurando que los externos, incluido el propio contrato de Tornado, permanezcan inconscientes, protegiendo así la privacidad del usuario.

Un detalle interesante es que la operación de depósito utiliza dos números aleatorios, K y r, para generar Cn en lugar de solo uno, porque un solo número aleatorio podría no ser lo suficientemente seguro y potencialmente podría ser forzado por fuerza bruta.

En cuanto al símbolo "A" en la ilustración, representa la dirección que recibe la retirada y es proporcionada por el retirante. Mientras tanto, "nf" es un identificador establecido para evitar ataques de repetición, su valor determinado como nf=Hash(K), donde K es uno de los dos números aleatorios (K y r) utilizados durante el depósito para generar Cn. Como tal, cada Cn tiene un nf correspondiente, y los dos están vinculados de forma única.

¿Por qué la necesidad de prevenir ataques de repetición? Debido a las características de diseño del mezclador, durante la retirada, no está claro qué depósito en el Árbol de Merkle corresponde a los fondos retirados. Dado que la conexión entre el depositante y los montos retirados sigue siendo oscura, los usuarios malintencionados podrían aprovechar esto y retirar repetidamente del mezclador, agotando el pool de tokens.

Aquí, el identificador nf funciona de manera similar al contador de transacciones “nonce” inherente a cada dirección de Ethereum, establecido para prevenir repeticiones de transacciones. Al solicitar un retiro, los usuarios deben enviar un nf. El sistema verifica si este nf ha sido usado previamente: si ha sido utilizado, el retiro se invalida; si no, el retiro procede y el nf se registra, asegurando que su uso posterior resultaría en una invalidación.

Algunos podrían preguntarse: ¿Puede alguien fabricar un nf que el contrato no haya registrado? Es poco probable. Durante la generación de la Prueba de Conocimiento Cero, es esencial asegurar nf=Hash(K), y el número aleatorio K está vinculado al registro de depósito Cn. Si alguien crea arbitrariamente un nf, no coincidirá con ninguno de los depósitos registrados, lo que hará imposible la generación de una Prueba de Conocimiento Cero válida, y posteriormente detendrá el proceso de retiro.

Otros podrían preguntar: ¿Hay alguna manera de evitar el uso de nf? Dado que los retirantes deben presentar una Prueba de Conocimiento Cero (ZK Proof), que atestigua su conexión con un Cn específico, ¿no sería suficiente comprobar si ya se ha registrado una Prueba de Conocimiento Cero correspondiente en la cadena? Sin embargo, los costos asociados con este enfoque son exorbitantes, ya que el contrato de Tornado Cash no almacena de forma perpetua las Pruebas de Conocimiento Cero presentadas anteriormente para evitar el desperdicio de almacenamiento. Comparar cada nueva Prueba de Conocimiento Cero con las existentes para garantizar la consistencia requiere muchos más recursos que simplemente registrar un identificador compacto como nf.

Según el ejemplo de código de la función de retiro, los parámetros requeridos y la lógica empresarial son los siguientes: los usuarios envían Prueba ZK, nf (NullifierHash) = Hash(K), y designan una dirección de destinatario para el retiro. La Prueba ZK oculta los valores de Cn, K y r, asegurando que el mundo exterior no pueda determinar la identidad del usuario. Normalmente, los destinatarios especificarán una dirección limpia y nueva para evitar revelar información personal.

Sin embargo, surge un desafío menor: cuando los usuarios realizan retiros, con el fin de no ser rastreados, a menudo utilizan direcciones recién generadas para iniciar la transacción de retiro. En esos momentos, estas nuevas direcciones no tienen suficiente ETH para cubrir las comisiones de gas. Por lo tanto, durante el retiro, la dirección debe declarar explícitamente un retransmisor para cubrir las comisiones de gas. Posteriormente, el contrato mezclador deduce una parte del retiro del usuario para compensar al retransmisor.

En conclusión, Tornado Cash puede oscurecer la conexión entre depositantes y retirantes. Cuando hay una gran base de usuarios, es similar a un criminal mezclándose en una multitud bulliciosa, lo que dificulta que las autoridades hagan un seguimiento. El proceso de retiro emplea ZK-SNARK, con la parte oculta del “testigo” que contiene información crucial sobre el retirante. Esta es, posiblemente, la característica más vital del mezclador. Actualmente, Tornado podría ser una de las aplicaciones más ingeniosas relacionadas con ZK.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [medio]. Todos los derechos de autor pertenecen al autor original [Faust, web3 geek]. Si hay objeciones a esta reimpresión, por favor contacte al equipo de Gate Learn（gatelearn@gate.io) y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.