Solidchain

Criptografía / Blockchain / Web

Comprendiendo las Pruebas de Cero Conocimiento (Zero-Knowledge Proofs): De zk-SNARKs a la Privacidad Web

· Lectura: 13 minutos

Un dato privado permite generar una prueba; el verificador recibe la afirmación pública y la prueba, sin recibir el dato secreto.

Para comprobar que alguien cumple una condición, muchas aplicaciones piden más información de la que necesitan. Un sitio podría solicitar una foto del documento para verificar la edad, aunque su única pregunta sea si la persona supera un umbral. La respuesta termina acompañada de nombre, fecha de nacimiento y otros datos que el servicio deberá custodiar.

Las pruebas de cero conocimiento, o Zero-Knowledge Proofs (ZKP), permiten demostrar que una afirmación es verdadera sin revelar el secreto que la respalda. Con un protocolo adecuado, podemos acreditar una propiedad de un dato y conservar ese dato en privado.

Esta idea conecta dos problemas: compartir menos información y verificar cálculos sin repetir todo el trabajo. Para entender cómo llega desde la criptografía hasta los zk-SNARKs y la capa 2, empezaremos con una intuición y después seguiremos las ecuaciones.

Recorrido del artículo
  1. Qué se demuestra y qué permanece privado
  2. Las tres propiedades de una ZKP
  3. La cueva y la probabilidad de engañar
  4. Un ejemplo matemático con Schnorr
  5. De un cálculo a un zk-SNARK
  6. Groth16, PLONK y STARKs
  7. Qué verifican los rollups de capa 2
  8. Aplicaciones en privacidad web
  9. Qué garantiza la prueba y qué depende del diseño

1. Qué se demuestra y qué permanece privado

En una prueba intervienen dos roles: el demostrador (prover), que posee información privada, y el verificador (verifier), que comprueba la evidencia. La información privada se llama testigo (witness).

Una forma compacta de escribir el problema es:

R(x, w) = 1

x representa las entradas públicas; w, el testigo privado; y R, la relación que debe cumplirse. El demostrador produce una prueba π. El verificador recibe x y π, y comprueba la relación sin recibir w.

Por ejemplo, la afirmación podría ser: «Conozco un valor que produce este hash público». El testigo sería ese valor. En una credencial de edad, el testigo podría incluir una fecha de nacimiento y una firma del emisor; las entradas públicas, la clave del emisor y la fecha límite aceptada.

Demostrar que un dato cumple una regla exige definir la regla. Probar que una fecha corresponde a una persona adulta no acredita, por sí solo, que esa fecha sea auténtica. La relación también debe comprobar su vínculo con una fuente aceptada, por ejemplo una credencial firmada.

2. Las tres propiedades de una ZKP

Un protocolo de cero conocimiento debe reunir tres propiedades:

La última propiedad se formaliza mediante un simulador: un algoritmo que, sin conocer el testigo, puede generar una vista indistinguible de la que obtiene el verificador. Si esa vista puede reproducirse sin el secreto, la interacción no entrega conocimiento adicional sobre él. Esta formalización nace del trabajo de Goldwasser, Micali y Rackoff.

El resultado sí comunica algo: que se cumple la condición. Si las entradas públicas ya identifican a la persona, la prueba no elimina esa identificación.

3. La cueva y la probabilidad de engañar

Imaginá una cueva con dos caminos, A y B, unidos al fondo por una puerta que solo se abre con una palabra secreta. Querés demostrar que conocés la palabra sin pronunciarla delante de otra persona.

Entrás por uno de los caminos mientras el verificador espera afuera y no ve cuál elegiste. Después te pide, al azar, que regreses por A o por B. Si conocés el secreto, podés abrir la puerta y salir por el camino solicitado.

Si no lo conocés, solo podés volver por el lado por el que entraste. Acertarías por casualidad la mitad de las veces. Si cada desafío es independiente, impredecible y llega después de que elegiste el camino, la probabilidad de superar k rondas sin conocer el secreto es:

