Pruebas de conocimiento cero en criptografía: una guía técnica práctica

Qué garantiza realmente una prueba de conocimiento cero

En criptografía, una prueba de conocimiento cero es un protocolo entre dos partes: un probador que posee un testigo secreto y un verificador que posee una afirmación pública. El probador quiere convencer al verificador de que la afirmación es verdadera —por ejemplo, "conozco una clave privada correspondiente a esta clave pública" o "esta transacción conserva el valor"— sin entregar el testigo mismo. El verificador solo aprende el único bit de información de que la afirmación es verdadera.

Esta es una garantía más fuerte que la autenticación ordinaria. Una comprobación de contraseña revela la contraseña al servidor; una firma revela el mensaje; una ZKP no revela ni el testigo ni ningún cálculo intermedio. Esa propiedad es la razón por la que la criptografía de pruebas de conocimiento cero sustenta la identidad que preserva la privacidad, las transacciones confidenciales y la computación verificable en redes públicas.

La definición formal se remonta al artículo de 1985 "The Knowledge Complexity of Interactive Proof Systems" de Goldwasser, Micali y Rackoff, que introdujo el marco probador-verificador que todavía se usa hoy. El proyecto de Criptografía para la Mejora de la Privacidad (PEC) del NIST considera las ZKP como una técnica central de PEC y señala su uso para establecer el comportamiento correcto dentro de otros protocolos como la computación multipartita segura.

• Probador: posee el testigo y genera la prueba.
• Verificador: posee la afirmación pública y comprueba la prueba.
• Testigo: la entrada secreta que nunca debe transmitirse.
• Afirmación: la declaración pública que se prueba, como un hash o una restricción de saldo.

Las tres propiedades que toda ZKP debe cumplir

Cualquier protocolo que afirme ser una prueba de conocimiento cero debe cumplir tres propiedades. Estos son los criterios de aceptación que debe probar, no las afirmaciones de marketing.

Completitud: si la afirmación es verdadera y ambas partes siguen el protocolo honestamente, el verificador acepta. Un sistema de pruebas que falla con entradas válidas está roto.

Solidez: si la afirmación es falsa, ningún probador deshonesto puede convencer al verificador excepto con una probabilidad insignificante. La solidez es lo que impide que se acepten pruebas falsificadas en la cadena.

Conocimiento cero: si la afirmación es verdadera, el verificador no aprende nada más allá de su veracidad. Formalmente, esto se demuestra mediante un simulador que puede producir una transcripción indistinguible de una real sin el testigo.

• Completitud — probador honesto, afirmación verdadera, el verificador acepta.
• Solidez — probador deshonesto, afirmación falsa, el verificador rechaza con probabilidad abrumadora.
• Conocimiento cero — la transcripción no filtra información sobre el testigo.

Sistemas de prueba interactivos versus no interactivos

Las primeras ZKP eran interactivas: el probador y el verificador intercambiaban múltiples rondas de desafío-respuesta. El ejemplo clásico es el amigo daltónico y las dos bolas, o la cueva de Alí Babá, donde la repetición lleva la probabilidad de trampa hacia cero. Las pruebas interactivas son excelentes para enseñar pero incómodas para las blockchains, porque el verificador debe estar en línea y la transcripción crece con cada ronda.

Las pruebas no interactivas colapsan el intercambio en un solo mensaje. El probador ejecuta una configuración, calcula una prueba y la publica; cualquier verificador puede comprobarla más tarde sin más comunicación. Esta es la forma utilizada en sistemas de producción. Las dos familias dominantes son zk-SNARKs (Argumentos de Conocimiento No Interactivos Sucintos) y zk-STARKs (Argumentos de Conocimiento Transparentes Escalables).

El compromiso importa para la infraestructura. Los SNARKs suelen producir pruebas muy pequeñas y verificación barata, pero requieren una ceremonia de configuración confiable. Los STARKs evitan la configuración confiable y se basan en supuestos basados en hash, pero las pruebas son más grandes. Ninguno es universalmente mejor; la elección depende del costo de verificación, el tamaño de la prueba y el modelo de confianza que pueda tolerar.

