a16z: Elementos clave para los creadores: ‘Jolt Inside’

Autor del artículo: a16z crypto

Traducción del artículo: Block unicorn

Introducción

Hoy, LayerZero ha lanzado su nueva cadena Zero, que incluye múltiples avances tecnológicos, entre ellos un método completamente nuevo de prueba de conocimiento cero que desacopla la ejecución y la verificación de transacciones. Todo esto gracias a “Jolt Inside”.

¿Pero qué es Jolt? Jolt es una máquina virtual zk open source basada en RISC-V (o más precisamente, una máquina virtual “sencilla”), que es rápida, segura y fácil de usar. Representa un enfoque completamente nuevo y avanzado en el diseño de SNARK, desarrollado por a16z crypto durante tres años, y lo haremos open source para que cualquiera pueda usarlo o desarrollarlo aún más. Pero la historia de Jolt en realidad lleva décadas gestándose.

¿Por qué son tan importantes el diseño de zkVM y SNARK?

Antes de profundizar en la evolución del diseño de SNARK, primero debemos entender qué es una zkVM.

Este tipo de máquinas virtuales suelen llamarse “zk”, pero aquí lo que más importa es la sencillez. Aunque la “prueba de conocimiento cero” es fundamental para la privacidad, “sencillez” significa que la prueba es corta y fácil de verificar — dos características útiles pero distintas, que a menudo se confunden. (Jolt ya tiene la propiedad de sencillez y pronto también implementará conocimiento cero).

Pero, ¿por qué son tan importantes las zkVM? La zkVM y, en un sentido más amplio, los SNARK (pruebas de conocimiento no interactivo y sencillo) son componentes clave para la escalabilidad, privacidad y seguridad en blockchain. Estas pruebas, argumentos y conocimientos cero (en conjunto, tecnologías de computación verificable) tienen innumerables aplicaciones en la industria de la criptografía y otros campos.

Por diversas razones de diseño y otras, la industria ha adoptado métodos bastante complejos para construir zkVMs; en lo que sigue explicaremos esto con más detalle. Sin embargo, Jolt desde el principio se centró en un enfoque radicalmente diferente en el diseño de SNARK, con el objetivo de lograr mayor eficiencia, usabilidad y rendimiento.

En resumen, una zkVM es un método para demostrar que has ejecutado correctamente un programa de computadora. La ventaja de la zkVM frente a otros SNARK es su amigabilidad para los desarrolladores. Aprovechando infraestructuras de cómputo existentes (como el ecosistema de compiladores LLVM open source), los desarrolladores pueden usar SNARK en su lenguaje de programación preferido sin necesidad de un lenguaje específico de dominio (DSL).

Esto es muy similar a lo que ocurre en muchas áreas modernas de criptografía: contamos con estándares y bibliotecas integradas para cifrado y firmas digitales — que los desarrolladores usan a diario sin entender en detalle cómo funcionan internamente. Jolt ofrece una capa de abstracción similar: simplemente usan su código existente y lo verifican, sin preocuparse por la interacción entre ambos. Esto es un requisito fundamental para la adopción masiva de nuevas aplicaciones criptográficas.

Los desarrolladores pueden centrarse en la lógica práctica. Con Jolt, no necesitan conocimientos especializados en SNARK: solo presionan un botón y generan una prueba Jolt a partir de su código de computadora.

Pero, aunque Jolt ha avanzado mucho, generar una prueba para tareas de complejidad media (por ejemplo, una operación en un solo núcleo de CPU durante un segundo) todavía requiere una potencia computacional significativa. Para crear pruebas complejas en tiempos razonables, se necesitan varias GPU. LayerZero ha portado el generador de pruebas de Jolt a CUDA y ha lanzado Zero: combina algoritmos altamente paralelizables de Jolt con hardware GPU para escalar aún más.

LayerZero trabaja para llevar Jolt a producción en GPU, incluyendo versiones optimizadas para GPU en colaboración con nosotros, lo cual es crucial para mejorar la escalabilidad de zkVM y las pruebas.

Investigación y desarrollo open source

Jolt es open source, por lo que cualquiera puede usarlo o desarrollarlo basándose en sus innovaciones. La apertura es un multiplicador definitivo: compartir resultados públicamente permite que más personas en el ecosistema los utilicen, reutilicen, sometan a pruebas, auditorías, reparaciones y mejorías, y construyan sobre ello nuevas innovaciones.

Invertir en proyectos open source puede parecer inusual, pero la estructura moderna de I+D hace que la mayor parte del trabajo de desarrollo ocurra en empresas (como antiguos laboratorios corporativos o laboratorios de fundaciones) o en la academia. La creación de a16z crypto busca precisamente conectar la teoría académica con la práctica industrial, formando un laboratorio de investigación y un equipo de ingeniería. Como firma de inversión, también podemos financiar proyectos que otras instituciones no puedan, especialmente en inversiones en reverso.

