El camino hacia zkVMs seguros y eficientes: Cómo seguir el progreso
El autor original: a16z crypto
原文编译：Golem，Odaily 星球日报
zkVM (Zero Knowledge Virtual Machine) se compromete a 'popularizar SNARK', permitiendo a cualquier persona (incluso a aquellos sin conocimientos profesionales en SNARK) demostrar que han ejecutado correctamente cualquier programa dado en una entrada (o testigo) dada. Su principal ventaja radica en la experiencia del desarrollador, pero actualmente se enfrentan a grandes desafíos en términos de seguridad y rendimiento. Para que la visión de zkVM se haga realidad, los diseñadores deben superar estos desafíos. En este artículo, enumero las posibles etapas del desarrollo de zkVM, las cuales tomarán varios años completar.
Desafío
En términos de seguridad, zkVM es un proyecto de software altamente complejo que sigue estando lleno de vulnerabilidades. En términos de rendimiento, la velocidad de ejecución correcta del programa de prueba puede ser decenas de miles de veces más lenta que la ejecución local, lo que hace que la mayoría de las aplicaciones actualmente no puedan ser implementadas en el mundo real.
A pesar de estos desafíos del mundo real, la mayoría de las empresas en la industria blockchain describen zkVM como algo que se puede implementar de inmediato. De hecho, algunos proyectos ya han pagado una gran cantidad de costos de computación para demostrar la actividad en la cadena. Sin embargo, como zkVM aún no está completo, esto es simplemente una forma costosa de simular que el sistema está protegido por SNARK, cuando en realidad está protegido por permisos o, peor aún, es vulnerable a ataques.
Nos llevará varios años antes de lograr un zkVM seguro y de alto rendimiento. Este artículo presenta una serie de objetivos específicos escalonados para seguir el progreso de zkVM, lo que puede eliminar la especulación y ayudar a la comunidad a enfocarse en avances reales.
Fase de seguridad
Un zkVM basado en SNARK generalmente consta de dos componentes principales:
· Prueba interactiva de oráculo de polinomios (PIOP): Un marco de prueba interactivo para demostrar afirmaciones sobre polinomios (o restricciones derivadas de ellos).
· Esquema de compromiso polinomial (PCS): Asegura que el probador no puede mentir sobre la evaluación polinomial sin ser descubierto.
zkVM esencialmente codifica la ejecución efectiva en sistemas de restricciones, lo que significa que obliga a la máquina virtual a usar correctamente registros y memoria, y luego aplica SNARK para demostrar que estas restricciones se cumplen.
La única forma de asegurar que sistemas tan complejos como zkVM no tengan errores es a través de la verificación formal. A continuación se detallan las fases de seguridad. La Fase 1 se centra en el protocolo correcto, mientras que la Fase 2 y la Fase 3 se centran en la implementación correcta.
Fase de seguridad 1: Protocolo correcto
La verificación formal de la confiabilidad de PIOP;
PCS verifica la prueba en una forma vinculante en ciertas suposiciones criptográficas o modelos ideales.
3、Si se utiliza Fiat-Shamir, la prueba concisa obtenida al combinar PIOP y PCS es segura en el modelo de oráculo aleatorio como prueba formal de verificación (reforzada según sea necesario con otras suposiciones criptográficas);
El sistema de restricciones utilizado por PIOP es equivalente a la demostración de verificación formal de la semántica de VM;
5、Todos estos componentes anteriores se unen en una única prueba de SNARK segura, formalmente verificada, para ejecutar cualquier programa especificado por el bytecode de la VM. Si el protocolo tiene la intención de lograr la prueba de conocimiento cero, también se debe verificar formalmente esta propiedad para garantizar que no se divulgue información sensible sobre los testigos.
Advertencia de recursividad: Si zkVM utiliza recursividad, se debe verificar cada PIOP, esquema de compromiso y sistema de restricciones involucrados en cualquier lugar de esta recursividad antes de que se considere esta etapa como completada.
Fase de seguridad 2: Implementación correcta del validador
La implementación real del verificador de prueba zkVM (utilizando Rust, Solidity, etc.) coincide con el protocolo de verificación de fase 1. Lograr esto asegura que el protocolo implementado sea razonable (no solo un diseño en papel o una especificación ineficiente escrita en Lean, etc.).
La razón por la que la etapa 2 se centra únicamente en la implementación del verificador (en lugar del probador) tiene dos aspectos. En primer lugar, el uso correcto del verificador ya es suficiente para garantizar la confiabilidad (es decir, asegurar que el verificador no puede creer que ninguna declaración falsa sea realmente verdadera). En segundo lugar, la implementación del verificador de zkVM es al menos un orden de magnitud más simple que la implementación del probador.
Fase de seguridad 3: Implementación correcta del verificador
La implementación real del verificador zkVM genera correctamente las pruebas del sistema de verificación de las fases 1 y 2, es decir, la verificación formal. Esto garantiza la integridad, es decir, ningún sistema que utilice zkVM se quedará atascado con declaraciones no probables. Si el verificador tiene la intención de implementar el conocimiento cero, debe verificar formalmente esta propiedad.
Calendario previsto
· Fase 1 Progreso: Podemos esperar logros graduales el próximo año (por ejemplo, ZKLib). Pero al menos dentro de dos años, no hay zkVM que pueda cumplir completamente con los requisitos de la Fase 1;
· Fase 2 y Fase 3: Estas fases pueden avanzar simultáneamente con algunos aspectos de la Fase 1. Por ejemplo, algunos equipos ya han demostrado que la implementación del validador Plonk coincide con el protocolo del papel (aunque el protocolo del papel en sí mismo puede no estar completamente validado). Sin embargo, no espero que ningún zkVM alcance la Fase 3 en menos de cuatro años, y quizás más.
Consideraciones clave: seguridad Fiat-Shamir y código de bytes verificado
Un factor complicado clave es la existencia de problemas de investigación no resueltos en torno a la seguridad de la conversión Fiat-Shamir. Los tres pasos consideran a Fiat-Shamir y al oráculo aleatorio como parte de su seguridad impenetrable, pero en realidad todo el paradigma podría tener vulnerabilidades. Esto se debe a la idealización excesiva del oráculo aleatorio y las diferencias entre las funciones hash idealizadas y las utilizadas en la práctica. En el peor de los casos, un sistema que ha alcanzado la etapa 2 debido a problemas de Fiat-Shamir podría descubrirse como completamente inseguro. Esto ha generado una gran preocupación y una investigación continua. Es posible que necesitemos modificar la conversión en sí misma para prevenir mejor este tipo de vulnerabilidades.
Un sistema sin recursión es teóricamente más robusto, ya que algunos ataques conocidos implican circuitos similares a los utilizados en pruebas recursivas.
Otro aspecto importante a tener en cuenta es que si el bytecode en sí mismo tiene defectos, entonces la prueba de que el programa de computadora ha sido ejecutado correctamente (especificado por el bytecode) también tiene un valor limitado. Por lo tanto, la utilidad de zkVM depende en gran medida del método para generar bytecode de verificación formal, lo cual es un desafío enorme y está más allá del alcance de este documento.
Sobre la seguridad en la era post-cuántica
Durante al menos los próximos cinco años (quizás más), la computación cuántica no representará una amenaza grave, mientras que las vulnerabilidades son un riesgo de supervivencia. Por lo tanto, el enfoque principal en este momento debería ser cumplir con las etapas de seguridad y rendimiento discutidas en este documento. Si podemos cumplir más rápidamente con estos requisitos de seguridad utilizando SNARK no cuántico, entonces deberíamos hacerlo hasta que el SNARK poscuántico alcance, o hasta que la preocupación por la aparición de computadoras cuánticas relacionadas con la criptografía sea grave.
Estado actual del rendimiento de zkVM
Actualmente, el costo generado por el verificador zkVM es aproximadamente un millón de veces el costo de ejecución nativo. Si un programa necesita X ciclos para ejecutarse, el costo de la ejecución correcta es de aproximadamente X veces 1 millón de ciclos de CPU. Hace un año era así, y hoy sigue siéndolo.
Las narrativas populares suelen describir este gasto de una manera que suena aceptable. Por ejemplo:
·「El costo anual de generar pruebas en la red principal de Ethereum es inferior a un millón de dólares estadounidenses.」
·"Podemos generar pruebas de bloques de Ethereum en tiempo real utilizando un clúster compuesto por decenas de GPU."
·"Nuestro último zkVM es 1000 veces más rápido que su predecesor."
Aunque técnicamente precisas, estas afirmaciones pueden resultar engañosas sin el contexto adecuado. Por ejemplo:
· zkVM ### es 1000 veces más rápido que la versión anterior, pero sigue siendo muy lento en términos absolutos. Esto indica más cuán malas son las cosas en lugar de cuán buenas.
· Alguien ha propuesto aumentar en 10 veces la cantidad de cálculos procesados en la red principal de Ethereum. Esto hará que el rendimiento actual de zkVM sea más lento.
La llamada "prueba de casi tiempo real" de los bloques de Ethereum sigue siendo mucho más lenta que la requerida por 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).
·"Varios GPU funcionando constantemente sin errores" no pueden alcanzar una garantía de actividad aceptable.
· Menos de un millón de dólares al año para demostrar que todas las actividades en la red principal de Ethereum reflejan el hecho de que solo se necesitan alrededor de 25 dólares al año para que un nodo completo de Ethereum realice cálculos.
Para aplicaciones fuera de la cadena de bloques, este tipo de gastos obviamente es demasiado alto. Ninguna paralelización o ingeniería puede compensar un gasto tan grande. Deberíamos tomar como referencia básica una velocidad para zkVM que sea no más de 100,000 veces más lenta que la ejecución nativa, incluso si eso es solo el primer paso. La adopción real a gran escala podría requerir un gasto cercano a 10,000 veces o incluso menor.
Cómo medir el rendimiento
El rendimiento SNARK tiene tres componentes principales:
· La eficiencia intrínseca del sistema de prueba de trabajo.
Optimización específica de la aplicación (por ejemplo, precompilación).
· Ingeniería y aceleración de hardware (como GPU, FPGA o CPU multicore).
Aunque ambos son críticos para la implementación real, a menudo son aplicables a cualquier sistema de prueba, por lo que no necesariamente reflejan los costos fundamentales. Por ejemplo, agregar aceleración GPU y precompilación en zkEVM puede lograr fácilmente una aceleración de 50 veces, mucho más rápido que los métodos sin precompilación puramente basados en CPU, lo que hace que un sistema intrínsecamente menos eficiente parezca mejor que un sistema sin el mismo pulido.
Por lo tanto, a continuación se presenta el rendimiento de SNARK sin hardware especial y precompilado. Esto difiere del método de prueba de referencia actual, que suele agrupar los tres factores en un 'número de título'. Esto sería equivalente a evaluar el valor de un diamante en función del tiempo de pulido en lugar de su pureza intrínseca. Nuestro objetivo es eliminar los gastos internos del sistema de prueba de generalidad, ayudando a la comunidad a eliminar factores confusos y centrarse en el verdadero progreso del diseño del sistema de prueba.
Etapa de rendimiento
A continuación se presentan 5 hitos en el rendimiento logrados. En primer lugar, debemos reducir en varios órdenes de magnitud los costos del verificador en la CPU. Solo así debería centrarse en seguir reduciendo a través de hardware. También es necesario aumentar la tasa de uso de la memoria.
En todas las etapas a continuación, los desarrolladores no necesitan implementar un código personalizado según la configuración de zkVM para lograr el rendimiento necesario. La experiencia del desarrollador es la principal ventaja de zkVM. Sacrificar DevEx para cumplir con los estándares de rendimiento va en contra del propósito mismo de zkVM.
Estos indicadores se centran en el costo del verificador. Sin embargo, si se permite un costo ilimitado para el verificador (es decir, no hay límite en el tamaño de la prueba o en el tiempo de verificación), se puede cumplir fácilmente cualquier indicador del verificador. Por lo tanto, para que el sistema cumpla con la etapa mencionada, se deben especificar límites máximos para el tamaño de la prueba y el tiempo de verificación.
requisitos de rendimiento
Fase 1 Requisito: 'Costo de verificación razonable y no trivial':
· Tamaño de prueba: El tamaño de la prueba debe ser menor que el tamaño de la firma.
· El tiempo de verificación: la velocidad de verificación de la prueba no debe ser más lenta que la ejecución del programa en la máquina local (es decir, realizar cálculos sin la verificación de la corrección).
Estos son los requisitos mínimos de concisión. Se aseguran de que el tamaño de la prueba y el tiempo de verificación no sean peores que enviar el testigo al validador y permitir que el validador lo verifique directamente.
Fase 2 y posteriores requisitos:
· Tamaño de prueba máximo: 256 KB。
· Tiempo de validación máximo: 16 milisegundos.
Estos valores de umbral se han establecido intencionalmente en un nivel más alto para adaptarse a las nuevas tecnologías de prueba de rapidez que pueden acarrear costos de verificación más altos. Al mismo tiempo, excluyen pruebas muy costosas, por lo que pocos proyectos están dispuestos a incluirlas en la cadena de bloques.
Etapa de Velocidad 1
La prueba de hilo único debe ser al menos cien mil veces más lenta que la ejecución local, medida en una serie de aplicaciones (no solo pruebas de bloques de Ethereum), sin depender de la compilación previa.
Específicamente, imagine un proceso RISC-V que se ejecuta en un ordenador portátil moderno a aproximadamente 30 mil millones de ciclos por segundo. Lograr la Fase 1 significa que puede demostrar aproximadamente 30,000 ciclos RISC-V por segundo en el mismo ordenador portátil (un solo hilo). Sin embargo, el costo de verificación debe ser "razonable y no trivial", como se mencionó anteriormente.
Etapa de velocidad 2
La prueba de un solo hilo debe ser como máximo diez mil veces más lenta que la ejecución en el dispositivo local.
O, debido a que algunos prometedores métodos SNARK (especialmente los basados en campos binarios) están siendo obstaculizados por las actuales CPU y GPU, puede considerar el uso de FPGA (incluso ASIC) para alcanzar esta etapa:
La cantidad de núcleos RISC-V que se pueden simular a la velocidad nativa en un FPGA;
Simular y demostrar (casi) la cantidad de FPGA necesarios para ejecutar RISC-V en tiempo real.
Si el segundo es como máximo 10, 000 veces mayor que el primero, calificará para la segunda etapa. En una CPU estándar, el tamaño de la prueba debe ser como máximo de 256 KB y el tiempo del validador como máximo de 16 milisegundos.
Fase de velocidad 3
Además de alcanzar la etapa 2 de velocidad, también se puede utilizar la precompilación con síntesis automática y verificación de forma para lograr gastos de demostración de menos de 1000 veces (aplicable a una amplia gama de aplicaciones). Básicamente, se puede personalizar dinámicamente un conjunto de instrucciones para cada programa para acelerar la demostración, pero debe hacerse de manera fácil de usar y verificar formalmente.
Fase de memoria 1
La velocidad de la Fase 1 se logra con menos de 2 GB de memoria requerida en el verificador (junto con la prueba de conocimiento cero).
Esto es crucial para muchos dispositivos móviles o navegadores, por lo que ha habilitado innumerables casos de uso de zkVM del lado del cliente. La prueba del cliente es fundamental, ya que nuestros teléfonos móviles son nuestra conexión continua con el mundo real: rastrean nuestra ubicación, credenciales, etc. Si la generación de pruebas requiere más de 1-2 GB de memoria, eso es demasiado para la mayoría de los dispositivos móviles actuales. Se deben aclarar dos puntos:
· 2 GB de límite de espacio es aplicable a declaraciones grandes (que requieren miles de millones de ciclos de CPU para ejecutarse localmente). Los sistemas de prueba de límite de espacio solo para declaraciones pequeñas carecen de amplia aplicabilidad.
· Si el verificador de pruebas es muy lento, es fácil mantener el espacio del verificador de pruebas por debajo de 2 GB de memoria. Por lo tanto, para que la fase de memoria 1 no sea simple, pido que se cumpla la velocidad de la fase 1 dentro del límite de espacio de 2 GB.
Fase de memoria 2
La velocidad de la etapa 1 se logra con un uso de memoria inferior a 200 MB (10 veces mejor que la etapa 1 de memoria).
¿Por qué reducir a menos de 2 GB? Considere un ejemplo de no blockchain: cada vez que accede a un sitio web a través de HTTPS, descargará un certificado para la autenticación y el cifrado. En cambio, el sitio web puede enviar pruebas zk con estos certificados. Los sitios web de gran tamaño pueden emitir cientos de millones de estas pruebas por segundo. Si cada prueba requiere 2 GB de memoria para generarse, se necesitaría un total de PB de RAM. Reducir aún más el uso de memoria es crucial para implementaciones fuera de la cadena de bloques.
¿Precompilación: ¿Última milla o bastón?
En el diseño de zkVM, la precompilación se refiere a SNARK especializados hechos a medida para funciones específicas, como el hash Keccak/SHA para firmas digitales o operaciones de grupos de curvas elípticas. En Ethereum (donde la mayor parte del trabajo pesado implica hashes de Merkle y verificación de firmas), algunas precompilaciones hechas a mano pueden reducir el costo del verificador. Sin embargo, depender de ellas como muletas no permite que los SNARK logren su propósito deseado. Las razones son las siguientes:
· Para la mayoría de las aplicaciones (tanto internas como externas a la cadena de bloques) sigue siendo demasiado lento: incluso con la precompilación de hash y firmas, el zkVM actual sigue siendo demasiado lento (tanto dentro como fuera del entorno de la cadena de bloques) debido a la baja eficiencia del sistema central de pruebas.
· Fallo de seguridad: La precompilación no verificada a mano es casi seguramente propensa a errores y puede provocar fallos de seguridad catastróficos.
· Mala experiencia del desarrollador: En la mayoría de zkVM en la actualidad, agregar nuevos precompilados significa escribir manualmente un sistema de restricciones para cada función, esencialmente volviendo al flujo de trabajo de la década de 1960. Incluso al usar precompilados existentes, los desarrolladores deben refactorizar el código para llamar a cada precompilado. Deberíamos optimizar para la seguridad y la experiencia del desarrollador en lugar de sacrificar ambas en aras de buscar un rendimiento incremental. Hacerlo solo demostrará que el rendimiento no alcanza el nivel adecuado.
· I/O overhead without RAM: Although precompilations can improve the performance of heavy encryption tasks, they may not provide meaningful acceleration for more diverse workloads, as they incur significant overhead when passing input/output and cannot use RAM. Even in a blockchain environment, as long as you go beyond single-chip L1s like Ethereum (for example, if you want to build a series of cross-chain bridges), you will face different hash functions and signature schemes. Repeated precompilation on the issue is not scalable and poses significant security risks.
Por todas estas razones, nuestra tarea principal debería ser mejorar la eficiencia del zkVM subyacente. La mejor tecnología zkVM también generará los mejores precompilados. Realmente creo que los precompilados seguirán siendo crucial a largo plazo, pero siempre y cuando sean sintetizados automáticamente y verificados formalmente. De esta manera, se puede mantener la ventaja en la experiencia del desarrollador zkVM, al tiempo que se evitan riesgos de seguridad catastróficos. Este punto de vista se refleja en la etapa 3 de velocidad.
Calendario previsto
Espero que zkVM alcance la Etapa 1 de velocidad y la Etapa 1 de memoria más adelante este año. Creo que también lograremos la Etapa 2 de velocidad en los próximos dos años, pero no está claro en este momento si podremos lograr este objetivo sin algunas ideas nuevas que aún no han surgido. Estimo que los restantes pasos (Etapa 3 de velocidad y Etapa 2 de memoria) llevarán varios años para lograrse.
Resumen
Aunque he identificado por separado la seguridad y el rendimiento de zkVM en esta publicación, estos aspectos de zkVM no son completamente independientes. A medida que se descubran más vulnerabilidades en zkVM, se espera que algunas solo se puedan solucionar con una disminución significativa del rendimiento. El rendimiento debe ser pospuesto hasta que zkVM alcance el nivel de seguridad 2.
zkVM tiene el potencial de popularizar realmente las pruebas de conocimiento cero, pero todavía están en una etapa inicial, llena de desafíos de seguridad y grandes costos de rendimiento. La especulación y la publicidad dificultan evaluar los verdaderos avances. Al aclarar hitos de seguridad y rendimiento específicos, se espera proporcionar un mapa de ruta libre de distracciones. Lograremos nuestros objetivos, pero llevará tiempo y esfuerzo continuo.
Enlace al artículo original
：
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: Cómo lograr zkVM seguro y eficiente en distintas fases (imprescindible para desarrolladores)
zkVM (Zero Knowledge Virtual Machine) se compromete a 'popularizar SNARK', permitiendo a cualquier persona (incluso a aquellos sin conocimientos profesionales en SNARK) demostrar que han ejecutado correctamente cualquier programa dado en una entrada (o testigo) dada. Su principal ventaja radica en la experiencia del desarrollador, pero actualmente se enfrentan a grandes desafíos en términos de seguridad y rendimiento. Para que la visión de zkVM se haga realidad, los diseñadores deben superar estos desafíos. En este artículo, enumero las posibles etapas del desarrollo de zkVM, las cuales tomarán varios años completar.
Desafío
En términos de seguridad, zkVM es un proyecto de software altamente complejo que sigue estando lleno de vulnerabilidades. En términos de rendimiento, la velocidad de ejecución correcta del programa de prueba puede ser decenas de miles de veces más lenta que la ejecución local, lo que hace que la mayoría de las aplicaciones actualmente no puedan ser implementadas en el mundo real.
A pesar de estos desafíos del mundo real, la mayoría de las empresas en la industria blockchain describen zkVM como algo que se puede implementar de inmediato. De hecho, algunos proyectos ya han pagado una gran cantidad de costos de computación para demostrar la actividad en la cadena. Sin embargo, como zkVM aún no está completo, esto es simplemente una forma costosa de simular que el sistema está protegido por SNARK, cuando en realidad está protegido por permisos o, peor aún, es vulnerable a ataques.
Nos llevará varios años antes de lograr un zkVM seguro y de alto rendimiento. Este artículo presenta una serie de objetivos específicos escalonados para seguir el progreso de zkVM, lo que puede eliminar la especulación y ayudar a la comunidad a enfocarse en avances reales.
Fase de seguridad
Un zkVM basado en SNARK generalmente consta de dos componentes principales:
· Prueba interactiva de oráculo de polinomios (PIOP): Un marco de prueba interactivo para demostrar afirmaciones sobre polinomios (o restricciones derivadas de ellos).
· Esquema de compromiso polinomial (PCS): Asegura que el probador no puede mentir sobre la evaluación polinomial sin ser descubierto.
zkVM esencialmente codifica la ejecución efectiva en sistemas de restricciones, lo que significa que obliga a la máquina virtual a usar correctamente registros y memoria, y luego aplica SNARK para demostrar que estas restricciones se cumplen.
La única forma de asegurar que sistemas tan complejos como zkVM no tengan errores es a través de la verificación formal. A continuación se detallan las fases de seguridad. La Fase 1 se centra en el protocolo correcto, mientras que la Fase 2 y la Fase 3 se centran en la implementación correcta.
Fase de seguridad 1: Protocolo correcto
La verificación formal de la confiabilidad de PIOP;
PCS verifica la prueba en una forma vinculante en ciertas suposiciones criptográficas o modelos ideales.
3、Si se utiliza Fiat-Shamir, la prueba concisa obtenida al combinar PIOP y PCS es segura en el modelo de oráculo aleatorio como prueba formal de verificación (reforzada según sea necesario con otras suposiciones criptográficas);
El sistema de restricciones utilizado por PIOP es equivalente a la demostración de verificación formal de la semántica de VM;
5、Todos estos componentes anteriores se unen en una única prueba de SNARK segura, formalmente verificada, para ejecutar cualquier programa especificado por el bytecode de la VM. Si el protocolo tiene la intención de lograr la prueba de conocimiento cero, también se debe verificar formalmente esta propiedad para garantizar que no se divulgue información sensible sobre los testigos.
Advertencia de recursividad: Si zkVM utiliza recursividad, se debe verificar cada PIOP, esquema de compromiso y sistema de restricciones involucrados en cualquier lugar de esta recursividad antes de que se considere esta etapa como completada.
Fase de seguridad 2: Implementación correcta del validador
La implementación real del verificador de prueba zkVM (utilizando Rust, Solidity, etc.) coincide con el protocolo de verificación de fase 1. Lograr esto asegura que el protocolo implementado sea razonable (no solo un diseño en papel o una especificación ineficiente escrita en Lean, etc.).
La razón por la que la etapa 2 se centra únicamente en la implementación del verificador (en lugar del probador) tiene dos aspectos. En primer lugar, el uso correcto del verificador ya es suficiente para garantizar la confiabilidad (es decir, asegurar que el verificador no puede creer que ninguna declaración falsa sea realmente verdadera). En segundo lugar, la implementación del verificador de zkVM es al menos un orden de magnitud más simple que la implementación del probador.
Fase de seguridad 3: Implementación correcta del verificador
La implementación real del verificador zkVM genera correctamente las pruebas del sistema de verificación de las fases 1 y 2, es decir, la verificación formal. Esto garantiza la integridad, es decir, ningún sistema que utilice zkVM se quedará atascado con declaraciones no probables. Si el verificador tiene la intención de implementar el conocimiento cero, debe verificar formalmente esta propiedad.
Calendario previsto
· Fase 1 Progreso: Podemos esperar logros graduales el próximo año (por ejemplo, ZKLib). Pero al menos dentro de dos años, no hay zkVM que pueda cumplir completamente con los requisitos de la Fase 1;
· Fase 2 y Fase 3: Estas fases pueden avanzar simultáneamente con algunos aspectos de la Fase 1. Por ejemplo, algunos equipos ya han demostrado que la implementación del validador Plonk coincide con el protocolo del papel (aunque el protocolo del papel en sí mismo puede no estar completamente validado). Sin embargo, no espero que ningún zkVM alcance la Fase 3 en menos de cuatro años, y quizás más.
Consideraciones clave: seguridad Fiat-Shamir y código de bytes verificado
Un factor complicado clave es la existencia de problemas de investigación no resueltos en torno a la seguridad de la conversión Fiat-Shamir. Los tres pasos consideran a Fiat-Shamir y al oráculo aleatorio como parte de su seguridad impenetrable, pero en realidad todo el paradigma podría tener vulnerabilidades. Esto se debe a la idealización excesiva del oráculo aleatorio y las diferencias entre las funciones hash idealizadas y las utilizadas en la práctica. En el peor de los casos, un sistema que ha alcanzado la etapa 2 debido a problemas de Fiat-Shamir podría descubrirse como completamente inseguro. Esto ha generado una gran preocupación y una investigación continua. Es posible que necesitemos modificar la conversión en sí misma para prevenir mejor este tipo de vulnerabilidades.
Un sistema sin recursión es teóricamente más robusto, ya que algunos ataques conocidos implican circuitos similares a los utilizados en pruebas recursivas.
Otro aspecto importante a tener en cuenta es que si el bytecode en sí mismo tiene defectos, entonces la prueba de que el programa de computadora ha sido ejecutado correctamente (especificado por el bytecode) también tiene un valor limitado. Por lo tanto, la utilidad de zkVM depende en gran medida del método para generar bytecode de verificación formal, lo cual es un desafío enorme y está más allá del alcance de este documento.
Sobre la seguridad en la era post-cuántica
Durante al menos los próximos cinco años (quizás más), la computación cuántica no representará una amenaza grave, mientras que las vulnerabilidades son un riesgo de supervivencia. Por lo tanto, el enfoque principal en este momento debería ser cumplir con las etapas de seguridad y rendimiento discutidas en este documento. Si podemos cumplir más rápidamente con estos requisitos de seguridad utilizando SNARK no cuántico, entonces deberíamos hacerlo hasta que el SNARK poscuántico alcance, o hasta que la preocupación por la aparición de computadoras cuánticas relacionadas con la criptografía sea grave.
Estado actual del rendimiento de zkVM
Actualmente, el costo generado por el verificador zkVM es aproximadamente un millón de veces el costo de ejecución nativo. Si un programa necesita X ciclos para ejecutarse, el costo de la ejecución correcta es de aproximadamente X veces 1 millón de ciclos de CPU. Hace un año era así, y hoy sigue siéndolo.
Las narrativas populares suelen describir este gasto de una manera que suena aceptable. Por ejemplo:
·「El costo anual de generar pruebas en la red principal de Ethereum es inferior a un millón de dólares estadounidenses.」
·"Podemos generar pruebas de bloques de Ethereum en tiempo real utilizando un clúster compuesto por decenas de GPU."
·"Nuestro último zkVM es 1000 veces más rápido que su predecesor."
Aunque técnicamente precisas, estas afirmaciones pueden resultar engañosas sin el contexto adecuado. Por ejemplo:
· zkVM ### es 1000 veces más rápido que la versión anterior, pero sigue siendo muy lento en términos absolutos. Esto indica más cuán malas son las cosas en lugar de cuán buenas.
· Alguien ha propuesto aumentar en 10 veces la cantidad de cálculos procesados en la red principal de Ethereum. Esto hará que el rendimiento actual de zkVM sea más lento.
La llamada "prueba de casi tiempo real" de los bloques de Ethereum sigue siendo mucho más lenta que la requerida por 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).
·"Varios GPU funcionando constantemente sin errores" no pueden alcanzar una garantía de actividad aceptable.
· Menos de un millón de dólares al año para demostrar que todas las actividades en la red principal de Ethereum reflejan el hecho de que solo se necesitan alrededor de 25 dólares al año para que un nodo completo de Ethereum realice cálculos.
Para aplicaciones fuera de la cadena de bloques, este tipo de gastos obviamente es demasiado alto. Ninguna paralelización o ingeniería puede compensar un gasto tan grande. Deberíamos tomar como referencia básica una velocidad para zkVM que sea no más de 100,000 veces más lenta que la ejecución nativa, incluso si eso es solo el primer paso. La adopción real a gran escala podría requerir un gasto cercano a 10,000 veces o incluso menor.
Cómo medir el rendimiento
El rendimiento SNARK tiene tres componentes principales:
· La eficiencia intrínseca del sistema de prueba de trabajo.
Optimización específica de la aplicación (por ejemplo, precompilación).
· Ingeniería y aceleración de hardware (como GPU, FPGA o CPU multicore).
Aunque ambos son críticos para la implementación real, a menudo son aplicables a cualquier sistema de prueba, por lo que no necesariamente reflejan los costos fundamentales. Por ejemplo, agregar aceleración GPU y precompilación en zkEVM puede lograr fácilmente una aceleración de 50 veces, mucho más rápido que los métodos sin precompilación puramente basados en CPU, lo que hace que un sistema intrínsecamente menos eficiente parezca mejor que un sistema sin el mismo pulido.
Por lo tanto, a continuación se presenta el rendimiento de SNARK sin hardware especial y precompilado. Esto difiere del método de prueba de referencia actual, que suele agrupar los tres factores en un 'número de título'. Esto sería equivalente a evaluar el valor de un diamante en función del tiempo de pulido en lugar de su pureza intrínseca. Nuestro objetivo es eliminar los gastos internos del sistema de prueba de generalidad, ayudando a la comunidad a eliminar factores confusos y centrarse en el verdadero progreso del diseño del sistema de prueba.
Etapa de rendimiento
A continuación se presentan 5 hitos en el rendimiento logrados. En primer lugar, debemos reducir en varios órdenes de magnitud los costos del verificador en la CPU. Solo así debería centrarse en seguir reduciendo a través de hardware. También es necesario aumentar la tasa de uso de la memoria.
En todas las etapas a continuación, los desarrolladores no necesitan implementar un código personalizado según la configuración de zkVM para lograr el rendimiento necesario. La experiencia del desarrollador es la principal ventaja de zkVM. Sacrificar DevEx para cumplir con los estándares de rendimiento va en contra del propósito mismo de zkVM.
Estos indicadores se centran en el costo del verificador. Sin embargo, si se permite un costo ilimitado para el verificador (es decir, no hay límite en el tamaño de la prueba o en el tiempo de verificación), se puede cumplir fácilmente cualquier indicador del verificador. Por lo tanto, para que el sistema cumpla con la etapa mencionada, se deben especificar límites máximos para el tamaño de la prueba y el tiempo de verificación.
requisitos de rendimiento
Fase 1 Requisito: 'Costo de verificación razonable y no trivial':
· Tamaño de prueba: El tamaño de la prueba debe ser menor que el tamaño de la firma.
· El tiempo de verificación: la velocidad de verificación de la prueba no debe ser más lenta que la ejecución del programa en la máquina local (es decir, realizar cálculos sin la verificación de la corrección).
Estos son los requisitos mínimos de concisión. Se aseguran de que el tamaño de la prueba y el tiempo de verificación no sean peores que enviar el testigo al validador y permitir que el validador lo verifique directamente.
Fase 2 y posteriores requisitos:
· Tamaño de prueba máximo: 256 KB。
· Tiempo de validación máximo: 16 milisegundos.
Estos valores de umbral se han establecido intencionalmente en un nivel más alto para adaptarse a las nuevas tecnologías de prueba de rapidez que pueden acarrear costos de verificación más altos. Al mismo tiempo, excluyen pruebas muy costosas, por lo que pocos proyectos están dispuestos a incluirlas en la cadena de bloques.
Etapa de Velocidad 1
La prueba de hilo único debe ser al menos cien mil veces más lenta que la ejecución local, medida en una serie de aplicaciones (no solo pruebas de bloques de Ethereum), sin depender de la compilación previa.
Específicamente, imagine un proceso RISC-V que se ejecuta en un ordenador portátil moderno a aproximadamente 30 mil millones de ciclos por segundo. Lograr la Fase 1 significa que puede demostrar aproximadamente 30,000 ciclos RISC-V por segundo en el mismo ordenador portátil (un solo hilo). Sin embargo, el costo de verificación debe ser "razonable y no trivial", como se mencionó anteriormente.
Etapa de velocidad 2
La prueba de un solo hilo debe ser como máximo diez mil veces más lenta que la ejecución en el dispositivo local.
O, debido a que algunos prometedores métodos SNARK (especialmente los basados en campos binarios) están siendo obstaculizados por las actuales CPU y GPU, puede considerar el uso de FPGA (incluso ASIC) para alcanzar esta etapa:
La cantidad de núcleos RISC-V que se pueden simular a la velocidad nativa en un FPGA;
Simular y demostrar (casi) la cantidad de FPGA necesarios para ejecutar RISC-V en tiempo real.
Si el segundo es como máximo 10, 000 veces mayor que el primero, calificará para la segunda etapa. En una CPU estándar, el tamaño de la prueba debe ser como máximo de 256 KB y el tiempo del validador como máximo de 16 milisegundos.
Fase de velocidad 3
Además de alcanzar la etapa 2 de velocidad, también se puede utilizar la precompilación con síntesis automática y verificación de forma para lograr gastos de demostración de menos de 1000 veces (aplicable a una amplia gama de aplicaciones). Básicamente, se puede personalizar dinámicamente un conjunto de instrucciones para cada programa para acelerar la demostración, pero debe hacerse de manera fácil de usar y verificar formalmente.
Fase de memoria 1
La velocidad de la Fase 1 se logra con menos de 2 GB de memoria requerida en el verificador (junto con la prueba de conocimiento cero).
Esto es crucial para muchos dispositivos móviles o navegadores, por lo que ha habilitado innumerables casos de uso de zkVM del lado del cliente. La prueba del cliente es fundamental, ya que nuestros teléfonos móviles son nuestra conexión continua con el mundo real: rastrean nuestra ubicación, credenciales, etc. Si la generación de pruebas requiere más de 1-2 GB de memoria, eso es demasiado para la mayoría de los dispositivos móviles actuales. Se deben aclarar dos puntos:
· 2 GB de límite de espacio es aplicable a declaraciones grandes (que requieren miles de millones de ciclos de CPU para ejecutarse localmente). Los sistemas de prueba de límite de espacio solo para declaraciones pequeñas carecen de amplia aplicabilidad.
· Si el verificador de pruebas es muy lento, es fácil mantener el espacio del verificador de pruebas por debajo de 2 GB de memoria. Por lo tanto, para que la fase de memoria 1 no sea simple, pido que se cumpla la velocidad de la fase 1 dentro del límite de espacio de 2 GB.
Fase de memoria 2
La velocidad de la etapa 1 se logra con un uso de memoria inferior a 200 MB (10 veces mejor que la etapa 1 de memoria).
¿Por qué reducir a menos de 2 GB? Considere un ejemplo de no blockchain: cada vez que accede a un sitio web a través de HTTPS, descargará un certificado para la autenticación y el cifrado. En cambio, el sitio web puede enviar pruebas zk con estos certificados. Los sitios web de gran tamaño pueden emitir cientos de millones de estas pruebas por segundo. Si cada prueba requiere 2 GB de memoria para generarse, se necesitaría un total de PB de RAM. Reducir aún más el uso de memoria es crucial para implementaciones fuera de la cadena de bloques.
¿Precompilación: ¿Última milla o bastón?
En el diseño de zkVM, la precompilación se refiere a SNARK especializados hechos a medida para funciones específicas, como el hash Keccak/SHA para firmas digitales o operaciones de grupos de curvas elípticas. En Ethereum (donde la mayor parte del trabajo pesado implica hashes de Merkle y verificación de firmas), algunas precompilaciones hechas a mano pueden reducir el costo del verificador. Sin embargo, depender de ellas como muletas no permite que los SNARK logren su propósito deseado. Las razones son las siguientes:
· Para la mayoría de las aplicaciones (tanto internas como externas a la cadena de bloques) sigue siendo demasiado lento: incluso con la precompilación de hash y firmas, el zkVM actual sigue siendo demasiado lento (tanto dentro como fuera del entorno de la cadena de bloques) debido a la baja eficiencia del sistema central de pruebas.
· Fallo de seguridad: La precompilación no verificada a mano es casi seguramente propensa a errores y puede provocar fallos de seguridad catastróficos.
· Mala experiencia del desarrollador: En la mayoría de zkVM en la actualidad, agregar nuevos precompilados significa escribir manualmente un sistema de restricciones para cada función, esencialmente volviendo al flujo de trabajo de la década de 1960. Incluso al usar precompilados existentes, los desarrolladores deben refactorizar el código para llamar a cada precompilado. Deberíamos optimizar para la seguridad y la experiencia del desarrollador en lugar de sacrificar ambas en aras de buscar un rendimiento incremental. Hacerlo solo demostrará que el rendimiento no alcanza el nivel adecuado.
· I/O overhead without RAM: Although precompilations can improve the performance of heavy encryption tasks, they may not provide meaningful acceleration for more diverse workloads, as they incur significant overhead when passing input/output and cannot use RAM. Even in a blockchain environment, as long as you go beyond single-chip L1s like Ethereum (for example, if you want to build a series of cross-chain bridges), you will face different hash functions and signature schemes. Repeated precompilation on the issue is not scalable and poses significant security risks.
Por todas estas razones, nuestra tarea principal debería ser mejorar la eficiencia del zkVM subyacente. La mejor tecnología zkVM también generará los mejores precompilados. Realmente creo que los precompilados seguirán siendo crucial a largo plazo, pero siempre y cuando sean sintetizados automáticamente y verificados formalmente. De esta manera, se puede mantener la ventaja en la experiencia del desarrollador zkVM, al tiempo que se evitan riesgos de seguridad catastróficos. Este punto de vista se refleja en la etapa 3 de velocidad.
Calendario previsto
Espero que zkVM alcance la Etapa 1 de velocidad y la Etapa 1 de memoria más adelante este año. Creo que también lograremos la Etapa 2 de velocidad en los próximos dos años, pero no está claro en este momento si podremos lograr este objetivo sin algunas ideas nuevas que aún no han surgido. Estimo que los restantes pasos (Etapa 3 de velocidad y Etapa 2 de memoria) llevarán varios años para lograrse.
Resumen
Aunque he identificado por separado la seguridad y el rendimiento de zkVM en esta publicación, estos aspectos de zkVM no son completamente independientes. A medida que se descubran más vulnerabilidades en zkVM, se espera que algunas solo se puedan solucionar con una disminución significativa del rendimiento. El rendimiento debe ser pospuesto hasta que zkVM alcance el nivel de seguridad 2.
zkVM tiene el potencial de popularizar realmente las pruebas de conocimiento cero, pero todavía están en una etapa inicial, llena de desafíos de seguridad y grandes costos de rendimiento. La especulación y la publicidad dificultan evaluar los verdaderos avances. Al aclarar hitos de seguridad y rendimiento específicos, se espera proporcionar un mapa de ruta libre de distracciones. Lograremos nuestros objetivos, pero llevará tiempo y esfuerzo continuo.
Enlace al artículo original
：