a16z: Cómo implementar zkVM de forma segura y eficiente por fases (lectura imprescindible para desarrolladores)

Título original: El camino hacia zkVM seguras y eficientes: cómo hacer seguimiento del progreso

Autor original: a16z crypto

Traducción original: Golem, Odaily Planet Daily Golem

zkVM (máquina virtual de conocimiento cero) promete «popularizar los SNARK», al permitir que cualquiera (incluso sin conocimientos especializados en SNARK) demuestre que ejecutó correctamente cualquier programa con una entrada determinada (o testigo). Su principal ventaja está en la experiencia de desarrollo, pero actualmente enfrenta importantes desafíos de seguridad y rendimiento. Para cumplir la visión de zkVM, sus diseñadores deben superar estos retos. En este artículo, describo las posibles etapas del desarrollo de zkVM, que tardará varios años en completarse.

Desafíos

En términos de seguridad, zkVM es un proyecto de software muy complejo que todavía está plagado de vulnerabilidades. En cuanto al rendimiento, la velocidad para demostrar que un programa se ejecutó correctamente puede ser varios órdenes de magnitud más lenta que la ejecución nativa, lo que hace que desplegarla en el mundo real resulte poco práctico para la mayoría de las aplicaciones.

A pesar de estos desafíos del mundo real, la mayoría de las empresas de la industria blockchain presenta zkVM como una tecnología lista para desplegarse de inmediato. De hecho, algunos proyectos ya han pagado costos computacionales considerables para generar pruebas de actividad on-chain. Sin embargo, como zkVM todavía es imperfecta, esto no es más que una forma costosa de fingir que el sistema está protegido por SNARK cuando, en realidad, está protegido mediante permisos o, peor aún, es vulnerable a ataques.

Aún faltan varios años para lograr una zkVM segura y de alto rendimiento. Este artículo propone una serie de objetivos específicos por etapas para hacer seguimiento del progreso de zkVM: objetivos que pueden acabar con el hype y ayudar a la comunidad a enfocarse en avances reales.

Etapas de seguridad

Las zkVM basadas en SNARK suelen incluir dos componentes principales:

· Prueba de oráculo interactiva polinomial (PIOP): se utiliza para demostrar afirmaciones sobre polinomios (o restricciones derivadas de ellos) dentro de un marco de pruebas interactivas.

· Esquema de compromiso polinomial (PCS): garantiza que el probador no pueda mentir sobre las evaluaciones de polinomios sin que lo descubran.

zkVM transforma fundamentalmente una ejecución eficiente en un sistema de restricciones —lo que, en términos generales, significa que obliga a la máquina virtual a usar correctamente los registros y la memoria— y luego aplica SNARK para demostrar que se cumplen esas restricciones.

La verificación formal permite garantizar que sistemas complejos como zkVM estén libres de errores. A continuación, se desglosan las etapas de seguridad. La Fase 1 se centra en que el protocolo sea correcto, mientras que las Fases 2 y 3 se enfocan en que la implementación sea correcta.

Fase 1 de seguridad: protocolo correcto

1. Prueba de verificación formal de la confiabilidad de PIOP;

2. Prueba de verificación formal de que PCS es eficaz bajo ciertos supuestos criptográficos o modelos ideales;

3. Si se utiliza Fiat-Shamir, prueba de verificación formal de que el argumento conciso obtenido al combinar PIOP y PCS es seguro en el modelo de oráculo aleatorio (reforzada con otros supuestos criptográficos, según sea necesario);

4. Prueba de verificación formal de que el sistema de restricciones usado por PIOP es equivalente a la semántica de la VM;

5. Integrar todas las partes anteriores en una prueba SNARK segura, unificada y verificada formalmente para ejecutar cualquier programa especificado por el bytecode de la VM. Si el protocolo busca propiedades de conocimiento cero, también debe verificarse formalmente este atributo para evitar que se filtre información confidencial sobre los testigos.

Alerta sobre recursión: si zkVM utiliza recursión, es necesario verificar cada PIOP, esquema de compromiso y sistema de restricciones que intervenga en cualquier punto de la recursión para considerar completa esta fase.

Fase 2 de seguridad: implementación correcta del validador

Verificar formalmente que la implementación del validador de zkVM (en Rust, Solidity, etc.) coincida con el protocolo validado en la Fase 1. Lograrlo garantiza que el protocolo implementado sea sólido (y no solo un diseño teórico o una especificación ineficiente escrita, por ejemplo, en Lean).