El apoyo a un método de diseño de SNARK basado en reverse engineering es especialmente importante para Jolt, porque representa un cambio de paradigma radical y diferente a los enfoques tradicionales. Esta evolución en el diseño ha llevado años.

La historia de la innovación suele ser una historia de cambios en la arquitectura

Para entender el cambio radical en el diseño de SNARK que propone Jolt, hay que remontarse a más de dos mil años atrás: los griegos pionearon en sistemas formales de pruebas matemáticas, que luego fueron ampliados en Oriente Medio, Asia y otras regiones.

Estas primeras pruebas — deducciones lógicas escritas paso a paso — se registraban en lenguaje formal o en fórmulas, para que cualquiera pudiera verificarlas. Por ejemplo, un matemático podía escribir una prueba en un “libro” y otro podía leerla palabra por palabra para verificarla. Este concepto de prueba estática y escrita, es la base del famoso problema “P vs. NP”.

Es importante notar que estas pruebas tradicionales son secuenciales y no interactivas: requieren que las partes se turnen.

Pero en 1985*, Shafi Goldwasser, Silvio Micali y Charles Rackoff propusieron el concepto de prueba interactiva (“IP”).[*En realidad, su artículo fue presentado unos años antes, pero fue rechazado varias veces antes de ser aceptado.] La idea central es que, en una interacción, dos partes — por ejemplo, matemáticos — pueden comunicarse en tiempo real, sin tener que esperar a que una escriba toda la prueba para convencer a la otra. En otras palabras, mediante interacción, se puede explorar la validez de la prueba en tiempo real.

El enorme poder de estas pruebas interactivas — en comparación con las tradicionales estáticas de la antigua Grecia — fue plenamente reconocido en 1990, cuando Carsten Lund, Lance Fortnow, Howard Karloff y Noam Nisan propusieron el protocolo de sumas y verificaciones: un método algebraico para sistemas de prueba interactivos. Combinado con trabajos posteriores de Adi Shamir, esto llevó rápidamente a la conclusión fundamental “IP=PSPACE”, que en términos sencillos significa:

Si el probador y el verificador pueden interactuar — como en los sistemas tradicionales — y el probador no puede engañar sin ser detectado, entonces podemos verificar declaraciones mucho más complejas en menos tiempo que con las pruebas estáticas antiguas.

En otras palabras: la interacción otorga ventajas enormes en los sistemas de prueba. La técnica clave para aprovechar esto es la verificación por sumas (sum-check), que permite al verificador comprobar resultados sin reconstruir toda la computación subyacente.

Unos años después, Joe Kilian propuso construir pruebas de conocimiento cero (ZK) eficientes a partir de pruebas probabilísticas verificables (PCP). En PCP, el probador (como un matemático griego, pero en computadora) escribe una prueba en un “libro” con mucha redundancia. La ventaja es que el verificador no necesita leer todo: puede simplemente consultar unas pocas posiciones aleatorias — por ejemplo, tres “palabras” — y con alta probabilidad determinar si la prueba es válida.

El problema es que las pruebas PCP son muy largas, aunque su verificación es barata.

Kilian mostró cómo combinar PCP con criptografía, permitiendo que el probador “prometa” que ha escrito toda la prueba, y solo revele unas pocas palabras junto con una certificación criptográfica. La prueba final en el protocolo de Kilian consiste en esas palabras (más la certificación), que son suficientes para convencer al verificador de la validez de toda la prueba.

Estas pruebas todavía eran interactivas. Luego, Micali mostró cómo aplicar la transformación de Fiat-Shamir para convertir las pruebas interactivas de Kilian en pruebas no interactivas. En resumen, la transformación “elimina” los desafíos aleatorios del verificador, permitiendo que el probador genere toda la prueba en una sola pasada.

La influencia duradera de los esquemas tradicionales

A lo largo de la historia de los sistemas de prueba, hemos pasado de pruebas estáticas a interactivas, luego a probabilísticas y no interactivas (PCP), después volvimos a interactivas (Kilian), y finalmente a no interactivas (Micali). Los SNARK aparecen en esta línea de evolución: aplicando la transformación de Fiat-Shamir a las pruebas de Kilian, Micali logró la primera construcción de SNARK.

Pero en estos primeros SNARK basados en PCP, la carga de trabajo del probador era enorme — demasiado costosa para ser práctica.

A pesar de ello, el método de diseño de SNARK se mantuvo durante décadas. Incluso cuando la industria intentó abandonar los enfoques basados en PCP, los diseñadores siguieron usando conceptos relacionados (como “PCP lineales”), que en realidad son variaciones heurísticas de PCP. Aunque estos métodos lograron crear SNARKs muy cortos, no fueron los más rápidos para el probador.

Los diseñadores de SNARK no han vuelto a sus raíces — los protocolos de sumas — para obtener SNARKs más rápidos y fáciles de usar con la computación moderna.

