Protocolo de prueba de conocimiento cero: cómo funcionan las ZKP y cómo verificarlas

Qué garantiza realmente un protocolo de prueba de conocimiento cero

Un protocolo de prueba de conocimiento cero (ZKP) es una interacción criptográfica en la que una parte, el probador, convence a otra parte, el verificador, de que una afirmación es verdadera sin transmitir nada más allá del hecho de su veracidad. La afirmación suele estar vinculada a una entrada secreta llamada testigo. Por ejemplo, la afirmación podría ser "conozco una clave privada correspondiente a esta clave pública", y el testigo es la propia clave privada.

Tres propiedades definen un protocolo sólido. La completitud significa que un probador honesto con un testigo válido siempre puede convencer a un verificador honesto. 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 el verificador no aprende nada sobre el testigo más allá de la veracidad de la afirmación, normalmente formalizado mostrando que una transcripción simulada es indistinguible de una real.

Estas garantías son probabilísticas, no absolutas. La mayoría de los protocolos llevan la confianza del verificador arbitrariamente cerca de la certeza mediante repetición o mediante una única prueba cuyo error de solidez es criptográficamente insignificante. Esa distinción importa cuando se evalúa un sistema de pruebas para producción: se está eligiendo un parámetro de seguridad concreto, no una propiedad binaria.

• Completitud: un testigo válido siempre convence al verificador.
• Solidez: las afirmaciones falsas se rechazan con una probabilidad abrumadora.
• Conocimiento cero: la transcripción no revela nada sobre el testigo.
• Parámetro de seguridad: el número de repeticiones o el tamaño del campo que fija el error de solidez.

Suposiciones y requisitos previos antes de construir

Antes de implementar o integrar un protocolo ZKP, confirme cuatro cosas. Primero, defina la afirmación con precisión: ¿qué entradas públicas ve el verificador y qué entradas privadas deben permanecer ocultas? Segundo, elija una familia de sistemas de pruebas que se ajuste a sus restricciones, como configuraciones transparentes frente a configuraciones de confianza, y pruebas sucintas frente a no sucintas. Tercero, decida si la prueba debe ser no interactiva, porque la mayoría de los sistemas en cadena y asíncronos no pueden soportar un ida y vuelta en vivo. Cuarto, identifique dónde se generarán y verificarán las pruebas, ya que el costo del probador y el costo del verificador suelen ser asimétricos.

También necesita un entorno de desarrollo con una biblioteca ZK o un compilador de circuitos, una forma de serializar pruebas y claves de verificación, y un entorno de ejecución del verificador. Si su verificador se ejecuta en una cadena de bloques, el costo de gas del contrato verificador y el endpoint RPC que utiliza para enviar y confirmar transacciones pasan a formar parte del envelope operativo del protocolo. Para la selección de endpoints, las páginas del servicio de API RPC y precios de RPC describen cómo se estructura el acceso gestionado, mientras que el directorio de redes enumera las cadenas compatibles.

El modelo mental probador-verificador

Piense en el protocolo como un contrato entre dos roles. El probador posee un testigo w y una afirmación pública x. Una relación R(x, w) define cuándo la afirmación es verdadera. El probador ejecuta un algoritmo de prueba que produce una prueba π. El verificador ejecuta un algoritmo de verificación que devuelve aceptar o rechazar dado (x, π) y, en algunos sistemas, una clave de verificación.

El punto de diseño crítico es que el verificador nunca necesita w. Solo necesita suficiente estructura pública para comprobar que π solo podría haber sido producida por alguien que conoce un w válido. En sistemas no interactivos, esto a menudo se logra derivando el desafío a partir de un hash de los compromisos del probador, una técnica conocida como transformación de Fiat-Shamir. Esa transformación convierte un protocolo interactivo de desafío-respuesta en un único mensaje que cualquiera puede verificar más tarde.

Una analogía útil es un sobre sellado con un sello a prueba de manipulaciones. El verificador puede confirmar que el sello es válido y que el contenido cumple una regla pública, pero no puede leer el contenido. La analogía falla en cuanto a la solidez: los protocolos reales se basan en suposiciones de dureza computacional, no en sellos físicos, por lo que el argumento de seguridad debe contrastarse con la suposición específica que utiliza su biblioteca.

Protocolos de prueba interactivos frente a no interactivos

Los protocolos interactivos requieren que el verificador envíe desafíos aleatorios frescos al probador a lo largo de múltiples rondas. Son conceptualmente simples y a menudo eficientes, pero requieren que ambas partes estén en línea y sincronizadas. Los protocolos no interactivos producen una única prueba que puede verificarse más tarde, por una parte diferente, sin comunicación adicional. Por eso las pruebas no interactivas dominan los casos de uso de cadena de bloques y computación verificable.

