Hoy, LayerZero ha lanzado su nueva cadena, Zero, que incluye varios avances tecnológicos, incluido un nuevo enfoque de prueba de conocimiento cero que desacopla la ejecución de la transacción de la verificación. Todo esto es posible gracias a «Jolt Inside».

¿Qué es Jolt? Jolt es una zkVM (máquina virtual de conocimiento cero, o más precisamente, una máquina virtual «sucinta») RISC-V de código abierto que es rápida, segura y fácil de usar. Representa un nuevo y vanguardista enfoque de diseño SNARK basado en tres años de investigación y desarrollo de a16z crypto, que hemos puesto a disposición de código abierto para que cualquiera lo use o lo desarrolle aún más. Pero el nacimiento de Jolt es en realidad una historia que se ha estado gestando durante décadas.

¿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 comprender en detalle qué es una zkVM. Este tipo de máquinas virtuales se suelen denominar máquinas virtuales «zk», pero la característica más utilizada aquí es la concisión. Si bien el «conocimiento cero» es fundamental para la protección de la privacidad, la «concisión» significa que las pruebas son breves y fáciles de verificar; estas son dos características útiles pero diferentes que a menudo se confunden. (Jolt ya tiene concisión y pronto también implementará el conocimiento cero).

Pero, ¿por qué es tan importante zkVM? zkVM y SNARK (argumentos de conocimiento sucintos no interactivos) en un sentido más amplio son componentes importantes de la escalabilidad, la privacidad, la seguridad y muchos otros aspectos de la cadena de bloques. Este tipo de pruebas, argumentos y conocimiento cero (denominados colectivamente tecnologías de computación verificables) tienen innumerables aplicaciones en la industria del cifrado y en otros campos. Debido a las arquitecturas de diseño tradicionales y otras razones, la industria ha adoptado hasta ahora un enfoque relativamente complejo para construir zkVM; esto se explicará con más detalle a continuación. Sin embargo, Jolt se ha centrado desde el principio en un enfoque de diseño SNARK muy diferente, destinado a lograr una mayor eficiencia, usabilidad y rendimiento.

En resumen, una zkVM es una forma de demostrar que ha ejecutado correctamente un programa de computadora. La ventaja de zkVM sobre otros SNARK es su facilidad de uso para los desarrolladores. Al aprovechar la infraestructura informática existente (como el ecosistema de compiladores LLVM de código abierto), los desarrolladores pueden aprovechar el poder de SNARK en el lenguaje de programación que elijan sin tener que utilizar un lenguaje específico del dominio (DSL).

Esto es bastante similar a muchos campos de la criptografía moderna en la actualidad: tenemos bibliotecas estándar integradas para el cifrado y las firmas digitales, y los desarrolladores comunes las utilizan todos los días sin necesidad de comprender su funcionamiento interno. Jolt proporciona la misma capa de abstracción para los desarrolladores: simplemente use los programas existentes y verifíquelos sin preocuparse por la interacción entre los dos. Este es un requisito necesario para cualquier aplicación de popularización de la criptografía novedosa. Los desarrolladores pueden centrarse en las operaciones reales. Con Jolt, los desarrolladores no necesitan ninguna experiencia en SNARK, simplemente presionan un botón para usar el código informático que ya han escrito para generar pruebas de Jolt.

Sin embargo, incluso con los muchos avances de Jolt, probar cualquier prueba de complejidad moderada (como un solo núcleo de CPU estándar que ejecuta un segundo de operaciones) todavía requiere una gran potencia informática. Para generar pruebas complejas en un tiempo razonable, necesita varias GPU. LayerZero ha portado el probador Jolt a CUDA y ha lanzado Zero: combina el algoritmo subyacente altamente paralelizado de Jolt con el hardware paralelo de las GPU, logrando así una escalabilidad de orden superior. LayerZero se compromete a llevar la prueba de GPU de nivel de producción de Jolt, incluido el desarrollo de una versión compatible con GPU del algoritmo Jolt en cooperación con nosotros, lo cual es fundamental para mejorar la escalabilidad de zkVM y la prueba.

Jolt en sí es de código abierto, por lo que cualquiera puede usarlo o desarrollar basándose en su tecnología innovadora. El código abierto es el multiplicador definitivo: compartir los resultados públicamente permite que más personas en el ecosistema los usen, los reutilicen, los prueben/auditen/reparen, los mejoren y sigan innovando sobre esa base.

