Explicar el principio de diseño de Tornado Cash V2 en detalle

> El desarrollador ameen.eth combina el concepto de "Prueba de inocencia" con Tornado Cash para proporcionar otra dirección de que "la privacidad no es igual al crimen".

Escrito por: Albert Lin

Prefacio

TornadoCash es un conocido servicio de transacciones anónimas en el mundo de las criptomonedas. TornadoCash utiliza la tecnología ZKP (Zero-Knowledge Proof) para ocultar el origen de los fondos. El gobierno de EE. UU. argumentó que dicho mecanismo facilitó las actividades ilícitas de flujo financiero y finalmente fue sancionado por el Departamento del Tesoro de EE. UU. en agosto de 2022 y obligado a retirarlo de los estantes. La protección de la privacidad y el lavado de dinero siempre parecen ir de la mano en muchos casos. Mientras persiguen la privacidad, los delincuentes a menudo usan estas características de privacidad para lavar fondos ilegales. ¿Se puede encontrar una manera que permita a las personas tener privacidad mientras se frena efectivamente el lavado de dinero? Privacy-Pools de ameen.eth, uno de los primeros desarrolladores de TornadoCash, puede dar una dirección. (Solo el sitio web front-end y el Repositorio de GitHub se ven afectados por la parte de eliminación de la lista, y la parte del contrato no se ve afectada porque está en la cadena de bloques. Finalmente, GitHub restauró el Repositorio gracias a los esfuerzos de Electronic Frontier Foundation. Para más detalles, por favor consulte aquí)

Introducción Principio de TornadoCash

Antes de presentar Privacy-Pools, debe comprender los principios de diseño relacionados con TornadoCash. Para obtener una introducción detallada, consulte mi artículo anterior "Desglosando TornadoCash: una guía para principiantes para explicar su funcionalidad a los amigos". Aquí hay una breve revisión de los principios de diseño de TornadoCash.

TornadoCash utiliza recibos (compromisos) para controlar el acceso. El recibo se genera codificando el secreto (valor secreto) y el anulador (código de cierre de sesión), y cada recibo solo se puede retirar una vez. Utilice Merkle Tree (árbol hash) para registrar la información del depósito, utilice el recibo como nodo hoja y calcule Merkle Root (raíz del árbol hash). El usuario solo necesita proporcionar los datos que se transmiten entre la hoja y la raíz para demostrar si los datos son una de las hojas del árbol Merkle e indirectamente probar que se han depositado fondos en TornadoCash antes. Use la prueba de conocimiento cero para ocultar la fuente del depósito y use el anulador para evitar el ataque de doble retiro.

El recibo de TornadoCash tiene dos significados

  • Prueba de que el remitente ha depositado fondos antes
  • Asegúrese de que cada destinatario solo pueda reclamar fondos una vez

「Prueba-de-inocencia」

De acuerdo con el principio de diseño de TornadoCash, solo se puede saber que los fondos recibidos deben provenir de un depósito anterior, pero no se sabe de qué depósito provino. Este es el objetivo principal de los delincuentes que usan TornadoCash para actividades ilegales de lavado de dinero, y también es la razón por la cual el gobierno de EE. UU. regula TornadoCash. Si podemos proponer otra Prueba (ZKP) para demostrar que los fondos recibidos no son de los depósitos en la lista de rechazo, ¿podemos probar que los fondos recibidos no provienen de delincuentes? Esta es la "Prueba de inocencia" (" Prueba de la inocencia") concepto central.

El concepto de "Prueba de inocencia" se puede dividir en dos direcciones

  • Evidencia de que los fondos recibidos son del cobro de fondos depositados en lista permitida (allowed list)
  • Evidencia de que los fondos que se retiran no provienen del conjunto de fondos de depósito en la lista de rechazo (reject list)

Ambos métodos pueden probar que los fondos retirados no son de los depósitos en la lista de rechazo. El enfoque en la figura a continuación es usar la lista de rechazo para probar que los fondos recibidos no provienen del depósito (rojo) en la lista de rechazo.

fuente:

##Principio de diseño de piscinas de privacidad

Privacy-Pools agrega el concepto de "Prueba de inocencia" a TornadoCash. Además del significado original del recibo de TorandoCash, el recibo de pago de Privacy-Pools tiene un tercer significado: "para demostrar que los fondos recibidos provienen de los depósitos en la lista permitida".

El recibo de Privacy-Pools significa:

  • Prueba de que el remitente ha depositado fondos antes
  • Asegúrese de que cada destinatario solo pueda reclamar fondos una vez
  • Evidencia de que los fondos a retirar provienen de depósitos en la lista permitida

Aquí usamos Allow Merkle Tree para explicar cómo Privacy-Pools usa "Prueba de inocencia" en este sistema (Allow Merkle Tree es el concepto de usar la lista de permisos). En primer lugar, Allow Merkle Tree tiene varias características

  • Permitir Merkle Tree como su nombre indica es un Merkle Tree
  • La altura del árbol y el número de nodos son los mismos que los del árbol Merkle de depósito de los pools de privacidad. *Todas las hojas del Allow Merkle Tree corresponden a la posición de la hoja (depósito) del Deposit Merkle Tree.

