Pruebas de conocimiento cero: una guía práctica para verificar conocimiento sin revelarlo

Qué garantiza realmente una prueba de conocimiento cero

Una prueba de conocimiento cero es un protocolo criptográfico en el que una parte, el probador, convence a otra parte, el verificador, de que una afirmación es verdadera. La restricción definitoria es que el verificador no aprende nada más allá de la veracidad de la afirmación: ni la entrada secreta, ni la computación intermedia, ni ningún dato testigo utilizado para construir la prueba.

Esto es diferente de simplemente ocultar datos detrás de un cifrado. El cifrado protege los datos en tránsito o en reposo, pero el receptor aún descifra y ve el texto plano. Una prueba ZK permite al verificador comprobar una afirmación mientras los datos subyacentes permanecen ocultos para todos, incluido el verificador. Esa distinción importa para los sistemas blockchain, donde cada transacción y transición de estado es pública por defecto.

Tres propiedades definen un protocolo de conocimiento cero válido. La completitud significa que un probador honesto con una afirmación verdadera siempre puede convencer al verificador. La solidez significa que un probador deshonesto no puede convencer al verificador de una afirmación falsa, excepto con una probabilidad insignificante. El conocimiento cero significa que la vista del verificador de la interacción puede simularse sin el testigo, por lo que no se filtra información sobre el secreto.

• Completitud: las afirmaciones verdaderas se aceptan.
• Solidez: las afirmaciones falsas se rechazan con una probabilidad abrumadora.
• Conocimiento cero: la prueba no revela nada más allá de la validez.

El modelo mental probador-verificador y un ejemplo concreto

La intuición clásica es la cueva de Alí Babá: Peggy afirma que conoce la palabra secreta que abre una puerta mágica en una cueva circular con dos entradas. Víctor quiere una prueba pero no debe aprender la palabra. Peggy entra por un túnel al azar, Víctor grita por qué túnel debe salir, y ella sale directamente por ese túnel o usa la palabra secreta para pasar por la puerta. Después de muchas rondas, la probabilidad de que Peggy adivine correctamente cada vez sin conocer la palabra se vuelve insignificante, pero Víctor nunca aprende la palabra en sí.

Un ejemplo más relevante para blockchain es una prueba de rango de saldo. Un usuario quiere demostrar que el saldo de su cuenta está por encima de un umbral sin revelar el saldo exacto. El probador construye una prueba de que el valor comprometido se encuentra en el rango requerido, y el verificador comprueba la prueba contra el compromiso público. El verificador solo aprende que se cumple la condición de rango.

La misma estructura aparece en sistemas de identidad: demostrar que eres mayor de 18 años sin revelar tu fecha de nacimiento, demostrar que posees una credencial válida sin revelar el contenido de la credencial, o demostrar que una transacción es válida sin revelar el emisor, el receptor o el importe. Cada caso tiene una afirmación pública, un testigo privado y una prueba que los vincula.

Pruebas interactivas versus no interactivas

Las pruebas interactivas requieren comunicación de ida y vuelta entre el probador y el verificador, como en el ejemplo de la cueva. Son útiles para la enseñanza y para protocolos en los que ambas partes están en línea, pero son poco prácticas para blockchains porque un contrato inteligente no puede ejecutar una sesión de desafío-respuesta de múltiples rondas con cada usuario.

Las pruebas de conocimiento cero no interactivas (NIZK) colapsan la interacción en un solo mensaje. El probador genera una prueba que cualquiera puede verificar más tarde sin más comunicación. La heurística de Fiat-Shamir es la transformación estándar: el probador deriva el desafío hasheando las entradas públicas y los compromisos, reemplazando el desafío aleatorio del verificador por un valor determinista que el probador no puede predecir antes de comprometerse.

En la práctica, la mayoría de los sistemas ZK de blockchain utilizan pruebas no interactivas. Los zk-SNARK (Argumentos de Conocimiento No Interactivos Sucintos) producen pruebas pequeñas con verificación rápida pero requieren una configuración de confianza en muchas construcciones. Los zk-STARK (Argumentos de Conocimiento Transparentes Escalables) evitan la configuración de confianza y se basan en criptografía basada en hash, normalmente con tamaños de prueba mayores. La elección correcta depende del coste de verificación, el tamaño de la prueba y si una configuración de confianza es aceptable para tu modelo de amenaza.

• Interactivas: múltiples rondas, adecuadas para protocolos directos entre pares.
• No interactivas: un solo mensaje de prueba, adecuadas para verificación en cadena.
• Fiat-Shamir: convierte pruebas interactivas en no interactivas mediante hashing.

