Reenviar el título original 'Un paradigma de conocimiento cero: Parte 1 - ¿Qué es un zk-VM?'

1. Pruebas de conocimiento cero: una introducción

¿Qué son las pruebas de conocimiento cero (ZKP)?

Si no tienes conocimientos previos de pruebas de conocimiento cero (ZKP), este vídeo de Wired explica el concepto en cinco niveles de dificultad de forma interactiva con ejemplos y demostraciones fácilmente comprensibles. Muy recomendable.

En términos más simples, los ZKP permiten a una parte (el probador) demostrar a otra parte (el verificador) que sabe algo sin revelar qué es esa cosa o cualquier información adicional. Más específicamente, los ZKP prueban el conocimiento de un dato, o el conocimiento del resultado de un cálculo, sin revelar los datos o las entradas. El proceso de creación de una prueba de conocimiento cero implica una serie de modelos matemáticos para transformar los resultados de un cálculo en una pieza de información que de otro modo no tendría sentido y que demuestre la ejecución exitosa del código, que luego se puede verificar.

En algunos casos, se necesita menos trabajo para verificar la prueba, que se construye después de múltiples rondas de conversiones algebraicas y criptografía, que para ejecutar el cálculo. Esta combinación única de seguridad y escalabilidad es lo que hace que la criptografía de conocimiento cero sea una herramienta tan poderosa.

zkSNARKs: Argumento sucinto no interactivo de conocimiento cero

• Se basa en un proceso de configuración inicial (de confianza o no de confianza) para establecer parámetros para la verificación
• Requiere al menos una interacción entre el probador y el verificador
• Los tamaños de prueba son pequeños y fáciles de verificar
• Las pruebas basadas en NARK son utilizadas por rollups como zkSync, Scroll y Linea

zkSTARKs: Argumento de Conocimiento Transparente Escalable de Conocimiento Cero

• No se requiere una configuración de confianza
• Ofrecer una alta transparencia mediante el uso de la aleatoriedad verificable públicamente para crear sistemas verificables sin confianza, es decir, generar parámetros aleatorios demostrables para probar y verificar
• Altamente escalables, ya que pueden generar y verificar pruebas rápidamente (no siempre), incluso cuando el tamaño del testigo subyacente (datos) es grande
• No requiere interacción entre el probador y el verificador
• Tiene el costo de que los STARK generan pruebas más grandes, que pueden ser más difíciles de verificar que los SNARK
• Las pruebas son más difíciles de verificar que algunas pruebas de zkSNARK, pero no tanto como otras
• Los STARK son utilizados por Starknet, así como por zkVM como Lita, Risc Zero y Succinct Labs

(Nota: El puente de Succinct utiliza SNARKs, pero SP1 es un protocolo basado en STARK)

Vale la pena señalar que todos los STARK son SNARK, pero no todos los SNARK son STARK.

Para una mejor comprensión general de SNARKs y STARKs, recomendamos leer esta serie de artículos @krzhang/privacy-in-cryptocurrencies-zero-knowledge-and-zk-snarks-1-2-68ce1838fd9c">article escrita por Yan Zhang y Yi Sun de Axiom, y esta colección de artículos en el github de Ventali Tan.

2. ¿Qué es una zkVM?

Una máquina virtual (VM) es un programa que ejecuta programas. En contexto, una zkVM es una computadora virtual que se implementa como un sistema para generar pruebas de conocimiento cero, o un circuito universal, o herramienta, para generar ZKP para cualquier programa o cálculo.

Las zkVM eliminan la necesidad de aprender matemáticas y criptografía complicadas para diseñar y codificar ZK, y permiten a cualquier desarrollador ejecutar programas escritos en sus lenguajes preferidos y generar ZKP, lo que facilita mucho la integración e interacción con cero conocimiento. En términos generales, la mayoría de las referencias a zkVM incluyen implícitamente las cadenas de herramientas del compilador y los sistemas de prueba anexados a la máquina virtual que ejecuta los programas, y no solo a la máquina virtual en sí. A continuación, resumimos los principales componentes de una zkVM y sus funciones:

Los componentes principales de una zkVM

