Solo con fines educativos; no constituye asesoramiento de inversión ni de seguridad. Una prueba válida solo garantiza el enunciado codificado bajo los supuestos del sistema de prueba.
Respuesta directa
Una prueba de conocimiento cero (ZKP) permite que un probador convenza a un verificador de que un enunciado es verdadero sin revelar el testigo secreto que lo demuestra. La garantía formal no dice que la transcripción carezca literalmente de información. Dice que todo lo que aprende un verificador permitido puede simularse sin el testigo, salvo lo que se deduce del enunciado público.
Un sistema de prueba se evalúa mediante tres propiedades separadas: completitud, por la que se acepta al probador honesto con un testigo válido; solidez, por la que un enunciado falso solo se acepta con probabilidad despreciable; y conocimiento cero, por la que el testigo permanece oculto bajo el modelo de amenazas definido. Muchos sistemas prácticos son argumentos computacionales: su solidez vale frente a adversarios con capacidad de cómputo limitada y depende de supuestos criptográficos declarados.
El conocimiento cero también es distinto de la concisión y la validez. Una prueba puede ser de conocimiento cero pero costosa de verificar, concisa pero mostrar datos públicos, o demostrar una relación correctamente codificada que no coincide con la regla prevista por la aplicación.
El probador ejecuta un lote o cálculo y registra la transición de estado.
Cómo funciona
Se parte de un enunciado público x, un testigo privado w y una relación R definida con precisión. El probador genera una prueba y el verificador la evalúa con parámetros públicos o una clave de verificación. La afirmación de solidez pretendida puede resumirse así:
Verify(vk, x, proof) = 1 => exists w: R(x, w) = 1
La ecuación solo afirma que existe un testigo adecuado para la relación codificada. No lo revela, no autentica entradas offchain ni demuestra que R recoja todas las reglas de negocio que la aplicación quería aplicar.
- Interactiva y no interactiva. Los primeros protocolos ZK intercambian retos y respuestas. Los sistemas no interactivos agrupan la evidencia en una prueba y suelen depender de material de configuración, un modelo de oráculo aleatorio o ambos.
- Modelo de configuración. Groth16 produce pruebas muy pequeñas, pero usa una configuración estructurada específica del circuito. Los sistemas tipo PLONK pueden usar una cadena de referencia estructurada universal y actualizable. STARK evita una configuración estructurada de confianza, aunque normalmente genera pruebas mayores y depende de hashes y pruebas de bajo grado.
- Aritmetización y compromisos. Las implementaciones traducen un programa a restricciones algebraicas, comprometen valores derivados del testigo y usan comprobaciones aleatorias para que el verificador pruebe el cálculo sin repetirlo ni ver el testigo.
- Prueba de conocimiento. Algunos sistemas afirman además que el probador aceptado conoce un testigo, formalizado mediante un extractor. Es una propiedad aparte y no se deduce de la etiqueta “conocimiento cero”.
Ejemplo
Supongamos que x contiene un compromiso y un umbral de 100 units, mientras que w contiene el saldo comprometido y el factor de ocultación. La relación comprueba que el compromiso se abre correctamente y que el saldo es de al menos 100 units. Una ZKP válida demuestra esa relación sin revelar el saldo exacto.
El resultado no prueba por sí solo que el probador sea dueño de la cuenta, que los fondos estén libres de cargas ni que el mismo compromiso no se haya reutilizado. Esas afirmaciones requieren restricciones y entradas públicas adicionales.
En una criptomoneda protegida, un circuito puede imponer autorización, conservación del valor y ausencia de duplicados mientras oculta ciertos datos de la transacción. En un validity rollup, una prueba puede certificar una transición de estado por lotes; aun así pueden publicarse los datos, por lo que “ZK Rollup” no significa automáticamente transacciones privadas.
Riesgos
- Un circuito incompleto o incorrecto puede demostrar perfectamente la regla equivocada.
- La falta de separación de dominios, identificadores de cadena, raíces o compromisos puede vincular una prueba al contexto erróneo.
- Una configuración comprometida o residuos tóxicos conservados pueden romper la solidez de sistemas con configuración de confianza.
- Los errores en probador, verificador, transcripción, curva, hash, compilador o contrato inteligente pueden invalidar la garantía teórica.
- Las entradas públicas, el momento de la prueba, los grafos de transacciones, las comisiones y los metadatos de red pueden filtrar información fuera del enunciado ZK formal.
- Los canales laterales al generar el testigo, en navegadores, hardware o servicios remotos pueden exponer secretos antes de generar la prueba.
- Verificar la prueba no aporta disponibilidad de datos, actividad del secuenciador, finalidad de liquidación, resistencia a la censura ni actualizaciones seguras.
- Los supuestos y márgenes concretos de seguridad varían; el tamaño o la velocidad de verificación no constituyen por sí solos una clasificación de seguridad.
Errores comunes
- “Conocimiento cero significa que no se revela ningún dato.” El enunciado público y las salidas expuestas deliberadamente siguen visibles, y los metadatos pueden filtrarse fuera del modelo.
- “Una prueba válida significa que la aplicación es correcta.” Significa que se aceptó la relación codificada; todavía puede haber errores de circuito, integración o política.
- “Todos los sistemas ZK tienen los mismos supuestos de confianza.” Las ceremonias, curvas, hashes, modelos de transcripción y controles de actualización difieren sustancialmente.
- “ZK es cifrado.” El cifrado oculta datos para que una parte autorizada pueda descifrarlos; una ZKP establece una afirmación sin enviar el testigo para su descifrado.
Temas relacionados
Fuentes
- The Knowledge Complexity of Interactive Proof Systems - SIAM Journal on Computing (consultado: 2026-08-22)
- On the Size of Pairing-based Non-interactive Arguments - IACR Cryptology ePrint Archive (consultado: 2026-08-22)
- Scalable, transparent, and post-quantum secure computational integrity - IACR Cryptology ePrint Archive (consultado: 2026-08-22)
- PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge - IACR Cryptology ePrint Archive (consultado: 2026-08-22)
- Zcash Protocol Specification - Zcash Protocol Specification (consultado: 2026-08-22)