Hay dos razones por las que la Fase 2 se ocupa únicamente de la implementación del validador (y no del probador). Primero, garantizar el uso correcto del validador es suficiente para asegurar la confiabilidad (es decir, garantizar que el validador no pueda aceptar como verdaderas afirmaciones falsas). Segundo, la implementación del validador de zkVM es más de un orden de magnitud más sencilla que la implementación del probador.

Fase 3 de seguridad: implementación correcta del probador

La implementación real del probador de zkVM genera correctamente el sistema de pruebas para la verificación de las Fases 1 y 2; es decir, logra la verificación formal. Esto garantiza la completitud, lo que significa que ningún sistema que use zkVM se quedará «atascado» con afirmaciones imposibles de demostrar. Si el probador busca lograr conocimiento cero, esta propiedad también debe verificarse formalmente.

Plazos previstos

· Avance de la Fase 1: podemos esperar avances graduales el próximo año (por ejemplo, ZKLib). Sin embargo, pasarán al menos dos años antes de que cualquier zkVM pueda cumplir por completo los requisitos de la Fase 1;

· Fases 2 y 3: estas fases pueden avanzar en paralelo con algunos aspectos de la Fase 1. Por ejemplo, algunos equipos ya han demostrado que la implementación del probador de Plonk coincide con el protocolo descrito en el artículo (aunque el propio protocolo del artículo quizá no esté validado por completo). Aun así, creo que ninguna zkVM llegará a la Fase 3 en menos de cuatro años, y posiblemente tarde más.

Puntos clave: seguridad de Fiat-Shamir y bytecode verificado

Un factor que complica mucho la situación son los problemas de investigación aún sin resolver en torno a la seguridad de la transformación Fiat-Shamir. Las tres fases consideran Fiat-Shamir y el oráculo aleatorio parte de su seguridad a prueba de todo, pero, en realidad, todo el paradigma podría tener vulnerabilidades. Esto se debe a una idealización excesiva del oráculo aleatorio y a las diferencias con las funciones hash prácticas. En el peor de los casos, más adelante podría descubrirse que un sistema que llegó a la Fase 2 es totalmente inseguro debido a problemas de Fiat-Shamir. Esto ha generado serias preocupaciones y una investigación en curso. Quizá debamos modificar la propia transformación para mitigar mejor estas vulnerabilidades.

En teoría, los sistemas no recursivos son más robustos, porque algunos ataques conocidos involucran circuitos similares a los que se utilizan en pruebas recursivas.

Otro aspecto que hay que tener en cuenta es que, si el propio bytecode tiene fallas, el valor de una prueba exitosa de la ejecución correcta de un programa informático (especificado mediante bytecode) es limitado. Por lo tanto, la viabilidad práctica de zkVM depende en gran medida del método para generar bytecode verificado formalmente, un desafío importante que queda fuera del alcance de este artículo.

Sobre la seguridad poscuántica

Al menos durante los próximos cinco años (y posiblemente más), la computación cuántica no representará una amenaza grave, mientras que las vulnerabilidades sí suponen un riesgo existencial. Por eso, el enfoque principal ahora debería estar en alcanzar las etapas de seguridad y rendimiento que se analizan en este artículo. Si podemos cumplir estos requisitos de seguridad más rápido con SNARK no seguros frente a la computación cuántica, deberíamos hacerlo hasta que los SNARK poscuánticos estén a la altura o surjan preocupaciones serias sobre una computación cuántica relevante desde el punto de vista criptográfico.

Estado del rendimiento de zkVM

Actualmente, el factor de sobrecosto del probador de zkVM se acerca a 1,000,000 veces el costo de la ejecución nativa. Si un programa tarda X ciclos en ejecutarse, demostrar que su ejecución fue correcta cuesta aproximadamente X multiplicado por 1,000,000 ciclos de CPU. Así era hace un año y así sigue siendo hoy.

Las narrativas populares suelen describir este sobrecosto de una forma que parece aceptable. Por ejemplo:

· «Generar una prueba de todas las transacciones de la red principal de Ethereum durante un año cuesta menos de un millón de dólares».

· «Casi podemos generar pruebas de bloques de Ethereum en tiempo real con un clúster de decenas de GPU».

· «Nuestra zkVM más reciente es 1,000 veces más rápida que su predecesora».

