Zero-Knowledge Proofs: demostrar sin revelar con Groth16 y zkSNARKs

La idea imposible: demostrar que sabes algo sin decir qué sabes

En el verano de 1982, dos jóvenes investigadores del MIT —Shafi Goldwasser, una matemática israelí-estadounidense de veintitrés años, y Silvio Micali, un informático italiano de veintisiete— estaban trabajando en un artículo que sus propios colegas consideraban absurdo. La idea central era tan contraintuitiva que, según contaría Goldwasser décadas después, varios revisores académicos rechazaron el manuscrito inicial con una variación del mismo argumento: «lo que ustedes proponen es, por definición, imposible». Lo que Goldwasser y Micali proponían era lo siguiente: que una persona pudiera demostrar matemáticamente que conoce un secreto —la solución de un problema, una contraseña, la respuesta a una pregunta— sin revelar absolutamente nada sobre ese secreto. Ni un solo bit de información. Ni la más mínima pista.

Piensa en lo radical de esta afirmación. En la vida cotidiana, demostrar que sabes algo implica inevitablemente revelarlo. Si quieres convencer a alguien de que conoces la contraseña de una caja fuerte, la forma obvia es abrirla delante de esa persona. Si quieres demostrar que sabes la solución de un acertijo, la recitas. Si quieres probar que tienes más de dieciocho años, enseñas tu documento de identidad, que de paso revela tu nombre, tu dirección, tu fecha exacta de nacimiento y tu número de identificación. En cada uno de estos casos, la demostración implica una fuga de información que va mucho más allá de lo estrictamente necesario. Goldwasser y Micali querían demostrar que existía otra forma. Una forma en la que la demostración no filtrara nada.

Junto con Charles Rackoff, completaron el artículo y lo presentaron en 1985 bajo el título The Knowledge Complexity of Interactive Proof Systems. La versión definitiva se publicó en SIAM Journal on Computing en 1989, y con ella nació formalmente el concepto de prueba de conocimiento cero (en inglés, zero-knowledge proof, abreviado ZKP). El término «conocimiento cero» no era una metáfora: significaba, en términos matemáticos rigurosos, que el verificador no obtiene literalmente ninguna información nueva después de interactuar con el demostrador, más allá de la convicción de que la afirmación es verdadera. Cero conocimiento transferido. Cero bits de información filtrados.

La reacción de la comunidad académica evolucionó del escepticismo a la fascinación. En 2012, Goldwasser y Micali recibieron el Premio Turing —el equivalente al Nobel en ciencias de la computación—, en gran parte por este trabajo. Pero durante más de dos décadas, las pruebas de conocimiento cero permanecieron en el ámbito teórico, como una curiosidad matemática demasiado lenta y costosa para aplicaciones prácticas. Todo cambió el 28 de octubre de 2016, cuando un grupo de criptógrafos liderado por Zooko Wilcox lanzó Zcash, la primera criptomoneda que utilizaba pruebas de conocimiento cero —específicamente, un sistema llamado Groth16— para permitir transacciones completamente privadas en una blockchain pública. Por primera vez, era posible enviar dinero digital demostrando que la transacción era válida sin revelar quién enviaba, quién recibía ni cuánto se transfería. La idea «imposible» de 1982 se había convertido en infraestructura financiera funcional.

Este artículo recorre el camino completo: desde la intuición básica de qué significa demostrar sin revelar, hasta la mecánica interna de sistemas como Groth16 que hacen posible esta magia matemática. No necesitas conocimientos previos de criptografía. Solo curiosidad y paciencia para dejar que las ideas se asienten.

La cueva de Alí Babá: la analogía que lo explica todo

En 1990, los criptógrafos Jean-Jacques Quisquater y Louis Guillou publicaron un artículo delicioso titulado How to Explain Zero-Knowledge Protocols to Your Children, en el que utilizaban una analogía que se ha convertido en la forma canónica de explicar las pruebas de conocimiento cero. La analogía es tan elegante que merece contarse con detalle.

Imagina una cueva con forma de anillo. La entrada es un túnel que se bifurca en dos caminos —izquierda y derecha— que se adentran en la montaña y se encuentran en el fondo, donde hay una puerta mágica que solo se abre con una palabra secreta. Desde la entrada, no puedes ver el fondo de la cueva; la curvatura del túnel lo impide.

Alicia afirma que conoce la palabra secreta que abre la puerta. Bruno no le cree. Alicia quiere convencer a Bruno de que dice la verdad, pero no quiere revelarle la palabra secreta. ¿Cómo lo hacen?

El protocolo es el siguiente. Primero, Alicia entra sola en la cueva y elige al azar uno de los dos caminos —izquierda o derecha—, sin que Bruno la vea. Bruno no sabe por cuál de los dos caminos ha ido Alicia. Segundo, Bruno se acerca a la bifurcación y grita: «¡Sal por la izquierda!» o «¡Sal por la derecha!», eligiendo al azar. Tercero, Alicia debe salir por el camino que Bruno ha indicado. Si Alicia entró por el camino que Bruno pidió, simplemente da la vuelta y sale. Pero si entró por el camino contrario, necesita atravesar la puerta mágica —usando la palabra secreta— para llegar al otro lado y salir por donde Bruno le pidió.

Si Alicia realmente conoce la palabra secreta, puede cumplir la petición de Bruno el cien por cien de las veces, sin importar por qué camino entró ni por cuál le pidan salir. Si no la conoce, tiene exactamente un cincuenta por ciento de probabilidades de acertar cada vez: las veces que Bruno pida el mismo camino por el que entró, podrá salir sin problema; pero las veces que pida el camino contrario, estará atrapada al otro lado de una puerta que no puede abrir.

Ahora bien, un solo intento no es muy convincente: un impostor tendría un 50% de probabilidades de pasar la prueba por pura suerte. Pero si repiten el protocolo veinte veces, la probabilidad de que un impostor supere todas las rondas es de uno entre un millón (concretamente, una entre 1.048.576, que es 2 elevado a 20). Con cuarenta repeticiones, la probabilidad baja a una entre un billón. Bruno puede repetir la prueba tantas veces como necesite hasta alcanzar el nivel de confianza que desee.

Lo extraordinario es lo que Bruno no aprende durante todo este proceso. Después de cuarenta rondas, Bruno está convencidísimo de que Alicia conoce la palabra secreta. Pero no tiene la menor idea de cuál es esa palabra. No ha obtenido ni un solo bit de información sobre ella. Es más: si Bruno grabara todo el experimento en vídeo e intentara mostrárselo a una tercera persona —Carmen— para convencerla, Carmen no tendría por qué creerle. Bruno podría haber grabado un vídeo falso, acordando previamente con un cómplice por qué camino entrar y por cuál pedir la salida. La prueba solo es convincente para quien la vive en tiempo real, no para terceros. Esta propiedad se llama no transferibilidad, y es fundamental en las pruebas de conocimiento cero.

