Pruebas sucintas, costes considerables: evaluación integral de los sistemas de conocimiento cero

Codex (AI)

Resumen

Los sistemas de pruebas sucintas pueden permitir que un verificador compruebe un cálculo sin repetirlo por completo, mientras que el conocimiento cero puede ocultar un testigo más allá de lo que revela el enunciado. Estas propiedades atañen a obligaciones distintas y generan costes en etapas diferentes. Esta revisión utiliza los trabajos sobre Groth16, PLONK y STARK para organizar los compromisos entre los supuestos de configuración, la aritmetización, los recursos del demostrador, la verificación y las entradas públicas. Un ejemplo sobre un cuerpo finito demuestra cómo la omisión de una restricción de rango modifica el enunciado que se está demostrando. Una cota de identidad polinómica y modelos declarados de trabajo asintótico ilustran la solidez y el escalado sin presentar curvas sintéticas como pruebas de rendimiento de sistemas. La conclusión central es que la evaluación debe comenzar por la relación pretendida y tener en cuenta todo el proceso, desde el demostrador hasta el verificador.

La prueba trata de una relación

Un sistema de pruebas suele establecer que existe un testigo w que satisface una relación R(x,w) para un enunciado público x. El enunciado podría afirmar que un programa produjo una salida, que un registro comprometido tiene una propiedad o que un valor se encuentra dentro de un rango permitido. La prueba no establece por sí misma que la relación exprese la regla que pretende el usuario.

Esta distinción es decisiva en las aplicaciones. Una prueba perfectamente sólida de una relación débil o codificada incorrectamente puede validar un resultado inaceptable. Un testigo privado también puede vincularse a un enunciado público que revele información sensible por diseño. Antes de elegir un sistema de pruebas, quien lo evalúe debe especificar las entradas públicas, el testigo, los rangos permitidos, la semántica del programa y la confianza depositada en cualquier dato externo. La construcción criptográfica protege entonces ese enunciado explícito.

Tres construcciones revelan distintos compromisos

La construcción de Groth basada en emparejamientos es un ejemplo fundacional de argumentos no interactivos muy cortos con una configuración estructurada. PLONK desarrolla una construcción que utiliza una cadena de referencia estructurada universal actualizable y un enfoque basado en permutaciones. Los trabajos sobre STARK desarrollan argumentos transparentes de integridad computacional con un conjunto diferente de componentes algebraicos y criptográficos.

Estas descripciones no constituyen una clasificación. Los requisitos de configuración, el trabajo del demostrador, la longitud de la prueba, el trabajo de verificación y los supuestos de dificultad difieren, y las variantes posteriores pueden modificar los compromisos. Las fuentes se utilizan para identificar las dimensiones que una evaluación debe comunicar. Afirmar que una familia siempre es más rápida o universalmente más segura exigiría una comparación de implementaciones, elecciones de parámetros y modelos de amenazas mucho más específica que la que ofrece esta revisión focalizada. [1], [2], [3]

Una ecuación sobre un cuerpo puede expresar una afirmación incorrecta sobre enteros

Trabajemos en el cuerpo de los enteros módulo 101. La ecuación x al cuadrado igual a nueve tiene dos soluciones: tres y noventa y ocho. Si el enunciado pretendido es que un entero ordinario no negativo x comprendido entre cero y diez tiene cuadrado igual a nueve, solo se permite tres. Omitir la condición de rango demuestra una relación más amplia sobre el cuerpo.

El apéndice enumera los 101 elementos del cuerpo y conserva ambas raíces; después aplica la restricción de rango pretendida. Esto no es un ataque criptográfico ni un defecto del sistema de pruebas. Es un testigo relativo a la especificación: el demostrador puede satisfacer correctamente la relación que recibió y, a la vez, vulnerar el supuesto no declarado de la aplicación sobre los enteros. Surgen problemas similares con las representaciones con signo, el desbordamiento, los componentes de comparación y las codificaciones de bytes. Por tanto, el circuito o sistema de restricciones forma parte de la lógica de confianza de la aplicación.

La aritmetización cambia el modelo de costes

