Autor: Justin Thaler Fuente: a16z Traducción: Shanooba, Golden Finance
La Máquina Virtual de Conocimiento Cero (zkVMs) tiene como objetivo 'popularizar SNARKs', permitiendo que incluso las personas sin conocimientos especializados en SNARK puedan demostrar que ejecutaron correctamente un programa en una entrada específica (o testigo). Su principal ventaja radica en la experiencia del desarrollador, pero actualmente zkVMs enfrenta grandes desafíos en cuanto a seguridad y rendimiento. Si zkVMs quiere cumplir su promesa, los diseñadores deben superar estos obstáculos. Este artículo explorará las posibles etapas de desarrollo de zkVM, un proceso que podría tardar varios años en completarse; no creas a nadie que diga que esto se puede lograr rápidamente.
Desafíos que enfrentamos
En cuanto a la seguridad, zkVMs es un proyecto de software altamente complejo que todavía está lleno de vulnerabilidades.
En términos de rendimiento, demostrar la ejecución correcta de un programa puede ser decenas de miles de veces más lenta que la ejecución nativa, lo que hace que la implementación de la mayoría de las aplicaciones en el mundo real sea actualmente inviable.
A pesar de ello, muchas voces en la industria de la cadena de bloques siguen promocionando que zkVMs pueden desplegarse de inmediato, incluso algunos proyectos ya están pagando costos computacionales elevados para generar pruebas de conocimiento cero de las actividades en la cadena. Sin embargo, debido a las numerosas vulnerabilidades que aún existen en zkVMs, esta práctica en realidad es solo una costosa fachada que hace que el sistema parezca protegido por SNARK, cuando en realidad depende de control de permisos o, peor aún, está expuesto a riesgos de ataque.
La realidad es que todavía estamos a varios años de distancia de construir un zkVM verdaderamente seguro y eficiente. Este artículo presenta una serie de objetivos concretos y escalonados para ayudarnos a rastrear el progreso real de zkVM, reducir la especulación y dirigir la atención de la comunidad hacia avances tecnológicos reales.
Etapa de desarrollo de seguridad
Antecedentes
Los zkVMs basados en SNARK suelen contener dos componentes principales:
Prueba de oráculo interactivo polinómico (PIOP): marco de prueba interactivo utilizado para demostrar polinomios (o restricciones derivadas de polinomios).
Esquema de compromiso polinómico (Polynomial Commitment Scheme, PCS): garantiza que el verificador no pueda falsificar los resultados de la evaluación del polinomio sin ser detectado.
zkVM asegura el uso correcto de los registros y la memoria de la máquina virtual mediante la codificación de trayectorias de ejecución válidas como sistemas de restricciones, y luego demuestra la satisfacción de estas restricciones mediante pruebas de conocimiento cero (SNARK).
En un sistema tan complejo, la única forma de garantizar que zkVM no tenga vulnerabilidades esverificación formal. Aquí se presentan las diferentes etapas de seguridad de zkVM, donde la primera etapa se centra en la corrección del protocolo y las etapas dos y tres se centran en la corrección de la implementación.
Fase de seguridad 1: Protocolo correcto
Prueba formal de verificación de confiabilidad de PIOP;
PCS en algunas hipótesis de cifrado o modelos ideales tienen formas de prueba restrictivas;
Si se utiliza Fiat-Shamir, la prueba concisa obtenida al combinar PIOP y PCS es segura en el modelo de oráculo aleatorio, formalmente demostrada (reforzada según sea necesario con otras suposiciones criptográficas).
El sistema de restricciones utilizado por PIOP es equivalente a la prueba formal de verificación de la semántica de VM;
Todos estos componentes anteriores se 'adherirán' integralmente en una prueba SNARK segura, verificada formalmente, para ejecutar cualquier programa especificado por el bytecode de la VM. Si el protocolo tiene la intención de lograr el conocimiento cero, también debe verificarse formalmente este atributo para garantizar que no se divulguen información sensible sobre los testigos.
Si zkVM utiliza recursividad, entonces durante el proceso de recursividad, PIOP, planes de compromiso y sistemas de restricción involucrados deben ser verificados, de lo contrario, esta etapa no se considerará completa.
Fase 2 de seguridad: Implementación correcta del validador
En esta etapa, se requiere realizar una verificación formal de la implementación real del validador de zkVM (como Rust, Solidity, etc.) para garantizar que cumple con los protocolos verificados en la primera etapa. Completar esta etapa significa que la implementación de zkVM es coherente con el diseño teórico, y no es simplemente un protocolo de seguridad en papel, o una especificación ineficaz escrita en Lean, etc.
Por qué solo prestar atención a los validadores y no a los probadores hay dos razones principales: en primer lugar, asegurar la corrección del validador garantiza la integridad del sistema de prueba zkVM (es decir, garantizar que el validador no sea engañado para aceptar una prueba incorrecta). En segundo lugar, la implementación del validador zkVM es más simple que la implementación del probador en un orden de magnitud, y es más fácil garantizar su corrección a corto plazo.
Fase 3 de seguridad: Implementación correcta de los probadores
En esta etapa, se requiere realizar una verificación formal de la implementación real de los probadores zkVM para asegurar que puedan generar correctamente pruebas del sistema ya verificadas en las primeras dos etapas. El objetivo de esta etapa es la completitud es decir: ningún sistema que utilice zkVM debe quedarse atascado por no poder demostrar una declaración legal. Si zkVM requiere tener propiedades de conocimiento cero, entonces se debe proporcionar una verificación formal para garantizar que la prueba no revele ninguna información sobre el testigo.
Calendario estimado
Fase 1 de progreso: Podemos esperar algún progreso el próximo año (por ejemplo, ZKLib es un esfuerzo en esta dirección). Pero al menos en los próximos dos años, no habrá un zkVM que cumpla completamente con los requisitos de la Fase 1.
Fase 2 y Fase 3: Estas fases pueden avanzar al mismo tiempo que algunos aspectos de la Fase 1. Por ejemplo, algunos equipos ya han demostrado que la implementación del verificador Plonk se ajusta al protocolo del documento (aunque el protocolo del documento en sí mismo puede no haber sido completamente verificado). A pesar de esto, espero que cualquier zkVM no alcance la Fase 3 en menos de cuatro años, e incluso podría ser más largo.
Fiat-Shamir seguridad y bytecode verificado
Un problema de complejidad principal es que la seguridad de la transformación Fiat-Shamir sigue siendo un problema de investigación no resuelto. Todos los tres pasos de seguridad consideran a Fiat-Shamir y al oráculo aleatorio como absolutamente seguros, pero en realidad todo el paradigma puede tener vulnerabilidades. Esto se debe a las diferencias entre el modelo idealizado del oráculo aleatorio y las funciones hash utilizadas en la práctica.
En el peor de los casos, un sistema que ya ha alcanzado la etapa de seguridad 2, puede ser encontrado completamente inseguro debido a problemas relacionados con Fiat-Shamir. Esto merece nuestra atención y continua investigación. Es posible que necesitemos modificar la transformación de Fiat-Shamir en sí misma para defendernos mejor contra este tipo de vulnerabilidades.
Un sistema que no utiliza recursividad es teóricamente más seguro, ya que algunos ataques conocidos implican circuitos similares a los utilizados en la demostración recursiva. Sin embargo, este riesgo sigue siendo un problema fundamental no resuelto.
Otro problema a tener en cuenta es que, incluso si zkVM demuestra que un programa de cálculo (especificado por bytecode) se ha ejecutado correctamente, si el bytecode en sí mismo tiene defectos, entonces el valor de esta demostración es extremadamente limitado. Por lo tanto, la utilidad de zkVM depende en gran medida de cómo se genera el bytecode verificado formalmente, y este desafío es enorme y está más allá del alcance de este documento.
Sobre la seguridad contra la computación cuántica
En los próximos al menos 5 años (e incluso más tiempo), las computadoras cuánticas no representarán una amenaza grave, mientras que las vulnerabilidades de software son un problema vital. Por lo tanto, la tarea principal en este momento debería ser lograr los objetivos de seguridad y rendimiento propuestos en este artículo. Si los SNARKs no resistentes a los cuánticos pueden cumplir más rápidamente con estos objetivos, deberíamos darles prioridad. Cuando los SNARKs resistentes a los cuánticos alcancen el mismo nivel de desarrollo, o haya indicios de que las computadoras cuánticas que representan una amenaza real están a punto de aparecer, entonces consideraremos cambiar.
Nivel de seguridad específico
100-bit Classic Security is the minimum standard for any SNARK used to protect valuable assets (but there are still some systems that do not meet this low standard). Nevertheless, this should not be accepted, as standard cryptographic practices typically require security of 128 bits and above. If SNARK's performance truly meets the standard, we should not compromise security to improve performance.
Fase de rendimiento
Current situation
Actualmente, el costo computacional del verificador zkVM es aproximadamente 1 millón de veces la ejecución nativa. En otras palabras, si la ejecución nativa de un programa requiere X ciclos de CPU, entonces generar una prueba de ejecución correcta requiere aproximadamente X × 1,000,000 ciclos de CPU. Esto era así hace un año y sigue siéndolo hoy en día (aunque hay algunas confusiones).
Algunos términos populares en la industria pueden ser engañosos, por ejemplo:
El costo de generar pruebas para toda la red principal de Ethereum es inferior a 1 millón de dólares al año.
"Hemos logrado casi la generación en tiempo real de pruebas de bloques de Ethereum, solo necesitamos unas pocas GPU."
"Nuestro último zkVM es 1000 veces más rápido que su predecesor."
Sin embargo, estas afirmaciones pueden ser engañosas sin contexto:
• 1000 veces más rápido que el antiguo zkVM y todavía puede ser muy lento, lo que es más indicativo de lo malo que era en el pasado que de lo bueno que es ahora.
• La potencia de cálculo de la red principal de Ethereum puede aumentar hasta 10 veces en el futuro, lo que hará que el rendimiento actual de zkVM no pueda satisfacer la demanda.
• La llamada generación de pruebas "casi en tiempo real" todavía es demasiado lenta para muchas aplicaciones de blockchain (por ejemplo, el tiempo de bloque de Optimism es de 2 segundos, mucho más rápido que los 12 segundos de Ethereum).
• "Docenas de GPUs funcionando las 24 horas del día, los 7 días de la semana durante largos períodos de tiempo" no proporciona suficientes garantías de actividad.
• Estos tiempos de generación de pruebas suelen ser para tamaños de prueba superiores a 1 MB, lo cual es demasiado grande para muchos casos de uso.
• El costo de menos de 1 millón de dólares al año es solo porque un nodo completo de Ethereum realiza aproximadamente 25 dólares de cálculos al año.
Para aplicaciones fuera de la cadena de bloques, este costo computacional es claramente demasiado alto. No importa cuántos cálculos paralelos o mejoras de ingeniería haya, no se puede compensar un costo computacional tan grande.
Nuestro objetivo básico debe ser establecer: el rendimiento no debe exceder 100,000 veces la ejecución nativa. Sin embargo, esto es solo el primer paso. Para lograr aplicaciones de escala masiva verdaderamente populares, es posible que necesitemos reducir el rendimiento a 10,000 veces o menos que la ejecución nativa.
Medición de rendimiento
El rendimiento de SNARK tiene tres componentes principales:
La eficiencia sólida del sistema de prueba de trabajo.
Optimización para aplicaciones específicas (como la precompilación).
Aceleración de hardware y de ingeniería (por ejemplo, GPU, FPGA o CPU multinúcleo).
Aunque (2) y (3) son críticos para la implementación real, son aplicables a cualquier sistema de prueba, por lo tanto, no necesariamente reflejan mejoras en los costos fundamentales. Por ejemplo, agregar aceleración GPU y precompilación a zkEVM puede aumentar la velocidad en 50 veces con facilidad en comparación con depender únicamente de la CPU, lo que podría hacer que un sistema aparentemente menos eficiente parezca mejor que otro sistema que no ha sido optimizado de la misma manera.
Por lo tanto, este artículo se centra en medir el rendimiento básico de SNARK sin hardware especializado y precompilación. Esto difiere de los métodos de prueba de referencia actuales, que suelen combinar los tres factores en un "valor total". Es como juzgar un diamante por su tiempo de pulido en lugar de evaluar su claridad inherente.
Nuestro objetivo es aislar los costos inherentes del sistema de prueba de trabajo, reducir la barrera de entrada a tecnologías aún no profundamente investigadas y ayudar a la comunidad a eliminar las distracciones para centrarse en el verdadero progreso en el diseño del sistema de prueba.
Etapa de rendimiento
Aquí están los hitos de los cinco niveles de rendimiento que he propuesto. En primer lugar, necesitamos reducir significativamente los costos de los validadores en la CPU antes de poder depender más de los costos reducidos en el hardware. Al mismo tiempo, el uso de la memoria también debe mejorar.
En todas las etapas, los desarrolladores no deben ajustar el código para el rendimiento de zkVM. La experiencia del desarrollador es la ventaja central de zkVM. Si se sacrifica la DevEx para cumplir con las métricas de rendimiento, no solo se pierde el significado de las pruebas de referencia, sino que también va en contra del propósito original de zkVM.
Estos indicadores se centran principalmente en el costo del probador. Sin embargo, si se permite que el costo del validador aumente sin límite (es decir, sin límite en el tamaño de la prueba o el tiempo de validación), entonces cualquier indicador del probador podría cumplirse fácilmente. Por lo tanto, para cumplir con los requisitos de la siguiente etapa, también se debe limitar tanto el tamaño máximo de la prueba como el tiempo máximo de validación.
Fase 1 Requisito: "Costo de verificación no trivial razonable"
• Tamaño de prueba: Debe ser menor que el tamaño de la prueba.
• Tiempo de verificación: La velocidad de verificación de la prueba no debe ser más lenta que la ejecución nativa del programa (es decir, no debe ser más lenta que la ejecución directa del cálculo).
Estos son los requisitos mínimos de simplicidad para garantizar que el tamaño de la prueba y el tiempo de verificación no sean peores que enviar directamente la prueba al verificador y dejar que lo verifique directamente.
Fase 2 y superior
• Tamaño máximo de prueba: 256 KB.
• Tiempo de verificación máximo: 16 milisegundos.
Estos límites superiores están deliberadamente establecidos de forma más flexible para adaptarse a las nuevas tecnologías de prueba de velocidad, incluso si pueden resultar en costos de verificación más altos. Al mismo tiempo, estos límites excluyen pruebas tan costosas que prácticamente ningún proyecto estaría dispuesto a utilizar en la cadena de bloques.
Etapa 1 de velocidad
La velocidad de la prueba de un solo hilo no debe ser más lenta que la ejecución nativa en más de 100,000 veces (aplicable a diversas aplicaciones, no solo a la prueba de bloques de Ethereum), y no debe depender de la precompilación.
Específicamente, suponiendo que un procesador RISC-V en una computadora portátil moderna funcione a una velocidad de aproximadamente 30 mil millones de ciclos por segundo, alcanzar la etapa 1 significa que la computadora portátil puede generar pruebas a una velocidad de 30,000 ciclos por segundo de RISC-V (un solo hilo).
El costo del validador debe cumplir con el estándar previamente definido de "costo de validación no trivial razonable".
Fase 2 de velocidad
La velocidad de la prueba de hilo único no puede ser más lenta que la ejecución nativa en más de 10,000 veces.
O, debido a las limitaciones actuales de la CPU y la GPU en relación con algunos métodos SNARK prometedores (especialmente SNARK de campo binario), se puede recurrir a FPGA (incluso ASIC) para satisfacer esta etapa:
Calcula la cantidad de núcleos RISC-V simulados a velocidad nativa por FPGA.
Calcular, simular y demostrar el número de FPGA necesarios para ejecutar (casi en tiempo real) RISC-V.
Si la cantidad de (2) no supera las 10,000 veces (1), se cumple la fase 2.
• Tamaño de prueba: máximo 256 KB.
• Tiempo de verificación: máximo de 16 milisegundos en CPU estándar.
Fase 3 de velocidad
En base a la Etapa 2 de la fase de velocidad, lograr un gasto de prueba de hasta 1000x (aplicable a diversas aplicaciones) y se debe utilizar una precompilación con síntesis automática y verificación formal. Fundamentalmente, personalizar dinámicamente el conjunto de instrucciones de cada programa para acelerar la generación de pruebas, pero se debe garantizar la usabilidad y verificación formal. (Para obtener más información sobre por qué la precompilación es un arma de doble filo y por qué la precompilación "manual" no es un método sostenible, consulte la siguiente sección.)
Fase de memoria 1
En menos de 2 GB de memoria alcanzar la fase 1 de velocidad y al mismo tiempo cumplir con los requisitos de conocimiento cero. Esta etapa es crucial para los dispositivos móviles o navegadores y abre las puertas a numerosos casos de uso de zkVM en el cliente. Por ejemplo, teléfonos inteligentes utilizados para privacidad de ubicación, credenciales de identidad, etc. Si la generación de pruebas requiere más de 1-2 GB de memoria, la mayoría de los dispositivos móviles no podrán ejecutarla.
Dos puntos importantes:
Incluso para cálculos a gran escala (que requieren la ejecución nativa de miles de millones de ciclos de CPU), el sistema de prueba también debe mantener un límite de 2 GB de memoria, de lo contrario la aplicabilidad se verá limitada.
Si se demuestra que la velocidad es extremadamente lenta, mantener el límite de memoria de 2 GB es muy fácil. Por lo tanto, para que la fase de memoria 1 sea significativa, es necesario alcanzar la fase de velocidad 1 dentro del límite de memoria de 2 GB.
Etapa 2 de la memoria
Alcanzar lafase 1 de velocidad (10 veces más rápido que la fase 1 de memoria) con menos de 200 MB de memoria.
¿Por qué reducirlo a 200 MB? Considere un escenario no basado en blockchain: cuando visita un sitio web HTTPS, descarga certificados de autenticación y cifrado. Si el sitio web cambia para enviar estas certificaciones como pruebas zk, es posible que los grandes sitios web necesiten generar millones de pruebas por segundo. Si cada prueba requiere 2 GB de memoria, los requisitos de recursos computacionales alcanzarán el nivel de PB, lo que claramente no es factible. Por lo tanto, reducir aún más el uso de memoria es crucial para las aplicaciones no basadas en blockchain.
Precompilación: ¿El último tramo, o la muleta?
La precompilación se refiere a un sistema de restricciones SNARK optimizado específicamente para funciones particulares (como hash, firma de curva elíptica). En Ethereum, la precompilación puede reducir los costos de hash de Merkle y verificación de firma, pero depender demasiado de la precompilación no mejora realmente la eficiencia central de SNARK.
Problemas de precompilación
1. Aún demasiado lento: A pesar de usar precompilaciones de hash y firma, zkVM sigue teniendo problemas de eficiencia en los sistemas de prueba de núcleo dentro y fuera de la cadena de bloques.
2. Vulnerabilidad de seguridad: Si la precompilación a mano no se verifica formalmente, es casi seguro que habrá vulnerabilidades que puedan resultar en un fracaso de seguridad catastrófico.
3. Experiencia del desarrollador pobre: Actualmente, muchos zkVM requieren que los desarrolladores escriban a mano sistemas de restricciones, similar a la forma de programación de la década de 1960, lo que afecta gravemente la experiencia de desarrollo.
4.误导 de la prueba de referencia: Si la prueba de referencia depende de la optimización de una compilación previa específica, puede llevar a que las personas se centren en optimizar el sistema manualmente en lugar de mejorar el diseño SNARK en sí.
5. Gastos de E/S y acceso sin RAM Aunque la precompilación puede mejorar el rendimiento de tareas criptográficas intensivas, es posible que no puedan acelerar de manera significativa cargas de trabajo más diversificadas, ya que generan muchos gastos al procesar la entrada/salida y no pueden utilizar RAM.
Incluso en el entorno de la cadena de bloques, si superas una sola L1 como Ethereum (por ejemplo, si deseas construir una serie de puentes interconectados), te enfrentarás a diferentes funciones hash y esquemas de firma. La solución a este problema es realizar compilaciones previas continuas, lo cual no es escalable y conlleva enormes riesgos de seguridad.
Realmente creo que la precompilación sigue siendo crucial a largo plazo, pero solo si se genera automáticamente y se valida formalmente. De esta manera, podemos mantener la ventaja de la experiencia de desarrollo de los desarrolladores de zkVM y al mismo tiempo evitar riesgos de seguridad catastróficos. Esta perspectiva se refleja en la etapa 3.
Cronograma Previsto
Espero que el zkVM alcance la fase de velocidad 1 y la fase de memoria 1 más tarde este año. Creo que también podemos lograr la fase de velocidad 2 en los próximos dos años, pero aún no está claro si podemos alcanzar este objetivo sin nuevas ideas de investigación.
Espero que los siguientes etapas (Fase de velocidad 3 y Fase de memoria 2) tardarán varios años en completarse.
Aunque este documento enumera por separado la seguridad y el rendimiento de zkVM, ambos no son completamente independientes. A medida que se descubren continuamente vulnerabilidades en zkVM, espero que la corrección de algunas de estas vulnerabilidades inevitablemente provoque una disminución significativa del rendimiento. Por lo tanto, los resultados de las pruebas de rendimiento de zkVM deben considerarse como datos provisionales hasta que zkVM alcance la Etapa de Seguridad 2.
zkVM tiene un gran potencial para popularizar realmente las pruebas de conocimiento cero, pero actualmente se encuentra en una etapa temprana llena de desafíos de seguridad y graves cuellos de botella de rendimiento. La especulación del mercado y la publicidad dificultan medir los verdaderos avances. Con hitos claros en seguridad y rendimiento, espero proporcionar un mapa de ruta que pueda despejar la neblina. Eventualmente alcanzaremos el objetivo, pero esto llevará tiempo y un esfuerzo continuo en investigación e ingeniería.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
a16z: El camino eficiente y seguro de explorar zkVM
Autor: Justin Thaler Fuente: a16z Traducción: Shanooba, Golden Finance
La Máquina Virtual de Conocimiento Cero (zkVMs) tiene como objetivo 'popularizar SNARKs', permitiendo que incluso las personas sin conocimientos especializados en SNARK puedan demostrar que ejecutaron correctamente un programa en una entrada específica (o testigo). Su principal ventaja radica en la experiencia del desarrollador, pero actualmente zkVMs enfrenta grandes desafíos en cuanto a seguridad y rendimiento. Si zkVMs quiere cumplir su promesa, los diseñadores deben superar estos obstáculos. Este artículo explorará las posibles etapas de desarrollo de zkVM, un proceso que podría tardar varios años en completarse; no creas a nadie que diga que esto se puede lograr rápidamente.
Desafíos que enfrentamos
En cuanto a la seguridad, zkVMs es un proyecto de software altamente complejo que todavía está lleno de vulnerabilidades.
En términos de rendimiento, demostrar la ejecución correcta de un programa puede ser decenas de miles de veces más lenta que la ejecución nativa, lo que hace que la implementación de la mayoría de las aplicaciones en el mundo real sea actualmente inviable.
A pesar de ello, muchas voces en la industria de la cadena de bloques siguen promocionando que zkVMs pueden desplegarse de inmediato, incluso algunos proyectos ya están pagando costos computacionales elevados para generar pruebas de conocimiento cero de las actividades en la cadena. Sin embargo, debido a las numerosas vulnerabilidades que aún existen en zkVMs, esta práctica en realidad es solo una costosa fachada que hace que el sistema parezca protegido por SNARK, cuando en realidad depende de control de permisos o, peor aún, está expuesto a riesgos de ataque.
La realidad es que todavía estamos a varios años de distancia de construir un zkVM verdaderamente seguro y eficiente. Este artículo presenta una serie de objetivos concretos y escalonados para ayudarnos a rastrear el progreso real de zkVM, reducir la especulación y dirigir la atención de la comunidad hacia avances tecnológicos reales.
Etapa de desarrollo de seguridad
Antecedentes
Los zkVMs basados en SNARK suelen contener dos componentes principales:
Prueba de oráculo interactivo polinómico (PIOP): marco de prueba interactivo utilizado para demostrar polinomios (o restricciones derivadas de polinomios).
Esquema de compromiso polinómico (Polynomial Commitment Scheme, PCS): garantiza que el verificador no pueda falsificar los resultados de la evaluación del polinomio sin ser detectado.
zkVM asegura el uso correcto de los registros y la memoria de la máquina virtual mediante la codificación de trayectorias de ejecución válidas como sistemas de restricciones, y luego demuestra la satisfacción de estas restricciones mediante pruebas de conocimiento cero (SNARK).
En un sistema tan complejo, la única forma de garantizar que zkVM no tenga vulnerabilidades es verificación formal. Aquí se presentan las diferentes etapas de seguridad de zkVM, donde la primera etapa se centra en la corrección del protocolo y las etapas dos y tres se centran en la corrección de la implementación.
Fase de seguridad 1: Protocolo correcto
Si zkVM utiliza recursividad, entonces durante el proceso de recursividad, PIOP, planes de compromiso y sistemas de restricción involucrados deben ser verificados, de lo contrario, esta etapa no se considerará completa.
Fase 2 de seguridad: Implementación correcta del validador
En esta etapa, se requiere realizar una verificación formal de la implementación real del validador de zkVM (como Rust, Solidity, etc.) para garantizar que cumple con los protocolos verificados en la primera etapa. Completar esta etapa significa que la implementación de zkVM es coherente con el diseño teórico, y no es simplemente un protocolo de seguridad en papel, o una especificación ineficaz escrita en Lean, etc.
Por qué solo prestar atención a los validadores y no a los probadores hay dos razones principales: en primer lugar, asegurar la corrección del validador garantiza la integridad del sistema de prueba zkVM (es decir, garantizar que el validador no sea engañado para aceptar una prueba incorrecta). En segundo lugar, la implementación del validador zkVM es más simple que la implementación del probador en un orden de magnitud, y es más fácil garantizar su corrección a corto plazo.
Fase 3 de seguridad: Implementación correcta de los probadores
En esta etapa, se requiere realizar una verificación formal de la implementación real de los probadores zkVM para asegurar que puedan generar correctamente pruebas del sistema ya verificadas en las primeras dos etapas. El objetivo de esta etapa es la completitud es decir: ningún sistema que utilice zkVM debe quedarse atascado por no poder demostrar una declaración legal. Si zkVM requiere tener propiedades de conocimiento cero, entonces se debe proporcionar una verificación formal para garantizar que la prueba no revele ninguna información sobre el testigo.
Calendario estimado
Fase 1 de progreso: Podemos esperar algún progreso el próximo año (por ejemplo, ZKLib es un esfuerzo en esta dirección). Pero al menos en los próximos dos años, no habrá un zkVM que cumpla completamente con los requisitos de la Fase 1.
Fase 2 y Fase 3: Estas fases pueden avanzar al mismo tiempo que algunos aspectos de la Fase 1. Por ejemplo, algunos equipos ya han demostrado que la implementación del verificador Plonk se ajusta al protocolo del documento (aunque el protocolo del documento en sí mismo puede no haber sido completamente verificado). A pesar de esto, espero que cualquier zkVM no alcance la Fase 3 en menos de cuatro años, e incluso podría ser más largo.
Fiat-Shamir seguridad y bytecode verificado
Un problema de complejidad principal es que la seguridad de la transformación Fiat-Shamir sigue siendo un problema de investigación no resuelto. Todos los tres pasos de seguridad consideran a Fiat-Shamir y al oráculo aleatorio como absolutamente seguros, pero en realidad todo el paradigma puede tener vulnerabilidades. Esto se debe a las diferencias entre el modelo idealizado del oráculo aleatorio y las funciones hash utilizadas en la práctica.
En el peor de los casos, un sistema que ya ha alcanzado la etapa de seguridad 2, puede ser encontrado completamente inseguro debido a problemas relacionados con Fiat-Shamir. Esto merece nuestra atención y continua investigación. Es posible que necesitemos modificar la transformación de Fiat-Shamir en sí misma para defendernos mejor contra este tipo de vulnerabilidades.
Un sistema que no utiliza recursividad es teóricamente más seguro, ya que algunos ataques conocidos implican circuitos similares a los utilizados en la demostración recursiva. Sin embargo, este riesgo sigue siendo un problema fundamental no resuelto.
Otro problema a tener en cuenta es que, incluso si zkVM demuestra que un programa de cálculo (especificado por bytecode) se ha ejecutado correctamente, si el bytecode en sí mismo tiene defectos, entonces el valor de esta demostración es extremadamente limitado. Por lo tanto, la utilidad de zkVM depende en gran medida de cómo se genera el bytecode verificado formalmente, y este desafío es enorme y está más allá del alcance de este documento.
Sobre la seguridad contra la computación cuántica
En los próximos al menos 5 años (e incluso más tiempo), las computadoras cuánticas no representarán una amenaza grave, mientras que las vulnerabilidades de software son un problema vital. Por lo tanto, la tarea principal en este momento debería ser lograr los objetivos de seguridad y rendimiento propuestos en este artículo. Si los SNARKs no resistentes a los cuánticos pueden cumplir más rápidamente con estos objetivos, deberíamos darles prioridad. Cuando los SNARKs resistentes a los cuánticos alcancen el mismo nivel de desarrollo, o haya indicios de que las computadoras cuánticas que representan una amenaza real están a punto de aparecer, entonces consideraremos cambiar.
Nivel de seguridad específico
100-bit Classic Security is the minimum standard for any SNARK used to protect valuable assets (but there are still some systems that do not meet this low standard). Nevertheless, this should not be accepted, as standard cryptographic practices typically require security of 128 bits and above. If SNARK's performance truly meets the standard, we should not compromise security to improve performance.
Fase de rendimiento
Current situation
Actualmente, el costo computacional del verificador zkVM es aproximadamente 1 millón de veces la ejecución nativa. En otras palabras, si la ejecución nativa de un programa requiere X ciclos de CPU, entonces generar una prueba de ejecución correcta requiere aproximadamente X × 1,000,000 ciclos de CPU. Esto era así hace un año y sigue siéndolo hoy en día (aunque hay algunas confusiones).
Algunos términos populares en la industria pueden ser engañosos, por ejemplo:
El costo de generar pruebas para toda la red principal de Ethereum es inferior a 1 millón de dólares al año.
"Hemos logrado casi la generación en tiempo real de pruebas de bloques de Ethereum, solo necesitamos unas pocas GPU."
"Nuestro último zkVM es 1000 veces más rápido que su predecesor."
Sin embargo, estas afirmaciones pueden ser engañosas sin contexto:
• 1000 veces más rápido que el antiguo zkVM y todavía puede ser muy lento, lo que es más indicativo de lo malo que era en el pasado que de lo bueno que es ahora.
• La potencia de cálculo de la red principal de Ethereum puede aumentar hasta 10 veces en el futuro, lo que hará que el rendimiento actual de zkVM no pueda satisfacer la demanda.
• La llamada generación de pruebas "casi en tiempo real" todavía es demasiado lenta para muchas aplicaciones de blockchain (por ejemplo, el tiempo de bloque de Optimism es de 2 segundos, mucho más rápido que los 12 segundos de Ethereum).
• "Docenas de GPUs funcionando las 24 horas del día, los 7 días de la semana durante largos períodos de tiempo" no proporciona suficientes garantías de actividad.
• Estos tiempos de generación de pruebas suelen ser para tamaños de prueba superiores a 1 MB, lo cual es demasiado grande para muchos casos de uso.
• El costo de menos de 1 millón de dólares al año es solo porque un nodo completo de Ethereum realiza aproximadamente 25 dólares de cálculos al año.
Para aplicaciones fuera de la cadena de bloques, este costo computacional es claramente demasiado alto. No importa cuántos cálculos paralelos o mejoras de ingeniería haya, no se puede compensar un costo computacional tan grande.
Nuestro objetivo básico debe ser establecer: el rendimiento no debe exceder 100,000 veces la ejecución nativa. Sin embargo, esto es solo el primer paso. Para lograr aplicaciones de escala masiva verdaderamente populares, es posible que necesitemos reducir el rendimiento a 10,000 veces o menos que la ejecución nativa.
Medición de rendimiento
El rendimiento de SNARK tiene tres componentes principales:
La eficiencia sólida del sistema de prueba de trabajo.
Optimización para aplicaciones específicas (como la precompilación).
Aceleración de hardware y de ingeniería (por ejemplo, GPU, FPGA o CPU multinúcleo).
Aunque (2) y (3) son críticos para la implementación real, son aplicables a cualquier sistema de prueba, por lo tanto, no necesariamente reflejan mejoras en los costos fundamentales. Por ejemplo, agregar aceleración GPU y precompilación a zkEVM puede aumentar la velocidad en 50 veces con facilidad en comparación con depender únicamente de la CPU, lo que podría hacer que un sistema aparentemente menos eficiente parezca mejor que otro sistema que no ha sido optimizado de la misma manera.
Por lo tanto, este artículo se centra en medir el rendimiento básico de SNARK sin hardware especializado y precompilación. Esto difiere de los métodos de prueba de referencia actuales, que suelen combinar los tres factores en un "valor total". Es como juzgar un diamante por su tiempo de pulido en lugar de evaluar su claridad inherente.
Nuestro objetivo es aislar los costos inherentes del sistema de prueba de trabajo, reducir la barrera de entrada a tecnologías aún no profundamente investigadas y ayudar a la comunidad a eliminar las distracciones para centrarse en el verdadero progreso en el diseño del sistema de prueba.
Etapa de rendimiento
Aquí están los hitos de los cinco niveles de rendimiento que he propuesto. En primer lugar, necesitamos reducir significativamente los costos de los validadores en la CPU antes de poder depender más de los costos reducidos en el hardware. Al mismo tiempo, el uso de la memoria también debe mejorar.
En todas las etapas, los desarrolladores no deben ajustar el código para el rendimiento de zkVM. La experiencia del desarrollador es la ventaja central de zkVM. Si se sacrifica la DevEx para cumplir con las métricas de rendimiento, no solo se pierde el significado de las pruebas de referencia, sino que también va en contra del propósito original de zkVM.
Estos indicadores se centran principalmente en el costo del probador. Sin embargo, si se permite que el costo del validador aumente sin límite (es decir, sin límite en el tamaño de la prueba o el tiempo de validación), entonces cualquier indicador del probador podría cumplirse fácilmente. Por lo tanto, para cumplir con los requisitos de la siguiente etapa, también se debe limitar tanto el tamaño máximo de la prueba como el tiempo máximo de validación.
Fase 1 Requisito: "Costo de verificación no trivial razonable"
• Tamaño de prueba: Debe ser menor que el tamaño de la prueba.
• Tiempo de verificación: La velocidad de verificación de la prueba no debe ser más lenta que la ejecución nativa del programa (es decir, no debe ser más lenta que la ejecución directa del cálculo).
Estos son los requisitos mínimos de simplicidad para garantizar que el tamaño de la prueba y el tiempo de verificación no sean peores que enviar directamente la prueba al verificador y dejar que lo verifique directamente.
Fase 2 y superior
• Tamaño máximo de prueba: 256 KB.
• Tiempo de verificación máximo: 16 milisegundos.
Estos límites superiores están deliberadamente establecidos de forma más flexible para adaptarse a las nuevas tecnologías de prueba de velocidad, incluso si pueden resultar en costos de verificación más altos. Al mismo tiempo, estos límites excluyen pruebas tan costosas que prácticamente ningún proyecto estaría dispuesto a utilizar en la cadena de bloques.
Etapa 1 de velocidad
La velocidad de la prueba de un solo hilo no debe ser más lenta que la ejecución nativa en más de 100,000 veces (aplicable a diversas aplicaciones, no solo a la prueba de bloques de Ethereum), y no debe depender de la precompilación.
Específicamente, suponiendo que un procesador RISC-V en una computadora portátil moderna funcione a una velocidad de aproximadamente 30 mil millones de ciclos por segundo, alcanzar la etapa 1 significa que la computadora portátil puede generar pruebas a una velocidad de 30,000 ciclos por segundo de RISC-V (un solo hilo).
El costo del validador debe cumplir con el estándar previamente definido de "costo de validación no trivial razonable".
Fase 2 de velocidad
La velocidad de la prueba de hilo único no puede ser más lenta que la ejecución nativa en más de 10,000 veces.
O, debido a las limitaciones actuales de la CPU y la GPU en relación con algunos métodos SNARK prometedores (especialmente SNARK de campo binario), se puede recurrir a FPGA (incluso ASIC) para satisfacer esta etapa:
Calcula la cantidad de núcleos RISC-V simulados a velocidad nativa por FPGA.
Calcular, simular y demostrar el número de FPGA necesarios para ejecutar (casi en tiempo real) RISC-V.
Si la cantidad de (2) no supera las 10,000 veces (1), se cumple la fase 2.
• Tamaño de prueba: máximo 256 KB.
• Tiempo de verificación: máximo de 16 milisegundos en CPU estándar.
Fase 3 de velocidad
En base a la Etapa 2 de la fase de velocidad, lograr un gasto de prueba de hasta 1000x (aplicable a diversas aplicaciones) y se debe utilizar una precompilación con síntesis automática y verificación formal. Fundamentalmente, personalizar dinámicamente el conjunto de instrucciones de cada programa para acelerar la generación de pruebas, pero se debe garantizar la usabilidad y verificación formal. (Para obtener más información sobre por qué la precompilación es un arma de doble filo y por qué la precompilación "manual" no es un método sostenible, consulte la siguiente sección.)
Fase de memoria 1
En menos de 2 GB de memoria alcanzar la fase 1 de velocidad y al mismo tiempo cumplir con los requisitos de conocimiento cero. Esta etapa es crucial para los dispositivos móviles o navegadores y abre las puertas a numerosos casos de uso de zkVM en el cliente. Por ejemplo, teléfonos inteligentes utilizados para privacidad de ubicación, credenciales de identidad, etc. Si la generación de pruebas requiere más de 1-2 GB de memoria, la mayoría de los dispositivos móviles no podrán ejecutarla.
Dos puntos importantes:
Incluso para cálculos a gran escala (que requieren la ejecución nativa de miles de millones de ciclos de CPU), el sistema de prueba también debe mantener un límite de 2 GB de memoria, de lo contrario la aplicabilidad se verá limitada.
Si se demuestra que la velocidad es extremadamente lenta, mantener el límite de memoria de 2 GB es muy fácil. Por lo tanto, para que la fase de memoria 1 sea significativa, es necesario alcanzar la fase de velocidad 1 dentro del límite de memoria de 2 GB.
Etapa 2 de la memoria
Alcanzar la fase 1 de velocidad (10 veces más rápido que la fase 1 de memoria) con menos de 200 MB de memoria.
¿Por qué reducirlo a 200 MB? Considere un escenario no basado en blockchain: cuando visita un sitio web HTTPS, descarga certificados de autenticación y cifrado. Si el sitio web cambia para enviar estas certificaciones como pruebas zk, es posible que los grandes sitios web necesiten generar millones de pruebas por segundo. Si cada prueba requiere 2 GB de memoria, los requisitos de recursos computacionales alcanzarán el nivel de PB, lo que claramente no es factible. Por lo tanto, reducir aún más el uso de memoria es crucial para las aplicaciones no basadas en blockchain.
Precompilación: ¿El último tramo, o la muleta?
La precompilación se refiere a un sistema de restricciones SNARK optimizado específicamente para funciones particulares (como hash, firma de curva elíptica). En Ethereum, la precompilación puede reducir los costos de hash de Merkle y verificación de firma, pero depender demasiado de la precompilación no mejora realmente la eficiencia central de SNARK.
Problemas de precompilación
1. Aún demasiado lento: A pesar de usar precompilaciones de hash y firma, zkVM sigue teniendo problemas de eficiencia en los sistemas de prueba de núcleo dentro y fuera de la cadena de bloques.
2. Vulnerabilidad de seguridad: Si la precompilación a mano no se verifica formalmente, es casi seguro que habrá vulnerabilidades que puedan resultar en un fracaso de seguridad catastrófico.
3. Experiencia del desarrollador pobre: Actualmente, muchos zkVM requieren que los desarrolladores escriban a mano sistemas de restricciones, similar a la forma de programación de la década de 1960, lo que afecta gravemente la experiencia de desarrollo.
4.误导 de la prueba de referencia: Si la prueba de referencia depende de la optimización de una compilación previa específica, puede llevar a que las personas se centren en optimizar el sistema manualmente en lugar de mejorar el diseño SNARK en sí.
5. Gastos de E/S y acceso sin RAM Aunque la precompilación puede mejorar el rendimiento de tareas criptográficas intensivas, es posible que no puedan acelerar de manera significativa cargas de trabajo más diversificadas, ya que generan muchos gastos al procesar la entrada/salida y no pueden utilizar RAM.
Incluso en el entorno de la cadena de bloques, si superas una sola L1 como Ethereum (por ejemplo, si deseas construir una serie de puentes interconectados), te enfrentarás a diferentes funciones hash y esquemas de firma. La solución a este problema es realizar compilaciones previas continuas, lo cual no es escalable y conlleva enormes riesgos de seguridad.
Realmente creo que la precompilación sigue siendo crucial a largo plazo, pero solo si se genera automáticamente y se valida formalmente. De esta manera, podemos mantener la ventaja de la experiencia de desarrollo de los desarrolladores de zkVM y al mismo tiempo evitar riesgos de seguridad catastróficos. Esta perspectiva se refleja en la etapa 3.
Cronograma Previsto
Espero que el zkVM alcance la fase de velocidad 1 y la fase de memoria 1 más tarde este año. Creo que también podemos lograr la fase de velocidad 2 en los próximos dos años, pero aún no está claro si podemos alcanzar este objetivo sin nuevas ideas de investigación.
Espero que los siguientes etapas (Fase de velocidad 3 y Fase de memoria 2) tardarán varios años en completarse.
Aunque este documento enumera por separado la seguridad y el rendimiento de zkVM, ambos no son completamente independientes. A medida que se descubren continuamente vulnerabilidades en zkVM, espero que la corrección de algunas de estas vulnerabilidades inevitablemente provoque una disminución significativa del rendimiento. Por lo tanto, los resultados de las pruebas de rendimiento de zkVM deben considerarse como datos provisionales hasta que zkVM alcance la Etapa de Seguridad 2.
zkVM tiene un gran potencial para popularizar realmente las pruebas de conocimiento cero, pero actualmente se encuentra en una etapa temprana llena de desafíos de seguridad y graves cuellos de botella de rendimiento. La especulación del mercado y la publicidad dificultan medir los verdaderos avances. Con hitos claros en seguridad y rendimiento, espero proporcionar un mapa de ruta que pueda despejar la neblina. Eventualmente alcanzaremos el objetivo, pero esto llevará tiempo y un esfuerzo continuo en investigación e ingeniería.