Una guía para desarrolladores de zkGalaxy

Esta es una heurística extremadamente útil para diferenciar enfoques para admitir un zkEVM. Sin embargo, los zkEVM son un subconjunto de todas las formas posibles de crear aplicaciones de conocimiento cero. Para un programador que quiera aprovechar las propiedades únicas de la computación zk, a saber concisión, conocimiento cero y corrección, un zkEVM puede no ser la mejor opción. Al presentar el conjunto completo de herramientas para desarrolladores, espero brindar una guía que ayude en el proceso de toma de decisiones sobre la pila zk adecuada para su aplicación.

Durante el último año o dos, ha habido una enorme cantidad de progreso en las herramientas zk. Se están acercando a un punto en el que los desarrolladores de software ordinarios pueden aprovechar las poderosas propiedades de zk sin una comprensión profunda de las intimidantes matemáticas e ingeniería subyacentes. Por otro lado, ha habido una proliferación de herramientas para usuarios avanzados que brindan a los expertos de zk un control extremadamente fino sobre la pila de zk.

El software moderno se basa en innumerables capas de abstracción para maximizar la productividad de los especialistas. Hay muchas ventajas de la abstracción en la ingeniería que son algo intuitivas: un desarrollador web no necesita comprender en profundidad cómo funcionan los sistemas operativos. 

La clave para construir buenas capas de abstracción reutilizables es encapsular la complejidad de una capa y luego proporcionar interfaces simples pero expresivas para que las capas superiores en la pila las usen. Hecho correctamente, esto permite a los desarrolladores con diferentes áreas de experiencia y conocimiento crear herramientas útiles en toda la pila.

No es de extrañar que estos mismos principios se apliquen a los sistemas zk, y estas capas de abstracción se están volviendo lo suficientemente maduras como para que un novato en zk comience a usarlas y crear aplicaciones hoy.

Arkworks-rs es un ecosistema de bibliotecas de Rust que proporciona implementaciones eficientes y seguras de los subcomponentes de una aplicación zkSNARK. Arkworks proporciona las interfaces necesarias para que los desarrolladores personalicen la pila de software para una aplicación zk sin tener que volver a implementar elementos comunes con otras bibliotecas existentes.

Antes de Arkworks, la única forma de crear una nueva aplicación zk era construir todo desde cero. Las principales ventajas de Arkworks-rs sobre las herramientas personalizadas e integradas verticalmente son el nivel de flexibilidad, la reducción de la ingeniería duplicada y la reducción del esfuerzo de auditoría. Las sensibles líneas de interfaz de Arkworks entre los componentes permiten un ritmo de actualización que puede mantener la pila relevante en medio del vertiginoso ritmo de innovación en las tecnologías zk, sin obligar a los equipos a reconstruir todo desde cero.

Arkworks es para proyectos que necesitan un control preciso sobre toda la pila de software zk, pero no quieren construir todas las piezas redundantes desde cero. Si está considerando una versión personalizada de un circuito DSL porque, por ejemplo, está creando un prototipo de un nuevo sistema de prueba pero no está seguro del esquema de compromiso o la curva elíptica correspondiente, arkworks le permitirá cambiar rápidamente entre varias opciones con interfaces compartidas, en lugar de que empezar de cero.

Para crear una prueba sobre algún cálculo, primero este cálculo debe expresarse en una forma que un sistema zkSNARK pueda entender. Varios lenguajes específicos de dominio han creado lenguajes de programación que permiten a los desarrolladores de aplicaciones expresar su cálculo de esa manera. Éstas incluyen Negro azteca, de Starknet El Cairo, circo, ZoKrates, y de Aleo Leo entre otros. El sistema de prueba subyacente y los detalles matemáticos generalmente no están expuestos al desarrollador de la aplicación.

Los desarrolladores de zkApp deben dominar la escritura de sus programas en lenguajes específicos de dominio. Algunos de estos lenguajes se parecen mucho a los lenguajes de programación familiares, mientras que otros pueden ser bastante difíciles de aprender. Analicemos algunos de estos:

El Cairo – Starkware DSL necesario para crear aplicaciones en Starknet. Se compila en lenguaje ensamblador específico de Cairo que puede ser interpretado por Cairo zkVM.

ZoKrates — ZoKrates es un conjunto de herramientas para las necesidades comunes de SNARK que incluye un lenguaje de alto nivel para escribir circuitos. ZoKrates también tiene cierta flexibilidad en torno a las curvas, el esquema de prueba y el backend, lo que permite a los desarrolladores intercambiar en caliente mediante un simple argumento CLI.

circo — Circom es un lenguaje especialmente diseñado para construir circuitos. Actualmente, es el lenguaje de facto para los circuitos en producción. El lenguaje no es especialmente ergonómico. El lenguaje mismo te hace muy consciente del hecho de que estás escribiendo circuitos.

Leo — Leo se desarrolló como el lenguaje para la cadena de bloques Aleo. Leo tiene una sintaxis similar a Rust y está hecho específicamente para transiciones de estado dentro de una cadena de bloques.

Negro – Sintaxis inspirada en Rust. Diseñado alrededor del IR en lugar del lenguaje en sí, lo que significa que puede tener una interfaz arbitraria. 

Cualquier desarrollador de aplicaciones que quiera aprovechar las propiedades únicas de zk en su aplicación. Algunos de estos lenguajes han sido probados en batalla con miles de millones de dólares moviéndose a través de cadenas como ZCash y Starknet. Si bien algunos de los proyectos que analizaremos no están listos para su uso en producción, escribir sus circuitos en uno de estos lenguajes es actualmente la mejor estrategia, a menos que necesite los controles más precisos que proporciona un conjunto de herramientas como Arkworks.

El objetivo principal de un zkEVM es tomar una transición de estado de Ethereum y probar su validez utilizando una prueba de corrección sucinta de conocimiento cero. Como se menciona en la publicación de Vitalik, hay varias formas de hacer esto con diferencias sutiles y las compensaciones correspondientes. 

La principal diferencia técnica entre todos estos es exactamente en qué parte de la pila del lenguaje se convierte el cálculo en una forma (aritmetización) que se puede usar en un sistema de prueba. En algunos zkEVM, esto sucede en los lenguajes de alto nivel (Solidity, Vyper, Yul), mientras que otros enfoques intentan probar el EVM hasta el nivel del código de operación. Las compensaciones entre estos enfoques se cubrieron profundamente en la publicación de Vitalik, pero lo resumiré en una oración: cuanto menor sea la conversión/aritmetización en la pila, mayor será la penalización de rendimiento.

El principal desafío con la creación de pruebas para una máquina virtual es que el tamaño del circuito crece proporcionalmente al tamaño de TODAS las instrucciones posibles para cada instrucción ejecutada. Esto ocurre porque el circuito no sabe qué instrucciones se ejecutarán en cada programa, por lo que necesita soportarlas todas.

Lo que esto significa en la práctica es que paga (en costo de rendimiento) por la instrucción más costosa posible, incluso cuando solo ejecuta la instrucción más simple. Esto conduce a una compensación directa entre la generalización y el rendimiento: a medida que agrega más instrucciones para la generalización, paga por esto en cada ¡instrucción que demuestras!

Este es un problema fundamental con los circuitos universales, pero con nuevos desarrollos en tecnologias al igual que IVC (cómputo incremental verificable), esta limitación se puede mejorar dividiendo el cómputo en partes más pequeñas, cada una con subcircuitos más pequeños y especializados.

Las implementaciones actuales de zkEVM utilizan diferentes estrategias para mitigar el impacto de este problema... Por ejemplo, zkSync extrae las operaciones más costosas (principalmente precompilaciones criptográficas como hashes y ECDSA) del circuito de prueba de ejecución principal en circuitos separados que se agregan juntos en el terminar a través de la recursividad de snark. zkSync adoptó este enfoque después de darse cuenta de que la mayoría de sus costos provenían de unas pocas instrucciones complejas.