La compensación no es gratuita. Las pruebas no interactivas a menudo dependen de una cadena de referencia común o de un modelo de oráculo aleatorio, y la ceremonia de configuración o la suposición de hash pasan a formar parte de su modelo de confianza. Las configuraciones transparentes evitan una ceremonia de confianza pero pueden aumentar el tamaño de la prueba o el tiempo de verificación. Cuando compare sistemas de pruebas, compárelos sobre la misma afirmación y el mismo parámetro de seguridad, no sobre afirmaciones de marketing.

• Interactivo: múltiples rondas, desafíos frescos del verificador, ambas partes en línea.
• No interactivo: mensaje de prueba único, verificable de forma asíncrona, a menudo mediante Fiat-Shamir.
• Configuración de confianza: pruebas más pequeñas pero requiere una ceremonia cuya transcripción debe auditarse.
• Configuración transparente: sin ceremonia, pero potencialmente pruebas más grandes o verificación más lenta.

Flujo de trabajo ejecutable: generar y verificar una prueba

El siguiente esbozo en Python muestra la forma de un flujo de trabajo de pruebas utilizando una interfaz de biblioteca de marcador de posición. Reemplace zklib con su biblioteca real de sistema de pruebas y adapte la definición del circuito a su afirmación. El objetivo es hacer explícito el flujo de datos: entran las entradas públicas y el testigo, salen una prueba y una clave de verificación, y el verificador solo comprueba datos públicos.

Ejecute esto en un entorno aislado y registre el tamaño de la prueba, el tiempo de prueba y el tiempo de verificación. Esos tres números son las entradas para toda decisión de infraestructura posterior.

import time
import zklib  # placeholder for your ZK library

# 1. Define the relation R(x, w)
circuit = zklib.Circuit("knowledge_of_preimage")

# 2. Public input and private witness
public_input = {"commitment": "0xabc..."}
witness = {"secret": "0xdef..."}

# 3. Setup (skip if your system uses a universal or transparent setup)
params = zklib.setup(circuit)

# 4. Prove
start = time.perf_counter()
proof = zklib.prove(circuit, params, public_input, witness)
prove_ms = (time.perf_counter() - start) * 1000

# 5. Verify
start = time.perf_counter()
ok = zklib.verify(circuit, params.verification_key, public_input, proof)
verify_ms = (time.perf_counter() - start) * 1000

print({"accepted": ok, "prove_ms": round(prove_ms, 2), "verify_ms": round(verify_ms, 2), "proof_bytes": len(proof)})
assert ok is True

Verificar una prueba a través de un endpoint RPC

Si su verificador es un contrato inteligente, la prueba se envía en una transacción y la función de verificación del contrato devuelve un booleano o revierte. El endpoint RPC es el transporte, no el ancla de confianza: el contrato impone la solidez, mientras que el endpoint determina si su envío se incluye y confirma de manera confiable. Utilice un endpoint de marcador de posición y nunca codifique credenciales en el control de código fuente.

El ejemplo de curl a continuación lee el resultado de un verificador de un contrato usando eth_call. Asume que su contrato expone una función de vista que acepta la entrada pública y los bytes de la prueba. Reemplace el selector de función y la codificación con el ABI de su verificador.

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

Resultado de verificación esperado y cómo interpretarlo

Una verificación exitosa devuelve true desde la función de verificación, o un recibo de transacción con estado 0x1 si la verificación cambia el estado. Una verificación fallida devuelve false o revierte con un error. No trate una respuesta RPC exitosa como validez de la prueba: la llamada JSON-RPC tuvo éxito si el nodo respondió, incluso cuando el resultado decodificado es false. Siempre decodifique el valor de retorno y verifíquelo con una aserción.

Para una comprobación reproducible, ejecute la misma prueba contra al menos dos implementaciones de verificador independientes, como su biblioteca local y el contrato en cadena. Si no coinciden, el error casi siempre está en la codificación, el orden de las entradas públicas o la clave de verificación, no en la criptografía. Registre las entradas públicas exactas, los bytes de la prueba y el hash de la clave de verificación junto con el resultado para que la comprobación pueda repetirse.

• Decodifique el valor de retorno; no infiera validez a partir de HTTP 200.
• Compare la verificación local y en cadena para la misma prueba.
• Almacene las entradas públicas, el hash de la prueba y el hash de la clave de verificación con cada resultado.
• Vuelva a ejecutar después de cualquier actualización del circuito o de la biblioteca.

