Del Tipo 1 al Tipo 4, ¿cuáles son las diferencias entre los distintos tipos de ZK-EVM?

Autor original| Lisa Akselrod

Compilado | Odaily Planet Daily 0xAyA

*Nota del editor: el autor lo compiló basándose en el artículo de introducción de ZK-EVM escrito previamente por Vitalik, y presentó en detalle los distintos tipos de ZK-EVM y las diferencias entre ellos. *

Hace aproximadamente un año, un grupo de ZK-EVM anunció que estaban a punto de lanzar una red de prueba. Estos movimientos han despertado la curiosidad de la comunidad Ethereum y han provocado un debate sobre los matices detrás de términos como equivalencia de Ethereum y equivalencia de EVM.

En aras de la claridad, Vitalik escribió un importante artículo titulado "Diferentes tipos de ZK-EVM" que clasifica varios ZK-EVM en cuatro tipos y explica sus diferencias.

La idea central es: el tipo 1 (por ejemplo, Taiko) es totalmente equivalente a Ethereum, mientras que el tipo 4 (por ejemplo, zkSync) sobresale en la generación eficiente de pruebas. Todos los demás tipos, Tipo 2, Tipo 2.5 y Tipo 3, se encuentran en el medio (por ejemplo, Polygon zkEVM, Scroll, Linea).

La mayoría de los ZK-EVM son inicialmente de Tipo 2.5 y Tipo 3, con cierta intención de evolucionar hacia el Tipo 1 o el Tipo 2, aunque estos proyectos no han proporcionado cronogramas ni compromisos específicos para esto.

**Este artículo se centra en las diferencias entre el Tipo 1 y el Tipo 2/Tipo 2.5 y describe las posibles consecuencias de romper la equivalencia de Ethereum. También tocaremos brevemente otros tipos. **

El objetivo principal de ZK-EVM es escalar Ethereum, es decir, aumentar el rendimiento de Ethereum manteniendo sus otras características (seguridad, experiencia de desarrollador, etc.). Idealmente, ZK-EVM debería poder:

• Demuestra la ejecución de código de bytes nativo no modificado (que cubre el 100 % de los códigos de operación de Ethereum) de acuerdo con la especificación de la máquina virtual de Ethereum en el Libro Amarillo.
• Genere pruebas rápidamente a bajo costo.
• Permite la reutilización del 100% de herramientas e infraestructura desarrolladas para Ethereum.
• Permitir que cualquier dApp de Ethereum se vuelva a implementar en ZK-EVM "tal cual" ("tal cual" significa que no se requieren cambios ni compromisos).

Diferencias entre los tipos ZK-EVM

En el mundo ZK-EVM, las diferencias provienen principalmente del nivel de equivalencia Ethereum/EVM, el impacto de los elementos no amigables con ZK en el costo y la velocidad de generación de pruebas y la complejidad de la implementación del circuito (como la construcción de VM o el estado). árboles).

Analicemos estas diferencias, distinguiendo específicamente el Tipo 1 del Tipo 2/Tipo 2.5. También abordaremos los casos de uso más relevantes para cada tipo.

Al comparar varios tipos, se suele utilizar el siguiente cuadro:

Para aquellos que no trabajan a tiempo completo en el campo ZK-EVM, esta tabla puede parecer confusa, así que traduzcamos estos términos a términos sencillos y echemos un vistazo:

Este diagrama brinda una imagen más clara de cómo se ve realmente cada tipo, pero aún puede ser un poco oscuro. Exploremos completamente el mundo ZK-EVM explicando cada tipo individualmente.

Tipo 1: Equivalente a Ethereum

Vitalik Buterin:

“El ZK-EVM tipo 1 es lo que finalmente necesitamos para hacer que la capa 1 de Ethereum sea más escalable”.

El tipo 1 significa no cambiar ninguna parte del sistema Ethereum para facilitar la generación de pruebas. Ningún cambio en Ethereum significa que no hay compromiso en la seguridad, ya que la mayoría de las primitivas criptográficas (por ejemplo, funciones hash), la infraestructura del desarrollador (por ejemplo, los depuradores) o la infraestructura de la cadena (por ejemplo, los clientes de ejecución) ya tienen 9 años de pruebas de campo.

El ZK-EVM tipo 1 no reemplaza nada: hashes, árboles de estado, árboles de transacciones, precompilación o cualquier otra lógica de consenso, todo es exactamente igual que el EVM de la red principal.