P(engañar en todas las rondas) = (1/2)k = 2−k

Explorá el efecto de repetir el desafío

1 entre 1.024 ≈ 0,09765625 %

Modelo de la cueva: una probabilidad de éxito de 1/2 por ronda, con desafíos independientes. Este control calcula la probabilidad; no genera una prueba criptográfica ni mide la seguridad de un zk-SNARK.

El verificador gana confianza sin aprender la palabra. La cueva ayuda a entender la interacción, aunque un sistema real necesita una definición matemática de qué puede observar un atacante y de qué tan difícil resulta engañarlo.

4. Un ejemplo matemático con Schnorr

El protocolo de Schnorr demuestra conocimiento de un exponente secreto. Usaremos números pequeños para seguir las cuentas: p = 23, q = 11 y g = 2. Las potencias de 2 módulo 23 forman un grupo de orden 11. «Módulo» significa tomar el resto de la división.

El secreto es w = 6. El valor público es y = 26 mod 23 = 18. En grupos adecuados y grandes, recuperar el exponente a partir de y es el problema del logaritmo discreto.

  1. El demostrador elige al azar r = 7 y envía t = 27 mod 23 = 13.
  2. El verificador envía un desafío aleatorio, aquí c = 4.
  3. El demostrador responde s = (r + c · w) mod 11 = (7 + 4 · 6) mod 11 = 9.

El verificador comprueba:

gs ≡ t · yc (mod p)
Izquierda: 2⁹ mod 23 = 6
Derecha:   13 · 18⁴ mod 23 = 13 · 4 mod 23 = 6
Resultado: ambos lados coinciden.

La igualdad funciona porque gr + c·w = gr · (gw)c. La aleatoriedad de r oculta el secreto en la respuesta. Esta variante interactiva tiene cero conocimiento frente a un verificador honesto que elige el desafío según el protocolo. Las notas de Berry Schoenmakers explican esta propiedad.

Usamos la convención de respuesta con suma; el RFC 8235 describe la convención equivalente con resta. Estos parámetros permiten recuperar el secreto por enumeración: sirven para aprender, sin ofrecer seguridad.

Del intercambio de mensajes a una prueba no interactiva

La transformación Fiat–Shamir sustituye el desafío del verificador por un hash del compromiso, la afirmación y el contexto del protocolo. Así, cualquiera puede recalcularlo y verificar la prueba. La seguridad se analiza en el modelo de oráculo aleatorio; requiere una transformación adecuada al protocolo. El RFC 8235 especifica este mecanismo para Schnorr.

Este paso introduce la idea de verificación no interactiva. Los zk-SNARKs para cálculos generales necesitan construcciones adicionales.

5. De un cálculo a un zk-SNARK

zk-SNARK significa Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. Cada parte describe una propiedad:

La definición y una aplicación a pagos privados aparecen en la explicación de zk-SNARKs de Zcash. Para entender cómo se prueba un programa, hay que mirar primero cómo se representa.

Convertir instrucciones en restricciones

Supongamos que queremos demostrar que conocemos valores privados a, b y c que satisfacen a · b + c = 17. Podemos dividir el cálculo en dos restricciones:

a · b = t
t + c = 17

Un testigo válido: a = 3, b = 4, c = 5, t = 12.

El circuito describe las igualdades que deben cumplirse. El testigo incluye las entradas privadas y los valores intermedios. Sistemas como R1CS expresan restricciones como productos de combinaciones lineales, una representación utilizada por Circom.

Las operaciones se realizan en un campo finito, normalmente módulo un primo grande. Comparar edades o saldos exige restricciones adicionales de rango: un elemento del campo no se comporta automáticamente como un entero positivo de nuestra aplicación.

El ejemplo admite muchos testigos. Solo demuestra la existencia y el conocimiento de una solución; no que esos números provengan de una factura real. Para acreditar un origen, también deben incorporarse restricciones sobre firmas, compromisos u otra evidencia.