La analogía de la cueva captura las tres propiedades esenciales que Goldwasser, Micali y Rackoff definieron formalmente. Completitud: si la afirmación es verdadera (Alicia conoce la palabra), el verificador (Bruno) siempre quedará convencido. Solidez: si la afirmación es falsa (Alicia no conoce la palabra), ningún impostor puede engañar al verificador salvo con una probabilidad despreciable. Conocimiento cero: el verificador no obtiene ninguna información adicional más allá de que la afirmación es verdadera.

De la cueva al mundo digital: pruebas interactivas y no interactivas

El problema de tener que estar presente

La analogía de la cueva de Alí Babá ilustra una prueba interactiva: Alicia y Bruno necesitan estar presentes simultáneamente, intercambiando mensajes en tiempo real durante múltiples rondas. En un contexto académico, esto está bien. Pero en el mundo real —y especialmente en el mundo de las blockchains— la interactividad es un problema enorme.

Imagina que Alicia quiere demostrar la validez de una transacción en una blockchain con diez mil nodos. Si la prueba es interactiva, necesita ejecutar el protocolo de la cueva con cada uno de los diez mil nodos. No solo es absurdamente ineficiente, sino que requiere que Alicia esté en línea y disponible en el momento en que cada nodo quiera verificar la prueba. Si Alicia se desconecta, la verificación se detiene.

Lo que necesitamos es una prueba que Alicia pueda generar una sola vez, publicar, y que cualquier persona pueda verificar en cualquier momento, sin interacción con Alicia. Una prueba que funcione como un certificado: un documento que, por sí solo, convence a quien lo examine de que la afirmación es verdadera. Esto es lo que los criptógrafos llaman una prueba no interactiva de conocimiento cero (en inglés, Non-Interactive Zero-Knowledge proof, o NIZK).

La transformación de Fiat-Shamir: convertir diálogo en monólogo

En 1986, Amos Fiat y Adi Shamir —sí, el mismo Shamir de la compartición de secretos— publicaron una idea brillante que resuelve exactamente este problema. La intuición es la siguiente: en una prueba interactiva, el papel del verificador (Bruno) es lanzar desafíos aleatorios. Bruno grita «¡sal por la izquierda!» o «¡sal por la derecha!», y su elección debe ser impredecible para que Alicia no pueda hacer trampas. Pero ¿y si Alicia pudiera generar esos desafíos aleatorios ella misma, de una forma que fuera verificablemente imparcial?

La solución de Fiat y Shamir consiste en reemplazar al verificador por una función hash. Funciona así: Alicia comienza el protocolo generando su primer mensaje (lo que enviaría al verificador en una prueba interactiva). Después, en lugar de esperar a que Bruno le lance un desafío, Alicia pasa su propio mensaje por una función hash criptográfica y usa el resultado como desafío. Como la función hash es determinista pero impredecible —recordemos el efecto avalancha: cualquier cambio mínimo en la entrada produce una salida completamente diferente—, el desafío resultante es efectivamente aleatorio desde la perspectiva de Alicia. Ella no puede manipular el desafío sin cambiar su mensaje inicial, y cambiar el mensaje inicial cambiaría el desafío de forma impredecible.

Es como si, en la analogía de la cueva, en lugar de necesitar a Bruno gritando instrucciones, Alicia llevara una moneda especial que, al lanzarla, siempre cae del mismo lado para las mismas condiciones iniciales, pero cuyo resultado es imposible de predecir de antemano. Alicia no puede hacer trampas porque no puede controlar cómo cae la moneda, y cualquier observador puede verificar que la moneda se lanzó correctamente.

Esta técnica —llamada transformación de Fiat-Shamir o heurística de Fiat-Shamir— es el puente que conecta las pruebas interactivas con las no interactivas. Prácticamente todos los sistemas modernos de pruebas de conocimiento cero la utilizan de una forma u otra. Groth16, PLONK, STARKs: todos aplican variantes de esta idea fundamental.

Circuitos aritméticos: traducir cualquier problema a un lenguaje que las matemáticas entienden

El concepto fundamental

Antes de poder demostrar algo sin revelarlo, necesitamos expresar ese «algo» en un lenguaje matemático preciso. No podemos meter la afirmación «conozco la contraseña de esta cuenta» directamente en un sistema de pruebas. Necesitamos traducirla a operaciones matemáticas elementales: sumas y multiplicaciones. Esta traducción es lo que los criptógrafos llaman un circuito aritmético.

La analogía más accesible es la de una cadena de montaje en una fábrica. Imagina una fábrica que recibe materias primas por una puerta (las entradas), las procesa a través de una serie de estaciones de trabajo conectadas entre sí, y produce un producto terminado por otra puerta (la salida). Cada estación de trabajo realiza exactamente una de dos operaciones: o bien combina dos piezas sumándolas, o bien las combina multiplicándolas. No hay más opciones. Solo sumas y multiplicaciones.

Puede parecer limitante tener solo dos operaciones, pero resulta que con sumas y multiplicaciones se puede expresar cualquier cálculo computacional. ¿Necesitas una comparación «mayor que»? Se descompone en operaciones sobre los bits individuales, que son sumas y multiplicaciones en un campo donde los números solo pueden ser 0 o 1. ¿Necesitas verificar que un número es primo? Se traduce a una secuencia de multiplicaciones y sumas. ¿Necesitas comprobar que una firma digital es válida? Se descompone en miles de sumas y multiplicaciones sobre los puntos de una curva elíptica. Es como descubrir que, con solo dos tipos de piezas de Lego —una pieza «suma» y una pieza «multiplicación»—, puedes construir absolutamente cualquier cosa, desde un castillo hasta un transbordador espacial. La construcción puede ser larga y compleja, pero es posible.

Las estaciones de trabajo de nuestra fábrica se llaman técnicamente puertas (gates). Una puerta de suma toma dos números y produce su suma. Una puerta de multiplicación toma dos números y produce su producto. Los cables que conectan las estaciones se llaman alambres (wires), y cada alambre transporta un número. El circuito completo —todas las puertas conectadas por alambres— es la traducción matemática de la afirmación que queremos demostrar.

R1CS: las reglas del juego

Una vez que tenemos nuestro circuito aritmético —nuestra cadena de montaje con puertas de suma y multiplicación—, necesitamos expresarlo en un formato estandarizado que los sistemas de pruebas puedan procesar. Ese formato se llama R1CS, que son las siglas de Rank-1 Constraint System (sistema de restricciones de rango 1). El nombre es intimidante, pero la idea es sorprendentemente intuitiva cuando se explica con un ejemplo.