Medir el costo del probador y del verificador

Los sistemas de pruebas tienen costos asimétricos. La prueba suele ser el paso costoso, mientras que la verificación está diseñada para ser barata y constante o logarítmica en el tamaño del circuito. Mida ambos en el hardware y el entorno de ejecución que realmente utilizará. Ejecute cada medición al menos 30 veces, descarte las ejecuciones de calentamiento y reporte la mediana y el p95 en lugar de una sola muestra.

Utilice una tabla de resultados como la siguiente. No la rellene con números prestados; complétela con sus propias ejecuciones. La tabla es el artefacto que le permite comparar sistemas de pruebas, tamaños de circuito y opciones de alojamiento en igualdad de condiciones.

• | Configuración | Tamaño del circuito | Tiempo de prueba mediano | Tiempo de prueba p95 | Tiempo de verificación mediano | Tamaño de la prueba |
• | Biblioteca local, afirmación A | su valor | su valor | su valor | su valor | su valor |
• | Verificador en cadena, afirmación A | su valor | n/a | n/a | su valor | su valor |
• | Biblioteca local, afirmación B | su valor | su valor | su valor | su valor | su valor |

Solución de problemas comunes del protocolo

La mayoría de las fallas en una integración ZKP no son rupturas criptográficas. Son desajustes entre la vista del probador y del verificador de las entradas públicas, claves de verificación obsoletas o diferencias de codificación entre la biblioteca y el contrato. Una prueba que verifica localmente pero falla en cadena es una señal fuerte para comparar los bytes serializados campo por campo.

Si la prueba es inesperadamente lenta, verifique si el circuito es más grande de lo previsto, si la clave de prueba se regenera en cada ejecución y si el proceso está limitado por la memoria. Si la verificación es inesperadamente costosa, verifique si el verificador realiza emparejamientos de curvas elípticas por cada entrada pública y si las entradas públicas se pueden agrupar. Si las pruebas se rechazan de forma intermitente, verifique el orden no determinista de las entradas y la derivación de desafíos que depende de estado mutable.

• Aprobación local, fallo en cadena: compare la codificación de entradas públicas y el hash de la clave de verificación.
• Rechazo intermitente: verifique el orden de las entradas y la derivación de desafíos.
• Prueba lenta: confirme el tamaño del circuito y reutilice la clave de prueba.
• Costo de verificación alto: cuente los emparejamientos y considere agrupar las entradas públicas.
• Tiempos de espera RPC: separe las fallas de transporte de los rechazos del verificador en los registros.

Limitaciones, compensaciones y límites operativos

Las pruebas de conocimiento cero no hacen que un sistema sea privado por defecto. Ocultan el testigo, pero las entradas públicas, los tiempos y los metadatos de las transacciones aún pueden filtrar información. Tampoco garantizan que la afirmación en sí sea significativa: una prueba válida de la afirmación equivocada sigue siendo una prueba válida. Defina la afirmación y sus entradas públicas con el mismo cuidado con que define el circuito.

Operativamente, la prueba consume muchos recursos computacionales y a menudo se beneficia de hardware dedicado, mientras que la verificación es ligera y puede ejecutarse en infraestructura modesta. Si su verificador está en cadena, la capa RPC se convierte en una dependencia de confiabilidad: una transacción descartada o un nodo retrasado pueden parecer un fallo de verificación. Para cargas de trabajo de verificación de alto volumen, un nodo dedicado puede reducir la variabilidad de los endpoints compartidos, y la biblioteca Learn cubre temas de infraestructura relacionados, como el alojamiento de nodos y la confiabilidad de los endpoints.

Próximos pasos para una integración ZKP en producción

Comience por congelar la afirmación, las entradas públicas y el parámetro de seguridad en un documento de especificación. Luego construya un arnés local de probador-verificador, agregue el verificador en cadena y ejecute la tabla de medición anterior en circuitos representativos. Solo después de que esos resultados sean estables debería elegir el alojamiento y la topología de endpoints.

Para la decisión del endpoint en sí, mantenga la metodología aquí y utilice la guía del Asistente RPC para elecciones concretas de proveedor y red. Una secuencia razonable es: validar el protocolo localmente, medir los costos, luego seleccionar acceso RPC gestionado a través del servicio de API o infraestructura dedicada, y confirmar las redes compatibles en el directorio de redes. Vuelva a ejecutar las comprobaciones de verificación y costo después de cada actualización del circuito, la biblioteca o el verificador para que las garantías del protocolo sigan vinculadas a la evidencia.