Un protocolo de conocimiento cero es un método mediante el cual una parte (el probador) puede demostrar a otra parte (el verificador) que algo es cierto, sin revelar ninguna información aparte del hecho de que esta declaración específica es verdadera.

Las pruebas de conocimiento cero han mejorado con el paso de los años y ahora se están utilizando en varias aplicaciones del mundo real.

¿Por qué necesitamos pruebas de conocimiento cero?

Las pruebas de conocimiento cero representaron un avance en la criptografía aplicada, ya que prometieron mejorar la seguridad de la información para los individuos. Considere cómo podría demostrar una afirmación (por ejemplo, "Soy ciudadano del país X") a otra parte (por ejemplo, un proveedor de servicios). Necesitaría proporcionar "evidencia" para respaldar su afirmación, como un pasaporte nacional o una licencia de conducir.

Pero hay problemas con este enfoque, principalmente la falta de privacidad. La Información de Identificación Personal (PII) compartida con servicios de terceros se almacena en bases de datos centrales, que son vulnerables a piraterías. Con el robo de identidad convirtiéndose en un problema crítico, se pide medios de compartir información sensible que protejan más la privacidad.

Las pruebas de cero conocimiento resuelven este problema al eliminar la necesidad de revelar información para demostrar la validez de las afirmaciones. El protocolo de cero conocimiento utiliza la declaración (llamada 'testigo') como entrada para generar una prueba sucinta de su validez. Esta prueba proporciona garantías sólidas de que una declaración es verdadera sin exponer la información utilizada para crearla.

Volviendo a nuestro ejemplo anterior, la única evidencia que necesitas para demostrar tu reclamo de ciudadanía es una prueba de conocimiento cero. El verificador solo tiene que verificar si ciertas propiedades de la prueba son verdaderas para estar convencido de que la afirmación subyacente también es verdadera.

¿Cómo funcionan las pruebas de conocimiento cero?

Una prueba de conocimiento cero te permite demostrar la veracidad de una afirmación sin compartir el contenido de la afirmación o revelar cómo descubriste la verdad. Para hacer esto posible, los protocolos de conocimiento cero se basan en algoritmos que toman ciertos datos como entrada y devuelven 'verdadero' o 'falso' como salida.

Un protocolo de conocimiento cero debe cumplir con los siguientes criterios:

1. Completitud: Si la entrada es válida, el protocolo de conocimiento cero siempre devuelve 'verdadero'. Por lo tanto, si la afirmación subyacente es verdadera y el demostrador y el verificador actúan honestamente, la prueba puede ser aceptada.
2. Solidez: Si la entrada es inválida, es teóricamente imposible engañar al protocolo de conocimiento cero para que devuelva 'verdadero'. Por lo tanto, un probador mentiroso no puede engañar a un verificador honesto para que crea que una afirmación inválida es válida (excepto con un pequeño margen de probabilidad).
3. Conocimiento cero: El verificador no aprende nada sobre una declaración más allá de su validez o falsedad (tiene "conocimiento cero" de la declaración). Este requisito también impide que el verificador derive la entrada original (el contenido de la instrucción) de la prueba.

En su forma básica, una prueba de conocimiento nulo se compone de tres elementos: testigo, desafío y respuesta.

• Testigo: Con una prueba de conocimiento cero, el probador quiere demostrar conocimiento de alguna información oculta. La información secreta es el "testigo" de la prueba, y el conocimiento asumido del testigo por parte del probador establece un conjunto de preguntas que solo puede responder una parte con conocimiento de la información. Así, el probador inicia el proceso de prueba eligiendo aleatoriamente una pregunta, calculando la respuesta y enviándola al verificador.
• Desafío: El verificador elige al azar otra pregunta del conjunto y le pide al experto que la responda.
• Respuesta: El experto acepta la pregunta, calcula la respuesta y la devuelve al verificador. La respuesta del experto permite al verificador verificar si el primero realmente tiene acceso al testigo. Para asegurarse de que el experto no está adivinando a ciegas y obteniendo las respuestas correctas por casualidad, el verificador selecciona más preguntas para hacer. Al repetir esta interacción muchas veces, la posibilidad de que el experto simule conocimiento del testigo disminuye significativamente hasta que el verificador esté satisfecho.