Piensa en un puzzle de sudoku. Un sudoku es, en esencia, un sistema de restricciones: cada fila debe contener los números del 1 al 9 sin repetir, cada columna debe contener los números del 1 al 9 sin repetir, y cada cuadrícula de 3×3 debe contener los números del 1 al 9 sin repetir. Si alguien te muestra un sudoku resuelto, puedes verificar en segundos que es correcto comprobando estas restricciones. No necesitas saber cómo lo resolvieron, ni qué estrategia usaron, ni cuánto tiempo les llevó. Solo compruebas que se cumplen las reglas.

R1CS funciona de manera análoga. Cada puerta de multiplicación del circuito se traduce en una restricción de la forma:

(combinación lineal A) × (combinación lineal B) = (combinación lineal C)

Donde A, B y C son sumas ponderadas de las variables del circuito. Cada restricción dice, básicamente: «el producto de esta combinación de variables por aquella combinación de variables debe ser igual a esta otra combinación de variables». Es una regla que debe cumplirse, exactamente como «esta fila debe contener los números del 1 al 9 sin repetir» es una regla del sudoku.

Un ejemplo numérico completo

Veamos un ejemplo concreto para que la abstracción cobre vida. Supongamos que Alicia quiere demostrar que conoce dos números secretos cuyo producto, más uno de ellos, es igual a un valor público. En términos matemáticos, quiere demostrar que conoce valores x e y tales que x × y + x = 15. Supongamos que los valores secretos de Alicia son x = 3 e y = 4 (porque 3 × 4 + 3 = 15).

Primero, traducimos la expresión a un circuito aritmético. Necesitamos descomponerla en operaciones elementales de una en una. El primer paso es calcular el producto: introducimos una variable intermedia m = x × y. Con los valores de Alicia, m = 3 × 4 = 12. El segundo paso es calcular la suma: el resultado final es m + x = 12 + 3 = 15. Ahora tenemos un circuito con dos puertas: una de multiplicación y otra de suma.

En R1CS, cada puerta de multiplicación genera una restricción. La puerta de suma se absorbe en las combinaciones lineales (porque sumar es una operación lineal, no requiere su propia restricción). Así que nuestro R1CS tiene las siguientes variables: una constante fija con valor 1, la entrada pública 15, y las variables privadas x, y y m. El vector completo de variables, que los criptógrafos llaman el testigo (witness), es: (1, 15, 3, 4, 12).

La restricción de nuestra puerta de multiplicación se expresa como tres vectores. El vector A selecciona la variable x: multiplica la tercera posición del testigo por 1 y las demás por 0, obteniendo el valor 3. El vector B selecciona la variable y: multiplica la cuarta posición por 1, obteniendo 4. El vector C selecciona m: la quinta posición, valor 12. La restricción dice: A × B = C, es decir, 3 × 4 = 12. Correcto.

La segunda restricción captura la ecuación completa. El vector A selecciona m + x (sumando las posiciones correspondientes), obteniendo 12 + 3 = 15. El vector B selecciona la constante 1. El vector C selecciona la salida pública 15. La restricción dice: 15 × 1 = 15. Correcto.

Si Alicia hubiera intentado hacer trampas —por ejemplo, usando x = 5 e y = 2, que dan 5 × 2 + 5 = 15, lo cual también es válido, o x = 3 e y = 5, que da 3 × 5 + 3 = 18 ≠ 15—, la restricción fallaría en el segundo caso. El sistema detecta cualquier inconsistencia porque cada restricción debe satisfacerse exactamente. No hay margen para el error ni para la trampa.

Lo crucial es esto: el verificador comprueba que las restricciones se satisfacen sin conocer los valores secretos del testigo. Ve que las ecuaciones cuadran, pero no sabe qué números específicos las hacen cuadrar. Es como el inspector que verifica un sudoku resuelto: sabe que la solución es correcta, pero si solo viera las restricciones cumplidas sin ver los números, sabría que existe una solución válida sin conocer cuál es.

Curvas elípticas y pairings: el apretón de manos matemático

Curvas elípticas: la geometría que protege al mundo

Para entender cómo Groth16 logra su magia, necesitamos hablar de curvas elípticas. No te asustes por el nombre: una curva elíptica es simplemente una curva suave y continua definida por una ecuación del tipo y² = x³ + ax + b. Si la dibujas en un papel, parece un lazo simétrico respecto al eje horizontal, como una oreja o la forma de un sombrero de tres picos visto de perfil.

Lo fascinante de estas curvas no es su forma, sino una operación que puede definirse sobre sus puntos: la suma de puntos. Si tomas dos puntos cualesquiera sobre la curva, puedes «sumarlos» para obtener un tercer punto que también está sobre la curva. La receta geométrica es: traza una línea recta entre los dos puntos, encuentra dónde esa recta corta la curva en un tercer lugar, y refleja ese tercer punto respecto al eje horizontal. El resultado es el «punto suma».

Ahora, imagina que tomas un punto —llamémoslo G, el punto generador— y lo sumas consigo mismo: G + G = 2G. Luego sumas G de nuevo: 2G + G = 3G. Y así sucesivamente: 4G, 5G, 100G, un millón de veces G. Calcular nG cuando conoces n y G es rápido: hay atajos matemáticos (llamados «multiplicación escalar rápida») que lo hacen en milisegundos incluso para valores enormes de n. Pero el problema inverso —dado G y el punto resultante nG, encontrar el número n— es extraordinariamente difícil. Se llama el problema del logaritmo discreto en curvas elípticas, y es la base de seguridad de la mayor parte de la criptografía moderna, desde las firmas digitales de tu navegador web hasta las transacciones de Bitcoin.

Es como una caja de seguridad con un candado de combinación: si conoces la combinación (el número n), abrirla es trivial. Pero si solo ves el candado cerrado (el punto nG), descubrir la combinación probando al azar te llevaría más tiempo del que existe en el universo, incluso con todos los ordenadores del planeta trabajando en paralelo.

Pairings bilineales: el apretón de manos entre dos mundos

Las curvas elípticas, por sí solas, ya son extraordinariamente útiles. Pero Groth16 necesita algo más: necesita una operación especial llamada pairing bilineal (emparejamiento bilineal). Esta operación es, quizá, el ingrediente más sutil y poderoso de toda la criptografía de conocimiento cero basada en curvas elípticas, y merece una explicación cuidadosa.

Imagina dos clubes exclusivos: el Club Rojo y el Club Azul. Cada club tiene sus propios miembros (puntos de una curva elíptica), sus propias reglas internas (la operación de suma de puntos) y su propia identidad. Los miembros del Club Rojo no pueden mezclarse directamente con los del Club Azul; son mundos separados. Pero existe una sala de reuniones especial —llamémosla la Sala Dorada— donde un miembro del Club Rojo y uno del Club Azul pueden encontrarse y producir un resultado en un tercer espacio, el Espacio Dorado. Esta operación de encuentro es el pairing.