El diseño y la implementación de cada componente se rigen por la elección de la prueba (SNARK o STARK) y la arquitectura del conjunto de instrucciones (ISA) de zkVM. Tradicionalmente, un ISA especifica lo que una CPU es capaz de hacer (tipos de datos, registros, memoria, etc.) y la secuencia de acciones que realiza la CPU cuando ejecuta un programa. En contexto, el ISA determina el código máquina que la máquina virtual puede interpretar y ejecutar. La elección de un ISA puede producir diferencias radicales en la accesibilidad y usabilidad de la zkVM, así como en la velocidad y eficiencia de los procesos de generación de pruebas, y sustenta la construcción de cualquier zkVM.

A continuación se muestran algunos ejemplos de zkVM y sus componentes para su referencia.

zkVMs y sus componentes

Por ahora, nos centraremos en las interacciones entre cada componente a un alto nivel para proporcionar un marco para comprender los procesos algebraicos y criptográficos, así como las compensaciones de diseño de una zkVM en un artículo posterior.

3. Flujo de proceso de zkVM abstraído

El siguiente diagrama es un diagrama de flujo de proceso abstracto y generalizado de una zkVM, dividido y categorizado entre el formato (entradas/salidas) de un programa a medida que se mueve a través de los componentes de una zkVM. Examinaremos cada proceso en profundidad en artículos posteriores.

Flujo general para una zkVM

El flujo de proceso de una zkVM es generalmente el siguiente:

• Fase del compilador

1. El compilador primero compila programas escritos en lenguajes convencionales (C, C++, Rust, Solidity) en código máquina. El formato del código máquina está dictado por la elección del ISA.

• Etapa de VM

1. La máquina virtual ejecuta el código máquina y genera un seguimiento de ejecución, que es la serie de pasos del programa subyacente. El formato de esto está predeterminado por la elección de la aritmética, así como por el conjunto de restricciones polinómicas. Los esquemas de aritmética comunes incluyen R1CS como en Groth16, aritmética PLONKish como en halo2 y AIR como en plonky2 y plonky3.

• Etapa de prueba

1. El probador recibe la traza y la representa como un conjunto de polinomios unidos por un conjunto de restricciones, esencialmente traduciendo el cálculo en álgebra mediante el mapeo de los hechos matemáticamente.

2. El probador se compromete con estos polinomios mediante un esquema de compromiso polinómico (PCS). Un esquema de compromiso es un protocolo que permite al probador crear una huella digital de algunos datos X, lo que se denomina compromiso con X, y luego probar hechos sobre X sin revelar X, utilizando el compromiso con X. El PCS es la huella dactilar; Una versión sucinta "preprocesada" de las restricciones en el cálculo. Esto permite al probador probar hechos sobre el cálculo, ahora expresados en una ecuación polinómica, utilizando valores aleatorios propuestos por el verificador en los siguientes pasos.

3. El probador ejecuta una prueba de oráculo interactiva polinómica (PIOP) para mostrar que los polinomios confirmados representan un seguimiento de ejecución que satisface las restricciones dadas. Un PIOP es un protocolo de prueba interactivo que consiste en una serie de rondas en las que el probador envía compromisos a polinomios, el verificador responde con valores de campo aleatorios y el probador proporciona evaluaciones del polinomio a estos valores aleatorios, similar a "resolver" la ecuación polinómica utilizando valores aleatorios para persuadir probabilísticamente al verificador.

4. Aplicando la heurística Fiat-Shamir; el probador ejecuta el PIOP en un modo no interactivo, donde el comportamiento del verificador se limita al envío de puntos de desafío pseudoaleatorios. En criptografía, la heurística Fiat-Shamir convierte una prueba interactiva de conocimiento en una firma digital para su verificación. Este paso encripta la prueba y la convierte en conocimiento cero.

5. El probador debe convencer al verificador de que las evaluaciones polinómicas reivindicadas son correctas, con respecto a los compromisos polinómicos que envió al verificador. Para ello, el probador produce una prueba de "evaluación" o "apertura", que es proporcionada por el esquema de compromiso polinómico (huella dactilar).

• Etapa del verificador

1. El verificador verifica la prueba siguiendo el protocolo de verificación del sistema de prueba, ya sea utilizando las restricciones o el compromiso. El verificador acepta o rechaza el resultado en función de la validez de la prueba.