Del circuito a la prueba compacta

En construcciones como Groth16, las restricciones se transforman en relaciones entre polinomios: expresiones que suman términos como x, x2 o x3, multiplicados por coeficientes. Su estructura permite reunir muchas restricciones en identidades algebraicas. La prueba las comprueba mediante operaciones sobre curvas elípticas llamadas emparejamientos. Se añade aleatoriedad para ocultar el testigo. El verificador comprueba una evidencia compacta en lugar de recibir todos los valores intermedios. La construcción está descrita en el trabajo de Jens Groth.

A nivel de aplicación, el flujo puede resumirse así:

π = Probar(parámetros_de_prueba, x, w)
Verificar(parámetros_de_verificación, x, π) → aceptar o rechazar

Generar la prueba suele requerir mucho más trabajo que verificarla. Esa asimetría permite delegar un cálculo y comprobar su resultado con un costo menor, aunque la generación tenga un costo significativo.

6. Groth16, PLONK y STARKs

No hay una única construcción detrás de todas las pruebas ZK. Cambian sus supuestos, parámetros, tamaños y costos.

Tres referencias para entender los compromisos de diseño
SistemaConfiguración inicialCaracterísticas
Groth16Parámetros estructurados específicos del circuito.Pruebas muy compactas; utiliza emparejamientos de curvas elípticas.
PLONK originalReferencia estructurada universal y actualizable, dentro de un límite de tamaño.Permite reutilizar la configuración entre distintos circuitos.
STARKsTransparente, sin un secreto de configuración que deba destruirse.Usa técnicas basadas en hashes; las pruebas suelen ser mayores que las de SNARKs con emparejamientos.

En una trusted setup se generan parámetros públicos mediante aleatoriedad secreta. En esquemas que dependen de ella, conservar ciertos secretos de la configuración permitiría falsificar pruebas. Las ceremonias multipartitas distribuyen esa responsabilidad; su seguridad depende de las condiciones de la ceremonia y de que se eliminen las contribuciones secretas necesarias.

Una configuración confiable no es un requisito de todos los zk-SNARKs. Por ejemplo, el sistema Halo 2 utilizado por Orchard en Zcash elimina esa necesidad. La explicación técnica de sus desarrolladores detalla cómo prescinde de las ceremonias. Tampoco conviene atribuir las mismas propiedades a toda variante de PLONK: el mecanismo que vincula la prueba con los polinomios, llamado compromiso polinómico, importa.

Los STARKs se diseñan con supuestos basados en hashes compatibles con seguridad poscuántica. Esa afirmación depende de las funciones y los parámetros utilizados; no constituye una garantía absoluta frente a cualquier ataque futuro. El trabajo original sobre STARKs desarrolla estos supuestos.

7. Qué verifican los rollups de capa 2

Un zk-rollup ejecuta un lote de transacciones fuera de Ethereum y presenta una prueba de que la transición de estado respeta sus reglas. Un contrato en la capa 1 verifica esa prueba antes de aceptar la actualización.

Estado anterior + transacciones válidas → estado nuevo

Por ejemplo, el circuito puede exigir firmas válidas, saldos suficientes y actualizaciones correctas de las cuentas. Las raíces de estado funcionan como compromisos compactos sobre esos datos. La prueba debe vincular los estados y el lote correspondiente.

El ahorro aparece al verificar evidencia del cálculo agregado en lugar de repetir toda su ejecución en la capa 1. Un rollup también publica datos suficientes para reconstruir su estado; una prueba de validez no sustituye la disponibilidad de datos. Los validiums mantienen esos datos fuera de la capa 1, con supuestos adicionales. La documentación de Ethereum sobre zk-rollups explica esta separación.

La etiqueta «zk» no implica transacciones privadas. La misma documentación indica que los datos publicados por los rollups son públicos. Para ocultar participantes o importes, la aplicación necesita un diseño de privacidad adicional.