Lo crucial del pairing es su propiedad de bilinealidad. Significa que el orden en el que se realizan las operaciones no importa de una manera muy específica. Si tomas un miembro del Club Rojo, lo «multiplicas» por 3 dentro de su club (obteniendo 3 veces ese miembro), y luego lo llevas a la Sala Dorada con un miembro del Club Azul, el resultado en el Espacio Dorado es exactamente el mismo que si hubieras llevado al miembro original del Club Rojo a la Sala Dorada con 3 veces el miembro del Club Azul. En notación matemática simplificada: pairing(3A, B) = pairing(A, 3B) = pairing(A, B)³.

¿Por qué importa esto? Porque permite verificar relaciones multiplicativas entre números secretos sin conocer esos números. Imagina que alguien te dice «tengo un número secreto s, y aquí tienes el punto sG del Club Rojo y el punto sH del Club Azul» (donde G y H son los generadores de cada club). Tú no conoces s, pero puedes verificar que ambos puntos codifican el mismo número secreto usando el pairing: calculas pairing(sG, H) y pairing(G, sH), y si los resultados coinciden, estás seguro de que el número s es el mismo en ambos casos. Has verificado una igualdad sobre valores secretos sin conocerlos. Esa es la magia que hace posible Groth16.

La curva elíptica más utilizada para pairings en criptografía moderna se llama BLS12-381, diseñada específicamente para este propósito por Sean Bowe en 2017. El número 381 se refiere al tamaño en bits del campo base, y el 12 al grado de embedding, un parámetro técnico que determina la eficiencia del pairing. Esta curva proporciona aproximadamente 128 bits de seguridad —lo que significa que romperla requeriría del orden de 2 elevado a 128 operaciones, un número con 39 dígitos— y está optimizada para que los cálculos de pairing sean lo más rápidos posible. Es la curva que utilizan Ethereum, Zcash y la inmensa mayoría de los sistemas de pruebas basados en Groth16.

Groth16: la prueba más compacta del mundo

El origen: un artículo de 2016 que cambió todo

En 2016, el criptógrafo danés Jens Groth, entonces profesor en el University College London, publicó un artículo titulado On the Size of Pairing-Based Non-interactive Arguments. El resultado principal era asombroso por su concisión: una prueba de conocimiento cero que consta de exactamente tres elementos de curva elíptica. Tres puntos. 192 bytes en total cuando se usa la curva BLS12-381. Para ponerlo en perspectiva, un tweet ocupa más espacio que una prueba Groth16. Y sin embargo, esos 192 bytes pueden demostrar la validez de cálculos que involucran millones de operaciones.

Groth16 pertenece a la familia de los zkSNARKs, un acrónimo que merece desmenuzarse: Zero-Knowledge Succinct Non-interactive ARguments of Knowledge. Cada palabra cuenta. «Zero-Knowledge»: no se filtra información. «Succinct»: la prueba es extremadamente pequeña y rápida de verificar, independientemente de la complejidad del cálculo original. «Non-interactive»: no requiere diálogo entre demostrador y verificador. «Arguments of Knowledge»: demuestra que el demostrador realmente conoce la información, no solo que existe.

La «succión» es lo que distingue a los zkSNARKs de otras pruebas de conocimiento cero. Verificar una prueba Groth16 requiere un número fijo de operaciones de pairing —típicamente tres— sin importar si el circuito original tiene cien puertas o cien millones. Es como tener un sello de garantía que verifica la calidad de un producto: el sello ocupa el mismo espacio y se comprueba con el mismo esfuerzo, tanto si el producto es un tornillo como si es un avión completo.

La configuración de confianza: la ceremonia que nadie debe recordar

Groth16 tiene un requisito que lo distingue de otros sistemas de pruebas y que es, a la vez, su mayor fortaleza práctica y su mayor debilidad teórica: necesita una configuración de confianza (trusted setup). Para entender qué es y por qué importa, necesitamos una analogía extendida.

Imagina que un grupo de químicos necesita crear un reactivo especial para un laboratorio. Cada químico añade un ingrediente secreto a la mezcla, revuelve, y destruye su ingrediente. Al final, el reactivo resultante tiene propiedades útiles que cualquiera puede aprovechar, pero nadie puede deducir qué ingredientes se usaron ni en qué proporciones. El reactivo es útil incluso sin conocer la receta. Pero —y aquí está el matiz crítico— si todos los químicos se confabularan y compartieran sus ingredientes, podrían reconstruir la receta y, con ella, fabricar reactivos adulterados que pasarían todas las pruebas de calidad. Por eso, el requisito fundamental es que al menos uno de los químicos sea honesto y destruya genuinamente su ingrediente.

En Groth16, la configuración de confianza genera lo que se conoce como parámetros públicos o cadena de referencia común (Common Reference String, CRS). Estos parámetros son puntos de curva elíptica calculados a partir de números secretos aleatorios —los «ingredientes» de nuestra analogía— que deben destruirse después de la ceremonia. Si alguien conservara esos números secretos (llamados coloquialmente toxic waste, «residuos tóxicos»), podría fabricar pruebas falsas que parecerían válidas. Podría, por ejemplo, demostrar que posee un millón de monedas que nunca tuvo, o que una transacción inválida es legítima.

Para mitigar este riesgo, las configuraciones de confianza se realizan como ceremonias multipartitas (llamadas a veces Powers of Tau). En la ceremonia de Zcash de 2016, seis participantes —cada uno en una ubicación geográfica diferente, usando hardware diferente— contribuyeron secuencialmente su «ingrediente» a los parámetros. La seguridad del sistema requiere únicamente que al menos uno de los seis haya destruido genuinamente su ingrediente. En ceremonias más recientes, como la de Zcash Sapling en 2018, participaron más de ochenta contribuyentes. La ceremonia Perpetual Powers of Tau, iniciada por Wei Jie Koh, permite añadir contribuyentes indefinidamente, de modo que la seguridad se fortalece con cada nuevo participante.

La configuración de confianza es específica para cada circuito. Si cambias el circuito —aunque sea añadiendo una sola puerta—, necesitas repetir la ceremonia completa. Esta rigidez es una de las razones por las que sistemas posteriores como PLONK, que veremos más adelante, introdujeron configuraciones de confianza «universales» que sirven para cualquier circuito hasta un tamaño máximo.

Generación de la prueba: el demostrador trabaja en la sombra

Una vez que los parámetros públicos están generados, cualquier persona puede usarlos para crear pruebas. El proceso de generación es computacionalmente intensivo —puede tardar desde milisegundos para circuitos pequeños hasta minutos para circuitos con millones de puertas—, pero el resultado siempre es el mismo: tres puntos de curva elíptica. Solo tres.