En resumen, una prueba de zkVM demuestra, para un programa dado, un resultado dado y condiciones iniciales dadas, que hay alguna entrada que hace que el programa produzca el resultado dado cuando se ejecuta a partir de las condiciones iniciales dadas. Podemos combinar esta declaración con el flujo del proceso para llegar a la siguiente descripción de una zkVM.

Una prueba de zkVM demuestra, para un programa de VM dado y una salida dada, que hay alguna entrada que hace que el programa dado produzca la salida dada cuando se ejecuta en la VM.

4. Evaluación de zkVMs

¿Cuáles son los criterios por los que debemos evaluar las zkVMs? En otras palabras, ¿cuándo deberíamos decir que una zkVM es mejor que otra? A decir verdad, la respuesta depende del caso de uso.

La investigación de mercado de Lita sugiere que para la mayoría de los casos de uso comercial, las propiedades más importantes, fuera de velocidad, eficiencia y concisión, son la velocidad o la eficiencia en el tiempo del núcleo, dependiendo de la aplicación. Algunas aplicaciones son sensibles al precio y desean optimizar el bajo consumo de energía y el bajo uso de capital en la demostración; Para estos, la eficiencia del tiempo central es probablemente la métrica más importante para optimizar. Otras aplicaciones, en particular las relacionadas con las finanzas o el comercio, son sensibles a la latencia y desean optimizar la velocidad.

La mayoría de las comparaciones de rendimiento publicitadas se centran exclusivamente en la velocidad, que es importante pero no una medida holística del rendimiento. También hay algunas propiedades importantes que miden la confiabilidad de una zkVM; La mayoría de los cuales no están a la altura de los estándares de producción, incluso para los operadores tradicionales líderes en el mercado.

Por la presente, proponemos que las zkVM se evalúen según los siguientes criterios, separados en dos subconjuntos:

Principales criterios para evaluar zk-VMs

Línea de base: mide la confiabilidad de las zkVM

• Corrección
• Seguridad
• Supuestos de confianza

Rendimiento: mide las capacidades de una zkVM

• Eficacia
• Velocidad
• Concisión

4.1 Línea de base: Supuestos de corrección, seguridad y confianza

Al evaluar zkVM para aplicaciones de misión crítica, la corrección y la seguridad deben considerarse como línea de base. Es necesario que haya razones suficientes para confiar en la exactitud y una seguridad reclamada suficientemente fuerte. Además, los supuestos de confianza deben ser lo suficientemente débiles para la aplicación.

Sin estas propiedades, zkVM es potencialmente peor que inútil para la aplicación, ya que puede no funcionar según lo especificado y exponer a los usuarios a piratería y exploits.

i. Corrección

• La máquina virtual debe ejecutar el cálculo según lo previsto
• El sistema de prueba debe satisfacer sus propiedades de seguridad declaradas

La corrección se compone de tres propiedades:

• Solidez: El sistema de prueba es veraz y, por lo tanto, todo lo que prueba es cierto. El verificador rechaza las pruebas de declaraciones falsas; Solo acepta el resultado de un cálculo si las entradas realmente producen ese resultado.
• Integridad: El sistema de prueba es completo y puede probar todas las afirmaciones verdaderas. Si el probador afirma que puede probar el resultado de un cálculo, debe ser capaz de producir una prueba que el verificador acepte.
• Conocimiento cero: Poseer una prueba no revela más sobre las entradas del cálculo que conocer el resultado en sí mismo

Se puede tener plenitud sin solidez; Si el sistema de prueba prueba todo, incluida la falsedad, obviamente es completo pero no sólido. Inversamente, se puede tener solidez sin completitud; Si el sistema de prueba prueba que un programa existió, pero no puede probar los cálculos, obviamente es sólido (después de todo, nunca prueba ninguna falsedad), pero no completo.

ii. Seguridad

• Se relaciona con las tolerancias de solidez, completitud y conocimiento cero

En la práctica, las tres propiedades de corrección tienen tolerancias distintas de cero. Esto implica que todas las pruebas son probabilidades estadísticas de exactitud, y no certezas absolutas. Una tolerancia se refiere a la probabilidad máxima tolerable de que se produzca un error en una propiedad. Las tolerancias cero son, por supuesto, lo ideal, pero las zkVM no logran tolerancias cero en todas estas propiedades en la práctica. La perfecta solidez y completitud parecen ser incompatibles con la concisión, y no hay métodos conocidos para lograr el conocimiento cero perfecto. Una forma común de medir la seguridad es en bits de seguridad, donde una tolerancia de 1 / (2^n) se denomina n bits de seguridad. Más bits de seguridad es mejor.