Suposiciones y requisitos previos antes de probar un flujo de trabajo ZK

Antes de ejecutar cualquier procedimiento de verificación, confirma qué estás demostrando y quién lo verifica. Escribe la afirmación pública, el testigo privado y la función de verificación. Si la afirmación es ambigua, la prueba puede ser válida pero inútil para tu aplicación.

También necesitas un entorno de verificador. Para la verificación en cadena, eso significa un contrato verificador desplegado y un endpoint RPC que pueda ejecutar llamadas de lectura y enviar transacciones. Para la verificación fuera de cadena, significa una biblioteca o CLI que implemente el mismo algoritmo de verificación que el verificador en cadena. Las versiones desajustadas entre probador y verificador son una causa común de fallos falsos.

Por último, decide cómo medirás el comportamiento. Registra el tiempo de generación de la prueba, el tamaño de la prueba, el tiempo de verificación y el coste de gas si verificas en cadena. No asumas que las cifras de otro proyecto se aplican al tuyo; la complejidad del circuito, el hardware y las condiciones de la red cambian el resultado.

• Afirmación pública y testigo privado definidos.
• Versión del contrato verificador o biblioteca fijada.
• Endpoint RPC disponible para llamadas de lectura y escritura.
• Plan de medición para generación, tamaño, verificación y gas.

Flujo de trabajo de verificación ejecutable con curl y JavaScript

El siguiente procedimiento asume que tienes un contrato verificador desplegado con una función verifyProof y un artefacto de prueba producido por tu cadena de herramientas de circuitos. Reemplaza RPC_URL, VERIFIER_ADDRESS y los campos de prueba con valores de tu propio entorno. El objetivo es confirmar que una prueba válida se acepta y una prueba inválida se rechaza.

Primero, comprueba que el contrato verificador es accesible y que el endpoint RPC responde. Esta es una llamada de solo lectura y no requiere una clave privada.

• Una respuesta exitosa devuelve un booleano codificado en hexadecimal o datos de reversión.
• Una reversión generalmente significa que la prueba o las entradas públicas están mal formadas.
• Utiliza un endpoint dedicado para pruebas repetidas para evitar límites de velocidad.

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_call",
    "params": [{
      "to": "VERIFIER_ADDRESS",
      "data": "0xVERIFY_PROOF_CALLDATA"
    }, "latest"]
  }'

Arnés de pruebas en JavaScript para pruebas válidas e inválidas

El siguiente fragmento utiliza ethers.js para llamar al verificador dos veces: una con la prueba real y otra con una prueba mutada. El resultado esperado es true para la prueba válida y false o una reversión para la prueba mutada. Esta prueba negativa es esencial; un verificador que acepta todo no es sólido.

Mantén las entradas públicas idénticas entre las dos llamadas para que la única diferencia sean los bytes de la prueba. Si ambas llamadas devuelven true, tu verificador o circuito está mal configurado.

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const verifier = new ethers.Contract(
  process.env.VERIFIER_ADDRESS,
  ["function verifyProof(bytes proof, uint256[] inputs) view returns (bool)"],
  provider
);

const validProof = process.env.VALID_PROOF;
const inputs = JSON.parse(process.env.PUBLIC_INPUTS);
const mutatedProof = validProof.slice(0, -2) + "00";

const validResult = await verifier.verifyProof(validProof, inputs);
const invalidResult = await verifier.verifyProof(mutatedProof, inputs);

console.log({ validResult, invalidResult });
if (validResult !== true || invalidResult !== false) {
  throw new Error("Verifier behavior does not match expectations");
}

Registrar resultados en una tabla de verificación

Ejecuta el flujo de trabajo varias veces y registra el resultado en una tabla. La tabla siguiente es una plantilla; completa tus propios valores medidos en lugar de copiar cifras de otro proyecto. Incluye la versión del circuito, el sistema de pruebas y el entorno para que los resultados sean reproducibles.

Si se acepta la prueba inválida, detente y corrige el verificador antes de medir el rendimiento. Si se rechaza la prueba válida, compara las entradas públicas byte por byte entre la salida del probador y la llamada al verificador. Los desajustes de codificación, las diferencias de endianness y el orden de los elementos del campo son causas frecuentes.

Solución de problemas comunes de verificación ZK

La mayoría de los fallos se engloban en unas pocas categorías. Los errores de codificación de la prueba ocurren cuando el probador serializa los elementos del campo de manera diferente a lo que espera el verificador. Los desajustes de entradas públicas ocurren cuando el verificador recibe las entradas en un orden o representación diferente al definido por el circuito. La deriva de versiones ocurre cuando el circuito se recompila pero el contrato verificador no se vuelve a desplegar.

