A16z：Elementos clave para los creadores: ‘Jolt Inside’

Autor del artículo: a16z crypto

Traducción del artículo: Block unicorn

Prefacio

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”.

¿Qué es Jolt? Jolt es una máquina virtual zk-RISC-V de código abierto (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 de diseño SNARK, desarrollado durante tres años por a16z crypto, y lo haremos de código abierto para que cualquiera pueda usarlo o desarrollarlo aún más. Pero la historia del nacimiento 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 más destacado es la sencillez. Aunque “conocimiento cero” es crucial 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 cero sencillas y no interactivas) 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.

Debido a arquitecturas tradicionales y otras razones, la industria ha adoptado hasta ahora enfoques relativamente complejos para construir zkVM; en lo que sigue, se explicará esto con más detalle. Sin embargo, Jolt desde el principio se centró en un enfoque radicalmente diferente para 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 sobre otros SNARK radica en su amigabilidad para los desarrolladores. Aprovechando infraestructuras de computación existentes (como el ecosistema de compiladores LLVM de código abierto), 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 la criptografía: contamos con estándares y bibliotecas integradas para cifrado y firmas digitales — los desarrolladores las usan a diario sin entender cómo funcionan internamente. Jolt ofrece a los desarrolladores una capa de abstracción similar: solo necesitan usar sus programas existentes y verificarlos, sin preocuparse por la interacción entre ambos. Esto es un requisito fundamental para la adopción de cualquier nueva aplicación criptográfica.

Los desarrolladores pueden centrarse en la operación real. Con Jolt, no se requiere experiencia previa en SNARK: simplemente presionan un botón para generar una prueba de Jolt a partir de su código de computadora.

Sin embargo, incluso con los avances de Jolt, generar una prueba de complejidad media (por ejemplo, una operación en un solo núcleo de CPU durante un segundo) todavía requiere una gran capacidad computacional. 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 el algoritmo altamente paralelo de Jolt con hardware paralelo de GPU, logrando una escalabilidad superior.

LayerZero se dedica a 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 de código abierto

Jolt en sí es de código abierto, por lo que cualquiera puede usarlo o desarrollarlo basándose en sus innovaciones. El código abierto es el multiplicador definitivo: compartir públicamente los resultados permite que más personas en el ecosistema puedan usar, reutilizar, someter a pruebas, auditorías, mejorar y seguir innovando sobre ello.

Invertir en proyectos de código abierto puede parecer inusual para algunos, pero la estructura moderna de I+D determina que la mayor parte del trabajo de desarrollo ocurre dentro de las empresas —como antiguos laboratorios corporativos o los laboratorios de fundaciones— o en el ámbito académico. La creación de la institución de investigación a16z crypto busca precisamente construir un laboratorio de investigación industrial y un equipo de ingeniería que conecte la teoría académica con la práctica industrial. Como firma de inversión de riesgo, también podemos financiar proyectos que otras instituciones no puedan, especialmente en inversiones en reverso.

El apoyo a un método de diseño inverso para SNARK es especialmente importante para Jolt, porque representa un cambio de paradigma radical respecto 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 la gran transformación en el diseño de SNARK que Jolt propone, debemos remontarnos a más de dos mil años atrás: los griegos fundaron los sistemas formales de pruebas matemáticas, que luego fueron ampliados por académicos en Oriente Medio, Asia y otras regiones.

Estas primeras pruebas —derivaciones lógicas escritas paso a paso— se registraban en lenguajes formales o fórmulas, para que cualquiera pudiera verificarlas. Por ejemplo, un matemático podía escribir una prueba en un “libro”, y otro matemático podía leerla palabra por palabra para verificarla. Este concepto tradicional de prueba estático, escrito, es la encarnación de la clase de complejidad NP en “P vs. NP”.

Es importante notar que estas pruebas tradicionales son secuenciales y requieren que las partes se realicen en orden: son estáticas y no interactivas.

Pero avanzamos a 1985*, cuando Shafi Goldwasser, Silvio Micali y Charles Rackoff propusieron el concepto de pruebas interactivas (“IP”). [*En realidad, su artículo fue presentado unos años antes, pero fue rechazado varias veces antes de ser aceptado.] La idea central de estas pruebas interactivas es que, por ejemplo, si dos matemáticos se comunican, no necesitan esperar a que uno escriba la prueba y convencer al otro. En cambio, pueden hacer preguntas en tiempo real; en otras palabras, la interacción permite explorar la validez de la prueba.