En esencia, la razón por la que probar un conjunto de instrucciones más equivalente a EVM es más costoso es que el EVM no fue diseñado para cálculos zk. Abandonar el EVM antes en la pila permite que los zkEVM se ejecuten en conjuntos de instrucciones que están más optimizados para zk y, por lo tanto, son más baratos de probar.

Los clientes ideales para un zkEVM son las aplicaciones de contratos inteligentes que necesitan transacciones mucho más baratas que las disponibles en L1 Ethereum. Estos desarrolladores no necesariamente tienen la experiencia o el ancho de banda para escribir aplicaciones zk desde cero. Por lo tanto, prefieren escribir sus aplicaciones en lenguajes de alto nivel con los que están familiarizados, como Solidity. 

Escalando Ethereum es actualmente la aplicación más demandada de la tecnología zk.

Un zkEVM es una solución de escalado de Ethereum que mitiga sin fricciones el problema de congestión que restringe a los desarrolladores de dApp L1.

El objetivo de un zkEVM es respaldar una experiencia de desarrollador que sea lo más cercana posible al desarrollo actual de Ethereum. El soporte completo de Solidity significa que los equipos no tienen que construir y mantener múltiples bases de código. Esto es algo poco práctico para hacerlo a la perfección porque los zkEVM necesitan compensar cierta compatibilidad para poder generar pruebas de tamaño razonable en un período de tiempo razonable.

La principal diferencia entre zkSync y Scroll es dónde/cuándo en la pila realizan la aritmetización, es decir, dónde se convierten de construcciones EVM normales a una representación compatible con SNARK. Para zkSync, esto sucede cuando convierten el código de bytes YUL en su propio conjunto de instrucciones zk personalizado. Para Scroll, esto sucede al final, cuando el seguimiento de ejecución real se genera con los códigos de operación EVM reales.

Entonces, para zkSync, todo es lo mismo que interactuar con el EVM hasta que se genera el bytecode zk. Para Scroll, todo es igual hasta que se ejecuta el código de bytes real. Esta es una diferencia sutil, que intercambia rendimiento por soporte. Por ejemplo, zkSync no admitirá herramientas de código de bytes EVM como un depurador listo para usar, porque es un código de bytes completamente diferente. Si bien Scroll tendrá más dificultades para obtener un buen rendimiento de un conjunto de instrucciones, eso no fue diseñado para zk. Hay ventajas y desventajas en ambas estrategias y, en última instancia, hay muchos factores exógenos que afectarán su éxito relativo.

???? A pesar de su nombre, LLVM no es una VM (máquina virtual). LLVM es el nombre de un conjunto de herramientas de compilación anclado por una representación intermedia (IR) que es independiente del lenguaje.

= cero; Fundación (sobre el nombre, es una chiste de inyeccion SQL si se lo pregunta) está creando un compilador que puede convertir cualquier lenguaje de interfaz de LLVM en una representación intermedia que se puede probar dentro de un SNARK. El zkLLVM está diseñado como una extensión de la infraestructura LLVM existente, una cadena de herramientas estándar de la industria que admite muchos lenguajes de alto nivel como Rust, C, C++, etc.

Un usuario que quiera probar algún cálculo simplemente implementaría ese cálculo en C++. El zkLLVM toma este código fuente de alto nivel que es compatible con su compilador clang modificado (actualmente C++) y genera una representación intermedia del circuito. En este punto, el circuito está listo para probarse, pero es posible que el usuario quiera probar el circuito basándose en algunas entradas dinámicas. Para manejar entradas dinámicas, el zkLLVM tiene un componente adicional denominado asignador, que genera una tabla de asignación con todas las entradas y testigos completamente preprocesados ​​y listos para probarse junto con el circuito.