• zk-SNARK: prueba pequeña, verificación rápida, configuración confiable en muchas construcciones.
• zk-STARK: configuración transparente, pruebas más grandes, supuestos de seguridad basados en hash.
• Pruebas recursivas: verificar una prueba dentro de otra prueba para comprimir historiales de computación largos.

Requisitos previos y supuestos antes de probar un pipeline ZKP

Antes de ejecutar cualquier flujo de verificación, confirme lo siguiente. Esta guía asume que tiene un endpoint RPC funcional para la red donde residen las pruebas o los contratos verificadores, y que puede leer el estado del contrato o enviar llamadas de solo lectura.

Necesita: una URL JSON-RPC (use un marcador de posición como RPC_URL y nunca confirme credenciales reales), una dirección de contrato verificador o un binario verificador local, y un artefacto de prueba válido conocido junto con sus entradas públicas. Si está probando un zk-rollup, también necesita el lote o la raíz de estado que la prueba pretende atestiguar.

Para la selección de endpoints, esta página se centra en la metodología. Si necesita una recomendación concreta de proveedor para una cadena específica, use el Asistente RPC en lugar de adivinar un endpoint. Para un contexto de infraestructura más amplio, consulte la guía de endpoints RPC multicadena y la guía de endpoints RPC.

Modelo mental: afirmación, testigo, prueba, verificador

Tenga en cuenta cuatro objetos. La afirmación es pública y fija. El testigo es privado y solo lo conoce el probador. La prueba es el artefacto producido por el algoritmo de prueba. El verificador es una función determinista que toma la afirmación y la prueba y devuelve aceptar o rechazar.

Una analogía útil de la documentación de Ethereum es el sobre opaco con un sello a prueba de manipulaciones: el verificador puede confirmar la aritmética sin abrir el sobre. En términos criptográficos, el sello es la prueba y el contenido oculto es el testigo.

La consecuencia crítica de ingeniería: la verificación debe ser barata y determinista, porque se ejecuta en la cadena o en un cliente ligero. La prueba puede ser costosa y generalmente se realiza fuera de la cadena. Cuando mide un sistema ZKP, casi siempre está midiendo el tiempo de prueba y el tamaño de la prueba por separado del tiempo de verificación.

Diagnóstico ejecutable: consultar un contrato verificador a través de JSON-RPC

La siguiente llamada curl realiza un eth_call de solo lectura contra un contrato verificador. Reemplace RPC_URL, VERIFIER_ADDRESS y los datos de llamada con valores de su propio despliegue. El selector mostrado es un marcador de posición; use el ABI de su verificador para codificar la función real y los bytes de prueba.

Este paso confirma la conectividad y que el verificador responde a una llamada bien formada antes de intentar un envío completo de prueba.

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": "0xPROOF_AND_PUBLIC_INPUTS_CALLDATA"
    }, "latest"]
  }'

Script de verificación ejecutable en JavaScript

El siguiente script envía la misma llamada a través de un cliente JSON-RPC e imprime el booleano decodificado. Separa los errores de transporte de los fallos de verificación, lo cual es esencial al depurar: una prueba rechazada y un nodo inalcanzable se ven muy diferentes y no deben confundirse.

Ejecútelo primero contra una prueba válida conocida, luego contra una prueba deliberadamente corrupta para confirmar el comportamiento de solidez. Un verificador correcto debe devolver false para la entrada corrupta.

const RPC_URL = process.env.RPC_URL;
const VERIFIER = process.env.VERIFIER_ADDRESS;

async function verify(calldata) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'eth_call',
      params: [{ to: VERIFIER, data: calldata }, 'latest']
    })
  });
  const json = await res.json();
  if (json.error) throw new Error(`RPC error: ${json.error.message}`);
  return json.result;
}

verify(process.env.VALID_CALLDATA)
  .then(r => console.log('valid proof result:', r))
  .catch(e => console.error(e.message));

verify(process.env.CORRUPTED_CALLDATA)
  .then(r => console.log('corrupted proof result:', r))
  .catch(e => console.error(e.message));

Resultados de verificación esperados y una tabla de medición

Un pipeline correcto produce un patrón predecible: la prueba válida devuelve un resultado verdadero (típicamente 0x...01), la prueba corrupta devuelve un resultado falso (0x...00), y los datos de llamada malformados devuelven un error RPC en lugar de un booleano. Registre cada resultado en una tabla de resultados para que el comportamiento sea reproducible.