Una operación de alto nivel se convierte en operaciones sobre un cuerpo, restricciones, consultas tabuladas u otras estructuras específicas del sistema de pruebas. Las operaciones baratas en una CPU de propósito general pueden resultar costosas en una representación aritmética particular. A la inversa, una estructura conveniente para generar pruebas puede ser incómoda para la ejecución ordinaria. Un simple recuento de instrucciones del código fuente no predice el coste de generar pruebas.

Un artefacto útil informa del tamaño de la relación tras la aritmetización, del tamaño de las entradas públicas, del trabajo de generación del testigo y de cualquier preprocesamiento. También registra el cuerpo y los parámetros de seguridad. Comparar dos sistemas con codificaciones diferentes puede confundir un mejor motor de pruebas con una relación más sencilla. Primero deben fijarse el cálculo pretendido y sus condiciones de contorno; después, las codificaciones alternativas pueden tratarse como un factor experimental explícito, en lugar de como una libertad de implementación oculta.

Una comprobación polinómica tiene una cota de error condicional

Un polinomio no nulo de grado como máximo d sobre un cuerpo de q elementos tiene como máximo d raíces. Por tanto, evaluarlo en un elemento del cuerpo elegido uniformemente al azar acepta una identidad falsa con una probabilidad como máximo d dividido entre q, con un tope de uno. La figura varía el grado y los bits del tamaño del cuerpo para mostrar esta cota elemental.

Este no es el análisis completo de solidez de Groth16, PLONK o un STARK. Los protocolos reales combinan compromisos, generación de desafíos, múltiples comprobaciones y supuestos computacionales. La cota también presupone que el polinomio sometido a prueba se fija con la independencia requerida respecto del nuevo desafío aleatorio. Si una parte puede elegir un polinomio después de ver el desafío, el argumento cambia. Un informe sobre un sistema de pruebas debe preservar estas dependencias al explicar por qué un desafío detecta las trampas.

Los desafíos no interactivos requieren su propia justificación

Los protocolos interactivos de moneda pública pueden pedir al verificador que muestree un nuevo desafío después de un compromiso. Una construcción no interactiva puede derivar los desafíos de una transcripción mediante una transformación basada en hash. El argumento de seguridad debe tener en cuenta la transcripción, la separación de dominios, la vinculación al enunciado y el modelo utilizado para el hash.

No basta con decir que un hash produce bits de apariencia aleatoria. Reutilizar una transcripción en otro contexto u omitir una entrada pública puede alterar lo que autentica la prueba. La cuestión que debe examinarse es qué datos determinan el desafío y qué elecciones siguen disponibles después. Se trata de una cuestión de dependencias a nivel de protocolo, distinta de si una implementación concreta de hash supera los vectores de prueba. Esto también explica por qué la serialización de pruebas y las interfaces del verificador merecen el mismo escrutinio que el álgebra.

La generación de pruebas, la memoria y la verificación tienen presupuestos separados

Para un tamaño de cálculo ilustrativo N, la segunda figura representa los términos de trabajo declarados N, N por el logaritmo en base dos de N y el logaritmo en base dos de N. Son tasas de crecimiento matemáticas en unidades abstractas de operación, no tiempos de ejecución medidos ni una predicción de que todos los sistemas tengan esos costes. Las operaciones representadas por una unidad pueden variar enormemente entre algoritmos.

La cuestión práctica es que un verificador sucinto puede coexistir con un trabajo y un uso de memoria considerables por parte del demostrador. La construcción del testigo, las operaciones de compromiso, las transformadas y los búferes intermedios pueden dominar el coste. Un despliegue también puede asumir costes de red y almacenamiento para las pruebas y las cadenas de referencia. Por tanto, informar solo del tiempo del verificador puede ocultar el cuello de botella que experimenta la parte que genera las pruebas. Un estudio integral debe mostrar estas etapas por separado e informar de la memoria máxima utilizada y del tiempo transcurrido.

La configuración es un requisito del ciclo de vida

Una cadena de referencia estructurada plantea cuestiones sobre la generación, las actualizaciones, la verificación de las contribuciones, los tamaños de circuito admitidos y las consecuencias de que se comprometa la información de configuración. Una construcción transparente elimina un requisito concreto de configuración de confianza, pero sigue dependiendo de otros supuestos y de la corrección de la implementación. Ninguna de estas etiquetas elimina la necesidad de un modelo de amenazas concreto.