El gran poder de estas pruebas interactivas —en comparación con las pruebas tradicionales, estáticas, escritas desde los griegos— no fue plenamente reconocido hasta 1990. En ese año, Carsten Lund, Lance Fortnow, Howard Karloff y Noam Nisan propusieron el protocolo de suma de verificación: un método algebraico para sistemas de pruebas interactivas. Combinado con el trabajo posterior de Adi Shamir, esto llevó rápidamente a la conclusión fundamental “IP=PSPACE”, que en términos sencillos afirma:

Si el probador y el verificador pueden interactuar —como en los sistemas de prueba tradicionales, con desafíos y respuestas— (suponiendo que un probador mentiroso no pueda ser atrapado por desafíos que no pueda responder), entonces podemos verificar declaraciones más complejas de manera rápida en comparación con las pruebas estáticas tradicionales.

En otras palabras: la interacción otorga ventajas enormes en los sistemas de prueba. La suma de verificación (sum-check) es la clave para convertir esa ventaja en verificaciones eficientes: permite al verificador validar el resultado declarado sin reconstruir todo el proceso de cálculo.

Unos años después, Joe Kilian propuso construir pruebas de conocimiento cero sencillas a partir de pruebas verificables probabilísticamente (PCP). En la teoría de PCP, el probador (que puede imaginarse como un matemático griego, pero ahora en una computadora) escribe una prueba en un “libro” con mucha redundancia. La redundancia permite que el verificador no tenga que leer todo el libro: solo necesita extraer aleatoriamente unas pocas posiciones —por ejemplo, tres “palabras”— y con alta probabilidad puede decidir si la prueba es válida.

Pero el problema es que las pruebas PCP son muy largas, aunque la verificación es muy barata.

Kilian mostró cómo combinar PCP con criptografía, permitiendo que el probador “prometa” que ha completado ese “libro” largo, y solo revela unas pocas palabras junto con una certificación criptográfica corta. La prueba final en el protocolo de Kilian en realidad consiste en esas palabras (más algunos datos criptográficos), que son suficientes para que el verificador crea que toda la prueba es válida.

Estas pruebas todavía eran interactivas. Luego, Micali mostró cómo, aplicando la transformación de Fiat-Shamir, convertir las pruebas interactivas basadas en PCP en pruebas no interactivas. En resumen, la transformación de Fiat-Shamir “elimina” los desafíos aleatorios del verificador, permitiendo que el probador genere los desafíos por sí mismo y produzca una prueba completa en una sola emisión.

El impacto duradero de la arquitectura heredada

A lo largo de la historia y evolución de los sistemas de prueba, hemos pasado de pruebas estáticas a interactivas, luego a probabilísticas y no interactivas (PCP), y después volvimos a interactivas (ver Kilian), para finalmente regresar a no interactivas (ver Micali). SNARK aparece al final de esta línea evolutiva: aplicando la transformación de Fiat-Shamir a las pruebas interactivas de Kilian, Micali logró construir el primer SNARK.

Pero en estos primeros SNARK basados en PCP, la carga del probador era enorme —el cálculo tomaba demasiado tiempo—, lo que dificultaba su despliegue práctico.

A pesar de ello, el método de diseño de SNARK ha persistido durante décadas. Incluso cuando la industria intentó alejarse del enfoque basado en PCP, los diseñadores siguieron usando conceptos relacionados (como “PCP lineal”), que en realidad son variaciones heurísticas de PCP. Aunque estos métodos lograron crear SNARKs muy cortos, no lograron los SNARKs con la velocidad de prueba más rápida.

Los diseñadores de SNARK nunca volvieron a sus raíces —el protocolo de suma de verificación— para obtener pruebas más rápidas y fáciles de usar con la tecnología moderna.

Para adoptar la suma de verificación más temprano, habría que replantear toda la historia y evolución de SNARK en un enfoque no lineal. Desde (a) prueba interactiva → (b) PCP → © prueba interactiva sencilla → (d) desarrollo de SNARKs tempranos, la industria experimentó los siguientes cambios:

En la transición de (a) a (b), el principal desafío fue cómo eliminar la interacción manteniendo la sencillez de la verificación. Esto llevó a los diseñadores a abandonar la suma de verificación (la parte interactiva).