Aunque estas afirmaciones son técnicamente precisas, pueden resultar engañosas si no se presentan con el contexto adecuado. Por ejemplo:

· Es 1,000 veces más rápida que la versión anterior de zkVM, pero la velocidad absoluta sigue siendo muy lenta. Esto refleja más lo mal que estaban las cosas que lo bien que están ahora.

· Se han presentado propuestas para aumentar 10 veces la carga computacional de la red principal de Ethereum. Esto haría que el rendimiento actual de zkVM fuera más lento.

· Lo que se denomina «prueba casi en tiempo real de bloques de Ethereum» sigue siendo mucho más lento de lo que requieren muchas aplicaciones blockchain (por ejemplo, Optmism tiene un tiempo de bloque de 2 segundos, mucho más rápido que los 12 segundos de Ethereum).

· «Un clúster de decenas de GPU que siempre funciona a la perfección» no puede ofrecer una garantía de disponibilidad aceptable.

· Gastar menos de un millón de dólares al año para demostrar toda la actividad de la red principal de Ethereum refleja que un nodo completo de Ethereum solo necesita gastar aproximadamente $25 al año para realizar cálculos.

Para las aplicaciones ajenas a blockchain, este sobrecosto es claramente demasiado alto. Ninguna cantidad de paralelización o ingeniería puede compensar un sobrecosto tan enorme. Deberíamos adoptar como referencia básica que la ralentización de zkVM frente a la ejecución nativa no supere 100,000 veces, aunque esto sea solo el primer paso. La adopción generalizada real podría requerir un sobrecosto cercano a 10,000 veces o menos.

Medición del rendimiento

El rendimiento de SNARK tiene tres componentes principales:

· Eficiencia intrínseca del sistema de pruebas subyacente.

· Optimizaciones específicas para cada aplicación (por ejemplo, precompilación).

· Ingeniería y aceleración por hardware (por ejemplo, GPU, FPGA o CPU multinúcleo).

Aunque los dos últimos factores son cruciales para el despliegue en el mundo real, suelen aplicarse a cualquier sistema de pruebas, por lo que no necesariamente reflejan el sobrecosto subyacente. Por ejemplo, añadir aceleración por GPU y precompilación a zkEVM puede fácilmente aumentar la velocidad 50x, mucho más que un enfoque que use solo CPU y no tenga precompilación; esto basta para que un sistema intrínsecamente menos eficiente parezca superior a otro que no haya recibido el mismo nivel de optimización.

Por lo tanto, a continuación nos enfocamos en el rendimiento de SNARK sin hardware especializado ni precompilación. Esto difiere del enfoque actual de evaluación comparativa, que suele agrupar los tres factores en una sola «cifra destacada». Es como juzgar el valor de un diamante por el tiempo que tomó pulirlo y no por su claridad intrínseca. Nuestro objetivo es eliminar el sobrecosto intrínseco de un sistema de pruebas genérico, para ayudar a la comunidad a eliminar variables de confusión y centrarse en el progreso real del diseño de sistemas de pruebas.

Etapas de rendimiento

Estos son 5 hitos de rendimiento. Primero, debemos reducir en varios órdenes de magnitud el sobrecosto del verificador en la CPU. Solo entonces deberíamos centrarnos en lograr reducciones adicionales mediante hardware. También es necesario aumentar el uso de memoria.

En todas las etapas que se indican a continuación, los desarrolladores no deberían tener que implementar código personalizado para zkVM a fin de alcanzar el rendimiento necesario. La experiencia de desarrollo es una ventaja clave de zkVM. Sacrificar DevEx para cumplir los indicadores de rendimiento contradiría la esencia misma de zkVM.

Estas métricas se centran en el costo del probador. Sin embargo, si se permite un costo ilimitado para el verificador (es decir, no hay límites en el tamaño de la prueba ni en el tiempo de verificación), cualquier métrica del probador se puede alcanzar fácilmente. Por lo tanto, para que los sistemas cumplan las etapas descritas, es necesario especificar valores máximos para el tamaño de la prueba y el tiempo de verificación.

Requisitos de rendimiento

Requisito de la Fase 1: «Costo de verificación razonable y no trivial»:

· Tamaño de la prueba: debe ser menor que el tamaño del testigo.

· Tiempo de verificación: la velocidad de verificación de la prueba no debe ser inferior a la de ejecutar el programa de forma nativa (es decir, realizar el cálculo sin una prueba de corrección).