Si una zkVM es perfectamente correcta, eso no implica necesariamente que sea confiable. La corrección solo implica que la zkVM satisface sus propiedades de seguridad hasta las tolerancias declaradas. Esto no implica que las tolerancias declaradas sean lo suficientemente bajas como para estar listas para el mercado. Además, si una zkVM es lo suficientemente segura, eso no implica que sea correcta; La seguridad se refiere a las tolerancias declaradas, no a las tolerancias que realmente se alcanzan. Solo cuando una zkVM es perfectamente correcta y suficientemente segura se puede decir que la zkVM es fiable hasta las tolerancias declaradas.

iii. Supuestos de confianza

• Suposiciones sobre la honestidad del probador y verificador para llegar a la conclusión de que zkVM funciona de manera confiable

Cuando las zkVM tienen suposiciones de confianza, esto suele tomar la forma de un proceso de configuración de confianza. Un proceso de configuración para un sistema de prueba ZK se ejecuta una vez, antes de que se genere la primera prueba utilizando el sistema de prueba, con el fin de generar cierta información llamada "los datos de configuración". En un proceso de configuración de confianza, uno o más individuos generan cierta aleatoriedad que se incorpora a los datos de configuración, y se debe suponer que al menos uno de esos individuos eliminó la aleatoriedad que incorporaron a los datos de configuración.

En la práctica, existen dos modelos comunes de asunción de confianza.

Una suposición honesta de confianza mayoritaria establece que de un conjunto de N individuos, más de N/2 de esos individuos exhibieron integridad en alguna interacción particular con el sistema, que es comúnmente utilizado por las cadenas de bloques

Una suposición de confianza de "1 de N" establece que de un conjunto de N individuos, al menos uno de esos individuos exhibió integridad en alguna interacción particular con el sistema, que es comúnmente utilizado por herramientas y aplicaciones basadas en MPC.

En general, se acepta que, en igualdad de condiciones, las zkVM sin suposiciones de confianza son más seguras que las zkVM que requieren suposiciones de confianza.

4.2 El trilema de zkVM: equilibrio entre la velocidad, la eficiencia y la concisión en zkVM

El trilema de zkVM: velocidad, eficiencia y concisión

La velocidad, la eficiencia y la concisión son propiedades de escala móvil. Todos estos factores contribuyen al coste de zkVM para el usuario final. La forma en que deben ponderarse en una evaluación depende de la aplicación. A menudo, la solución más rápida no es la más eficiente ni la más sucinta; La solución más sucinta no es la más rápida ni la más eficiente; y así sucesivamente. Definamos primero cada propiedad antes de explicar su relación

i. Velocidad

• ¿Con qué rapidez puede el probador generar pruebas?
• Medido en tiempo de reloj de pared, que es el tiempo transcurrido desde el principio hasta el final del cómputo

La velocidad debe definirse y medirse en relación con programas, entradas y sistemas de prueba específicos para garantizar que se pueda evaluar cuantitativamente. Esta métrica es fundamental para las aplicaciones sensibles a la latencia, en las que la disponibilidad rápida de las pruebas es esencial, pero conlleva una mayor sobrecarga y un mayor tamaño de las pruebas

ii. Eficiencia

• Los recursos consumidos por el probador, siendo preferiblemente menos
• Se puede aproximar por el tiempo del usuario, que es la cantidad de tiempo de computadora gastado por el código del programa

El probador consume dos tipos de recursos: tiempo de núcleo y espacio. Por lo tanto, la eficiencia se puede subdividir en eficiencia en tiempo central y eficiencia en espacio.

Eficiencia en tiempo de núcleo: Cantidad media de tiempo que el probador opera en todos los núcleos multiplicada por el número de núcleos que ejecutan el probador. Para un probador de un solo núcleo, el consumo de tiempo de núcleo y la velocidad son lo mismo. Para un probador con capacidad multinúcleo que se ejecuta en modo multinúcleo en un sistema multinúcleo, el consumo de tiempo de núcleo y la velocidad no son lo mismo. Si un programa utiliza completamente 5 núcleos o hilos durante 5 segundos, eso sería 25 segundos de tiempo de usuario y 5 segundos de tiempo de reloj de pared.

