Recientemente, muchos proyectos "ZK-EVM" han emitido anuncios uno tras otro. Polygon abrió su proyecto ZK-EVM, ZKSync lanzó planes para ZKSync 2.0 y Scroll, un novato relativo, anunció recientemente su proyecto ZK-EVM. Además, el equipo de Exploraciones de privacidad y escalado, el equipo de Nicolas Liochon et al y el equipo de Nethermind que trabajan en la traducción del lenguaje Solidity de EVM a un compilador alfa para el lenguaje Cairo compatible con ZK de StarkWare están trabajando en Esto continuará trabajando arduamente. todavía hay algunos proyectos que no he enumerado.
Los objetivos principales de estos proyectos son los mismos: usar la tecnología ZK-SNARK para generar pruebas encriptadas para la ejecución de transacciones similares a Ethereum, ya sea para hacer que las pruebas sean más fáciles de verificar en la propia cadena de Ethereum o para construir (cerca de) algunas funciones equivalentes a los proporcionados por Ethereum, pero más escalables que los ZK-rollups. Pero hay algunos matices entre estos proyectos, y hay diferencias en las compensaciones que hacen entre utilidad y velocidad. Esta publicación describirá la taxonomía de los diferentes "tipos" equivalentes de EVM, junto con las ventajas y los gastos generales de cada uno.
Resumen (formato de diagrama)
Tipo 1: Equivalente completo de Ethereum ZK-EVM
El primer tipo de ZK-EVM se esfuerza por ser un equivalente Ethereum completamente intransigente de ZK-EVM. No cambian ninguna parte del sistema Ethereum para facilitar la generación de pruebas: no reemplazan hashes, árboles de estado, árboles de transacción, precompilaciones u otra lógica en consenso, sin importar cuán pequeña sea.
Ventaja: compatibilidad perfecta
El objetivo de ZK-EVM es poder verificar bloques como lo hace actualmente Ethereum, o al menos, verificar bloques por encima de la capa de ejecución (por lo tanto, aunque la lógica de consenso de la cadena de balizas no está incluida, todas las transacciones ejecutadas, contratos inteligentes y se incluye la lógica de la cuenta).
El primer tipo de ZK-EVM es exactamente lo que necesitamos en última instancia para hacer que Ethereum L1 sea más escalable. A la larga, las modificaciones a Ethereum derivadas de los experimentos en el segundo y tercer tipo de ZK-EVM pueden introducirse razonablemente en Ethereum, pero esta nueva arquitectura tiene sus propias complejidades.
El primer tipo de ZK-EVM también es ideal para Rollups porque les permite reutilizar la infraestructura. Por ejemplo, los clientes de la capa de ejecución de Ethereum pueden generar y procesar bloques acumulativos como antes (al menos, una vez que se implementa la función de retiro, pueden reutilizar esta función para admitir depósitos ETH en acumuladores), por lo que los exploradores de bloques, las herramientas de bloques como generar pueden ser fácilmente reutilizado.
Desventaja: tiempo de generación de prueba lento
El diseño original de Ethereum no es compatible con ZK, por lo tanto, muchas partes del protocolo Ethereum necesitan realizar muchos cálculos para generar pruebas ZK. La primera clase de ZK-EVM tiene como objetivo replicar completamente el entorno de Ethereum y, como tal, no puede mitigar estas ineficiencias computacionales. Actualmente, las pruebas de bloque de Ethereum tardan muchas horas en generarse. Esto podría mitigarse mediante ineficiencias a través de una ingeniería inteligente (como la generación masiva de pruebas en paralelo) o, a largo plazo, a través de ZK-SNARK ASIC.
¿Quién está construyendo el primer tipo de ZK-EVM?
El equipo de exploraciones de privacidad y escalamiento está trabajando arduamente para construir un ZK-EVM, el primero de su tipo.
Tipo 2: ZK-EVM equivalente a EVM completo
El segundo tipo de ZK-EVM se esfuerza por ser un equivalente completo de EVM pero no un ZK-EVM equivalente a Ethereum. Es decir, "desde un punto de vista interno", son exactamente como Ethereum, pero hay algunas diferencias con Ethereum en el exterior, especialmente en las estructuras de datos, como la estructura de bloques y el árbol de estado.
Su objetivo es ser totalmente compatible con las aplicaciones existentes, pero realizará algunas modificaciones menores en Ethereum para facilitar el desarrollo y generar pruebas más rápido.
Ventajas: totalmente equivalente a nivel de máquina virtual
El segundo tipo de ZK-EVM cambiará la estructura de datos que almacena el estado de Ethereum. Afortunadamente, dado que el EVM en sí mismo no puede acceder directamente a estas estructuras de datos, no hay impacto en las aplicaciones que se ejecutan originalmente en Ethereum, y aún pueden ejecutarse en el segundo tipo de resumen ZK-EVM. Es posible que no pueda usar el cliente de la capa de ejecución de Ethereum como lo hacía originalmente, pero puede usar el cliente con algunas modificaciones y seguir teniendo acceso a las herramientas de depuración de EVM y a la mayoría de las otras infraestructuras de desarrollo.
Hay algunas excepciones. Las incompatibilidades de aplicaciones surgen cuando se validan las pruebas del árbol de Merkle de los bloques históricos de Ethereum para verificar las transacciones históricas, los recibos o las afirmaciones estatales (como lo hacen a veces los puentes, por ejemplo). Si ZK-EVM reemplaza a Keccak con una función hash diferente, corromperá estas pruebas. Además, a menudo desaconsejo crear aplicaciones de esta manera, porque las futuras actualizaciones de Ethereum (como el árbol Verkle) afectarán las aplicaciones incluso en Ethereum. Una mejor opción es agregar la compilación previa de acceso histórico a prueba de futuro por parte de Ethereum.
Desventajas: se ha mejorado pero sigue siendo demasiado lento
El segundo tipo de ZK-EVM puede proporcionar tiempos de generación de pruebas más rápidos que el primer tipo, principalmente mediante la eliminación de partes de la pila de Ethereum que dependen de una criptografía innecesariamente compleja y hostil a ZK. En particular, estas pilas pueden cambiar los árboles patricia Keccak y Merkle basados en RPL de Ethereum, y tal vez cambiar las estructuras de bloques y recibos. El segundo tipo de ZK-EVM utiliza una función hash diferente, como Poseidón. Naturalmente, modifica el árbol de estado para almacenar códigos hash y Keccak sin verificar hashes para manejar códigos de operación EXTCODEHASH y EXTCODECOPY.
Estas modificaciones mejoraron mucho el tiempo de generación de pruebas, pero no resolvieron todos los problemas. Este tipo de ZK-EVM hereda la ineficiencia y la incompatibilidad con ZK que trae consigo EVM, por lo que la ineficiencia original de generar pruebas basadas en EVM aún existe. La memoria es el ejemplo más simple: debido a que MLOAD puede leer 32 bytes cualesquiera, incluidos los segmentos de código "desordenados" (cuyo principio y final no son múltiplos de 32), MLOAD no puede entenderse simplemente como la lectura de un fragmento de código; más bien, puede requieren leer dos segmentos de código consecutivos y realizar manipulación de bits para combinar los resultados.
¿Quién está construyendo el segundo tipo de ZK-EVM?
El proyecto ZK-EVM de Scroll está construyendo un segundo tipo de ZK-EVM, al igual que Polygon Hermez. Aun así, ningún proyecto se ha convertido realmente en el segundo tipo de ZK-EVM; en particular, aún no se han implementado muchas precompilaciones más complejas. Por tanto, en la actualidad, se debe decir que estos dos proyectos pertenecen a la tercera categoría de ZK-EVM.
Tipo 2.5: equivalente a EVM, excepto para gastos generales de gas
En el peor de los casos, una forma de mejorar en gran medida el tiempo de generación de prueba lento es aumentar en gran medida el costo de gas de las ejecuciones que son difíciles de generar pruebas ZK en el EVM. Estas ejecuciones pueden implicar precompilación, códigos de operación KECCAK y pueden implicar la invocación de patrones específicos del contrato, el acceso a la memoria/almacenamiento o la reversión.
Cambiar el costo del gas puede reducir la compatibilidad de la herramienta del desarrollador y romper algunas aplicaciones, pero en general es menos riesgoso que cambiar "más profundamente" el EVM. Los desarrolladores deben tener cuidado de no consumir más gas del que puede acomodar un bloque, y nunca hacer llamadas con números de gas codificados (este ha sido un consejo estándar para los desarrolladores durante mucho tiempo).
Otra forma de administrar las restricciones de recursos es simplemente establecer un límite estricto en la cantidad de veces que se puede llamar a cada operación. Esto es simple de implementar en el circuito, pero las suposiciones de seguridad en el EVM no son tan buenas. Prefiero llamar a este enfoque Tipo 3 ZK-EVM en lugar de Tipo 2.5.
Tipo 3: casi equivalente a EVM
La tercera clase de ZK-EVM es casi equivalente a EVM, pero requiere algunos sacrificios para lograr una equivalencia total a fin de mejorar aún más el tiempo de generación de pruebas y facilitar el desarrollo de EVM.
Ventajas: Facilidad de construcción, tiempos de construcción comprobados más rápidos
El tercer tipo de ZK-EVM puede eliminar algunas características que son excepcionalmente difíciles de implementar en las implementaciones de ZK-EVM. La precompilación suele ser la más difícil de implementar de estas características; además, tales ZK-EVM a veces manejan el código de contrato, la memoria y las pilas de forma ligeramente diferente.
Desventaja: peor compatibilidad
El tercer tipo de ZK-EVM tiene como objetivo ser compatible con la mayoría de las aplicaciones y requiere solo una reescritura mínima de las aplicaciones restantes. Incluso entonces, será necesario volver a escribir algunas aplicaciones porque usan precompilaciones que el tercer tipo de ZK-EVM elimina, o porque tienen dependencias sutiles en casos extremos que la VM maneja de manera diferente.
¿Quién construirá el tercer tipo de ZK-EVM?
Tanto Scroll como Polygon en su forma actual pertenecen al tercer tipo de ZK-EVM, aunque se espera que mejoren la compatibilidad con el tiempo. El diseño de Polygon es único, usan su propio lenguaje interno zkASM para verificar ZK y usarán la implementación de zkASM para traducir el código ZK-EVM. Aunque los detalles de implementación son así, todavía me gusta llamarlo el tercer tipo real de ZK-EVM. Todavía puede verificar el código EVM, solo usa una lógica interna diferente.
En este momento, ningún equipo de ZK-EVM quiere ser un ZK-EVM Tipo 3; el Tipo es solo una fase de transición antes de que se realice el complejo trabajo de las adiciones precompiladas y el proyecto pueda pasar al Tipo 2.5. Sin embargo, al agregar una nueva precompilación compatible con ZK-SNARK, que brinda a los desarrolladores la capacidad de demostrar que el tiempo de generación es corto y la sobrecarga de gas es baja, el primer y segundo tipo de ZK-EVM pueden convertirse espontáneamente en el tercer tipo de ZK- EVM en el futuro EVM.
Tipo 4: equivalente de lenguaje de alto nivel
El cuarto tipo de sistema ZK-EVM funciona escribiendo el código fuente del contrato inteligente en un lenguaje de alto nivel (como Solidity, Vyper o algún lenguaje intermedio compilado a partir de los dos) y compilando estos códigos fuente en algunos claramente diseñados en otros lenguajes. que son compatibles con ZK-SNARK.
Ventaja: tiempo de generación de prueba extremadamente rápido
En lugar de generar pruebas ZK para todos los aspectos de cada paso de ejecución del EVM, puede comenzar directamente a probar el código escrito en un lenguaje de alto nivel, por lo que puede evitar muchos gastos generales.
En este artículo, aunque solo he usado una oración para describir esta ventaja (en comparación con la siguiente lista de desventajas relacionadas con la compatibilidad), ¡esta oración no debe interpretarse como un juicio de valor! La compilación directa desde un lenguaje de alto nivel realmente puede reducir drásticamente los gastos generales e impulsar la descentralización al facilitar el proceso de prueba.
Desventaja: peor compatibilidad
Una aplicación "normal" escrita en Vyper o Solidity se puede compilar y "simplemente funciona", pero hay una serie de situaciones importantes en las que muchas aplicaciones se vuelven no "normales":
-
La dirección del contrato en el sistema del cuarto tipo ZK-EVM puede ser diferente de la del EVM, porque la dirección del contrato CREATE2 depende del código de bytes específico. Esto rompe aplicaciones, billeteras ERC-4337, singletons EIP-2470 y muchas otras aplicaciones que dependen de "contratos contrafactuales" que aún no se han implementado.
-
El código de bytes EVM escrito a mano es más difícil de usar. Muchas aplicaciones usan partes escritas a mano del código de bytes EVM para mayor eficiencia. Aunque hay muchas maneras de implementar soporte para este tipo de código de bytes EVM restringido, es posible aplicar estos casos de uso sin convertirse completamente en un ZK-EVM de tercera clase, un sistema ZK-EVM de cuarta clase puede que dicho código de bytes escrito manualmente no lo sea. ser apoyado
-
Una gran cantidad de infraestructura de depuración no sobrevive porque se ejecuta en el código de bytes EVM. Sin embargo, podemos mitigar esta desventaja al tener un acceso más fácil a la infraestructura de depuración a través de lenguajes de alto nivel "tradicionales" o lenguajes intermedios (como LLVM).
Los desarrolladores deben ser conscientes de estos problemas.
¿Quién está construyendo el cuarto tipo de ZK-EVM?
El sistema ZKSync es el cuarto tipo de ZK-EVM, aunque puede mejorar la compatibilidad del código de bytes de EVM con el tiempo. El proyecto Warp de Nethermind está construyendo un compilador de solidez para StarkWare Cairo que convertirá a StarkNet en un verdadero sistema ZK-EVM de cuarta clase.
El futuro de cada tipo de ZK-EVM
No es que estos tipos sean "mejores" o "peores" que otros. Por el contrario, son diferentes en comparación: del tipo 1 al tipo 4, los tipos de ZK-EVM con números más bajos son más compatibles con la infraestructura existente, pero funcionan más lentamente; mientras que los tipos de ZK-EVM con números más altos son menos compatibles con la infraestructura existente, pero corre más rápido. En conclusión, la exploración de todos los tipos de ZK-EVM es beneficiosa para el desarrollo saludable del campo.
Además, un proyecto ZK-EVM puede comenzar fácilmente con un ZK-EVM con un número más alto y pasar a un tipo con un número más bajo (y viceversa) con el tiempo. Por ejemplo:
-
ZK-EVM se puede poner en uso al principio como un tercer tipo de ZK-EVM, sin agregar algunas características que son particularmente difíciles de generar pruebas ZK. Más tarde, pueden agregar esas funciones con el tiempo y pasar a la segunda categoría.
-
Los ZK-EVM que comienzan como ZK-EVM de segunda clase pueden luego convertirse en el tipo híbrido y de segunda clase del primer tipo de ZK-EVM. Scroll está considerando desarrollarse en esta dirección.
-
Algunos proyectos ZK-EVM que comenzaron como sistemas Tipo 4 pueden convertirse con el tiempo en ZK-EVM Tipo 3 agregando el procesamiento de código EVM más tarde (aunque todavía se alienta a los desarrolladores a compilar directamente desde lenguajes de alto nivel, esto reduce las tarifas y el tiempo de generación de pruebas) .
-
Si Ethereum adopta algunas modificaciones para volverse más compatible con ZK, entonces el segundo y tercer tipo pueden convertirse en el primer tipo ZK-EVM.
-
El primer o segundo tipo de ZK-EVM se puede cambiar al tercer tipo de ZK-EVM agregando la precompilación del código de lenguaje amigable de verificación ZK-SNARK. Esto les da a los desarrolladores la posibilidad de elegir entre la compatibilidad con Ethereum y la velocidad de operación. Esto podría considerarse un ZK-EVM de tercera clase, ya que destruiría la equivalencia perfecta de EVM, pero para fines prácticos probablemente aún tendría muchas de las ventajas de los ZK-EVM de primera y segunda clase. Su inconveniente puede ser que algunas herramientas de desarrollo no entiendan la autocompilación de ZK-EVM, aunque esto también se puede solucionar: las herramientas de desarrollo pueden admitir formatos de configuración que incluyen implementaciones precompiladas de código EVM equivalentes a Esto agrega compatibilidad genérica de compilación previa.
Personalmente, al combinar mejoras en ZK-EVM con mejoras que hacen que Ethereum sea más compatible con ZK-SNARK, espero que todos estos proyectos se conviertan lentamente en ZK-EVM de primera clase. En ese futuro, también tendremos una variedad de implementaciones de ZK-EVM, que se pueden usar para el resumen de ZK y también se pueden usar para verificar la cadena Ethereum en sí. En teoría, no es necesario que Ethereum se estandarice en una sola implementación de ZK-EVM para el uso de L1; diferentes clientes pueden usar diferentes pruebas y podemos seguir beneficiándonos de la redundancia de código.
En cualquier caso, todavía necesitamos algo de tiempo para conocer este futuro. Al mismo tiempo, también veremos mucha innovación en la expansión de Ethereum y el desarrollo de diferentes pistas basadas en Ethereum ZK rollup.