Estos 2 componentes son todo lo que se necesita para generar una prueba. En teoría, un usuario puede generar una prueba por sí mismo, pero dado que se trata de una tarea computacional algo especializada, es posible que desee pagarle a otra persona que tenga el hardware para que lo haga por él. Para este mecanismo de descubrimiento de contraparte, =nil; Foundation también ha establecido un 'mercado de prueba' en el que los probadores compiten para probar el cálculo para los usuarios que les pagarán por hacerlo. Esta dinámica de libre mercado hará que los probadores optimicen las tareas de prueba más valiosas.

Dado que cada tarea computacional que se probará es única y genera un circuito diferente, hay una cantidad infinita de circuitos que los probadores deberán poder manejar. Esta generalización forzada dificulta la optimización de circuitos individuales. La introducción de un mercado de prueba permite la especialización en los circuitos que el mercado considere valiosos. Sin este mercado, sería un desafío convencer a un probador para que optimice este circuito debido a este problema natural de arranque en frío.

La otra compensación es la clásica abstracción frente a control. Los usuarios que están dispuestos a utilizar esta interfaz fácil de usar están renunciando al control de las primitivas criptográficas subyacentes. Para muchos usuarios, esta es una compensación muy válida, ya que a menudo es mejor dejar que los expertos en criptografía tomen estas decisiones por usted.

Un zkVM describe el superconjunto de todas las máquinas virtuales zk, mientras que un zkEVM es un tipo específico de zkVM, que valió la pena discutir como un tema separado debido a su prevalencia en la actualidad. Hay algunos otros proyectos que están trabajando en la creación de zkVM más generalizados que se basan en ISA además de las máquinas virtuales criptográficas a medida.

En lugar de probar el EVM, el sistema podría probar una arquitectura de conjunto de instrucciones (ISA) diferente, como RISC-V o WASM en una nueva VM. Dos proyectos que están trabajando en estos zkVM generalizados son RISC Zero y zkWASM. Profundicemos un poco en RISC Zero aquí para demostrar cómo funciona esta estrategia y algunas de sus ventajas/desventajas. 

RISC Zero puede probar cualquier cálculo que se ejecute en una arquitectura RISC-V. RISC-V es un estándar de arquitectura de conjunto de instrucciones (ISA) de código abierto que ha ido ganando popularidad. La filosofía RISC (computadora con conjunto de instrucciones reducido) es construir un conjunto de instrucciones extremadamente simple con una complejidad mínima. Esto significa que los desarrolladores en las capas más altas de la pila terminan asumiendo una mayor carga en la implementación de instrucciones usando esta arquitectura mientras simplifican la implementación del hardware.

Esta filosofía también se aplica a la informática en general, los chips ARM han aprovechado los conjuntos de instrucciones de estilo RISC y han comenzado a dominar el mercado de los chips móviles. Resulta que los conjuntos de instrucciones más simples también tienen una mayor eficiencia energética y de área de troquel.

Esta analogía se mantiene bastante bien para la eficiencia de generar pruebas zk. Como se discutió anteriormente, al probar un seguimiento de ejecución en zk, paga la suma del costo de todas las instrucciones por cada elemento en el seguimiento, por lo que es mejor que sea más simple y con menos instrucciones totales.

Desde la perspectiva de un desarrollador, usar RISC Zero para manejar las pruebas de zk es muy parecido a usar las funciones de AWS Lambda para manejar la arquitectura del servidor back-end. Los desarrolladores interactúan con RISC Zero o AWS Lambda simplemente escribiendo código y el servicio maneja toda la complejidad del back-end.

Para RISC Zero, los desarrolladores escriben Rust o C++ (eventualmente cualquier cosa que apunte a RISC-V). Luego, el sistema toma el archivo ELF generado durante la compilación y lo usa como código de entrada para el circuito VM. Los desarrolladores simplemente llaman a probar que devuelve un objeto de recibo (que contiene la prueba zk del seguimiento de la ejecución) que cualquiera puede llamar `verificar` desde cualquier lugar. Desde el punto de vista del desarrollador, no hay necesidad de entender cómo funciona zk, el sistema subyacente maneja toda esta complejidad.