Estos son requisitos mínimos y concisos. Garantizan que el tamaño de la prueba y el tiempo de verificación no sean peores que simplemente enviar el testigo al verificador y hacer que este compruebe directamente si es correcto.

Requisitos para la Fase 2 y posteriores:

· Tamaño máximo de la prueba: 256 KB.

· Tiempo máximo de verificación: 16 milisegundos.

Estos umbrales se establecieron intencionalmente en valores altos para dar cabida a nuevas tecnologías de pruebas rápidas que podrían implicar mayores costos de verificación. Al mismo tiempo, excluyen las pruebas muy costosas que pocos proyectos estarían dispuestos a incluir en la blockchain.

Fase 1 de velocidad

Una prueba de un solo hilo debe ser como máximo 100.000 veces más lenta que la ejecución nativa, medida en diversas aplicaciones (no solo en pruebas de bloques de Ethereum) y sin depender de precompilaciones.

En concreto, pensemos en un proceso RISC-V que se ejecuta a unos 30.000 M ciclos por segundo en una laptop moderna. Alcanzar la Fase 1 significa poder generar pruebas a una velocidad aproximada de 30,000 ciclos RISC-V por segundo en esa misma laptop (con un solo hilo). Sin embargo, el costo de verificación debe ser, como se mencionó antes, «razonable, pero no trivial».

Fase 2 de velocidad

Una prueba de un solo hilo debe ser como máximo 10.000 veces más lenta que la ejecución nativa.

Como alternativa, dado que algunas técnicas SNARK prometedoras (especialmente las basadas en campos binarios) se ven limitadas por las CPU y GPU actuales, se puede alcanzar esta etapa comparando con el uso de una FPGA (o incluso un ASIC):

La cantidad de núcleos RISC-V que una FPGA puede simular de forma nativa;

La cantidad de FPGA necesaria para simular y demostrar una ejecución de RISC-V en tiempo (casi) real.

Si la segunda cantidad supera a la primera en como máximo 10.000 veces, se cumple el requisito de la Fase 2. En una CPU estándar, el tamaño de la prueba debe ser como máximo 256 KB y el tiempo de validación debe ser como máximo 16 milisegundos.

Fase 3 de velocidad

Además de alcanzar la Fase 2 de velocidad, también se pueden usar implementaciones precompiladas, sintetizadas automáticamente y verificadas formalmente, con costos de prueba inferiores a 1,000 veces (adecuadas para una amplia variedad de aplicaciones). En esencia, se puede personalizar dinámicamente un conjunto de instrucciones para cada programa a fin de acelerar la prueba, pero hay que hacerlo de una forma fácil de usar y verificada formalmente.

Fase 1 de memoria

La velocidad de la Fase 1 se alcanza cuando el probador requiere menos de 2 GB de memoria (y, a la vez, logra conocimiento cero).

Esto es crucial para muchos dispositivos móviles y navegadores, y abre innumerables casos de uso de zkVM en el cliente. Las pruebas en el cliente son importantes porque nuestros teléfonos son nuestro contacto continuo con el mundo real: registran nuestra ubicación, credenciales, etc. Si generar una prueba requiere más de 1-2 GB de memoria, es demasiado para la mayoría de los dispositivos móviles actuales. Hay que aclarar dos puntos:

· El límite de espacio de 2 GB se aplica a afirmaciones grandes (las que requieren billones de ciclos de CPU para ejecutarse localmente). Los sistemas de pruebas que solo imponen un límite de espacio para afirmaciones pequeñas no tienen una aplicabilidad amplia.

· Si un probador es muy lento, es fácil mantener su uso de memoria por debajo de 2 GB. Por lo tanto, para que la Fase 1 de memoria sea un objetivo significativo, exijo que se alcance la Fase 1 de velocidad dentro de este límite de espacio de 2 GB.

Fase 2 de memoria

La velocidad de la Fase 1 se alcanza con un uso de memoria inferior a 200 MB (10 veces mejor que en la Fase 1 de memoria).

¿Por qué reducirlo a menos de 2 GB? Pensemos en un ejemplo ajeno a blockchain: cada vez que visitas un sitio web mediante HTTPS, descargas un certificado para identificarte y cifrar la comunicación. En su lugar, el sitio web podría enviar pruebas zk junto con esos certificados. Un sitio web grande podría emitir millones de estas pruebas por segundo. Si generar cada prueba requiere 2 GB de memoria, se necesitaría un total de RAM del orden de PB. Reducir aún más el uso de memoria es fundamental para los despliegues ajenos a blockchain.

