Explicar en detalle los cinco tipos de ZK-EVM: arquitectura, ventajas e inconvenientes y soluciones

Autor del texto original: s Recopilación del texto original: Deep Tide TechFlow

Este artículo explora cinco tipos de ZK-EVM en detalle, cada uno con su arquitectura única, ventajas y desventajas y posibles soluciones.

Además, el artículo también enumera algunos ejemplos prácticos de proyectos para que los lectores puedan comprender mejor el rendimiento de estos tipos en aplicaciones prácticas. Tanto si es un desarrollador de cadenas de bloques como un lector interesado en la tecnología de cadenas de bloques, este artículo le proporcionará información detallada y concisa.

Exploremos los tipos de ZK-EVM, sus ventajas y desventajas.

1. Tipo 1: completamente equivalente a Ethereum;

2. Tipo 2: completamente equivalente a EVM;

3. Tipo 2.5: Parcialmente equivalente a EVM;

4. Tipo 3: casi equivalente a EVM;

5. Tipo 4: donde el lenguaje de alto nivel es equivalente.

Tipo 1: totalmente equivalente a Ethereum

Arquitectura: Es exactamente igual que Ethereum y no cambia ninguna parte del sistema Ethereum.

ventaja

Perfecta compatibilidad:

• Capacidad para verificar bloques de Ethereum;
• Ayudar a que Ethereum L1 sea más escalable;
• Adecuado para Rollups ya que pueden reutilizar mucha infraestructura.

defecto

Perfecta compatibilidad:

• Ethereum no fue diseñado originalmente para la funcionalidad ZK;
• Muchos componentes de Ethereum requieren muchos cálculos para generar pruebas ZK (ZKP);
• Las pruebas para los bloques de Ethereum tardan muchas horas en generarse.

Solución al problema:

• Probador de paralelización a gran escala;
• ASIC ZK-SNARK.

Tipo 2: totalmente equivalente a EVM

Arquitectura:

• La estructura de datos (estructura de bloque y árbol de estado) es significativamente diferente de Ethereum;
• Totalmente compatible con las aplicaciones existentes;
• Modificaciones menores a Ethereum para un desarrollo más fácil y una generación de pruebas más rápida.

ventaja

• Proporciona tiempos de prueba más rápidos que el Tipo 1;
• La EVM no accede directamente a la estructura de datos;
• Aplicaciones que se ejecutan en Ethereum: es probable que se ejecuten en Tipo 2;
• Compatibilidad con las herramientas de depuración de EVM existentes y otra infraestructura de desarrollo.

defecto

Antes de comprender las desventajas, primero comprenda qué es “Keccak”:

• El algoritmo hash de la cadena de bloques Ethereum;
• Se utiliza para proteger datos en Ethereum;
• Asegúrese de que el mensaje se convierta en un hash.

El tipo 2 no es compatible con aplicaciones que verifican pruebas de Merkle de bloques históricos para verificar información sobre transacciones históricas, recibos/estados. Esto se debe a que si el algoritmo hash cambia (ya no es Keccak), la prueba dejará de ser válida.

Podemos pensar en Keccak como un lenguaje que usa pruebas de Merkle (alfabetos). Si ZK-EVM reemplaza a Keccak con otro algoritmo hash (como Poseidon), las pruebas de Merkle se volverán desconocidas y las aplicaciones no podrán leerlas y validar sus afirmaciones.

Solución potencial a las deficiencias: Ethereum podría agregar precompilación de acceso de historial escalable en el futuro.

proyecto

• Desplazarse;
• Polígono Hermez.

Sin embargo, estos proyectos aún no han implementado una precompilación más sofisticada, por lo tanto, pueden considerarse Tipo 2 incompletos.

Tipo 2.5: Parcialmente equivalente a EVM

Arquitectura:

Aumentar el costo del gas de operaciones EVM específicas que son difíciles de probar ZK;

• Precompilado;
• Código de operación Keccak;
• El modo de llamar al contrato;
• Acceder a la memoria;
• almacenamiento.

ventaja

• Mejora significativa del tiempo de prueba en el peor de los casos;
• Más seguro que realizar cambios más profundos en la pila de EVM.

defecto

• Se reduce la compatibilidad de las herramientas de desarrollo;
• Algunas aplicaciones no funcionarán.

Tipo 3: Casi equivalente a EVM

Arquitectura:

• En la implementación de ZK-EVM, se eliminan algunas funciones que son extremadamente difíciles de implementar, generalmente precompiladas;
• ZK-EVM tiene ligeras diferencias en la forma en que maneja el código de contrato, la memoria o la pila.

ventaja

• acortar el tiempo de verificación;
• Facilitar el desarrollo de EVM;
• El objetivo es requerir reescrituras mínimas para aplicaciones menos compatibles.

defecto

• Más incompatibilidades;
• Las aplicaciones que usan precompilación que se eliminaron en el Tipo 3 deberán volver a escribirse.

proyecto

Actualmente, Scroll y Polygon se consideran Tipo 3; sin embargo, el equipo de ZK-EVM no debe contentarse con ser Tipo 3, el Tipo 3 es una etapa de transición en la que ZK-EVM agrega precompilación para mejorar la compatibilidad y pasa al Tipo 2.5.

Tipo 4: equivalente de lenguaje de alto nivel

Arquitectura:

• Aceptar código de contrato inteligente escrito en lenguajes de alto nivel (como Solidity, Vyper);
• Compilado en un lenguaje diseñado para ser compatible con ZK-SNARK.

ventaja

• Tiempo de prueba muy rápido;
• Reducción de gastos generales (costo, tiempo y esfuerzo computacional);
• Reducir la barrera para convertirse en probador: aumentar el grado de descentralización.

defecto

• En un sistema tipo 4, la dirección del contrato puede ser diferente de la dirección en el EVM, porque la dirección depende del bytecode exacto;
• Esto significa que si los ZK-EVM de tipo 4 no tienen bytecodes, no podrán crear direcciones;
• El tipo 4 será incompatible con las solicitudes basadas en contratos contrafácticos en los casos anteriores;
• Muchas infraestructuras de depuración no son portátiles porque se ejecutan en el código de bytes EVM.

proyecto

• zkSync

Finalmente, podemos comparar los tipos anteriores para ayudar a todos a comprender los diferentes zkEVM de un vistazo.