Para entender intuitivamente qué hace el demostrador, imagina a un escultor al que le encargan una figura. El escultor (el demostrador) tiene un bloque de mármol (el testigo, con todos los valores secretos), unas instrucciones detalladas de cómo debe ser la figura (el circuito R1CS) y un conjunto de herramientas calibradas (los parámetros públicos de la configuración de confianza). Con todo esto, talla tres pequeñas gemas —los tres elementos de la prueba— que capturan la esencia de la figura sin revelar el bloque de mármol original. Cualquiera que examine las gemas con las herramientas adecuadas puede confirmar que fueron talladas a partir de un bloque de mármol legítimo, pero nadie puede reconstruir el bloque original a partir de las gemas.

Técnicamente, el demostrador realiza operaciones de «multiplicación escalar» sobre los puntos de curva elíptica que forman los parámetros públicos, usando como escalares los valores de su testigo y algunos números aleatorios que añade para garantizar la propiedad de conocimiento cero. Los números aleatorios actúan como un velo que oculta los valores reales: dos ejecuciones del demostrador con el mismo testigo producen pruebas diferentes (porque los números aleatorios cambian), pero ambas son igualmente válidas. Es como si el escultor tallara gemas ligeramente diferentes cada vez, pero todas demostraran la misma afirmación.

Verificación: tres pairings y un veredicto

La verificación de una prueba Groth16 es fulminantemente rápida. El verificador toma los tres puntos de la prueba, los combina con las entradas públicas y los parámetros públicos, y realiza un pequeño número de operaciones de pairing. Si las ecuaciones de pairing se satisfacen, la prueba es válida. Si no, es rechazada. El proceso tarda típicamente entre 3 y 10 milisegundos, independientemente de la complejidad del circuito.

Volviendo a nuestra analogía: el verificador es como un tasador de gemas que tiene un dispositivo especial (los parámetros públicos de verificación). Coloca las tres gemas en el dispositivo, presiona un botón, y obtiene un veredicto: auténtico o falso. No necesita ver el bloque de mármol, no necesita saber cómo se tallaron las gemas, no necesita ser un experto escultor. Solo necesita el dispositivo y las gemas. Y el veredicto es determinista: no hay ambigüedad, no hay «probablemente válido». Es válido o no lo es.

La ecuación de verificación de Groth16 tiene una estructura elegante que se puede describir sin fórmulas. El verificador comprueba que el «apretón de manos» (pairing) entre el primer elemento de la prueba y el segundo produce el mismo resultado en el Espacio Dorado que la combinación de otros pairings que involucran los parámetros públicos, las entradas públicas y el tercer elemento de la prueba. Es, en esencia, verificar que una ecuación se cumple en un espacio matemático donde nadie puede hacer trampas, porque la estructura del pairing bilineal lo impide.

Funciones hash dentro de circuitos ZK: el cuello de botella invisible

Por qué las funciones hash importan aquí

En la sección anterior hemos visto que para generar una prueba de conocimiento cero, primero necesitamos expresar nuestro cálculo como un circuito aritmético de sumas y multiplicaciones. Ahora bien, muchas aplicaciones prácticas necesitan calcular funciones hash dentro de la prueba. Por ejemplo, para demostrar que conoces la preimagen de un hash (la contraseña cuyo hash está almacenado), o para verificar la pertenencia a un árbol de Merkle (necesitas calcular hashes en cada nivel del árbol).

Aquí surge un problema que no es obvio: las funciones hash tradicionales como SHA-256 fueron diseñadas para ser eficientes en procesadores normales, no dentro de circuitos aritméticos. SHA-256 utiliza internamente operaciones sobre bits individuales: rotaciones, desplazamientos, operaciones lógicas XOR. Cada una de estas operaciones, trivial para un procesador, se convierte en decenas o cientos de puertas de multiplicación cuando se traduce a un circuito aritmético. El resultado es que un solo cálculo de SHA-256 dentro de un circuito requiere del orden de 25.000 restricciones R1CS. Si tu aplicación necesita verificar una ruta en un árbol de Merkle con 30 niveles de profundidad, eso son 30 hashes, que se convierten en 750.000 restricciones solo para la parte del hash. El circuito se vuelve enorme, la generación de la prueba se ralentiza, y los costes computacionales se disparan.

Es como tener una fábrica (nuestro circuito aritmético) cuyos tornillos están en sistema métrico, y necesitar instalar una pieza diseñada para tornillos imperiales. La pieza funciona perfectamente en su entorno original, pero adaptarla a tu fábrica requiere cientos de conversores y adaptadores que hacen la instalación lenta y costosa.

Poseidon: una función hash nacida para los circuitos

La solución es diseñar funciones hash específicamente para el entorno de los circuitos aritméticos. En lugar de operar sobre bits individuales, estas funciones operan directamente sobre los elementos del campo finito que el circuito ya utiliza. La más conocida y ampliamente adoptada se llama Poseidon, desarrollada por Lorenzo Grassi, Dmitry Khovratovich, Christian Rechberger, Arnab Roy y Markus Schofnegger.

Poseidon utiliza internamente una operación llamada «elevación al cubo» (o a la quinta potencia, dependiendo de la variante) aplicada a elementos del campo finito, seguida de una mezcla lineal de los resultados. Estas operaciones se traducen a muy pocas puertas de multiplicación en un circuito aritmético: un cálculo completo de Poseidon requiere típicamente entre 200 y 400 restricciones R1CS, frente a las 25.000 de SHA-256. La reducción es de casi dos órdenes de magnitud.

Volviendo a nuestra analogía de la fábrica: Poseidon es la pieza diseñada desde el principio con tornillos métricos. No necesita adaptadores. Se instala directamente y funciona con la eficiencia nativa de la fábrica.

El compromiso es que Poseidon es más lenta que SHA-256 cuando se ejecuta en un procesador normal (fuera de un circuito). Pero como la mayor parte del trabajo en un sistema de pruebas de conocimiento cero ocurre dentro del circuito, la ganancia neta es enorme. Es un diseño optimizado para su caso de uso principal, aunque no sea el más rápido en todos los contextos.

Otras funciones hash diseñadas para circuitos incluyen MiMC y Rescue, cada una con sus propias ventajas. MiMC es especialmente simple (usa una sola operación de elevación al cubo por ronda) pero requiere más rondas. Rescue fue diseñada para ser eficiente tanto en circuitos aritméticos como en implementaciones nativas. Poseidon, sin embargo, se ha convertido en el estándar de facto, adoptada por la mayoría de los protocolos basados en ZKP.

Aplicaciones: cuando demostrar sin revelar transforma el mundo real

María demuestra su edad sin enseñar su documento

María tiene veintitrés años y quiere comprar una entrada para un festival de música que requiere ser mayor de dieciocho. En el mundo actual, María muestra su DNI al portero, quien ve no solo su edad, sino su nombre completo, su dirección, su número de documento, su foto y su fecha exacta de nacimiento. El portero solo necesitaba saber una cosa —¿tiene más de dieciocho años?—, pero María le ha revelado toda su identidad.