Lo anterior describe la estructura de una 'prueba interactiva de conocimiento cero'. Los protocolos tempranos de conocimiento cero usaban pruebas interactivas, donde verificar la validez de una declaración requería comunicación de ida y vuelta entre probadores y verificadores.

Un buen ejemplo que ilustra cómo funcionan las pruebas interactivas es la famosa de Jean-Jacques Quisquater Historia de la cueva de Ali Baba

(se abre en una nueva pestaña)

. En la historia, Peggy (el probador) quiere demostrar a Víctor (el verificador) que ella conoce la frase secreta para abrir una puerta mágica sin revelar la frase.

Pruebas de conocimiento cero no interactivas

Si bien revolucionaria, la demostración interactiva tenía una utilidad limitada ya que requería que las dos partes estuvieran disponibles e interactuaran repetidamente. Incluso si un verificador estaba convencido de la honestidad de un probador, la prueba no estaría disponible para verificación independiente (calcular una nueva prueba requería un nuevo conjunto de mensajes entre el probador y el verificador).

Para resolver este problema, Manuel Blum, Paul Feldman y Silvio Micali sugirieron el primero pruebas de conocimiento cero no interactivas

(se abre en una nueva pestaña)

donde el experto y el verificador tienen una clave compartida. Esto permite al experto demostrar su conocimiento de cierta información (es decir, testigo) sin proporcionar la información en sí misma.

A diferencia de las pruebas interactivas, las pruebas no interactivas requieren solo una ronda de comunicación entre los participantes (probador y verificador). El probador pasa la información secreta a un algoritmo especial para calcular una prueba de conocimiento nulo. Esta prueba se envía al verificador, quien verifica que el probador conoce la información secreta mediante otro algoritmo.

La demostración no interactiva reduce la comunicación entre el probador y el verificador, lo que hace que las pruebas de conocimiento cero sean más eficientes. Además, una vez que se genera una prueba, está disponible para cualquier otra persona (con acceso a la clave compartida y al algoritmo de verificación) para verificar.

Las pruebas no interactivas representaron un avance para la tecnología de conocimiento cero y estimularon el desarrollo de los sistemas de demostración utilizados hoy en día. Discutimos estos tipos de pruebas a continuación:

Tipos de pruebas de conocimiento cero

ZK-SNARKs

ZK-SNARK es un acrónimo de Argumento de Conocimiento Sucinto No Interactivo de Conocimiento Cero. El protocolo ZK-SNARK tiene las siguientes cualidades:

• Zero-conocimiento: Un verificador puede validar la integridad de una afirmación sin saber nada más sobre la afirmación. El único conocimiento que tiene el verificador de la afirmación es si es verdadera o falsa.
• Succinct: La prueba de conocimiento cero es más pequeña que el testigo y se puede verificar rápidamente.
• No interactivo: La prueba es 'no interactiva' porque el probador y el verificador solo interactúan una vez, a diferencia de las pruebas interactivas que requieren múltiples rondas de comunicación.
• Argumento: La prueba satisface el requisito de 'corrección', por lo que hacer trampa es extremadamente improbable.
• (De) Conocimiento: La prueba de conocimiento nulo no se puede construir sin acceso a la información secreta (testigo). Es difícil, si no imposible, para un experto que no tiene el testigo calcular una prueba de conocimiento nulo válida.