Eficiencia del espacio: se refiere a la capacidad de almacenamiento utilizada, como la memoria RAM

El tiempo del usuario es interesante como indicador de la energía consumida al ejecutar un cálculo. En una situación en la que todos los núcleos se utilizan por completo casi todo el tiempo, el consumo de energía de una CPU debe permanecer relativamente constante. En esta situación, el tiempo de usuario empleado por una ejecución de código enlazada a la CPU, predominantemente en modo de usuario, debe ser aproximadamente proporcional linealmente al número de vatios-hora (es decir, energía) consumidos por esa ejecución de código.

Economizar en el consumo de energía, o el uso de recursos informáticos, debería ser interesante desde el punto de vista de cualquier operación de prueba que tenga la escala suficiente como para que su factura de energía (o su factura de computación en la nube) para probar sea un costo operativo considerable. Por estas razones, el tiempo de usuario es una métrica interesante. Los costos de prueba más bajos permiten a los proveedores de servicios trasladar los precios de prueba más bajos a los clientes sensibles a los costos.

Ambos tipos de eficiencia están relacionados con el consumo de energía del proceso de prueba y la cantidad de capital utilizado por el proceso de prueba, que se relaciona con el costo financiero de la prueba. Para poner en práctica la definición de eficiencia para la medición, la definición debe hacerse en relación con uno o más programas de prueba, una o más entradas de prueba para cada uno de esos programas y uno o más sistemas de prueba.

iii. Concisión

• El tamaño de las pruebas generadas y la complejidad de verificarlas

La concisión es un compuesto de tres métricas distintas, con la complejidad de la verificación de la prueba subdividida aún más:

• Tamaño de la prueba: el tamaño físico de las pruebas, que normalmente se mide en kilobytes
• Tiempo de verificación de pruebas: Duración requerida para verificar pruebas.
• Espacio de verificación de pruebas: uso de memoria durante la verificación de pruebas

La verificación suele ser una operación de un solo núcleo, por lo que la velocidad y la eficiencia en tiempo de núcleo son generalmente equivalentes en este contexto. Al igual que con la velocidad y la eficiencia, la puesta en práctica de la definición de concisión requiere especificar conjuntos de programas de prueba, entradas de prueba y sistemas de prueba.

Con cada propiedad de rendimiento definida, ahora ilustramos los efectos atenuantes de optimizar una propiedad sobre las demás.

• Velocidad: La generación rápida de pruebas conduce a tamaños de prueba más grandes, pero la verificación de pruebas es lenta. Se consumen más recursos para generar pruebas, lo que reduce la eficiencia
• Concisión: Prover necesita más tiempo para comprimir las pruebas. Pero la verificación de pruebas es rápida. Cuanto más sucinta sea la prueba, mayor será la sobrecarga de cálculo
• Eficiencia: Minimizar el uso de recursos reduce la velocidad de generación de pruebas y la concisión de las mismas

En general, optimizar para una calidad significa no optimizar para otra calidad y, por lo tanto, se necesita un análisis multidimensional para elegir una solución óptima caso por caso.

Una buena manera de ponderar estas propiedades en una evaluación puede ser definir niveles aceptables para cada propiedad y, a continuación, determinar qué propiedades son las más importantes. Las propiedades más importantes deben optimizarse, siempre y cuando se mantengan niveles suficientemente buenos en todas las demás propiedades.

A continuación resumimos cada propiedad y sus principales consideraciones:

Propiedades de evaluación de zkVMs

5. ¿Qué sigue?

Con la tabla anterior, concluimos el primer artículo de nuestra serie. En los próximos artículos, nos basaremos en el diagrama de flujo que se muestra arriba para explicar los procesos aritméticos y criptográficos comunes en zkVM.

Si te ha resultado útil, visita nuestro sitio web y gitbook para obtener más información sobre lo que estamos construyendo en Lita.

Además, síguenos en X y Discord para estar al día y no perderte el resto de la serie

Renuncia:

1. Este artículo es una reimpresión de [lita]. Reenviar el título original 'Un paradigma de conocimiento cero: Parte 1 - ¿Qué es un zk-VM?'. Todos los derechos de autor pertenecen al autor original [Lita Team]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los 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 de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.