• El tipo 1 es el único que puede verificar la cadena Ethereum en sí, desde bloques completos hasta la ejecución de transacciones, contratos inteligentes y lógica de cuenta.

Tipo 2: Equivalente a EVM

El tipo 2 acelera la generación de pruebas y facilita el desarrollo de circuitos al eliminar algunas piezas que no son propicias para ZK. Sin embargo, debido a las consecuencias de esto, puede hacer que el desarrollo de otras partes del paquete acumulativo de ZK (como el software del nodo) sea más complejo. Estas complejidades pueden deberse a incompatibilidades entre las mejores prácticas establecidas y las herramientas de prueba y los cambios que se están implementando (como un árbol de estado alterado).

*Nota: Equivalente a Ethereum y equivalente a EVM no son lo mismo. Si bien la equivalencia con Ethereum significa que no se ha cambiado ninguna parte de Ethereum, lo que significa que es totalmente compatible con todas las dApps de Ethereum, la equivalencia con EVM permite cambios en las estructuras de datos (como estructuras de bloques o árboles de estado). *

Si bien estos ajustes pueden parecer menores, afectan la compatibilidad de Ethereum. Los cambios en las estructuras de datos pueden hacer que las dApps de Ethereum sean incompatibles con el ZK-EVM tipo 2, especialmente al validar pruebas de Merkle sobre transacciones, recibos o estados pasados (como a través de puentes de cadena).

Eliminar elementos no amigables de ZK

Las modificaciones a Ethereum tienen como objetivo simplificar el desarrollo y aumentar la velocidad de generación de pruebas. El objetivo es podar las partes de Ethereum que dependen de una criptografía hostil de conocimiento cero. En términos más técnicos, partes que requieren una gran cantidad de puertas (operaciones de suma y multiplicación) debido a dominios no locales (como funciones hash), una gran cantidad de multiplicaciones multiescalares y/o transformadas rápidas de Fourier (FFT); o Sólo la parte que requiere mucha manipulación.

Ejemplos específicos de elementos hostiles de conocimiento cero que el ZK-EVM tipo 2 puede modificar:

• Función hash: mientras que Ethereum utiliza la función hash Keccak, muchos ZK-EVM utilizan la función hash Poseidon, que requiere un número significativamente menor de puertas. Por ejemplo, estimemos cuántas funciones hash de cada tipo se pueden calcular por segundo (es decir, una comparación que demuestra la velocidad de generación).

Las funciones hash de Poseidon tienen importantes ventajas de velocidad en la generación de pruebas.

Sin embargo, es importante señalar que las primitivas criptográficas más nuevas no son tan populares en comparación con las primitivas criptográficas establecidas que son ampliamente reconocidas por la comunidad. Si bien Poseidón puede ofrecer velocidad, las características probadas en batalla de Keccak lo hacen más robusto y seguro a medida que se adopta ampliamente.

Es por eso que Keccak, a pesar de ser más antiguo y adoptado por una comunidad más amplia (en otras industrias, como sistemas de seguridad o sensores en dispositivos inteligentes), puede considerarse más probado que Poseidon, que después de todo está dentro de la comunidad ZK New hash. Funciones para crear y utilizar.

• Árboles de estado para almacenamiento de datos: por ejemplo, mientras Ethereum usa árboles Merkle Patricia (usando hash Keccak), algunos ZK-EVM de tipo 2 eligen árboles Merkle dispersos (usando hash Poseidon). Cambiar el árbol de estados puede causar algunas incompatibilidades. Por ejemplo, el árbol Merkle de Ethereum tiene diferentes tipos de nodos y utiliza RLP para codificar datos, lo cual es algo difícil de hacer en ZK.
• Estructura de bloques: Los bloques contienen una gran cantidad de información. Sin embargo, cuando exploramos L2, solo nos preocupamos por ution_payload_header (es decir, el hash del bloque). En la imagen siguiente, se encuentra la estructura (hash de bloque) de todos los datos contenidos en ution_payload_header.

**Tenga en cuenta: cambiar cualquiera de estos componentes romperá la equivalencia de Ethereum. **

Tipo 2.5: Equivalente a EVM, considerando el costo del gas

El tipo 2.5 ZK-EVM aumenta el costo del gas en operaciones específicas que son difíciles de probar utilizando la tecnología ZK en EVM.

Dado el límite de gas por bloque de Ethereum (30 M de gas), aumentar el costo del gas por código de operación da como resultado menos códigos de operación por bloque. Por lo tanto, se pueden incluir códigos de operación menos complejos en un bloque. Los códigos de operación más simples permiten que los circuitos sean más pequeños y las pruebas se generen más rápido.