La 'clave compartida' mencionada anteriormente se refiere a parámetros públicos en los que el demostrador y el verificador acuerdan usar en la generación y verificación de pruebas. La generación de los parámetros públicos (conocidos colectivamente como la Cadena de Referencia Común (CRS)) es una operación sensible debido a su importancia en la seguridad del protocolo. Si la entropía (aleatoriedad) utilizada en la generación del CRS cae en manos de un demostrador deshonesto, pueden calcular pruebas falsas.

Computación multipartita (MPC)

(se abre en una nueva pestaña)

es una forma de reducir los riesgos en la generación de parámetros públicos. Varios participantes intervienen en una ceremonia de configuración confiable

(se abre en una nueva pestaña)

, donde cada persona contribuye algunos valores aleatorios para generar el CRS. Mientras una parte honesta destruya su porción de la entropía, el protocolo ZK-SNARK conserva la solidez computacional.

Las configuraciones de confianza requieren que los usuarios confíen en los participantes en la generación de parámetros. Sin embargo, el desarrollo de ZK-STARKs ha permitido protocolos de demostración que funcionan con una configuración no confiable.

ZK-STARKs

ZK-STARK es un acrónimo de Argumento Transparente Escalable de Conocimiento de Cero-Conocimiento. ZK-STARKs son similares a ZK-SNARKs, excepto que son:

• Escalable: ZK-STARK es más rápido que ZK-SNARK en la generación y verificación de pruebas cuando el tamaño del testigo es mayor. Con las pruebas STARK, los tiempos de prueba y verificación solo aumentan ligeramente a medida que el testigo crece (los tiempos de prueba y verificación de SNARK aumentan linealmente con el tamaño del testigo).
• Transparente: ZK-STARK se basa en la aleatoriedad públicamente verificable para generar parámetros públicos para la demostración y verificación en lugar de una configuración confiable. Por lo tanto, son más transparentes en comparación con ZK-SNARKs.

ZK-STARKs producen pruebas más grandes que ZK-SNARKs, lo que significa que generalmente tienen costos de verificación más altos. Sin embargo, hay casos (como probar conjuntos de datos grandes) donde ZK-STARKs pueden ser más rentables que ZK-SNARKs.

Casos de uso para pruebas de conocimiento cero

Pagos anónimos

Los pagos con tarjeta de crédito a menudo son visibles para múltiples partes, incluyendo el proveedor de pagos, los bancos y otras partes interesadas (por ejemplo, las autoridades gubernamentales). Si bien la vigilancia financiera tiene beneficios para identificar actividades ilegales, también socava la privacidad de los ciudadanos comunes.

Las criptomonedas se pretendían proporcionar un medio para que los usuarios realicen transacciones privadas de igual a igual. Pero la mayoría de las transacciones de criptomonedas son abiertamente visibles en cadenas de bloques públicas. Las identidades de los usuarios a menudo son seudónimas y están vinculadas intencionalmente a identidades del mundo real (por ejemplo, incluyendo direcciones de ETH en perfiles de Twitter o GitHub) o pueden estar asociadas a identidades del mundo real utilizando un análisis de datos básico dentro y fuera de la cadena.

Existen “monedas de privacidad” específicas diseñadas para transacciones completamente anónimas. Blockchains centradas en la privacidad, como Zcash y Monero, protegen los detalles de la transacción, incluidas las direcciones del remitente/receptor, el tipo de activo, la cantidad y la línea temporal de la transacción.

Al hornear la tecnología de conocimiento cero en el protocolo, las redes blockchain centradas en la privacidad permiten a los nodos validar transacciones sin necesidad de acceder a los datos de transacción.

Las pruebas de conocimiento cero también se aplican para anonimizar transacciones en blockchains públicos. Un ejemplo es Tornado Cash, un servicio descentralizado y no custodial que permite a los usuarios realizar transacciones privadas en Ethereum. Tornado Cash utiliza pruebas de conocimiento cero para ofuscar los detalles de la transacción y garantizar la privacidad financiera. Desafortunadamente, debido a que estas son herramientas de privacidad "opt-in", se asocian con actividades ilícitas. Para superar esto, la privacidad eventualmente tiene que convertirse en la opción predeterminada en blockchains públicos.