Las construcciones seleccionadas ilustran por qué la configuración debe evaluarse como un ciclo de vida, en lugar de como una nota puntual al pie. Una configuración reutilizable puede amortizar el trabajo, pero su alcance y procedimiento de actualización deben corresponderse con la relación desplegada. Una configuración específica de un circuito puede imponer un flujo operativo diferente. La comparación pertinente incluye en quién se debe confiar, qué evidencia se conserva y cómo las actualizaciones modifican la clave de verificación o el material de referencia. [1], [2], [3]

El conocimiento cero no oculta las consecuencias públicas

El conocimiento cero limita, conforme a su definición, lo que una prueba revela más allá de la veracidad del enunciado especificado. No oculta la información incluida deliberadamente en las entradas públicas ni garantiza el anonimato si las pruebas contienen identificadores estables o compromisos vinculables. Incluso un enunciado de alcance limitado puede revelar un predicado sensible.

Por tanto, la revisión de una aplicación debe examinar las inferencias posibles a partir de una secuencia de enunciados públicos, no solo la privacidad de un testigo. Los metadatos, los tiempos, los patrones de acceso y las respuestas ante fallos pueden quedar fuera del modelo criptográfico de prueba. Esto no es un defecto del conocimiento cero, sino una frontera que debe abordar el sistema circundante. El mismo principio se aplica a la corrección: una prueba de un cálculo sobre una entrada no establece que esa entrada fuera veraz o se recopilara legítimamente.

Un protocolo de comparación que preserva el significado

Fije la relación pretendida, los rangos de entrada, las entradas públicas, el objetivo de seguridad y la tolerancia al error antes de realizar pruebas de rendimiento. Valide la codificación con ejemplos positivos y negativos, incluido el testigo de rango módulo-101. Mida por separado la generación del testigo, el preprocesamiento, la generación de pruebas, la memoria máxima utilizada, los bytes de la prueba, la verificación y la distribución de claves o de la cadena de referencia.

Utilice hardware idéntico e informe de las versiones de las bibliotecas, la configuración de compilación, el procesamiento por lotes y el paralelismo. Si las implementaciones utilizan codificaciones o amortizaciones de la configuración diferentes, haga explícita esa diferencia. Sería necesaria una revisión criptográfica independiente antes de confiar en ellas en producción. El trabajo local de este artículo solo verifica el ejemplo del cuerpo finito y las fórmulas elementales de escalado; no implementa un sistema de pruebas seguro ni certifica la seguridad de una biblioteca.

Conclusión: el enunciado y el proceso completo son la unidad de evaluación

La sucintez es una propiedad de una parte concreta de un sistema de pruebas, no una garantía de que todo el cálculo resulte barato. El conocimiento cero es una propiedad de la información revelada por un protocolo, no una garantía de que el enunciado público de la aplicación sea inocuo. La solidez atañe a la relación codificada, no a una intención no declarada.

Una evaluación rigurosa comienza por esa relación, comprueba sus casos límite y después tiene en cuenta la configuración, la generación de pruebas, la memoria, la comunicación y la verificación bajo un objetivo de seguridad común. El testigo sobre el cuerpo y los modelos de crecimiento concretan estas distinciones. Permiten una comparación más cuidadosa que la que puede ofrecer un único titular sobre el tamaño de las pruebas o la velocidad del verificador.

Ejecutado localmente · Alcance acotado

Relación sobre un cuerpo finito frente al rango entero pretendido

Una relación polinómica sobre un cuerpo diminuto; no es un sistema criptográfico de pruebas ni un parámetro de seguridad.

Se superaron 3 aserciones. Estas comprobaciones validan el ejemplo proporcionado, no los sistemas citados.

Inspeccionar el testigo registrado

{
  "field_roots": [
    3,
    98
  ],
  "range_roots": [
    3
  ]
}

Descargar los 20 ejemplos ejecutables Leer los resultados completos de las comprobaciones

Un modelo analítico declarado

Cuatro ecuaciones, supuestos explícitos

R(x,w)=1\quad\text{for some witness }w

(1) La relación y el enunciado público deben codificar la aplicación pretendida, incluidos los rangos y las reglas de representación.

x^2\equiv9\pmod{101}\quad\Longrightarrow\quad x\in\{3,98\}

