Prototipando Pools de Privacidad en Stellar

Lo siguiente describe el prototipado de Privacy Pools en la plataforma de contratos inteligentes Stellar y la red Stellar. Privacy Pools [1] es una manera de realizar transferencias preservando la privacidad mediante la gestión de un fondo de donde los depositantes pueden retirar, mientras se oscurece el vínculo entre retiros y depósitos. Un aspecto innovador de Privacy Pools es la incorporación de Proveedores de Conjunto de Asociación (ASPs) que definen criterios de inclusión destinados a ayudar a mitigar el uso ilícito. Los ASPs permiten a los participantes asociarse selectivamente con conjuntos de otros participantes que cumplen con sus estándares de cumplimiento elegidos. Las garantías de privacidad se logran utilizando técnicas criptográficas de conocimiento cero que permiten probar propiedades útiles de las transacciones sin revelar sus detalles completos.

La implementación de Privacy Pools en Stellar está inspirada en 0xbow [6]. Su repositorio de Github contiene los circuitos relevantes para las pruebas ZK de propiedad de monedas e inclusión en el árbol de Merkle.

El esquema ZK es Groth16 usando una curva BLS12-381, soportado por Soroban.

Cadena de herramientas

Para probar declaraciones sobre transacciones, usamos el compilador Circom. Nos permite describir cálculos con la comodidad del lenguaje Circom y construir circuitos para los cuales podemos generar pruebas de conocimiento cero. Para la máxima eficiencia de generación y verificación de pruebas, usamos el esquema SNARK Groth’16 [7]. Verificar un SNARK (por compleja que sea la declaración) requiere solo un cálculo de emparejamiento bilineal. Esto toma aproximadamente 40 millones de instrucciones en un contrato de Soroban, que es %40 del presupuesto máximo de instrucciones en testnet.

En nuestra base de código el main.circom circuito (Fig.2) se utiliza para generar el SNARK para retirar una moneda. El circuito toma como entradas los parámetros de generación de monedas (s, n). La raíz del árbol de Merkle, y los hermanos a lo largo del camino de la hoja de compromiso. Prueba que la raíz del árbol de Merkle calculada independientemente por el circuito y la raíz de entrada son iguales, y emite el hash anulador.

Previniendo el frontrunning por una parte retransmisora

Si verificamos ingenuamente una prueba de conocimiento cero de depositar una moneda sin verificar quién está retirando, permitimos a una parte retransmisora retirar a cualquier dirección deseada editando la transacción. La prueba de conocimiento cero debe incluir la dirección del destinatario. Esto aún no está implementado en main.circom.

Para ejecutar un verificador ZK en Soroban usamos una no_std implementación compatible de un verificador Groth16, proporcionado en https://github.com/stellar/soroban-examples/tree/main/groth16_verifier.

Adaptamos los circuitos del repositorio 0xbow y los construimos usando Circom.

Implementamos funciones de conversión para usar salidas generadas por Circom con el verificador Groth’16 (es importante asegurarnos de que usamos la misma curva (BLS12-381).

coinutils es una herramienta CLI que maneja los aspectos prácticos de la participación en el pool de privacidad. Gestiona el ciclo de vida completo de las monedas del pool de privacidad, desde la generación hasta la preparación del retiro.

El comando generate crea nuevas monedas con parámetros criptográficamente seguros. Genera un secreto s, un nulificador n, y calcula el compromiso usando el hash de Poseidón sobre elementos de campo BLS12-381. La herramienta produce formatos decimal y hexadecimal, con el formato hexadecimal listo para la integración directa en el contrato.

Para el retiro, el comando withdraw toma un archivo de moneda y un archivo de estado que contiene el árbol de Merkle de compromisos. Reconstruye el árbol de Merkle, genera las pruebas de inclusión de Merkle necesarias y produce entradas compatibles con SNARK para el circuito main.circom. Si se utilizan conjuntos de asociación para verificar la elegibilidad de participación, también genera una prueba de participación legítima.

El comando updateAssociation gestiona listas de participantes que han sido aprobados por ASPs de acuerdo a sus respectivos estándares de cumplimiento y construye árboles de Merkle para habilitar la verificación del estado de aprobación del participante. Mantiene un árbol de Merkle del conjunto de asociación con cierta profundidad, soportando hasta 2depth etiquetas por conjunto.

Todas las operaciones trabajan directamente con elementos de campo BLS12-381, asegurando la compatibilidad con el entorno de Soroban y las pruebas Groth16. La herramienta usa la representación de cadena decimal para la legibilidad humana mientras proporciona salidas hexadecimales para la integración de contrato. Se integra sin problemas con la cadena de herramientas más amplia: las monedas generadas pueden ser depositadas directamente en contratos, y las entradas de retiro están listas para la generación de pruebas de SnarkJS.

• Protección contra frontrunning: incluir dirección del destinatario en la prueba ZK.
• Almacenar las últimas N raíces en el contrato para permitir que el retirador retire mientras se realizan nuevos depósitos.
• Funcionalidad de “rage-quit”: permitir a un usuario retirar sus fondos depositados públicamente si no fueron aprobados mediante un conjunto de asociación.