Invertir en proyectos de código abierto por parte de empresas de capital riesgo puede parecer inusual, pero la estructura de la investigación y el desarrollo modernos dicta que la mayor parte del trabajo de desarrollo se realiza internamente en las empresas, como los antiguos laboratorios corporativos o los laboratorios de las fundaciones actuales, o en el mundo académico. El propósito de establecer la institución de investigación de cifrado a16z es 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 empresa de capital riesgo, también podemos financiar proyectos que otras instituciones no pueden financiar… especialmente en el caso de la inversión inversa.

El método de diseño inverso que admite SNARK es especialmente importante para Jolt porque representa un importante «cambio de paradigma» que es muy diferente de los métodos de diseño anteriores. Esta evolución del diseño ha tardado muchos años. La historia de la innovación suele ser una historia de cambios en el diseño de la arquitectura.

Para comprender el importante cambio que Jolt ha adoptado para el método de diseño SNARK, debemos remontarnos a más de dos mil años: los antiguos griegos fueron pioneros en el desarrollo de sistemas de prueba matemática formal, que luego fueron ampliados por académicos de Oriente Medio, Asia y otras regiones. Estas primeras pruebas, deducciones lógicas escritas paso a paso, se registraron en lenguaje o fórmulas formales para que cualquiera pudiera verificarlas. Por ejemplo, un matemático podría escribir una prueba en un «libro» y luego otro matemático leería el libro palabra por palabra para verificarlo. Este concepto tradicional de prueba escrita estática es la encarnación de la famosa clase de complejidad «P vs. NP» NP. Cabe destacar que este método de prueba tradicional es secuencial y debe realizarse por turnos: es estático, no interactivo.

Pero avanzando rápidamente hasta 1985, Shafi Goldwasser, Silvio Micali y Charles Rackoff propusieron el concepto de prueba interactiva («IP»). [De hecho, su artículo se presentó unos años antes, pero fue rechazado varias veces antes de ser aceptado.] La idea central de este método de prueba interactivo es que, por ejemplo, si dos matemáticos se están comunicando, no tienen que esperar a que una de las partes escriba una prueba y luego convencer a la otra parte. En cambio, pueden hacer preguntas en tiempo real; en otras palabras, explorar la esencia de la prueba a través de la interacción.

El enorme poder de este tipo de prueba interactiva, en comparación con la prueba estática tradicional iniciada por los antiguos griegos, no se reconoció por completo hasta cinco años después, en 1990. En ese momento, Carsten Lund, Lance Fortnow, Howard Karloff y Noam Nisan propusieron el protocolo de suma de comprobación: un método algebraico para sistemas de prueba interactivos.

Combinado con el trabajo posterior de Adi Shamir, esto pronto condujo a la conclusión fundamental de «IP=PSPACE», una forma técnica de resumir la siguiente afirmación intuitiva: si el probador y el verificador pueden interactuar, es decir, realizar un desafío-respuesta como un sistema de prueba tradicional (suponiendo que un probador mentiroso no sea «atrapado» por un desafío al que no puede responder), entonces, en comparación con la prueba escrita estática tradicional de los antiguos griegos, podemos verificar rápidamente declaraciones más complejas. En otras palabras: la propiedad interactiva nos da una gran ventaja en los sistemas de prueba.

Y la suma de comprobación es el núcleo de la transformación de esta ventaja en una verificación eficiente: permite a los verificadores verificar los resultados reclamados sin tener que reconstruir todo el proceso de cálculo que se va a probar.

Unos años más tarde, Joe Kilian propuso construir argumentos sucintos de conocimiento cero a partir de pruebas verificables probabilísticamente (PCP). En la teoría de la prueba de PCP, el probador (que se puede imaginar como un matemático de la antigua Grecia, solo que ahora es una computadora) escribe una prueba ordinaria en un «libro», pero el formato es muy redundante. Cabe destacar que esta redundancia permite al verificador no tener que leer todo el libro: el verificador solo necesita extraer aleatoriamente un número fijo de ubicaciones de prueba, como tres «palabras» en el libro, para determinar con un alto grado de confianza si toda la prueba es válida.