Precompilaciones: ¿último paso o muleta?

En el diseño de zkVM, las precompilaciones son SNARK especializados (o sistemas de restricciones) adaptados a funciones específicas, como el hashing Keccak/SHA para firmas digitales o las operaciones de grupo de curvas elípticas. En Ethereum (donde gran parte del trabajo pesado consiste en hashing de Merkle y verificación de firmas), algunas precompilaciones hechas a mano pueden reducir los costos del verificador. Sin embargo, depender de ellas como muleta impide que SNARK cumpla su propósito. Estas son las razones:

· Siguen siendo demasiado lentas para la mayoría de las aplicaciones (tanto dentro como fuera de blockchain): incluso con precompilaciones para hashing y firmas, la zkVM actual sigue siendo demasiado lenta (dentro y fuera de entornos blockchain) debido a la ineficiencia del sistema de pruebas central.

· Fallas de seguridad: es casi seguro que las precompilaciones escritas a mano y no verificadas formalmente están plagadas de errores, lo que podría provocar fallas de seguridad catastróficas.

· Mala experiencia de desarrollo: en la mayoría de las zkVM actuales, añadir una nueva precompilación significa escribir manualmente un sistema de restricciones para cada funcionalidad, lo que en esencia devuelve el proceso a un flujo de trabajo propio de la década de 1960. Incluso con las precompilaciones existentes, los desarrolladores deben refactorizar el código para invocar cada una. Deberíamos optimizar la seguridad y la experiencia de desarrollo, en vez de sacrificar ambas para conseguir mejoras incrementales de rendimiento. Hacerlo solo demuestra que el rendimiento no ha alcanzado su verdadero potencial.

· Sobrecosto de E/S y falta de RAM: aunque las precompilaciones pueden mejorar el rendimiento de las tareas criptográficas pesadas, quizá no aceleren de manera significativa cargas de trabajo más diversas, ya que implican un sobrecosto considerable al procesar entradas y salidas y no pueden usar RAM. Incluso en un contexto blockchain, en cuanto vas más allá de una sola L1 como Ethereum (por ejemplo, si quieres crear una serie de puentes entre cadenas), te encuentras con distintas funciones hash y esquemas de firma. Rehacer las precompilaciones una y otra vez para resolver el mismo problema no es escalable y plantea riesgos de seguridad considerables.

Por todas estas razones, nuestra tarea principal debería ser mejorar la eficiencia de la zkVM subyacente. La tecnología que produzca la mejor zkVM también producirá las mejores precompilaciones. Creo que las precompilaciones seguirán siendo cruciales a largo plazo, pero solo si se sintetizan automáticamente y se verifican formalmente. Así, podremos conservar la ventaja de zkVM en experiencia de desarrollo y, al mismo tiempo, evitar riesgos de seguridad desastrosos. Esta perspectiva se refleja en la Fase 3 de velocidad.

Plazos previstos

Espero que algunas zkVM alcancen la Fase 1 de velocidad y la Fase 1 de memoria más adelante este año. También anticipo que la Fase 2 de velocidad se alcanzará dentro de los próximos dos años, aunque por el momento no está claro si podremos lograrlo sin ideas nuevas que todavía no han surgido. Creo que completar las fases restantes (Fase 3 de velocidad y Fase 2 de memoria) tomará algunos años más.

Conclusión

Aunque en este artículo he descrito por separado las etapas de seguridad y rendimiento de zkVM, estos aspectos no son totalmente independientes. A medida que se descubran más vulnerabilidades en zkVM, es probable que algunas solo puedan corregirse a costa de una pérdida considerable de rendimiento. El rendimiento debería dejarse para después, hasta que zkVM alcance la Fase 2 de seguridad.

zkVM promete democratizar de verdad las pruebas de conocimiento cero, pero aún está en sus inicios: está plagada de desafíos de seguridad y de un sobrecosto considerable de rendimiento. El hype y el marketing dificultan evaluar el progreso real. Al establecer hitos claros de seguridad y rendimiento, esta hoja de ruta busca ofrecer un camino a seguir sin distracciones. Alcanzaremos estos objetivos, pero hará falta tiempo y un esfuerzo sostenido.

Enlace al artículo original