La verificación en cadena también puede fallar debido a límites de gas, precompilados faltantes u opcodes no compatibles en la cadena de destino. Si la verificación funciona en una red pero no en otra, comprueba si el verificador depende de precompilados de curvas elípticas que la cadena de destino no expone. Para pruebas entre cadenas o en múltiples redes, utiliza un endpoint fiable por red y mantén la dirección del verificador y el ID de cadena en tu configuración.

Si estás comparando proveedores RPC para pruebas de verificación repetidas, las guías de endpoints del Asistente RPC cubren la selección concreta de proveedores, mientras que este artículo se centra en la metodología de verificación.

• Vuelve a codificar los bytes de la prueba y compáralos con el ABI del verificador.
• Registra las entradas públicas tanto en el lado del probador como en el del verificador.
• Fija las versiones del circuito, el probador y el verificador juntas.
• Confirma la compatibilidad de precompilados y opcodes en la cadena de destino.

Limitaciones, compensaciones y cuándo no usar pruebas ZK

Las pruebas de conocimiento cero son potentes pero no gratuitas. La generación de pruebas es computacionalmente costosa, especialmente para circuitos grandes, y el probador necesita acceso al testigo. La verificación suele ser barata, por lo que las pruebas ZK encajan en casos de uso en cadena, pero el coste inicial del diseño y la auditoría del circuito es significativo.

Las configuraciones de confianza introducen una dependencia de ceremonia para algunos sistemas de pruebas. Si la configuración se ve comprometida, la solidez puede romperse. Los sistemas de pruebas transparentes evitan esto pero a menudo producen pruebas más grandes y costes de verificación más altos. La compensación no es puramente técnica; también implica riesgo operativo y auditabilidad.

Las pruebas ZK tampoco resuelven la disponibilidad de datos por sí mismas. Una prueba puede demostrar que una computación se realizó correctamente, pero los datos subyacentes aún pueden necesitar estar disponibles en algún lugar para que el sistema funcione. De manera similar, las pruebas ZK no reemplazan el control de acceso ni la gestión de claves; los complementan.

Dónde encajan las pruebas ZK en blockchain y sistemas de identidad

En las redes blockchain, las pruebas ZK permiten transferencias privadas, pruebas de rango para saldos, computación verificable y enfoques de escalado como los rollups ZK. En los sistemas de identidad, permiten la divulgación selectiva: demostrar una propiedad de una credencial sin revelar la credencial en sí. En autenticación, pueden demostrar el conocimiento de un secreto sin transmitirlo.

Si estás desplegando un contrato verificador o ejecutando un servicio de probador, la infraestructura circundante importa tanto como la criptografía. La fiabilidad del nodo, la latencia del endpoint y el estado consistente de la cadena afectan a si tus pruebas de verificación son reproducibles. El directorio de redes de OnFinality enumera las cadenas compatibles, y las opciones de nodo dedicado están disponibles cuando necesitas un rendimiento predecible para la verificación repetida de pruebas.

Para los equipos que construyen aplicaciones habilitadas para ZK, comienza con un circuito pequeño, una afirmación clara y una prueba negativa. Amplía solo después de que el verificador rechace las pruebas inválidas de manera fiable.

• Pagos privados y transferencias confidenciales.
• Pruebas de rango y comprobaciones de solvencia.
• Divulgación selectiva y verificación de credenciales.
• Computación verificable y rollups ZK.

Próximos pasos para construir y probar flujos de trabajo ZK

Pasa del concepto a la implementación definiendo una afirmación, construyendo el circuito más pequeño que la demuestre y escribiendo pruebas de verificación tanto positivas como negativas. Registra tus mediciones en la tabla anterior y mantén el entorno documentado.

Cuando estés listo para probar contra redes en vivo, elige un endpoint RPC que coincida con tu carga de verificación. El Asistente RPC puede ayudarte a elegir un endpoint concreto, mientras que las guías de Learn cubren el alojamiento de nodos y la estrategia de endpoints multicadena. Revisa los precios del acceso RPC si esperas tráfico de verificación sostenido, y considera un nodo dedicado cuando los endpoints compartidos introduzcan variabilidad.

• Define la afirmación y el testigo.
• Construye y audita un circuito mínimo.
• Ejecuta pruebas de verificación positivas y negativas.
• Mide generación, tamaño, verificación y gas.
• Selecciona una estrategia de endpoint que coincida con tu carga.