*el gas es una unidad de medida de trabajo.

• Los precios de los códigos de operación se calculan en gasolina.
• Los códigos de operación especifican operaciones dentro de instrucciones en lenguaje de máquina.
• Un programa es una lista estática de códigos de operación. La ejecución del programa es un seguimiento de ejecución.
• Un seguimiento de ejecución es una lista ordenada específica de códigos de operación ejecutados por un programa.

Las piezas que son difíciles de probar ZK incluyen:

• Códigos de operación de Keccak y algunos otros códigos de operación que dependen de Keccak.
• Precompilado: funciones accesibles al EVM. Algunos de ellos proporcionan tareas complejas o matemáticamente complejas, como funciones criptográficas (como blake 2 f o sha 256). No se ejecutan dentro del EVM, sino como funciones codificadas en el cliente de ejecución y expuestas al EVM mediante LLAMADAS a direcciones especiales.
• Acceso a la memoria: por ejemplo, aumentar el tamaño de la ranura de memoria (por ejemplo, Ethereum usa memoria alineada con bytes, mientras que Polygon zkEVM usa ranuras de memoria de 32 bytes). Para que este cambio sea posible, se tuvo que cambiar la lógica interna de ciertos códigos de operación (como MLOAD).
• Almacenamiento (es decir, cambiar la función hash o el árbol de estado como se describe anteriormente).

Cambiar los costos del gas puede reducir la compatibilidad de las herramientas de desarrollo y dañar algunas dApps. Por ejemplo, un contrato inteligente que ejecuta con frecuencia códigos de operación con costos de gas crecientes puede exceder el límite de bloque de gas y no ejecutarse.

Tipo 3: Casi equivalente a EVM

El ZK-EVM tipo 3 omite la precompilación que no se aplica a ZK y puede ajustar el acceso a la memoria y al almacenamiento.

Las dApps que dependían de aplicaciones precompiladas eliminadas deberán reescribirse. En casos inusuales, las diferencias en cómo el ZK-EVM tipo 3 maneja los casos extremos y el EVM original pueden requerir ajustes en la dApp.

Tipo 4 (equivalente a lenguaje de alto nivel)

El tipo 4 ya está lejos de EVM.

El código fuente de contrato inteligente escrito en un lenguaje de alto nivel (por ejemplo, Solidity, Zinc) se compila en una representación intermedia, generando códigos de operación adecuados para máquinas virtuales compatibles con ZK.

• Este método evita generar pruebas ZK para cada paso de ejecución de EVM, lo que reduce en gran medida el trabajo de prueba.
• Incluso si el contrato se puede compilar, se requiere trabajo adicional si la dApp usa código de bytes escrito a mano EVM. *El ZK-EVM tipo 4 también requiere sus propias herramientas de desarrollo (solo nivel de código de operación), como depuradores y rastreadores.

En el circuito ZK que prueba la trayectoria de ejecución, cada paso implementa la restricción y el costo de cada paso es la suma de todos los códigos de operación. Por lo tanto, el ZK-EVM Tipo 4 está diseñado para utilizar la menor cantidad posible de códigos de operación complejos para optimizar la eficiencia.

Vale la pena mencionar que los códigos de operación personalizados (códigos de operación no cubiertos en Ethereum) permiten pasar nuevas funciones que no son posibles en Ethereum de forma predeterminada. Por ejemplo, realice múltiples llamadas para su ejecución a través de la función de abstracción de cuenta o inicie una billetera de contrato inteligente utilizando una solución lista para usar como Argent.

Resumir

Los diferentes tipos de ZK-EVM priorizan diferentes objetivos y características. El tipo 1 se centra en la equivalencia de Ethereum, mientras que el tipo 4 prioriza la generación eficiente de pruebas. Otros tipos se encuentran entre estos extremos, y muchos protocolos ZK-EVM Tipo 2 y 3 han anunciado su intención de pasar a equivalentes de Ethereum.

Es posible que estos cuatro tipos de clasificación no sean el estado final del paquete acumulativo de ZK y pueden estar sujetos a modificaciones adicionales en el futuro. Por ejemplo, algunos ZK-EVM pueden volverse híbridos, los Tipo 1/2 pueden desarrollar soluciones de Tipo 4 (con la mayor eficiencia posible) y proporcionar dApps con ambas opciones, mientras que los ZK-EVM Tipo 3 y 4 pueden agregar una opción equivalente a Ethereum.