8. Aplicaciones en privacidad web

Acreditar una condición con una credencial

Una aplicación podría comprobar «esta persona supera el umbral de edad» sin recibir su fecha de nacimiento. El modelo de credenciales verificables del W3C contempla pruebas sobre atributos ocultos y presentaciones con menos información. Las capacidades concretas dependen del mecanismo criptográfico utilizado.

En un diseño ilustrativo, el navegador o una billetera conservaría la credencial y produciría una prueba que compruebe su firma, la condición de edad y su vínculo con el titular. El servidor recibiría la prueba y los datos públicos necesarios. La aceptación también debe considerar la vigencia, la revocación y el emisor en quien se confía.

Revelar solo un atributo y demostrar una comparación son capacidades distintas. Un mecanismo de divulgación selectiva no permite automáticamente probar cualquier desigualdad sobre un atributo oculto. Otra opción es que el emisor firme directamente una afirmación como «mayor de 18».

Para una sesión web, la prueba debe vincularse a la solicitud y al servicio que la acepta. Por ejemplo, puede incluir un desafío de un solo uso y el dominio del verificador como parte del contexto comprobado. El servidor debe comprobar ese contexto y rechazar desafíos ya utilizados. Así, una evidencia copiada no funciona como una autorización reutilizable en otro contexto.

Demostrar pertenencia sin revelar identidad

Una comunidad puede querer aceptar un voto de cada integrante sin saber quién emitió cada uno. Semaphore permite demostrar pertenencia a un grupo y publicar un mensaje sin revelar la identidad del miembro.

Para impedir acciones duplicadas, emplea un nullifier: un valor derivado del secreto y de un ámbito de uso. El sistema registra los utilizados y rechaza repeticiones. Su ámbito importa: dentro de una misma votación permite detectar duplicados; reutilizar identificadores entre contextos puede facilitar correlaciones.

Validar pagos con datos ocultos

Las transacciones protegidas de Zcash muestran otra aplicación: verificar reglas de pago sin publicar los detalles privados de la transacción. La prueba se combina con compromisos, cifrado y mecanismos contra el doble gasto. Ocultar datos y demostrar la validez de una operación son tareas que se complementan.

9. Qué garantiza la prueba y qué depende del diseño

La garantía criptográfica se refiere a una relación concreta. Si un circuito omite comprobar una firma o una restricción de rango, una prueba válida puede acreditar algo más débil de lo que la aplicación necesita. Calcular un valor y restringirlo son operaciones diferentes; la documentación de Circom advierte sobre esa distinción.

La aleatoriedad también forma parte de la seguridad. En Schnorr, reutilizar el valor aleatorio con desafíos distintos puede revelar el exponente secreto, como explica el RFC 8235.

Y la privacidad de los atributos no resuelve toda la privacidad de una visita web. Las direcciones IP, los identificadores persistentes, los tiempos de acceso y los datos revelados por la propia aplicación pueden permitir correlaciones. El W3C analiza estos límites de privacidad en el uso de credenciales.

Por eso, la pregunta práctica es precisa: ¿qué afirmación acepta el verificador, qué entradas quedan públicas y qué información puede deducirse de ellas? Responderla permite evaluar si el sistema entrega la privacidad o la verificación que promete.

Demostrar una propiedad sin entregar su evidencia privada

El recorrido empieza con una idea sencilla: una persona puede responder desafíos que solo sabe resolver gracias a un secreto. Las ecuaciones convierten esa intuición en un protocolo; los circuitos permiten expresar reglas de programas; y los zk-SNARKs hacen posible verificar pruebas compactas sin un diálogo durante cada comprobación.

En capa 2, esa capacidad sirve para verificar ejecución. En privacidad web, permite compartir una condición comprobable en lugar de todos los datos que la sostienen. La utilidad depende de elegir bien la afirmación y de diseñar el resto de la aplicación para conservar esa separación.

Fuentes y lecturas para profundizar

← Seguir explorando los artículos