ZK Proofs: Un Análisis en Profundidad

La intuición central de los ZK proofs

Un ZK proof es un protocolo criptográfico donde un probador convence a un verificador de que un enunciado es verdadero, sin revelar ninguna información más allá del hecho de que el enunciado es verdadero. La ilustración clásica: imagina que quieres demostrarle a un amigo daltónico que dos pelotas son de colores distintos, sin decirle cuál es cuál. Le muestras las pelotas, las pone detrás de su espalda y las intercambia o no, y luego te las muestra nuevamente. Si siempre puedes identificar correctamente si las intercambió, has demostrado que las pelotas son distinguibles, pero no has revelado nada sobre qué color es cuál.

En la versión digital, el 'enunciado' es una relación matemática: 'Conozco un valor x tal que f(x) = y', donde y es público y x es secreto. Un ZK proof convence al verificador de que ese x existe sin revelar x en sí.

Completitud, solidez y zero-knowledge

Un sistema formal de ZK proof tiene tres propiedades. Completitud: si el probador conoce un testigo válido, siempre puede convencer al verificador. Solidez: si el probador no conoce un testigo válido, no puede convencer al verificador (excepto con probabilidad despreciable). Zero-knowledge: la prueba no revela nada más allá de la verdad del enunciado; un simulador que no conoce el testigo puede producir pruebas indistinguibles de las reales.

Estas tres propiedades juntas hacen que los ZKPs sean útiles para la autenticación que preserva la privacidad, la divulgación selectiva y las credenciales anónimas: demuestras que sabes algo sin revelar qué es lo que sabes.

SNARKs: pruebas sucintas con configuración de confianza

Los zk-SNARKs (Succinct Non-interactive ARguments of Knowledge) son la clase de ZK proofs más ampliamente desplegada. 'Sucinto' significa que la prueba es pequeña (cientos de bytes) y rápida de verificar (milisegundos), independientemente de la complejidad del cómputo subyacente. 'No interactivo' significa que la prueba es un único mensaje del probador al verificador, sin intercambios de ida y vuelta.

El compromiso es una 'configuración de confianza' (trusted setup): generar los parámetros de SNARK requiere una ceremonia de cómputo multipartita donde los participantes deben mantener secretos sus inputs aleatorios. Si todos los participantes confabulan, pueden falsificar pruebas. Las ceremonias modernas (como Powers of Tau de Zcash) involucran a cientos de participantes, haciendo la confabulación prácticamente imposible, pero el requisito sigue siendo una preocupación filosófica.

Los SNARKs son utilizados por Zcash, muchos rollups de Capa 2 de Ethereum (zkSync, Polygon zkEVM) y las primeras versiones del sistema de pruebas de Midnight.

STARKs: transparentes pero más grandes

Los zk-STARKs (Scalable Transparent ARguments of Knowledge) eliminan el requisito de configuración de confianza: usan solo aleatoriedad verificable públicamente, haciéndolos 'transparentes'. Los STARKs también son seguros frente a computación cuántica, ya que se basan en funciones hash en lugar de suposiciones sobre curvas elípticas.

El compromiso: las pruebas STARK son significativamente más grandes que las pruebas SNARK (kilobytes vs. cientos de bytes) y algo más lentas de verificar. A medida que el hardware y los algoritmos mejoran, la brecha de tamaño se está reduciendo. Los STARKs son utilizados por StarkNet (L2 de Ethereum) y se están explorando para futuros sistemas de pruebas de Midnight.

Cómo Midnight usa los ZK proofs

Midnight usa ZK proofs de forma generalizada. Cada transacción en Midnight que involucra estado protegido (privado) incluye un ZK proof de que la transición de estado se computó correctamente. El compilador de Compact toma una definición de contrato y genera un circuito aritmético que puede demostrarse en zero-knowledge.

Cuando un usuario envía una transacción de Midnight, su dispositivo local (a través del Midnight SDK) genera la prueba usando sus datos de testigo privados. Esta generación de pruebas en el lado del cliente es computacionalmente intensiva: puede tardar varios segundos en un portátil estándar. La prueba resultante se adjunta a la transacción y es verificada por los nodos de Midnight, que pueden hacerlo rápidamente gracias a la propiedad de sucintez del sistema de pruebas subyacente.

Ejemplos reales de divulgación selectiva ZK

Verificación de edad sin revelar fecha de nacimiento: Una credencial emitida por un gobierno contiene tu fecha de nacimiento completa. Un esquema de ZK proof te permite demostrar 'soy mayor de 18 años' a cualquier servicio, con el servicio verificando una prueba criptográfica contra la clave pública de la credencial, sin ver tu fecha de nacimiento real ni ninguna otra información personal.

KYC sin compartir datos: Un usuario se somete a KYC con un proveedor y recibe una credencial firmada. Puede demostrar a un protocolo DeFi que está verificado por KYC (y en qué jurisdicción) sin que el protocolo reciba nunca sus datos personales: los datos personales permanecen con el usuario y solo se comparte la prueba.

Montos de transacción confidenciales: Un sistema de pago puede demostrar que Alice pagó a Bob el monto correcto y que Alice tenía saldo suficiente, sin revelar los montos a nadie más que a Alice y Bob. Zcash fue pionero en este caso de uso; Midnight aplica técnicas similares a las interacciones con smart contracts.

Limitaciones y compromisos actuales

La generación de pruebas en el lado del cliente es lenta. En el hardware actual, generar un ZK proof para un contrato de Midnight de complejidad moderada tarda entre 5 y 30 segundos. Esto crea una latencia que muchas aplicaciones de consumo consideran inaceptable. La aceleración por hardware (probadores GPU/ASIC) y las mejoras algorítmicas son áreas de investigación activa que se espera reduzcan esto significativamente antes de 2027.

La complejidad del circuito limita lo que se puede demostrar. No todos los programas se compilan eficientemente en circuitos ZK. La recursión, los bucles dinámicos y ciertas operaciones con estructuras de datos son costosas o impracticables en los sistemas ZK actuales. El diseño de Compact restringe el modelo de contrato para que coincida con lo que los circuitos ZK pueden representar eficientemente.

La preocupación por la configuración de confianza, aunque prácticamente mitigada por las grandes ceremonias, sigue siendo una limitación conceptual de los sistemas basados en SNARK. Los proyectos que requieren las garantías de transparencia más sólidas pueden preferir alternativas basadas en STARK a pesar del mayor costo en tamaño y verificación.