Los datos de la hoja Permitir Merkle Tree se pueden dividir en las siguientes dos categorías:

  • permitido: Indica que se permite el depósito en este local. (Las posiciones que aún no han sido depositadas también están permitidas por defecto)
  • bloqueado: Indica que el depósito en esta ubicación es rechazado.

Como se muestra en la figura a continuación, las posiciones de índice 0 y 1 son fondos legales en Deposit Merkle Tree, y las posiciones correspondientes de la hoja Allow Merkle Tree también están permitidas.

Asumiendo que hoy un criminal quiere llevar a cabo actividades de lavado de dinero, deposita los fondos ilegales obtenidos después del ataque en Privacy-Pools, y la ubicación del depósito es Deposit Merkle Tree index: 2. Sabemos que se trata de fondos ilegales, por lo que lo actualizamos a bloqueado en el índice Permitir Merkle Tree correspondiente: posición 2.

Situación de recopilación de la lista de permisos

Suponiendo que hoy, un usuario que deposita en la lista permitida del gobierno de los EE. UU. quiere retirar fondos, debe proporcionar "pruebas de que el depósito está en Dposit Merkle Tree" y "pruebas de que el que está en la lista permitida de los EE. UU. está permitido". La prueba correspondiente a la lista de permitidos de EE. UU. incluye Permitir Merkle Root (proporcionado por el usuario, subetRoot en el código) y el valor del nodo que se pasará en el camino. Cuando Privacy-Pools verifique la etapa ZKP, usará el valor de la hoja según lo permitido (keccak256 (permitido) en el código real) y el valor de nodo dado para pasar a través de construir una Merkle Root. Verifique que este Merkle Root sea el mismo que Permitir Merkle Root proporcionado por el usuario. Si se pasa la verificación del mismo representante, significa que el fondo para el retiro es de un depósito que existe en la lista de permisos del gobierno de los EE. UU.

Situación de recogida de la lista de rechazos

Hoy, un usuario cuyo depósito no está en la lista permitida del gobierno de EE. UU. quiere retirar fondos, y la ubicación de depósito correspondiente está marcada como bloqueada en la lista permitida del gobierno de EE. UU. Esto hará que el usuario no pueda usar la lista de permisos del gobierno de los EE. UU. Permitir Merkle Root para retirar fondos, porque no se puede generar la prueba correspondiente y la verificación fallará (porque Privacy-Pools usa el valor de permitido para la hoja para hacer La ubicación está marcada como bloqueada, por lo que no se puede calcular el mismo Merkle Root).

Dicho diseño obliga al usuario a proporcionar otro Permitir que Merkle Root retire fondos (otros Árboles Permitir Merkle deben marcar la ubicación del depósito como permitida para calcular el mismo Permitir que Merkle Root pase la verificación). Este otro Allow Merkle Tree puede ser mantenido por otros gobiernos o instituciones, o incluso generado por este mismo usuario. Hoy en día, el gobierno de los EE. UU. puede usar Permitir la raíz de Merkle utilizada al realizar retiros para determinar si los fondos del usuario cumplen con las leyes y regulaciones del gobierno de los EE. UU., a fin de lograr el propósito de seguimiento. Si el usuario está utilizando el Allow Merkle Tree generado por él mismo o no es creíble, básicamente es muy probable que el fondo de retiro provenga de un depósito problemático (todos los Allow Merkle Tree de terceros creíbles marcan la ubicación del depósito como bloqueada).

Preguntas frecuentes

**P: Si el retiro proporciona el Allowroot, ¿es posible falsificar un Allow Merkle Root falso para demostrar que la hoja es un depósito en la lista permitida? ¿Significa que el dinero aún se puede retirar? **

R: La respuesta es sí, de hecho es posible retirar el dinero. El autor señaló específicamente que tal mecanismo no es para prohibir a los delincuentes que se lleven el dinero, pero incluso si pueden quitarlo, se sabrá que los fondos están en la lista de rechazo. Cuando el retirador proporciona un Allow Merkle Root poco convincente, básicamente se puede considerar que se retira de la lista de rechazo. El autor supone que la razón para permitir esto es mantener la naturaleza descentralizada de este servicio. Porque cada Allow Merkle Tree necesita cierta gestión de autoridad para actualizar el estado de cada hoja. Si una cierta raíz del árbol de permisos es obligatoria, significa que alguien tiene cierta autoridad para controlar el retiro de fondos, lo que no está en línea con el espíritu de descentralización.

**P: ¿Quién decidirá si la transacción proviene de fondos de la lista de rechazo? **

R: La parte que vi no se mencionó específicamente, y entiendo que esta parte debe ser realizada por cada agencia reguladora. Suponiendo que hoy el gobierno de los EE. UU. quiera verificar el dinero sucio de Privacy-Pools, puede verificar si es dinero sucio verificando Permitir Merkle Root de cada transacción. En cuanto a qué tipo de Allow Merkle Root está permitido, cada agencia reguladora debe juzgar por sí misma.