Sin embargo, el problema es que la prueba de PCP en sí es muy larga, aunque el costo de la verificación es bajo. Por lo tanto, Kilian demostró cómo combinar PCP con criptografía, lo que permite al probador «comprometerse» a completar este «libro largo» y luego solo revelar algunas palabras extraídas al azar, con una breve autenticación criptográfica adjunta. La prueba final en el protocolo de Kilian son en realidad estas pocas palabras (más algunos datos de autenticación criptográfica), pero son suficientes para convencer al verificador de que todo el libro es válido. Estas pruebas seguían siendo interactivas en ese momento.

Posteriormente, Micali demostró cómo transformar el argumento interactivo basado en PCP de Kilian en un argumento no interactivo aplicando la transformación Fiat-Shamir. En resumen, la transformación Fiat-Shamir «elimina» el desafío aleatorio del verificador, lo que permite al probador generar el desafío por sí mismo y generar toda la prueba de una sola vez.

A lo largo de la historia y la evolución de los sistemas de prueba, hemos experimentado una evolución de estático a interactivo, luego a probabilístico y no interactivo (PCP), luego de vuelta a interactivo (ver Kilian) y finalmente de vuelta a no interactivo (ver Micali). SNARK aparece al final de esta evolución: al aplicar la transformación Fiat-Shamir al argumento interactivo de Kilian, Micali obtuvo lo que ahora llamamos la primera construcción SNARK.

Pero en estos primeros SNARK basados en PCP, la carga de trabajo del probador era enorme (el cálculo consumía demasiado tiempo), lo que dificultaba su implementación práctica. Sin embargo, la forma en que se diseñó SNARK se ha utilizado durante décadas. Incluso cuando la industria intentó deshacerse del método de diseño SNARK basado en PCP, los diseñadores todavía usaban conceptos relacionados (como «PCP lineal», etc.), que en realidad son solo variaciones de la heurística de PCP.

Si bien estos métodos han dado como resultado SNARK con pruebas extremadamente cortas, no han dado como resultado SNARK con la velocidad de probador más rápida. Los diseñadores de SNARK nunca han regresado a su fuente fundamental, el protocolo de suma de comprobación, para obtener probadores más rápidos y fáciles de usar que ahora son posibles gracias a la computación moderna.

Retrocediendo un paso: para adoptar el protocolo de suma de comprobación antes, necesitamos examinar la historia y la evolución de SNARK que describimos anteriormente de una manera no lineal. Desde (a) prueba interactiva → (b) PCP → (c) argumento interactivo sucinto → (d) el desarrollo temprano de SNARK, la industria ha experimentado la siguiente transformación:

En la transición de (a) prueba interactiva → (b) PCP, el principal desafío era cómo eliminar la interacción del sistema de prueba manteniendo la concisión de la verificación. Esto llevó a los diseñadores a abandonar el protocolo de suma de comprobación (es decir, la parte interactiva). Pero cuando pasamos de (b) PCP a (c) argumento de conocimiento cero sucinto, la interacción reapareció… Finalmente, se eliminó a través de la transformación Fiat-Shamir, logrando así la transición de (c) argumento interactivo sucinto a (d) SNARK temprano.

En retrospectiva, al examinar todos estos pasos linealmente de (a) → (b) → (c) → (d), podemos ver claramente que los diseñadores de SNARK en realidad omitieron la interacción dos veces: una vez de (a) → (b) y otra vez de (c) → (d). Pero si vamos a usar Fiat-Shamir para eliminar la interacción… ¡deberíamos saltarnos directamente el paso intermedio (b), que es la prueba verificable probabilísticamente!

Saltarse este paso intermedio (b) es la idea clave detrás del método Jolt, que construye SNARK directamente a partir de pruebas interactivas, directamente a la verificación de la suma. ¿Por qué más personas no recurrieron antes a un método de diseño basado en el protocolo de verificación de la suma? Es posible que los primeros diseñadores de SNARK no lo hayan hecho porque PCP y SNARK parecen superficialmente similares, ya que ambos implementan el concepto de verificación sucinta. En cuanto al desarrollo posterior, la arquitectura, y la incomprensión, pueden persistir.

Para nosotros, invertir una gran cantidad de recursos de ingeniería e investigación en la zkVM Jolt basada en la suma de comprobación es una apuesta inversa porque va en contra del paradigma que ha dominado el campo de SNARK durante décadas.