Con una prueba de conocimiento cero, María podría demostrar que su fecha de nacimiento (almacenada de forma cifrada en un documento digital emitido por el gobierno) corresponde a una persona con más de dieciocho años, sin revelar la fecha exacta, ni su nombre, ni ningún otro dato. El circuito aritmético codificaría la lógica: «dado un certificado digital firmado por la autoridad emisora, la fecha de nacimiento contenida en ese certificado es anterior al 18 de marzo de 2008». La prueba Groth16 resultante —192 bytes— convence al verificador de que la afirmación es verdadera sin filtrar nada más.

Esto no es ciencia ficción. Proyectos como Polygon ID y Worldcoin ya implementan variantes de este concepto. La Unión Europea, a través de su marco de identidad digital (eIDAS 2.0), está explorando activamente la integración de pruebas de conocimiento cero en los monederos de identidad digital europeos.

La empresa de Ricardo demuestra solvencia sin abrir sus libros

Ricardo dirige una empresa que quiere participar en una licitación pública. El pliego de condiciones exige demostrar que la empresa tiene un capital social superior a dos millones de euros, pero Ricardo no quiere revelar sus balances detallados a la entidad licitadora ni a sus competidores, que podrían acceder al expediente.

Con un sistema ZKP, el auditor externo de la empresa podría certificar digitalmente los estados financieros, y Ricardo podría generar una prueba de conocimiento cero que demuestra que los estados certificados cumplen la condición de solvencia, sin revelar cifras específicas. El circuito verificaría: «dado un certificado del auditor autorizado, la suma de las partidas de capital de la empresa es superior a 2.000.000 euros». La entidad licitadora verifica la prueba en milisegundos y tiene garantía criptográfica de que la condición se cumple.

Este tipo de verificación privada de solvencia ya está siendo explorado en el sector financiero. JPMorgan, a través de su división Onyx, ha experimentado con pruebas de conocimiento cero para verificar el cumplimiento normativo en transacciones interbancarias sin compartir datos sensibles de los clientes.

Elena vota de forma anónima pero verificable

Elena participa en una votación de accionistas de una gran corporación. Quiere que su voto cuente, quiere poder verificar que fue contabilizado correctamente, pero no quiere que nadie —ni la junta directiva, ni otros accionistas, ni los administradores del sistema de votación— pueda saber cómo votó.

Un sistema de votación basado en ZKP funcionaría así: cada accionista registrado recibe una credencial criptográfica que demuestra su derecho a voto (ligado a su número de acciones). Al votar, el accionista genera una prueba de conocimiento cero que demuestra tres cosas simultáneamente: que posee una credencial válida emitida por la entidad registradora, que no ha votado previamente (utilizando un «anulador» criptográfico único que impide el doble voto sin revelar la identidad), y que su voto está correctamente formado (es «sí», «no» o «abstención», no un valor inválido). Todo esto sin revelar quién es el votante ni cuál es su voto.

El resultado: un sistema donde el recuento es públicamente verificable (cualquiera puede comprobar que los votos se contaron correctamente), pero la privacidad individual está garantizada criptográficamente. Proyectos como MACI (Minimal Anti-Collusion Infrastructure), desarrollado en el ecosistema Ethereum, ya implementan este tipo de votación.

Pablo envía dinero entre países sin que nadie vea los detalles

Pablo trabaja en España y envía mensualmente dinero a su familia en Colombia. En el sistema financiero actual, cada transferencia internacional pasa por múltiples intermediarios —bancos corresponsales, cámaras de compensación, organismos de control—, cada uno de los cuales tiene acceso a los detalles completos de la transacción: quién envía, quién recibe, cuánto, desde dónde, a dónde.

Con una blockchain que utilice pruebas de conocimiento cero —como Zcash o como los rollups ZK de Ethereum—, Pablo podría enviar dinero demostrando que la transacción es válida (tiene fondos suficientes, la dirección de destino es legítima, los importes cuadran) sin revelar las cantidades, las direcciones ni los participantes. Los reguladores podrían tener «claves de visión» (viewing keys) que les permitan auditar transacciones específicas bajo orden judicial, pero el público general no vería nada.

Las transacciones blindadas (shielded transactions) de Zcash utilizan exactamente Groth16 para este propósito. Cada transacción blindada incluye una prueba de 192 bytes que garantiza: que las monedas gastadas existen y no se han gastado antes, que la suma de las entradas es igual a la suma de las salidas (no se crea ni se destruye dinero), y que el remitente tiene la autoridad para gastar esas monedas. El verificador confirma todo esto sin saber qué monedas se gastaron, cuánto se transfirió ni a quién.

Carmen demuestra su identidad cruzando fronteras

Carmen es investigadora y viaja frecuentemente entre países de la Unión Europea y Latinoamérica. En cada frontera, su pasaporte es escaneado y sus datos quedan registrados en bases de datos de múltiples jurisdicciones. Con el tiempo, se acumula un perfil detallado de sus movimientos que podría ser explotado en caso de una brecha de seguridad.

Un sistema de identidad transfronteriza basado en ZKP permitiría a Carmen demostrar: que posee un pasaporte válido emitido por un país reconocido, que no aparece en listas de personas con restricciones de viaje, y que su visado (si es necesario) está vigente. Todo esto sin que el control fronterizo necesite almacenar sus datos personales ni siquiera leerlos. La prueba de conocimiento cero sustituye a la lectura completa del pasaporte: el sistema fronterizo verifica la prueba y obtiene un «pase» o «no pase», sin acumular datos personales.

Más allá de Groth16: el ecosistema de sistemas de pruebas

PLONK: la configuración universal

En 2019, Ariel Gabizon, Zachary Williamson y Oana Ciobotaru publicaron PLONK (Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge —un acrónimo deliberadamente forzado para que suene como «plonk», la onomatopeya inglesa de algo cayendo al agua—). PLONK aborda la principal debilidad de Groth16: la configuración de confianza específica por circuito.

En Groth16, cambiar una sola puerta del circuito invalida toda la configuración de confianza y obliga a repetir la ceremonia desde cero. En PLONK, la configuración de confianza es universal y actualizable: se realiza una sola vez para un tamaño máximo de circuito, y sirve para cualquier circuito que no supere ese tamaño. Es como la diferencia entre un traje a medida (Groth16: perfecto para una persona, inútil para otra) y una talla única ajustable (PLONK: funciona para cualquiera dentro de un rango).

El precio de esta universalidad es un ligero aumento en el tamaño de la prueba y en el tiempo de verificación. PLONK utiliza un esquema de compromiso polinomial (típicamente KZG, basado en los mismos pairings que Groth16) para codificar la satisfacción de las restricciones.

STARKs: sin confianza, con transparencia

