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.
Tipo 1: completamente equivalente a Ethereum;
Tipo 2: completamente equivalente a EVM;
Tipo 2.5: Parcialmente equivalente a EVM;
Tipo 3: casi equivalente a EVM;
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.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
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.
Tipo 1: completamente equivalente a Ethereum;
Tipo 2: completamente equivalente a EVM;
Tipo 2.5: Parcialmente equivalente a EVM;
Tipo 3: casi equivalente a EVM;
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:
defecto
Perfecta compatibilidad:
Solución al problema:
Tipo 2: totalmente equivalente a EVM
Arquitectura:
ventaja
defecto
Antes de comprender las desventajas, primero comprenda qué es "Keccak":
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
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;
ventaja
defecto
Tipo 3: Casi equivalente a EVM
Arquitectura:
ventaja
defecto
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:
ventaja
defecto
proyecto
Finalmente, podemos comparar los tipos anteriores para ayudar a todos a comprender los diferentes zkEVM de un vistazo.