Una prueba de conocimiento cero es un método criptográfico para establecer que una afirmación cuidadosamente especificada es válida sin revelar la información privada que la hace válida. El nombre puede invitar a una interpretación demasiado amplia. No significa que un sistema no revele nada en absoluto. Una prueba suele exponer que una afirmación definida ha satisfecho reglas de verificación definidas, y una aplicación aún puede exponer entradas públicas, horarios, registros, identificadores u otros metadatos fuera de la prueba.
La pregunta útil, por tanto, es concreta: ¿qué afirmación se prueba?, ¿qué es privado?, ¿qué es público? y ¿qué establece una verificación exitosa? Este artículo introduce esos términos antes de explicar SNARK y STARK como familias amplias de sistemas de pruebas de conocimiento cero. Es una explicación educativa, no una recomendación de utilizar, seleccionar ni basarse en un sistema de prueba particular.
Afirmaciones, testigos y relaciones definidas
Todo sistema de prueba comienza con una relación que puede evaluar. La parte pública suele llamarse afirmación. Una afirmación puede decir que un valor satisface condiciones publicadas o que un cálculo produjo una salida de acuerdo con un conjunto declarado de reglas. La información que demuestra por qué la afirmación es cierta se denomina normalmente testigo. Un testigo puede ser un valor secreto, una colección de entradas u otra información privada definida por el sistema de prueba.
La frontera entre afirmación y testigo es importante. Un verificador solo puede comprobar la relación que se codificó. Si una afirmación dice que una entrada cumple una condición concreta, la aceptación establece esa condición según las reglas del sistema. No establece automáticamente de dónde procede la entrada, si se incluyeron todos los hechos relevantes del mundo real ni qué pretende hacer una persona después de la verificación. Esas cuestiones requieren su propia evidencia, definiciones y gobernanza.
Muchos sistemas describen la relación mediante un circuito parecido a un programa. Aquí, un circuito es una abstracción de operaciones restringidas que el sistema de prueba puede comprobar; no es simplemente un programa de aplicación ordinario. La forma de escribir una relación, los campos que usa y las restricciones que aplica difieren entre construcciones. En consecuencia, una prueba trata de una relación precisa, no de una afirmación vaga sobre la realidad.
Este vocabulario también explica por qué una afirmación bien formulada es esencial. Si una relación omite una condición importante, una prueba puede seguir siendo válida para esa relación incompleta. La criptografía protege la integridad de la relación definida; no decide qué requisitos del mundo real debieron incluirse en ella.
Lo que el conocimiento cero oculta y lo que no oculta
La propiedad de conocimiento cero se refiere a lo que aprende un verificador al recibir o interactuar con una prueba. De manera informal, el verificador debe convencerse de que una afirmación es válida sin aprender el testigo más allá de lo que revela la propia afirmación. Los trabajos clásicos sobre sistemas interactivos de prueba formalizaron esta intuición al comparar la vista de un verificador real con una vista simulada que no usa el testigo.
Esa propiedad pertenece a un protocolo, no automáticamente a todas las capas de una aplicación circundante. Un sistema puede publicar deliberadamente una afirmación o una entrada pública, conservar registros, exponer un identificador o comunicarse por una red que transporte metadatos. Una prueba puede limitar la divulgación de un testigo mientras otras partes crean riesgos de privacidad distintos. Por ello, el análisis de privacidad debe considerar todo el flujo de información, no solo la presencia de una prueba de conocimiento cero.
El conocimiento cero tampoco vuelve pasivo al verificador. Este recibe suficiente material de prueba para ejecutar las comprobaciones prescritas. El protocolo está diseñado para que dicho material permita aceptar la afirmación sin revelar el testigo secreto de forma utilizable, sujeto a los supuestos y al alcance declarado de la construcción. Quien interprete el resultado de una prueba debe tener claro qué se revela intencionadamente.
El probador y el verificador
El probador es la parte o componente que posee el testigo y genera una prueba. El verificador recibe la afirmación pública, los parámetros públicos aplicables y los datos de prueba, y ejecuta después el procedimiento de verificación del sistema. Son funciones, no clases fijas de personas. Una aplicación puede organizarlas como servicios independientes, componentes locales o participantes de un entorno distribuido.
La generación y la verificación de pruebas cumplen fines distintos. El probador demuestra que puede satisfacer la relación usando el testigo. El verificador comprueba si la prueba se ajusta a la relación y a sus reglas de verificación. No tiene que reproducir el cálculo privado solo por haber recibido una prueba. La cantidad exacta de trabajo, material de prueba, interacción y configuración pública varía entre construcciones.
El contexto también importa. Una prueba válida para una afirmación no es automáticamente significativa para otra. Las versiones, entradas públicas, definiciones de relación y material de verificación pueden afectar la interpretación. Un sistema de prueba no puede determinar si un resultado técnico es apropiado para una decisión jurídica, científica, organizativa o social. Definir la relación y decidir cómo interpretarla sigue siendo responsabilidad de la aplicación.
Completitud, solidez y aceptación
Dos propiedades fundamentales ayudan a explicar por qué es útil verificar pruebas. La completitud indica, en términos generales, que un probador honesto con un testigo válido para una afirmación verdadera debería poder producir una prueba que acepte un verificador honesto. Sin completitud, un participante correcto podría ser rechazado aunque se hubiera satisfecho la relación.
La solidez aborda la dirección opuesta. A grandes rasgos, establece que un probador no debería poder lograr que un verificador acepte una afirmación falsa, salvo con la probabilidad limitada o bajo los supuestos especificados por el sistema. La solidez no es una propiedad universal de comprobación de hechos. Se aplica a una relación formal, un modelo de adversario y una definición de seguridad. No demuestra de manera independiente que las entradas se recogieron correctamente ni que una afirmación del mundo real no codificada sea cierta.
Algunas construcciones también tratan la solidez de conocimiento. En un nivel alto, el término vincula una prueba exitosa con la idea de que el probador posee o puede producir un testigo del tipo requerido. Su definición precisa es técnica y específica de cada construcción. No debe reformularse como si el probador conociera cada hecho contextual que un lector pudiera asociar con la afirmación pública.
Juntas, completitud y solidez dan a la aceptación un significado acotado: evidencia bien formada de una relación verdadera debe aceptarse, mientras que una relación falsa no debe aceptarse solo porque se afirme. No eliminan la necesidad de formular la relación adecuada, implementarla correctamente y evaluar el resultado en su contexto.
Generación y verificación de pruebas en contexto
En el plano conceptual, generar una prueba comienza con una afirmación pública, un testigo privado y una relación que los vincula. El probador realiza las operaciones prescritas por el sistema y produce datos de prueba. La verificación comienza con la afirmación pública, el material de verificación requerido y esos datos. El verificador devuelve aceptación o rechazo conforme al protocolo.
Los distintos sistemas eligen de forma diferente la interacción, la aleatoriedad, los parámetros públicos, los supuestos criptográficos y la representación de los cálculos. Algunos incluyen una fase de configuración que crea parámetros; otros se describen como transparentes porque evitan un participante secreto de configuración. Estas decisiones son importantes, pero las etiquetas por sí solas no establecen que una implementación completa tenga las propiedades de seguridad previstas.
Cuatro preguntas siguen siendo útiles en todos los sistemas: ¿qué afirmación exacta es pública?, ¿cuál es el testigo?, ¿qué material de verificación se presupone o se confía?, ¿qué establece la aceptación y qué deja sin resolver? Son preguntas pertinentes tanto si una prueba se conecta a un registro, una credencial, una base de datos u otro sistema de software.
SNARK y STARK como familias de sistemas de prueba
SNARK suele desarrollarse como «Succinct Non-interactive Argument of Knowledge». En términos generales, las construcciones SNARK buscan que un probador produzca una prueba compacta que un verificador pueda comprobar sin intercambio interactivo. «Argumento» tiene un sentido técnico: la seguridad descansa en supuestos computacionales, no en una garantía matemática incondicional. Las construcciones individuales pueden diferir en modelo de configuración, supuestos, representación de prueba y relaciones que admiten.
Investigaciones como el trabajo Pinocchio ilustran una estructura conocida de cómputo verificable: material público describe un cálculo, un ejecutor produce una prueba para una entrada determinada y un verificador revisa esa prueba. Ese ejemplo histórico no debe tratarse como definición de todo sistema posterior llamado SNARK. El término paraguas cubre ideas relacionadas, no una implementación uniforme.
STARK suele desarrollarse como «Scalable Transparent Argument of Knowledge». El término se asocia con construcciones que destacan la transparencia de su modelo de configuración y utilizan técnicas de prueba diferentes de los enfoques SNARK basados habitualmente en emparejamientos. La investigación original de STARK trata la integridad computacional transparente y un contexto de seguridad poscuántica. Esas descripciones se refieren a una construcción y sus supuestos; no hacen intercambiable cada implementación ni establecen un resultado universal.
La comparación más útil debe ser, por ello, específica. Considera los supuestos formales de una construcción, requisitos de configuración, representación de la relación, entorno de verificación, calidad de implementación y datos públicos. SNARK y STARK son mapas conceptuales, no conclusiones automáticas sobre la seguridad, privacidad o idoneidad de un sistema.
Alcance, límites y confianza circundante
Una prueba válida establece solo la afirmación representada por su relación. No muestra por sí misma que los datos subyacentes se recogieron de forma justa, que una fuente estaba autorizada, que ocurrió un hecho externo al sistema ni que la afirmación sigue vigente. Si una relación recibe entradas incompletas o engañosas, la verificación puede seguir siendo correcta respecto de esas entradas. La prueba protege un cálculo definido, no toda interpretación posible de su resultado.
El conocimiento cero tampoco elimina todas las consideraciones de privacidad. Las entradas públicas pueden revelar información; las presentaciones repetidas pueden crear asociaciones; y pueden existir metadatos de red, dispositivo, cuenta, interfaz y aplicación fuera de la prueba. Un diseño debe examinar estos canales directamente, en vez de tratar la prueba como una frontera completa de privacidad.
La seguridad práctica depende además de los supuestos matemáticos, el manejo de parámetros cuando corresponda, el software correcto y un verificador que evalúe la afirmación prevista. Fallos en cualquiera de estas capas pueden cambiar el resultado. Por eso, etiquetas breves como SNARK o STARK deben ser un punto de partida para una lectura cuidadosa, no un juicio final.
Al interpretar una afirmación de prueba, identifique la afirmación, el testigo, las entradas públicas, el probador, el verificador y el material de verificación. Después separe la aceptación técnica de la confianza más amplia: un verificador puede establecer que un resultado cumple las reglas del protocolo y aun así necesitar evaluar fuentes, definiciones, contexto y sus propias políticas. Esa distinción disciplinada muestra qué prueban realmente las pruebas de conocimiento cero y dónde permanecen sus límites.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Prueba de personalidad y resistencia a Sybil
- Transacciones privadas, shielded addresses y view keys
- Cómo se decide la elegibilidad para un airdrop: snapshots, puntos y filtros Sybil
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.
Fuentes
[1] Goldwasser, Micali and Rackoff: The Knowledge Complexity of Interactive Proof Systems people.csail.mit.edu
[2] IACR ePrint 2013/279: Pinocchio eprint.iacr.org
[3] IACR ePrint 2018/046: Scalable, transparent, and post-quantum secure computational integrity eprint.iacr.org
[4] W3C: Verifiable Credentials Data Model v2.0 w3.org