Para algunos circuitos básicos y reutilizables que son particularmente útiles para las aplicaciones de cadena de bloques o en otros lugares, es posible que los equipos ya hayan creado y optimizado estos circuitos para usted. Simplemente puede proporcionar la entrada para su caso de uso particular. Una prueba de inclusión de Merkle, por ejemplo, es algo que comúnmente se necesita en aplicaciones criptográficas (listas de lanzamiento aéreo, Tornado Cash, etc.). Como desarrollador de aplicaciones, siempre puede reutilizar estos contratos probados en batalla y simplemente modificar las capas en la parte superior para crear una aplicación única.

Por ejemplo, los circuitos de Tornado Cash se pueden reutilizar para un aplicación privada de lanzamiento aéreo o un solicitud de votacion privada. Manta y Semaphore están creando un conjunto completo de herramientas de dispositivos de circuitos comunes como este que se pueden usar en contratos de Solidity con poca o ninguna comprensión de las matemáticas subyacentes de zk moon.

Como se discutió extensamente, hay una gran cantidad de opciones diferentes para desarrollar una aplicación zk, todas con su propio conjunto único de compensaciones. Este cuadro ayudará a resumir esta matriz de decisiones para que, en función de su nivel de experiencia en zk y sus necesidades de rendimiento, pueda elegir la mejor herramienta para el trabajo. Esta no es una lista exhaustiva, planeo agregarla en el futuro a medida que me dé cuenta de que habrá más herramientas en el espacio.

zk está a la vanguardia de varias tecnologías, y construirlo requiere una comprensión profunda de las matemáticas, la criptografía, la informática y la ingeniería de hardware. Sin embargo, con más y más capas de abstracción disponibles cada día, los desarrolladores de aplicaciones pueden aprovechar el poder de zk sin un doctorado. A medida que las limitaciones de los tiempos de prueba se eliminen lentamente con el tiempo a través de optimizaciones en todos los niveles de la pila, es probable que veamos herramientas aún más simples para el desarrollador promedio.

Espero haberlo convencido, el desarrollador de software curioso, que puede comenzar a usar zk en sus aplicaciones hoy. Feliz piratería 🙂

Divulgaciones: Blockchain Capital es inversor en varios de los protocolos mencionados anteriormente.

Los puntos de vista expresados ​​en cada publicación de blog pueden ser los puntos de vista personales de cada autor y no reflejan necesariamente los puntos de vista de Blockchain Capital y sus afiliados. Ni Blockchain Capital ni el autor garantizan la precisión, adecuación o integridad de la información proporcionada en cada publicación del blog. No se hace ni da ninguna representación o garantía, expresa o implícita, por o en nombre de Blockchain Capital, el autor o cualquier otra persona en cuanto a la precisión, integridad o imparcialidad de la información contenida en cualquier publicación de blog y no se acepta ninguna responsabilidad u obligación. para cualquier información de este tipo. Nada de lo contenido en cada publicación de blog constituye asesoramiento de inversión, regulatorio, legal, de cumplimiento o fiscal o de otro tipo, ni se debe confiar en él para tomar una decisión de inversión. Las publicaciones de blog no deben verse como recomendaciones o solicitudes actuales o pasadas de una oferta para comprar o vender valores o para adoptar una estrategia de inversión. Las publicaciones del blog pueden contener proyecciones u otras declaraciones a futuro, que se basan en creencias, suposiciones y expectativas que pueden cambiar como resultado de muchos eventos o factores posibles. Si se produce un cambio, los resultados reales pueden variar materialmente de los expresados ​​en las declaraciones prospectivas. Todas las declaraciones prospectivas se refieren solo a la fecha en que se realizan dichas declaraciones, y ni Blockchain Capital ni cada autor asumen la obligación de actualizar dichas declaraciones, excepto según lo exija la ley. En la medida en que se haga referencia a documentos, presentaciones u otros materiales producidos, publicados o distribuidos por Blockchain Capital en cualquier publicación de blog, dichos materiales deben leerse con especial atención a las exenciones de responsabilidad proporcionadas en ellos.