Protección de la identidad

Los sistemas actuales de gestión de identidades ponen en riesgo la información personal. Las pruebas de conocimiento cero pueden ayudar a las personas a validar la identidad mientras protegen detalles sensibles.

Las pruebas de conocimiento cero son particularmente útiles en el contexto de identidad descentralizada. La identidad descentralizada (también descrita como 'identidad soberana') le da al individuo la capacidad de controlar el acceso a los identificadores personales. Demostrar su ciudadanía sin revelar su número de identificación fiscal o detalles del pasaporte es un buen ejemplo de cómo la tecnología de conocimiento cero permite la identidad descentralizada.

Autenticación

Usar servicios en línea requiere demostrar tu identidad y tu derecho de acceder a esas plataformas. A menudo, esto requiere proporcionar información personal, como nombres, direcciones de correo electrónico, fechas de nacimiento, y así sucesivamente. También puede que necesites memorizar contraseñas largas o arriesgarte a perder el acceso.

Las pruebas de conocimiento cero, sin embargo, pueden simplificar la autenticación tanto para plataformas como para usuarios. Una vez que se ha generado una prueba de ZK utilizando entradas públicas (por ejemplo, datos que atestiguan la membresía del usuario en la plataforma) y entradas privadas (por ejemplo, los detalles del usuario), el usuario simplemente puede presentarlo para autenticar su identidad cuando necesite acceder al servicio. Esto mejora la experiencia para los usuarios y libera a las organizaciones de la necesidad de almacenar grandes cantidades de información de usuario.

Cómputo verificable

La computación verificable es otra aplicación de la tecnología de conocimiento cero para mejorar los diseños de blockchain. La computación verificable nos permite externalizar el cálculo a otra entidad manteniendo resultados verificables. La entidad envía el resultado junto con una prueba que verifica que el programa se ejecutó correctamente.

La computación verificable es fundamental para mejorar la velocidad de procesamiento en blockchains sin reducir la seguridad. Comprender esto requiere conocer las diferencias en las soluciones propuestas para escalar Ethereum.

Soluciones de escalado en cadena, como el particionamiento, requieren una extensa modificación de la capa base del blockchain. Sin embargo, este enfoque es altamente complejo y los errores en la implementación pueden socavar el modelo de seguridad de Ethereum.

Soluciones de escalabilidad fuera de la cadenano requieren rediseñar el protocolo central de Ethereum. En cambio, confían en un modelo de cálculo externalizado para mejorar el rendimiento en la capa base de Ethereum.

Aquí es cómo funciona en la práctica:

• En lugar de procesar cada transacción, Ethereum transfiere la ejecución a una cadena separada.
• Después de procesar las transacciones, la otra cadena devuelve los resultados que se aplicarán al estado de Ethereum.

El beneficio aquí es que Ethereum no tiene que hacer ninguna ejecución y solo necesita aplicar los resultados de la computación externalizada a su estado. Esto reduce la congestión de la red y también mejora la velocidad de las transacciones (los protocolos fuera de la cadena se optimizan para una ejecución más rápida).

La cadena necesita una forma de validar transacciones fuera de la cadena sin volver a ejecutarlas, de lo contrario se pierde el valor de la ejecución fuera de la cadena.