Los STARKs (Scalable Transparent ARguments of Knowledge), propuestos por Eli Ben-Sasson, Iddo Bentov, Yinon Horesh y Michael Riabzev en 2018, representan una filosofía radicalmente distinta. La palabra clave es «transparent»: los STARKs no requieren ninguna configuración de confianza. Toda la aleatoriedad necesaria se genera públicamente, sin «residuos tóxicos» ni ceremonias secretas.

Los STARKs logran esto reemplazando las curvas elípticas y los pairings por funciones hash. En lugar de «esconder» información en la dificultad del logaritmo discreto en curvas elípticas, la esconden en la dificultad de invertir funciones hash. Las pruebas se construyen usando una técnica llamada FRI (Fast Reed-Solomon Interactive Oracle Proofs), que verifica que ciertos polinomios tienen grado bajo mediante un protocolo interactivo que luego se hace no interactivo con la transformación de Fiat-Shamir.

La analogía: Groth16 es como un cerrajero que te da una llave maestra fabricada en una ceremonia secreta. Si la ceremonia fue honesta, la llave es perfectamente segura, pero tienes que confiar en que lo fue. Un STARK es como un cerrajero que trabaja en una cabina de cristal a la vista de todos: no hay secretos en la fabricación, todo es verificable públicamente.

El precio de la transparencia es el tamaño: las pruebas STARK ocupan típicamente entre 40 y 200 kilobytes, frente a los 192 bytes de Groth16. Es la diferencia entre un sello de lacre (compacto, elegante, pero requiere confianza en el fabricante del sello) y un acta notarial completa (voluminosa, pero autocontenida y verificable por cualquiera).

Bulletproofs: ni configuración ni pairings

Los Bulletproofs, publicados por Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille y Greg Maxwell en 2018, ofrecen otro punto en el espectro de compromisos. No requieren configuración de confianza (como los STARKs) y no utilizan pairings (a diferencia de Groth16 y PLONK). Sus pruebas son razonablemente compactas —del orden de 700 bytes para pruebas de rango— pero la verificación es más lenta, con tiempo proporcional al tamaño del circuito.

Bulletproofs se utilizan principalmente en Monero, la criptomoneda centrada en la privacidad, para las llamadas range proofs: pruebas de que un valor está dentro de un rango válido (por ejemplo, que el monto de una transacción es positivo y no excede cierto límite) sin revelar el valor específico.

Comparativa de sistemas de pruebas

Característica	Groth16	PLONK	STARKs	Bulletproofs
Tamaño de la prueba	192 bytes (constante)	~400-600 bytes	40-200 KB	~700 bytes (para range proofs)
Tiempo de verificación	~3-10 ms (constante)	~10-20 ms	~50-100 ms	Proporcional al circuito
Configuración de confianza	Sí (específica por circuito)	Sí (universal y actualizable)	No (transparente)	No
Base criptográfica	Pairings (curvas elípticas)	Pairings (curvas elípticas)	Funciones hash	Logaritmo discreto
Resistencia poscuántica	No	No	Sí (conjetural)	No
Tiempo de generación	Rápido	Moderado	Moderado-lento	Lento
Uso principal	Zcash, rollups ZK	zkSync, Aztec, Scroll	StarkNet, zkEVM	Monero

Ningún sistema de pruebas es universalmente superior. La elección depende de las prioridades: si necesitas pruebas mínimas y verificación ultrarrápida (por ejemplo, en una blockchain donde el espacio de bloque es caro), Groth16 es imbatible. Si necesitas flexibilidad para actualizar circuitos sin repetir ceremonias, PLONK es preferible. Si la transparencia y la resistencia poscuántica son prioritarias, los STARKs son la elección natural. Y si necesitas pruebas compactas sin configuración de confianza ni pairings, Bulletproofs ocupa un nicho específico.

Seguridad y amenazas: lo que puede salir mal

La amenaza cuántica

Los ordenadores cuánticos representan la amenaza existencial más seria para Groth16, PLONK y cualquier sistema basado en curvas elípticas. El algoritmo de Shor, propuesto por Peter Shor en 1994, permite a un ordenador cuántico suficientemente potente resolver el problema del logaritmo discreto en tiempo polinomial. En términos prácticos: un ordenador cuántico con suficientes qubits estables podría romper la seguridad de las curvas elípticas, lo que permitiría falsificar pruebas Groth16.

¿Cuándo será esto una amenaza real? Las estimaciones varían enormemente, pero el consenso científico actual sitúa la disponibilidad de un ordenador cuántico capaz de romper criptografía de curvas elípticas de 256 bits en un horizonte de diez a treinta años. Puede parecer lejano, pero en criptografía, donde los sistemas se diseñan para proteger datos durante décadas, es una amenaza inminente.

Los STARKs son resistentes a esta amenaza porque su seguridad no depende de curvas elípticas ni del problema del logaritmo discreto, sino de la dificultad de invertir funciones hash, que los ordenadores cuánticos no pueden resolver eficientemente (el algoritmo de Grover proporciona solo una aceleración cuadrática, que se compensa duplicando el tamaño del hash). Esta es una de las razones por las que muchos investigadores consideran que el futuro a largo plazo de las pruebas de conocimiento cero pasa por los STARKs o por sistemas híbridos que combinen la eficiencia de los SNARKs con la resistencia poscuántica de los STARKs.

Errores en circuitos: el peligro silencioso

Una amenaza más inmediata y cotidiana que los ordenadores cuánticos son los errores en la construcción de los circuitos. Un circuito aritmético mal diseñado puede aceptar pruebas de afirmaciones falsas. No porque la criptografía falle, sino porque las restricciones R1CS no capturan correctamente la lógica que se pretendía codificar. Es como un contrato legal con una cláusula ambigua: el sello notarial es perfecto, el papel es oficial, las firmas son auténticas, pero el texto dice algo diferente de lo que las partes creían.

En 2018, se descubrió internamente una vulnerabilidad en el circuito de las transacciones blindadas de Zcash que habría permitido crear monedas de la nada; el hallazgo se hizo público en febrero de 2019. El error no estaba en Groth16 ni en la criptografía subyacente, sino en cómo se había construido el circuito específico. La vulnerabilidad fue corregida antes de ser explotada, pero ilustra un punto crucial: la seguridad de un sistema ZKP depende tanto de la corrección matemática del esquema de pruebas como de la corrección del circuito específico que lo utiliza.

La configuración de confianza comprometida

Si todos los participantes de una ceremonia de configuración de confianza se confabulan —o si un solo participante retiene los «residuos tóxicos» en un sistema donde solo hubo un participante—, la seguridad del sistema se desmorona. Las pruebas falsas se vuelven posibles. Este escenario es extremadamente improbable en ceremonias con decenas o cientos de participantes independientes, pero no es imposible.