No complete números que no haya medido. La siguiente tabla es una plantilla; complete las columnas de tiempo y tamaño a partir de sus propias ejecuciones. Mida el tiempo de prueba, el tamaño de la prueba y el tiempo de verificación por separado, y ejecute cada uno al menos diez veces para ver la varianza.

• | Caso | Entrada | Resultado esperado | Resultado observado | Tiempo de prueba (ms) | Tamaño de prueba (bytes) | Tiempo de verificación (ms) |
• | Prueba válida | Artefacto válido conocido | Aceptar | (medir) | (medir) | (medir) | (medir) |
• | Prueba corrupta | Byte invertido en la prueba | Rechazar | (medir) | n/a | (medir) | (medir) |
• | Entrada pública incorrecta | Afirmación no coincidente | Rechazar | (medir) | n/a | (medir) | (medir) |
• | Datos de llamada malformados | Bytes truncados | Error RPC | (medir) | n/a | n/a | n/a |

Solución de problemas comunes de verificación ZKP

La mayoría de los fallos se agrupan en un pequeño conjunto de categorías. Aíslalos en orden: transporte, codificación, discrepancia de afirmación, luego validez de la prueba.

Fallos de transporte aparecen como tiempos de espera o errores JSON-RPC. Verifique el endpoint, el ID de cadena y los límites de velocidad. Un nodo dedicado reduce la contención cuando se ejecutan llamadas de verificación repetidas; consulte infraestructura de nodo dedicado para el modelo operativo.

Fallos de codificación generalmente significan que los datos de llamada no coinciden con el ABI del verificador. Vuelva a codificar desde el ABI y confirme el selector de función.

Discrepancias de afirmación ocurren cuando las entradas públicas utilizadas en el momento de la prueba difieren de las enviadas en la verificación. Hashee las entradas públicas en ambos lados y compare.

Fallos de validez de la prueba significan que el verificador rechazó correctamente la prueba. Vuelva a ejecutar el probador, confirme que los parámetros de configuración coinciden y verifique que el testigo satisface cada restricción.

• Tiempo de espera o 429 — endpoint o límite de velocidad, no un problema de prueba.
• Revert sin razón — discrepancia de ABI o datos de llamada.
• Falso consistente — discrepancia de entrada pública o prueba inválida.
• Falso intermitente — no determinismo en la serialización de entrada.

Limitaciones y compromisos de la criptografía de pruebas de conocimiento cero

Las ZKP son poderosas pero no gratuitas. La prueba es computacionalmente pesada, a menudo órdenes de magnitud más costosa que la ejecución nativa. Las configuraciones confiables introducen riesgo de ceremonia si los residuos tóxicos no se destruyen. Los contratos verificadores añaden costo de gas y tamaño de bytecode a los despliegues en la cadena.

También hay un límite de confianza en la cadena de herramientas: un error en el circuito, el compilador o la biblioteca de pruebas puede producir pruebas que verifican pero atestiguan la afirmación incorrecta. La verificación formal y las auditorías independientes de circuitos no son opcionales para sistemas de alto valor.

Finalmente, el conocimiento cero es una propiedad del protocolo, no de la aplicación que lo rodea. Los metadatos, los tiempos y la correlación a nivel de red aún pueden filtrar información incluso cuando la prueba en sí es de conocimiento cero.

Próximos pasos: de la verificación de pruebas a la infraestructura de producción

Una vez que pueda reproducir el patrón de aceptar/rechazar y haya completado su tabla de medición, pase a las preocupaciones operativas: confiabilidad del endpoint bajo carga, reintentos de envío de pruebas y monitoreo de eventos del contrato verificador.

Para detalles de despliegue específicos de la red, explore las redes compatibles. Para la planificación de capacidad y costos, revise precios de RPC y la descripción general del servicio API. Si necesita una recomendación concreta de endpoint para una cadena específica, pregunte al Asistente RPC en lugar de codificar una URL no verificada.

Una progresión razonable es: verificar localmente, verificar contra un endpoint de testnet, luego verificar contra un endpoint de producción dedicado con monitoreo. Cada etapa debe reutilizar la misma tabla de resultados para que las regresiones sean visibles.