Aquí es donde entra en juego la computación verificable. Cuando un nodo ejecuta una transacción fuera de Ethereum, envía una prueba de conocimiento cero para demostrar la corrección de la ejecución fuera de la cadena. Esta prueba (llamada una

garantiza que una transacción es válida, lo que permite a Ethereum aplicar el resultado a su estado, sin tener que esperar a que nadie lo dispute.

Rollups de conocimiento ceroyvalidiumsson dos soluciones de escalabilidad fuera de la cadena que utilizan pruebas de validez para proporcionar escalabilidad segura. Estos protocolos ejecutan miles de transacciones fuera de la cadena y envían pruebas para su verificación en Ethereum. Esos resultados pueden aplicarse inmediatamente una vez que se verifica la prueba, lo que permite que Ethereum procese más transacciones sin aumentar la computación en la capa base.

Reducir el soborno y la colusión en la votación en cadena

Los esquemas de votación basados en blockchain tienen muchas características favorables: son completamente auditables, seguros contra ataques, resistentes a la censura y libres de restricciones geográficas. Pero incluso los esquemas de votación en cadena no son inmunes al problema de la colusión.

Definida como "coordinar para limitar la competencia abierta engañando, defraudando y engañando a otros", la colusión puede tomar la forma de un actor malicioso que influye en la votación ofreciendo sobornos. Por ejemplo, Alice podría recibir un soborno de Bob para votar por la opción B en una boleta incluso si prefiere la opción A.

El soborno y la colusión limitan la efectividad de cualquier proceso que utilice la votación como mecanismo de señalización (especialmente cuando los usuarios pueden demostrar cómo votaron). Esto puede tener consecuencias significativas, especialmente cuando los votos son responsables de asignar recursos escasos.

Por ejemplo, mecanismos de financiación cuadrática

(abre en una nueva pestaña)

confiar en las donaciones para medir la preferencia por ciertas opciones entre diferentes proyectos de bienes públicos. Cada donación cuenta como un "voto" para un proyecto específico, con los proyectos que reciben más votos obteniendo más fondos del fondo de emparejamiento.

El uso de la votación on-chain hace que la financiación cuadrática sea susceptible a la colusión: las transacciones de blockchain son públicas, por lo que los sobornadores pueden inspeccionar la actividad on-chain de un sobornador para ver cómo "votó". De esta manera, la financiación cuadrática deja de ser un medio eficaz para asignar fondos en función de las preferencias agregadas de la comunidad.

Afortunadamente, soluciones más recientes como MACI (Infraestructura Mínima Anti-Colusión) están utilizando pruebas de conocimiento cero para hacer que la votación en cadena (por ejemplo, mecanismos de financiación cuadráticos) sea resistente a la corrupción y la colusión. MACI es un conjunto de contratos inteligentes y scripts que permiten a un administrador central (llamado un “coordinador”) agregar votos y contabilizar resultados sin revelar detalles sobre cómo votó cada individuo. Aun así, sigue siendo posible verificar que los votos fueron contados correctamente, o confirmar que un individuo en particular participó en la ronda de votación.

¿Cómo funciona MACI con pruebas de conocimiento cero?

Al principio, el coordinador implementa el contrato MACI en Ethereum, después de lo cual los usuarios pueden registrarse para votar (registrando su clave pública en el contrato inteligente). Los usuarios emiten votos enviando mensajes cifrados con su clave pública al contrato inteligente (un voto válido debe estar firmado con la clave pública más reciente asociada a la identidad del usuario, entre otros criterios). Posteriormente, el coordinador procesa todos los mensajes una vez que termina el período de votación, totaliza los votos y verifica los resultados en la cadena.

En MACI, se utilizan pruebas de conocimiento cero para garantizar la corrección de la computación al hacer imposible que el coordinador procese incorrectamente votos y totalice resultados. Esto se logra al requerir que el coordinador genere pruebas ZK-SNARK que verifiquen que a) todos los mensajes fueron procesados correctamente y b) el resultado final corresponde a la suma de todos los votos válidos.

Por lo tanto, incluso sin compartir un desglose de votos por usuario (como suele ser el caso), MACI garantiza la integridad de los resultados calculados durante el proceso de recuento. Esta característica es útil para reducir la efectividad de esquemas básicos de colusión. Podemos explorar esta posibilidad utilizando el ejemplo anterior de Bob sobornando a Alice para que vote por una opción:

• Alice se registra para votar enviando su clave pública a un contrato inteligente.
• Alice acepta votar por la opción B a cambio de un soborno de Bob.
• Alice vota por la opción B.
• Alice envía secretamente una transacción encriptada para cambiar la clave pública asociada con su identidad.
• Alice envía otro mensaje (encriptado) al contrato inteligente votando por la opción A usando la nueva clave pública.
• Alice muestra a Bob una transacción que muestra que votó por la opción B (lo cual es inválido ya que la clave pública ya no está asociada con la identidad de Alice en el sistema)
• Mientras procesa los mensajes, el coordinador omite el voto de Alice por la opción B y cuenta solo el voto por la opción A. Por lo tanto, el intento de Bob de coludir con Alice y manipular la votación en cadena falla.

Usar MACI requiere confiar en el coordinador para que no colabore con sobornadores o intente sobornar a los votantes ellos mismos. El coordinador puede descifrar los mensajes de los usuarios (necesario para crear la prueba), por lo que puede verificar con precisión cómo votó cada persona.

Pero en los casos en los que el coordinador siga siendo honesto, MACI representa una herramienta poderosa para garantizar la santificación de la votación en cadena. Esto explica su popularidad entre las aplicaciones de financiamiento cuadrático (por ejemplo, clr.fund

(se abre en una nueva pestaña)

) que dependen en gran medida de la integridad de las decisiones de voto de cada individuo.

Obtenga más información sobre MACI

(se abre en una nueva pestaña)

.

Desventajas de usar pruebas de conocimiento cero

Costos de hardware

Generar pruebas de conocimiento cero implica cálculos muy complejos que se realizan mejor en máquinas especializadas. Dado que estas máquinas son costosas, a menudo están fuera del alcance de las personas comunes. Además, las aplicaciones que desean utilizar la tecnología de conocimiento cero deben tener en cuenta los costos de hardware, lo que puede aumentar los costos para los usuarios finales.

Costos de verificación de prueba

Verificar las pruebas también requiere una computación compleja y aumenta los costos de implementar la tecnología de conocimiento cero en aplicaciones. Este costo es particularmente relevante en el contexto de la computación de prueba. Por ejemplo, ZK-rollups pagan ~ 500,000 gas para verificar una sola prueba ZK-SNARK en Ethereum, con ZK-STARKs que requieren incluso tarifas más altas.

Supuestos de confianza

En ZK-SNARK, la Cadena de Referencia Común (parámetros públicos) se genera una vez y está disponible para su reutilización por parte de las partes que deseen participar en el protocolo de conocimiento cero. Los parámetros públicos se crean a través de una ceremonia de configuración confiable, donde se asume que los participantes son honestos.

Pero realmente no hay forma para que los usuarios evalúen la honestidad de los participantes y los usuarios tienen que confiar en la palabra de los desarrolladores. Los ZK-STARKs están libres de suposiciones de confianza ya que la aleatoriedad utilizada en la generación de la cadena es públicamente verificable. Mientras tanto, los investigadores están trabajando en configuraciones no confiables para ZK-SNARKs para aumentar la seguridad de los mecanismos de demostración.

Amenazas de computación cuántica

ZK-SNARK utiliza criptografía de curva elíptica

ECDSA) para encriptación. Aunque el algoritmo ECDSA es seguro por ahora, el desarrollo de computadoras cuánticas podría romper su modelo de seguridad en el futuro.

ZK-STARK se considera inmune a la amenaza de la computación cuántica, ya que utiliza hashes resistentes a colisiones para el cifrado. A diferencia de los emparejamientos de clave pública-privada utilizados en la criptografía de curva elíptica, el hashing resistente a colisiones es más difícil de romper para los algoritmos de computación cuántica.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [Ethereum]. Todos los derechos de autor pertenecen al autor original [Ethereum]. If there are objections to this reprint, please contact the Gate Learnequipo, y ellos lo resolverán rápidamente.
2. Renuncia de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.