- Tema
66k Popularidad
23k Popularidad
7k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
12k Popularidad
2k Popularidad
- Anclado
66k Popularidad
23k Popularidad
7k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
12k Popularidad
2k Popularidad
¿Qué zkEVM tiene el mejor rendimiento? Prueba de implementación del contrato Ethereum L2
Autor: Jarrod Watts; Compilación: Block Beats
En la guerra de expansión de Ethereum, Optimistic rollups son altamente compatibles o incluso completamente equivalentes a EVM, lo que lleva a las ventajas inherentes de Arbitrum y Optimism en la pista para que los desarrolladores las adopten. Su transferencia de código sin problemas de L1 a L2 y sus ricas herramientas de desarrollo pueden atraer rápidamente a los desarrolladores para instalarse, implementar y crear aplicaciones en la plataforma.
En cambio, la serie ZK es más difícil. Sus características técnicas inherentes hacen que los paquetes acumulativos de ZK personalicen sus propias máquinas virtuales, lo que significa que la parte del proyecto debe trabajar más para "interpretar" el código del EVM o incluso desarrollar y escribir código nuevo desde cero. Sin embargo, varios proyectos de seguimiento de ZK rollups, incluidos Taiko, Polygon, Linea, Scroll y ZkSync Era, han lanzado sus propias implementaciones de zkEVM.
Como el santo grial de la expansión, zkEVM tiene un impacto crucial en la experiencia de implementación del contrato del desarrollador Frente a una variedad de proyectos ZK rollups, ¿cómo deben elegir los desarrolladores?
Este artículo recopila un resumen de los tweets de Jarrod Watts, ingeniero de relaciones con desarrolladores en Polygon. Al implementar contratos inteligentes (un contrato inteligente Solidity y un contrato NFT) en el popular proyecto ZK rollups actual, midió el rendimiento de zkEVM de proyectos como Taiko, Polygon, Linea, Scroll y ZkSync Era, y comparó sus ventajas y desventajas respectivas y los créditos L2 a L1 Time para proporcionar una guía de prueba práctica para los desarrolladores que desean intentar implementar contratos de dos capas.
La siguiente es una compilación del texto original de BlockBeats:
**¿Qué es ZK-EVM y por qué lo necesitamos? ****Antes de interpretar qué es ZK-EVM, veamos por qué se necesita ZK-EVM. **
ZK Rollups brinda escalabilidad y alto rendimiento a Ethereum. En el otro lado de la moneda, la solución ZK Rollups no es compatible con EVM (Ethereum Virtual Machine), lo que significa que la solución ZK Rollups solo puede admitir operaciones limitadas, incluida la transferencia, la acuñación o la grabación, y se deben desarrollar herramientas como billeteras para los usuarios.
Por lo tanto, necesitamos ZK Rollups que sean compatibles con el EVM, y para ello, varias empresas han desarrollado sus propios ZK-EVM.
ZK-EVM, o Zero-Knowledge EVM, es una implementación de máquina virtual de Ethereum compatible con pruebas de Zero-Knowledge.
La función principal de ZK-EVM es procesar transacciones por lotes en Ethereum L2 (capa 2) y enviar la "prueba de validez" de las transacciones por lotes de regreso a Ethereum L1. En general, zkEVM puede hacer todo por la red principal de Ethereum. Compila código legible por humanos en Solidity o Vyper en bytecode, ejecuta contratos inteligentes y actualiza el estado de la cadena de bloques.
La dificultad de crear ZK Rollups compatibles con EVM es que Ethereum no se diseñó originalmente teniendo en cuenta la compatibilidad con ZK. Esto significa que las pruebas de conocimiento cero requieren muchos recursos para calcular.
Entre ellos, algunos códigos de operación de código de operación EVM son particularmente "antipáticos con ZK", lo que lleva a que los productos ZK-EVM finalmente estén diseñados por varias compañías con diferente compatibilidad con EVM.
** ¿Qué son los códigos de operación, código de bytes y EVM? **
Es hora de la ciencia popular, ¿qué son los códigos de operación, los códigos de bytes y EVM?
En primer lugar, EVM es el entorno operativo para contratos inteligentes en Ethereum. Ethereum almacena el llamado "estado de la máquina" en una estructura de datos de árbol trie, que cambia después de que se ejecuta cada transacción en un bloque.
El EVM es determinista, lo que significa que ejecutar un conjunto de instrucciones en cualquier estado en particular dará como resultado el mismo estado nuevo.
De acuerdo con la documentación del desarrollador de Ethereum, un antiguo estado válido (S) + un nuevo conjunto de transacciones válidas (T), Ethereum generará un nuevo estado de salida válido S'
Puedes pensar en ello como un juego como el ajedrez. Ethereum es como un tablero de ajedrez, donde hay diferentes estados de juego, y en Ethereum, las posibilidades de este estado son infinitas. Los juegos de mesa tienen sus propias reglas específicas de movimiento (compare las transacciones en Ethereum) y tienen restricciones específicas sobre qué acciones se pueden realizar en qué piezas. Los jugadores toman medidas (en comparación con los usuarios que envían transacciones en Ethereum), y el juego (Ethereum) formula y aplica las reglas, lo que da como resultado un nuevo estado de tablero (Ethereum global) después de cada ronda (correspondiente al tiempo de bloqueo).
Para Ethereum o cualquier desarrollo de cadena de bloques compatible con EVM, los contratos inteligentes deben escribirse en Solidity. Solidity es un lenguaje de alto nivel diseñado para ser legible por humanos, de modo que los desarrolladores puedan concentrarse en escribir código en lugar de registros, direcciones de memoria, pilas de llamadas y otras abstracciones.
Sin embargo, el EVM no puede leer Solidity. En cambio, solo entiende el "código de bytes", que es un código binario de bajo nivel legible por máquina.
En EVM, "bytecode" (código de bytes) representa una serie de "opcodes" (códigos de operación) de EVM, los códigos de operación son instrucciones legibles de bajo nivel del programa, que representan operaciones específicas que se pueden realizar en el EVM.
Dado que un lenguaje de alto nivel como Solidity no se puede ejecutar directamente en el EVM, necesitamos una forma de convertir el código de contrato inteligente del código de bytes del código de operación del lenguaje Solidity legible por humanos para que lo ejecute el EVM, que es el trabajo del compilador.
Después de compilar el código de Solidity con el compilador Remix IDE, puede ver el código de operación específico en el que se convierte el contrato inteligente y ver el código de bytes generado a partir del código de operación.
Aquí están los códigos de operación:
El siguiente es el código de bytes correspondiente al código de operación anterior.
Al traducir bytecodes en opcodes, es posible saber qué instrucciones de ejecución están contenidas en bytecodes.
Debido a la alta dificultad de la prueba ZK para algunos códigos de operación específicos en EVM, han aparecido en el mercado ZK-EVM con diferentes grados de compatibilidad.Entre ellos, algunos conjuntos de códigos de operación ZK-EVM y EVM son completamente equivalentes, algunos han modificado parcialmente algunos códigos de operación EVM y uno tiene códigos de bytes completamente diferentes.
Diferentes tipos de ZK-EVM
Dado que el diseño de Ethereum no consideró la compatibilidad con ZK al principio, en teoría, cuanto más se acerca al diseño de Ethereum, más difícil y lento es generar pruebas de ZK. En agosto de 2022, Vitalik, el fundador de Ethereum, publicó una publicación de blog "Escuche la interpretación de Vitalik sobre el futuro de los diferentes tipos de ZK-EVM", clasificando diferentes ZK-EVM.
En este artículo, Vitalik clasificó varios ZK-EVM en función de las dos dimensiones de la compatibilidad con EVM y el tiempo de generación de prueba de ZK (rendimiento). Vitalik enumeró cuatro (semi) tipos en este cuadro, y se pueden incluir todos los productos ZK-EVM actualmente en el mercado.
2.5, entre el tipo 2 y el tipo 3, también hay un tipo 2.5. Este tipo es exactamente equivalente al EVM, excepto que el costo del gas de ciertos tipos de operaciones se incrementa para "reducir significativamente el tiempo de prueba en el peor de los casos". Actualmente, no existe un ZK-EVM de este tipo en el mercado, sin embargo, un nuevo proyecto de ZK-EVM llamado Kakarot está trabajando en ello.
El tipo 3 es casi equivalente a EVM, pero con algunos compromisos en la precisión equivalente para reducir aún más el tiempo de prueba y simplificar el desarrollo de EVM. Actualmente, Polygon, Linea y Scroll son de este tipo.
El tipo 4 es equivalente al lenguaje de alto nivel de ZK-EVM.Este tipo de ZK-EVM compila el código fuente del contrato inteligente en un lenguaje compatible con ZK-SNARK, lo que traerá un tiempo de prueba más rápido y las desventajas correspondientes, como la incompatibilidad y las limitaciones. Actualmente, zkSync Era entra en esta categoría.
Vale la pena señalar que el tiempo requerido para enviar la prueba de validez a Ethereum L1 es el tiempo que le toma al usuario transferir fondos a L1. Si la generación de pruebas lleva horas, ese usuario no puede transferir fondos a L1 durante esas horas.
Combate práctico: evaluación del desarrollo Taiko, Polygon, Linea, Scroll y ZkSync Era
Después de repasar los conocimientos teóricos, la siguiente es la parte real del combate.
Al implementar contratos inteligentes de Solidity y contratos NFT en Taiko, Polygon, Linea, Scroll y ZkSync Era respectivamente, se prueban el rendimiento y los defectos correspondientes de cada ZK-EVM. El autor también proporciona los recursos disponibles para desarrolladores, y la evaluación se lleva a cabo principalmente desde las dos dimensiones de la experiencia del desarrollador y el tiempo de transición de L2 a L1.
Taiko ZK-EVM
Taiko es un ZK-EVM tipo 1 y actualmente se encuentra en la etapa de testnet. Taiko maneja exactamente lo que hace Ethereum; usando las mismas funciones hash, precios de gasolina, algoritmos de encriptación, etc.
Proceso de operación: implementó un contrato inteligente Solidity simple e implementó una colección NFT simple mediante el uso del proxy ThirdWeb.
La desventaja de Type 1 ZK-EVM es que lleva mucho tiempo generar pruebas cuando todo es exactamente igual que en Ethereum (incluso internamente). Esto significa que un usuario tarda varias horas en conectar ETH desde Taiko L2 hasta Ethereum L1 (como se muestra a continuación).
Línea ZK-EVM
Linea pertenece al tipo 3 ZK-EVM, y Linea aún no puede probar todos los códigos de operación o precompilación; representa un estado interno de cadena diferente al de Ethereum, como el uso de una función hash diferente.
El código de bytes implementado es el mismo que Ethereum.
El proceso de implementación fue casi perfecto, lo que facilitó la implementación e interacción con ambos contratos inteligentes. Este es el mismo comportamiento que Ethereum; las herramientas y billeteras existentes se pueden usar para implementar contratos inteligentes, interactuar con ellos, acuñar NFT, etc.
Al momento de escribir este artículo, Linea aún no ha lanzado la interfaz de front-end del puente. Por lo tanto, solo se pueden llamar directamente las funciones de contrato inteligente en puente.
Según la documentación de Linea, el puente L2 a L1 de ETH suele tardar unos 15 minutos, pero en este caso tardó unas horas.
Polígono ZK-EVM
Polygon ZK-EVM pertenece a Type 3 ZK-EVM y ha lanzado la red principal desde finales de marzo de este año.
La documentación oficial de Polygon zkEVM enumera todas las diferencias actuales entre EVM y zkEVM.
El equipo de ingeniería de Polygon afirmó que, además de mejorar la generación de pruebas y el tiempo de extracción, la precompilación restante se completará lo antes posible en el futuro, con el objetivo de convertirse en Tipo 2 en el diagrama de Vitalik.
En este caso de implementación, el puente de red principal de zkEVM se realizó sin problemas; el proceso de puente L2 -> L1 tarda aproximadamente 1 hora.
Desplazarse
Scroll pertenece al tipo 3 ZK-EVM y actualmente se encuentra en la etapa de testnet. Scroll también enumera las diferencias entre ZK-EVM y Ethereum EVM en la documentación oficial.
Era ZkSync
ZkSync Era pertenece al Tipo 4 ZK-EVM. Completamente diferente de otros ZK-EVM, el código de bytes del contrato inteligente implementado en el zkEVM de ZkSync Era es diferente de Ethereum.
Esto permite que ZkSync Era brinde una función única, soporte nativo para la abstracción de cuentas, que brindará una experiencia de desarrollador diferente. Por lo general, la mayoría de las billeteras criptográficas son solo direcciones estándar que pueden enviar y recibir fondos e interactuar con contratos inteligentes. Con la abstracción de cuentas, las billeteras criptográficas son personalizables y pueden diseñarse de formas más complejas para proporcionar una gama más amplia de funciones. Además, zkEVM aún permite a los desarrolladores usar los mismos lenguajes de alto nivel como Solidity.
Aunque el ZK-EVM de ZkSync Era es bastante diferente del EVM, ZkSync Era proporciona un conjunto de mejores prácticas y consideraciones para los desarrolladores. Además, los desarrolladores deberán realizar algunos ajustes menores en el proceso de desarrollo para construir específicamente para ZkSync Era.
Por ejemplo, en el siguiente ejemplo, el entorno Hardhat debe instalarse y configurarse con una extensión zkSync personalizada para generar un código de bytes que se puede implementar en Era ZK-EVM.
La compilación genera un código de bytes completamente nuevo que es completamente diferente de Ethereum, que es completamente diferente del código de bytes generado por el ZK-EVM anterior.
Vale la pena señalar que ThirdWeb lanzó zkSync Era para brindar a los desarrolladores una experiencia de implementación más conveniente.
Se implementan un total de dos contratos inteligentes durante esta operación, se interactúa con ellos y se envían activos de L2 a L1. Actualmente, hay un retraso de 24 horas para los retiros de la red principal de ZkSync Era a Ethereum L1 por razones de seguridad.
Kakarotto ZkEvm
Otro proyecto dedicado a realizar Type 2.5 ZK-EVM es Kakarot ZkEvm, que recibió financiamiento de varias instituciones, incluidas Vitalik Buterin y StarkWare en junio de este año. Kakarot planea lanzar la red de prueba más adelante en 2023.
Conclusión
Para los usuarios finales, no importa quién gane la carrera, ya que el progreso de una solución ZK compatible con EVM es una gran victoria para la industria en su conjunto. Para varias partes del proyecto, no se trata tanto de una competencia como de explorar diferentes métodos para promover el progreso de toda la industria. Vitalik incluso tiene una "teoría de múltiples certificadores". La premisa básica es que diferentes Rollups pueden trabajar juntos para mejorar la seguridad general de Ethereum.
Al final del día, todos quieren que Ethereum tenga éxito. La transformación de expansión L2 es una de las tres transformaciones técnicas que Vitalik cree que Ethereum debe experimentar. Esperaremos y veremos cómo se desarrolla en el futuro.