Pero al pasar de (b) a ©, la interacción volvió a aparecer… y finalmente, mediante la transformación de Fiat-Shamir, se eliminó para pasar de © a (d).

Al analizar todos estos pasos en línea —de (a) a (b), de (b) a ©, y de © a (d)— se puede ver claramente que los diseñadores de SNARK en realidad omitieron la interacción en dos ocasiones: una al pasar de (a) a (b), y otra al pasar de © a (d).

Pero si queremos usar Fiat-Shamir para eliminar la interacción, deberíamos saltarnos directamente el paso (b), es decir, las pruebas verificables probabilísticamente. Saltarse ese paso (b) es la clave detrás de Jolt: construir SNARK directamente desde pruebas interactivas, yendo directamente a la suma de verificación.

¿Por qué no lo hicieron antes? Es probable que los primeros diseñadores de SNARK no lo hicieran porque PCP y SNARK parecen similares —ambos implementan la verificación sencilla—, y la arquitectura y los malentendidos persistieron.

Para nosotros, invertir recursos en el zkVM basado en suma de verificación Jolt es una apuesta contraria a la corriente principal, porque desafía décadas de paradigma en el campo de SNARK.

‘Jolt Inside’

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

Ahora, años después de comenzar a construir Jolt, otros también están adoptando enfoques basados en suma de verificación en sus diseños. Entonces, ¿cuáles son las características distintivas de Jolt en los zkVM actuales? Jolt maximiza el aprovechamiento de las estructuras repetitivas en la ejecución de la CPU. Observando cómo el ciclo “fetch-decode-execute” en cada núcleo de CPU puede aplicarse a la evaluación por lotes, Jolt logra una eficiencia sin igual con una complejidad mínima.

En contraste, otros zkVM dependen en gran medida de “precompilaciones” (como aceleradores ASIC para subrutinas específicas) para lograr un rendimiento razonable. Jolt elimina estas precompilaciones, porque replican los errores de los enfoques previos a SNARK: requieren expertos para diseñar circuitos específicos, son más propensos a errores y más difíciles de usar para los desarrolladores en general. El enfoque de Jolt es democratizar el SNARK.

Verificar la corrección de la ejecución de la CPU es el valor central de la zkVM —y una gran mejora en la experiencia del desarrollador— porque permite reutilizar infraestructuras de computación general ya existentes y optimizadas. La infraestructura global de computación está construida para soportar CPU, y Jolt aprovecha al máximo la “estructura” inherente a la ejecución de CPU, maximizando sencillez y rendimiento.

Desde el principio, Jolt priorizó usabilidad y rendimiento de nivel productivo: los desarrolladores pueden verificar programas existentes directamente; incluso para validaciones rápidas, sin modificar el código. Jolt no obliga a reestructurar aplicaciones en torno a “precompilaciones” o APIs especiales, manteniendo la integridad del código original, facilitando su adopción, auditoría y reduciendo costos de iteración.

Más aún, Jolt no solo es más rápido, sino también más simple. Otros enfoques requieren que los diseñadores de zkVM creen circuitos para cada instrucción básica, mientras que en Jolt cada instrucción puede ser especificada con unas diez líneas de código en Rust. Sin circuitos complejos, solo diez líneas de código.

¿Y 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 en breve otro incremento de velocidad, sin contar la era post-cuántica.

Jolt hace posibles más aplicaciones. Para blockchain, la escalabilidad y descentralización que tanto se han esperado serán más fáciles de desplegar. Las pruebas de conocimiento cero listas para usar eliminan meses o años de trabajo criptográfico.

Pero, a medida que Jolt evoluciona —por ejemplo, creando una máquina virtual de conocimiento cero rápida y sencilla para teléfonos y laptops— los desarrolladores podrán desbloquear más casos de uso en clientes y privacidad. Aplicaciones en teléfonos móviles podrán ofrecer protección de privacidad que antes era difícil de mantener, casi imposible de ejecutar, ahora de forma sencilla y lista para usar.

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 universal —que permite a cualquiera enviar un archivo de prueba de 50 KB en lugar de todos los datos, para demostrar que posee varios GB que cumplen ciertos atributos— es tan poderosa que resulta difícil imaginar qué aplicaciones se desarrollarán con ella. Las posibilidades son infinitas.