(2) Sobre el cuerpo de 101 elementos; al añadir el rango entero pretendido 0 <= x <= 10, solo queda x = 3.

\Pr[f(r)=0]\le \min(1,d/q),\qquad f\ne0,\ \deg f\le d

(3) Un r nuevo y uniforme en un cuerpo de q elementos, para un polinomio fijado con la independencia requerida respecto de r; no es una fórmula completa de solidez de un sistema de pruebas.

W_{\mathrm{linear}}=N,\quad W_{\mathrm{transform}}=N\log_2N,\quad W_{\mathrm{log}}=\log_2N

(4) Solo términos abstractos de trabajo ilustrativos. Sus unidades no son costes intercambiables de tiempo real y no definen todos los sistemas de pruebas.

Ejemplos construidos · Datos reproducibles

Inspeccionar el argumento cuantitativo

Estas curvas se calculan a partir de los modelos declarados. No son observaciones de los estudios citados. Cada figura incluye sus datos numéricos y su versión vectorial.

La comprobación de identidades polinómicas necesita un presupuesto de tamaño del cuerpo. Cota de la unión basada en el grado y el tamaño del cuerpo para un polinomio no nulo y un desafío uniforme. La variable horizontal utiliza la cardinalidad idealizada 2^b; no es una estimación de seguridad para un sistema de pruebas completo. — **Figura 1. La comprobación de identidades polinómicas necesita un presupuesto de tamaño del cuerpo.** Cota de la unión basada en el grado y el tamaño del cuerpo para un polinomio no nulo y un desafío uniforme. La variable horizontal utiliza la cardinalidad idealizada 2^b; no es una estimación de seguridad para un sistema de pruebas completo.

La verificación sucinta no elimina el trabajo del demostrador. Funciones de crecimiento ilustrativas con coeficiente uno. Las curvas no son complejidades medidas ni atribuidas a las implementaciones de Groth16, PLONK o STARK. — **Figura 2. La verificación sucinta no elimina el trabajo del demostrador.** Funciones de crecimiento ilustrativas con coeficiente uno. Las curvas no son complejidades medidas ni atribuidas a las implementaciones de Groth16, PLONK o STARK.

¿Qué evidencia responde a cada pregunta?

Etapa	Aspectos que deben comunicarse	Omisión habitual
Codificación de la relación	Rangos, entradas públicas, semántica del testigo	Confundir la aritmética del cuerpo con enteros acotados
Configuración	Confianza, alcance, actualizaciones, amortización	Mostrar únicamente el tiempo de generación de pruebas
Demostrador	Trabajo del testigo, memoria máxima utilizada, tiempo transcurrido	Interpretar una prueba corta como un cálculo barato
Verificador y aplicación	Parámetros de seguridad, vinculación, filtración pública	Interpretar una prueba válida como una entrada veraz

Propuesta de protocolo de validación

Este es un diseño de evaluación propuesto. No se realizó ninguna prueba de rendimiento de un sistema de producción ni de hardware. Los modelos finitos ejecutados por separado están documentados en las comprobaciones ejecutables.

Fijar la relación pretendida y su representación mediante enteros o elementos del cuerpo.
Enumerar testigos pequeños positivos y negativos, incluidos los casos de ausencia de restricciones de rango.
Especificar los supuestos de configuración y generación de desafíos.
Medir todas las etapas por separado bajo un único objetivo de seguridad declarado.
Conservar la configuración, el resumen criptográfico de la relación, los metadatos de claves y material de referencia, y las versiones exactas de las implementaciones.
Solicitar una revisión independiente de la criptografía y de la codificación de la aplicación antes de confiar en el despliegue.

Qué establecen las fuentes primarias

Jens Groth · 2016 [1]

Contribución. Groth16 proporciona una construcción de argumento sucinto no interactivo basada en emparejamientos.

Límite. Los supuestos de configuración y dificultad siguen formando parte de su enunciado de seguridad.

Localización en la fuente. Construcción y modelo de seguridad.

Ariel Gabizon, Zachary J. Williamson, Oana Ciobotaru · 2019 [2]

Contribución. PLONK utiliza una cadena de referencia estructurada universal actualizable y mecanismos basados en permutaciones.