Código de grupos de privacidad

El código principal y los propios comentarios del autor se adjuntan aquí, con la esperanza de ayudar a todos a comprender la lógica principal a través del código.

// circuitos/retirar_de_subconjunto.circom

plantilla RetirarDeSubconjunto(niveles, valoresperado) {

// público

raíz de entrada de señal;

subconjunto de entrada de señalRoot;

anulador de entrada de señal;

entrada de señal assetMetadata; // abi.encode(token, cantidad).snarkHash();

entrada de señal retirar metadatos; // abi.encode(destinatario, reembolso, repetidor, tarifa).snarkHash();

// privado

secreto de entrada de señal;

ruta de entrada de la señal; // Indicar si los datos representan la hoja izquierda o la hoja derecha.

entrada de señal mainProof [levels] ; // Construya los datos necesarios para depositar la raíz.

subconjunto de entrada de señal [levels] ; // Construya los datos requeridos para permitir la raíz.

// Calcular el anulador y el compromiso.

componente hasher = CommitmentNullifierHasher();

hasher.secret <== secreto;

hash.ruta <== ruta;

hasher.assetMetadata <== activoMetadata;

anulador === hasher.anulador;

// valor esperado: keccak256("permitido") % p

componente doubleTree = DoubleMerkleProof(niveles, valoresperado);

doubleTree.leaf <== hasher.compromiso;

// Convierte la ruta a bits para especificar si es la hoja izquierda o la hoja derecha.

// Se puede observar que el árbol de depósito y el árbol de permisos comparten el mismo camino.

doubleTree.ruta <== ruta;

for ( i = 0; i < niveles; i++) {

doubleTree.mainProof [i] <== prueba principal [i] ;

doubleTree.subsetProof [i] <== prueba de subconjunto [i] ;

}

raíz === dobleÁrbol.raíz; // Verificar la raíz del depósito.

subconjuntoRaíz === árboldoble.subconjuntoRaíz; // Verificar la raíz permitida.

señal retirarMetadataSquare;

retirarMetadataSquare <== retirarMetadata * retirarMetadata;

}

TLDR

  • "Prueba de Inocencia" es usar otra Prueba para demostrar que el pago proviene del depósito en la lista permitida. La "prueba de inocencia" se puede construir desde dos perspectivas: la lista de permitidos y la lista de negados.
  • Privacy-Pools superpone el concepto de "Prueba de inocencia" sobre la base de TornadoCash. El recibo original representa un tercer significado: "Prueba de que los fondos recibidos provienen de los depósitos en la lista permitida".
  • La existencia de Allow Merkle Tree puede probar que el retiro de fondos existe en la lista permitida. La posición de la hoja del Allow Merkle Tree corresponde a la posición de la hoja de depósito del Deposit Merkle Tree. Permitir que los datos de la hoja de Merkle Tree estén permitidos y bloqueados.
  • Además de la información requerida para construir Depositar Merkle Root, el destinatario también debe proporcionar Permitir Merkle Root y la construcción Permitir Merkle Root información para demostrar que el retiro de fondos existe en la lista permitida.
  • Dado que el destinatario proporciona Allow Merkle Root, los delincuentes todavía tienen una forma de llevarse los fondos ilegales a través de Allow Merkle Root falso. El falso Allow Merkle Root seguirá apareciendo en la cadena y otros lo considerarán dudoso sobre el pago, a fin de rastrear el flujo de fondos ilegales.

El desarrollador ameen.eth combina el concepto de "Prueba de inocencia" con TornadoCash para proporcionar otra dirección de que "la privacidad no es igual al crimen". El autor encuentra interesante usar otro ZKP para probar otro hecho, que es un poco como la adición de ZKP. Esta forma de uso será más simple y eficiente que construir una ZKP más grande y más compleja. Con respecto a la elección de Allow Merkle Tree, siento que será construida por una unidad más justa en el futuro, que será más persuasiva para los demás.

Finalmente, ¡gracias a Chih-Cheng Liang y Ping Chen por ayudar a revisar el artículo y dar valiosas opiniones!

> Referencia:

> Dirección oculta

> Análisis de instancias de Tornado Cash

> Introducción al desarrollo de ZKP y contratos inteligentes

> [Club de lectura ZKP] TornadoCash

> Tornado Cash — Cómo funciona | DeFi + Prueba de conocimiento cero

> Comprensión profunda de los detalles técnicos de TornadoCash

> 0xhhh Hilo que presenta nuevas funciones y sus principios

> vídeo de demostración

> Charla de Vitalik sobre cómo mejorar Tornadov2

> piscinas de privacidad v0tweet

> Presentamos Prueba de inocencia basada en TornadoCash

Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
  • Recompensa
  • Comentar
  • Compartir
Comentar
0/400
Sin comentarios
  • Anclado
Comercie con criptomonedas en cualquier lugar y en cualquier momento
qrCode
Escanee para descargar la aplicación Gate.io
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)