El método de diseño SNARK de Jolt (que en sí mismo se basa en mecanismos de evaluación por lotes y verificación de memoria, como Twist + Shout) se basa en pruebas interactivas y protocolos de suma de comprobación. Hoy, unos años después de que comenzamos a construir Jolt, otros también están comenzando a adoptar métodos de protocolo de suma de comprobación en sus diseños. Entonces, ¿cuáles son las características notables de Jolt en la zkVM actual?

Jolt maximiza el uso de la estructura repetitiva en la ejecución de la CPU. Al observar cómo la abstracción «buscar-decodificar-ejecutar» de cada núcleo de CPU se aplica al mecanismo de evaluación por lotes, Jolt logra una eficiencia incomparable con una complejidad mínima. En contraste, otras zkVM dependen en gran medida de la «precompilación» (aceleradores similares a ASIC para subrutinas específicas) para lograr un rendimiento razonable. Jolt abandona estas precompilaciones porque repiten el mismo error que los métodos de diseño SNARK antes de que apareciera zkVM: debido a que se necesita un experto para diseñar este tipo de SNARK dedicados, son más propensos a errores y son más difíciles de usar para los desarrolladores en general. El enfoque de Jolt está en popularizar SNARK.

Verificar la corrección de la ejecución de la CPU es el valor central de zkVM, y también es un gran avance en la experiencia del desarrollador, porque permite reutilizar la infraestructura informática de propósito general existente y reforzada. La infraestructura informática global está construida para admitir la CPU, y Jolt aprovecha al máximo la «estructura» inherente a la ejecución de la CPU para maximizar la concisión y el rendimiento.

Jolt ha priorizado la usabilidad y el rendimiento de nivel de producción desde el principio: los desarrolladores pueden verificar directamente los programas existentes; incluso para una verificación rápida, no es necesario modificar ningún código. En lugar de obligar a los equipos a reestructurar las aplicaciones en torno a «precompilaciones» o API especiales para lograr un rendimiento aceptable como otras soluciones, Jolt mantiene la integridad del código original, lo que facilita su adopción, su auditoría y reduce los costos de iteración.

Más importante aún, Jolt no solo es más rápido, sino también más simple. Otras soluciones requieren que los diseñadores de zkVM especifiquen un circuito para cada instrucción básica de la máquina virtual, mientras que Jolt no lo requiere: en Jolt, solo se necesitan unas diez líneas de código Rust para especificar cada instrucción básica. No se necesitan circuitos, solo diez líneas de código.

Ya somos líderes en velocidad. Con más optimizaciones y la adición de funciones, incluidas la recursividad y las pruebas de conocimiento cero, especialmente nuestra transición planificada de la criptografía de curva elíptica a la criptografía de celosía, lograremos otro aumento de magnitud en la velocidad a finales de este año, sin mencionar la era poscuántica.

Jolt hace posibles más aplicaciones. Para la cadena de bloques, la tan esperada escalabilidad y descentralización serán más fáciles de implementar. Los resúmenes de prueba de conocimiento cero se pueden usar de inmediato, sin la necesidad de meses o incluso años de ingeniería criptográfica.

Pero a medida que Jolt continúa desarrollándose, por ejemplo, creando una máquina virtual de prueba de conocimiento cero rápida y sencilla que se puede ejecutar en teléfonos móviles y computadoras portátiles, los desarrolladores podrán desbloquear más casos de uso en el lado del cliente y la protección de la privacidad. Por ejemplo, las aplicaciones de protección de la privacidad en los teléfonos móviles pueden pasar de ser difíciles de mantener y casi imposibles de ejecutar a ser fáciles de usar de inmediato.

A largo plazo, estos sistemas de prueba se convertirán en un componente central de la infraestructura digital mundial, similar al cifrado y las firmas digitales. Esta tecnología de compresión criptográfica universal, en la que cualquiera puede demostrar que tiene gigabytes de datos que cumplen con propiedades específicas simplemente enviando un archivo de prueba de 50 kilobytes en lugar de todos los datos, es tan poderosa que es difícil predecir qué aplicaciones desarrollarán las personas con ella. Las posibilidades son infinitas.

[Block unicorn]