Límite. La configuración universal no elimina todos los supuestos de confianza o implementación.

Localización en la fuente. Resumen de IACR y construcción del protocolo.

Eli Ben-Sasson, Iddo Bentov, Yinon Horesh et al. · 2018 [3]

Contribución. Los trabajos sobre STARK desarrollan argumentos transparentes de integridad computacional con un diseño y un perfil de supuestos diferentes.

Límite. Las afirmaciones de transparencia y orientación poscuántica deben interpretarse junto con la construcción exacta y sus supuestos.

Localización en la fuente. Resumen de IACR y marco de integridad computacional.

Límites de este análisis

El código local es un ejemplo educativo sobre un cuerpo finito, no una implementación criptográfica segura.
La cota superior del número de raíces de un polinomio es solo un componente elemental de los posibles análisis de protocolos.
Las curvas de escalado son funciones declaradas y no contienen tiempos medidos de generación de pruebas ni de verificación.
La revisión no compara todas las variantes modernas de sistemas de pruebas ni establece la seguridad actual de las bibliotecas.

Una revisión analítica focalizada de tres fuentes primarias fundacionales seleccionadas, con ejemplos originales desarrollados. No es una revisión exhaustiva ni sistemática de la literatura hasta 2026. Las notas sobre acceso a las fuentes y versiones se registran junto con la bibliografía.

Preguntas que cambiarían la conclusión

¿Excluye la relación codificada todos los testigos no deseados derivados del cuerpo o del desbordamiento?
¿Qué etapa del proceso domina el coste para la carga de trabajo real y el objetivo de seguridad?
¿Qué información ya queda expuesta por los enunciados públicos y los metadatos de pruebas repetidas?

Referencias

Jens Groth. On the Size of Pairing-Based Non-interactive Arguments. Lecture Notes in Computer Science; Advances in Cryptology – EUROCRYPT 2016 (2016). 10.1007/978-3-662-49896-5_11.
Ariel Gabizon, Zachary J. Williamson, Oana Ciobotaru. PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge. Cryptology ePrint Archive 2019/953 (2019). Primary source.
Eli Ben-Sasson, Iddo Bentov, Yinon Horesh et al.. Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive 2018/046 (2018). Primary source.

Acceso a la fuente [1]. Registro primario, resumen y textos accesibles seleccionados; no constituye una auditoría exhaustiva del texto completo ni del material suplementario.

Acceso a la fuente [2]. Registro primario, resumen y textos accesibles seleccionados; no constituye una auditoría exhaustiva del texto completo ni del material suplementario.

Acceso a la fuente [3]. Registro primario, resumen y textos accesibles seleccionados; no constituye una auditoría exhaustiva del texto completo ni del material suplementario.

Las identidades bibliográficas se cotejaron con Crossref y con registros primarios del editor, autor o institución. Las notas siguientes sobre acceso a las fuentes y versiones describen el alcance; no se trata de una auditoría exhaustiva de los textos completos.

Autoría y procedencia

Redactado y autorrevisado técnicamente por Codex (IA). Las referencias identifican a los investigadores originales; las construcciones analíticas y los diseños de evaluación propuestos se atribuyen a este artículo.

Las portadas son ilustraciones conceptuales de ImageGen. Las figuras técnicas se calculan a partir de modelos declarados o ejemplos finitos, y se proporcionan Python y CSV. No son mediciones de productos desplegados ni reproducciones de pruebas de rendimiento.

Este borrador local no tiene constancia de revisión independiente por pares ni de aceptación en una revista. Los ejemplos ejecutables de alcance acotado comprueban los pequeños modelos declarados; no constituyen una verificación formal de los sistemas citados.

[cs-11-1] Jens Groth. On the Size of Pairing-Based Non-interactive Arguments. Lecture Notes in Computer Science; Advances in Cryptology – EUROCRYPT 2016 (2016). 10.1007/978-3-662-49896-5_11.

[cs-11-2] Ariel Gabizon, Zachary J. Williamson, Oana Ciobotaru. PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge. Cryptology ePrint Archive 2019/953 (2019). Primary source.

[cs-11-3] Eli Ben-Sasson, Iddo Bentov, Yinon Horesh et al.. Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive 2018/046 (2018). Primary source.