En realidad, para adoptar antes los protocolos de sumas, habría que replantear toda la historia y evolución de SNARK en un enfoque no lineal. Desde (a) prueba interactiva → (b) PCP → © argumentos interactivos sencillos → (d) desarrollo de los primeros SNARK, la industria ha pasado por varias transformaciones:

En la transición de (a) a (b), el principal reto fue eliminar la interacción manteniendo la sencillez de la verificación, lo que llevó a abandonar los protocolos de sumas (interacción).

Luego, en la transición de (b) a ©, la interacción reapareció… y finalmente, mediante la transformación de Fiat-Shamir, se eliminó para pasar de © a (d).

Al analizar estos pasos en línea, vemos que los diseñadores de SNARK en realidad omitieron la interacción en dos ocasiones: primero de (a) a (b), y luego de © a (d).

Pero si queremos usar Fiat-Shamir para eliminar la interacción, deberíamos saltarnos directamente el paso (b), los PCP verificables probabilísticamente. Saltar ese paso es la clave detrás de Jolt: construir SNARK directamente desde pruebas interactivas, usando sumas para verificar.

¿Por qué no lo hicieron antes? Los primeros diseñadores de SNARK quizás no vieron la oportunidad, porque PCP y SNARK parecen similares — ambos logran verificaciones cortas. Pero en realidad, la arquitectura y las confusiones han mantenido esa percepción.

Para nosotros, invertir recursos en el zkVM Jolt basado en sumas es una apuesta contracorriente, porque va en contra del paradigma dominante en SNARK durante décadas.

‘Jolt Inside’

El método de diseño de SNARK de Jolt (basado en evaluación por lotes y mecanismos de memoria, como Twist + Shout) combina protocolos interactivos y sumas de verificación.

Ahora, tras varios años construyendo Jolt, otros también empiezan a usar sumas en sus diseños. Entonces, ¿qué hace que Jolt sea especial en el zkVM actual? Aprovecha al máximo las estructuras repetitivas en la ejecución de CPU. Al observar cómo la abstracción de “fetch-decode-execute” en cada núcleo de CPU se aplica a la evaluación por lotes, Jolt logra una eficiencia sin igual con una complejidad mínima.

En contraste, otros zkVM dependen mucho de “precompilados” (como aceleradores ASIC para subrutinas específicas) para rendimiento razonable. Jolt evita estos precompilados, porque replican los errores de los enfoques anteriores en SNARK: requieren expertos para diseñar circuitos específicos, son más propensos a errores y menos accesibles para los desarrolladores. La prioridad de Jolt es democratizar el SNARK.

Verificar la corrección de la ejecución de la CPU es el núcleo de la zkVM — y una gran mejora para la experiencia del desarrollador — porque permite reutilizar infraestructuras de cómputo general ya existentes y optimizadas. La infraestructura global está construida para CPUs, y Jolt aprovecha esa “estructura” inherente para maximizar sencillez y rendimiento.

Desde el inicio, Jolt priorizó usabilidad y rendimiento en producción: los desarrolladores pueden verificar programas existentes directamente; incluso para validaciones rápidas, sin modificar código. Jolt no fuerza a reestructurar aplicaciones en “precompilados” o APIs especiales, manteniendo la integridad del código original, facilitando adopción, auditoría y menor coste de iteración.

Y lo más importante: Jolt no solo es más rápido, sino también más simple. Otros enfoques requieren que cada instrucción de la máquina virtual tenga un circuito dedicado, mientras que en Jolt cada instrucción puede definirse con unas diez líneas de código en Rust. Sin circuitos complejos, solo unas pocas líneas.

¿Qué sigue para Jolt?

Ya estamos en la vanguardia en velocidad. Con futuras optimizaciones y funciones, incluyendo recursividad y pruebas de conocimiento cero — especialmente en la transición de criptografía de curvas elípticas a criptografía de reticulados — lograremos otro salto de rendimiento este año, sin contar el post-cuántico.

Jolt hace posibles más aplicaciones. En blockchain, la escalabilidad y descentralización que todos esperan serán más fáciles de desplegar. Las pruebas de conocimiento cero listas para usar, sin meses o años de ingeniería criptográfica.

Pero, a medida que Jolt evoluciona, por ejemplo, para crear zkVM rápidos y fáciles de usar en teléfonos y laptops, los desarrolladores podrán desbloquear más casos de uso en clientes y privacidad. Aplicaciones en teléfonos con protección de datos, que antes eran difíciles de mantener o ejecutar, serán mucho más accesibles.

A largo plazo, estos sistemas de prueba serán componentes centrales de la infraestructura digital mundial, similares a la criptografía y firmas digitales. Esta tecnología de compresión criptográfica — donde cualquiera puede enviar un archivo de 50 KB para demostrar que posee varios GB de datos con ciertas propiedades — es tan poderosa que resulta difícil imaginar qué aplicaciones se desarrollarán con ella. Las posibilidades son infinitas.