La mitigación principal es la diversidad: ceremonias con muchos participantes, geográficamente distribuidos, usando diferentes sistemas operativos y hardware, con diferentes motivaciones y lealtades. Cuantos más participantes, más improbable es que todos sean deshonestos. Pero para quienes prefieren eliminar este riesgo por completo, los STARKs ofrecen la única solución definitiva: sin configuración de confianza, no hay «residuos tóxicos» que puedan comprometerse.

El horizonte: hacia dónde se dirige la investigación

El campo de las pruebas de conocimiento cero está avanzando a una velocidad sin precedentes en la historia de la criptografía. Tres direcciones de investigación merecen especial atención.

La primera es la recursividad: pruebas de conocimiento cero que verifican otras pruebas de conocimiento cero. Imagina una cadena donde cada eslabón es una prueba que demuestra «el eslabón anterior era válido, y además este lote de transacciones es correcto». El resultado es que, para verificar toda la historia de una blockchain, solo necesitas verificar la última prueba. Es como una cadena de custodios donde cada uno certifica que recibió el paquete intacto del anterior: verificar al último equivale a verificar toda la cadena. Proyectos como Mina Protocol utilizan pruebas recursivas para mantener una blockchain cuyo estado completo puede verificarse con una prueba de solo 22 kilobytes, independientemente de cuántas transacciones haya procesado.

La segunda dirección es la aceleración por hardware. La generación de pruebas es el cuello de botella computacional de todos los sistemas ZKP, y hay un esfuerzo creciente por diseñar procesadores especializados (ASICs y FPGAs) optimizados para las operaciones matemáticas específicas que dominan la generación de pruebas: la aritmética de campos finitos y la multiplicación escalar en curvas elípticas. Empresas como Cysic, Ingonyama y Ulvetanna están desarrollando hardware dedicado que promete acelerar la generación de pruebas en órdenes de magnitud.

La tercera dirección es la convergencia entre SNARKs y STARKs. Sistemas híbridos como los que utiliza Polygon zkEVM emplean STARKs internamente (para la generación eficiente) y luego «envuelven» la prueba STARK en una prueba SNARK más compacta para la verificación on-chain. Es lo mejor de ambos mundos: la transparencia y eficiencia de generación de los STARKs combinada con la succión de los SNARKs para la verificación final.

Para saber más: referencias y lecturas recomendadas

Si este artículo ha despertado tu curiosidad y quieres profundizar en los fundamentos teóricos y las aplicaciones prácticas de las pruebas de conocimiento cero, las siguientes referencias son un buen punto de partida, ordenadas aproximadamente de menor a mayor complejidad técnica.

• Goldwasser, S., Micali, S. y Rackoff, C. (1989). «The Knowledge Complexity of Interactive Proof Systems». SIAM Journal on Computing, 18(1), 186-208. El artículo fundacional que introdujo las pruebas de conocimiento cero. La versión original de conferencia data de 1985 (STOC), pero la versión de revista es la referencia canónica. Formalmente denso, pero históricamente imprescindible.
• Fiat, A. y Shamir, A. (1986). «How to Prove Yourself: Practical Solutions to Identification and Signature Problems». CRYPTO '86. Introduce la transformación que convierte pruebas interactivas en no interactivas reemplazando al verificador por una función hash. Es el puente que hizo posible los zkSNARKs modernos.
• Groth, J. (2016). «On the Size of Pairing-Based Non-interactive Arguments». EUROCRYPT 2016. El artículo que presenta Groth16, demostrando que es posible construir pruebas de conocimiento cero de solo tres elementos de grupo. Requiere familiaridad con álgebra abstracta y pairings bilineales.
• Ben-Sasson, E., Bentov, I., Horesh, Y. y Riabzev, M. (2018). «Scalable, Transparent, and Post-Quantum Secure Computational Integrity». IACR ePrint. La propuesta original de STARKs, que elimina la necesidad de configuración de confianza y ofrece resistencia poscuántica conjetural. Técnicamente exigente, pero con una exposición clara de las motivaciones.
• Gabizon, A., Williamson, Z. y Ciobotaru, O. (2019). «PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge». IACR ePrint 2019/953. Introduce el concepto de configuración de confianza universal para zkSNARKs. El artículo combina aritmetización polinomial con compromisos KZG de forma innovadora.
• Buterin, V. (2021). «An approximate introduction to how zk-SNARKs are possible». Publicado en el blog personal de Vitalik Buterin. Probablemente la mejor introducción accesible a los zkSNARKs escrita para un público técnico pero no necesariamente experto en criptografía. Excelente como primera lectura técnica después de este artículo.
• Grassi, L., Khovratovich, D., Rechberger, C., Roy, A. y Schofnegger, M. (2021). «Poseidon: A New Hash Function for Zero-Knowledge Proof Systems». USENIX Security 2021. Presenta la función hash Poseidon, diseñada específicamente para ser eficiente dentro de circuitos aritméticos. Incluye análisis de seguridad y comparativas de rendimiento con SHA-256 y otras alternativas.
• Documentación de Zcash sobre zk-SNARKs. z.cash/learn. La mejor referencia práctica sobre cómo se aplican los zkSNARKs (específicamente Groth16) en un sistema de pagos real. Combina explicaciones conceptuales con detalles de implementación sin ser excesivamente académica.
• Quisquater, J.-J., Guillou, L. et al. (1990). «How to Explain Zero-Knowledge Protocols to Your Children». CRYPTO '89. El artículo que introdujo la analogía de la cueva de Alí Babá. Breve, divertido y pedagógicamente brillante. Ideal para compartir con cualquier persona curiosa, independientemente de su formación técnica.
• Bowe, S. (2017). «BLS12-381: New zk-SNARK Elliptic Curve Construction». Especificación técnica de la curva elíptica estándar para pairings en sistemas ZKP modernos. Detalla los parámetros, las propiedades de seguridad y las optimizaciones. Referencia esencial para quien quiera entender la infraestructura criptográfica subyacente.

En 1982, tres investigadores propusieron que era posible demostrar la verdad sin revelar nada. Cuarenta años después, esa idea «imposible» sustenta sistemas que procesan miles de millones de euros en transacciones, protegen la identidad de millones de personas y están redefiniendo lo que significa la privacidad en la era digital. La prueba de conocimiento cero no es solo un logro matemático: es una declaración de principios. La declaración de que demostrar quien eres o lo que sabes no debería obligarte a desnudarte ante quien pregunta. Que la verificación no requiere la exposición. Que la confianza puede construirse sobre pruebas, no sobre confesiones. En un mundo donde cada clic genera datos, donde cada transacción deja un rastro y donde la privacidad se erosiona un poco más con cada servicio que aceptamos, las pruebas de conocimiento cero nos recuerdan algo fundamental: que es posible vivir en una sociedad transparente sin que esa transparencia signifique la aniquilación de lo íntimo.