ZK-EVM: El Santo Grial del ZK-Rollup

El escalado de Ethereum ha sido un tema candente, esperado ansiosamente por muchos usuarios. Una idea errónea común es que la Fusión de Ethereum en septiembre de 2022, que transformó su mecanismo de consenso de PoW a PoS, mejoraría el rendimiento de Ethereum. En realidad, la Fusión no alteró el tamaño de los bloques, y el tiempo entre bloques solo se redujo de un promedio de 13 segundos a 12 segundos, lo que significa que las mejoras de rendimiento se espera que sean limitadas. La esperanza de escalado a corto plazo de Ethereum aún descansa en las redes de capa 2 (Rollups). Entre los dos principales enfoques de Rollup —Optimistic Rollup y ZK-Rollup— muchas personas favorecen el último. ZK-Rollup no solo reduce las tarifas de red al agrupar múltiples transacciones fuera de la cadena, sino que también hereda la seguridad de Ethereum a través de pruebas de conocimiento cero, eliminando la necesidad de un período de impugnación como en Optimistic Rollup.

ZK-Rollups Solo para Pagos

Los primeros ZK-Rollups fueron criticados por carecer de compatibilidad con EVM y, por lo tanto, no soportar funcionalidad de contratos inteligentes. Por ejemplo, zkSync 1.0, el método principal de pago de donaciones de Gitcoin, solo podía soportar transferencias básicas. Las aplicaciones ZK actuales, como dYdX, están construidas a medida y no son interoperables, lo que dificulta el desarrollo. Además, diferentes aplicaciones ZK utilizan circuitos personalizados distintos, limitando la composabilidad. Por lo tanto, el mercado necesita urgentemente un ZK-Rollup compatible con los contratos inteligentes de Ethereum, para lo cual el principal obstáculo es lograr una máquina virtual compatible con pruebas de conocimiento cero. Este artículo presentará EVM, ZK-EVM y los principales proyectos ZK-EVM y sus diferencias.

¿Qué es EVM?

La Máquina Virtual de Ethereum (EVM) sirve como motor de ejecución de Ethereum, funcionando como el entorno de ejecución para contratos inteligentes. Los desarrolladores escriben la lógica de negocio en lenguajes de alto nivel como Solidity, que luego se compila en bytecode. EVM interpreta este bytecode en opcodes legibles por máquina, ejecutando las instrucciones correspondientes para actualizar el estado del sistema. EVM es una máquina virtual basada en pila que interactúa con la pila, la memoria y el almacenamiento. Para Ethereum y varias soluciones de escalado o cadenas competidoras, EVM se ha convertido en sinónimo del ecosistema Ethereum, representando sus desarrolladores, aplicaciones y herramientas. Las blockchains no compatibles con EVM deben construir su propio ecosistema, requiriendo que los desarrolladores recreen aplicaciones y herramientas. La compatibilidad con EVM permite a los desarrolladores migrar sin problemas los contratos existentes de Ethereum y acceder a sus herramientas.

El Emergente ZK-EVM

Aunque EVM juega un papel crucial en el ecosistema de Ethereum, desarrollar un ZK-EVM es desafiante. Un ZK-EVM genera pruebas de conocimiento cero mientras es compatible con EVM, permitiendo que los contratos inteligentes de Ethereum se implementen sin modificación y validen los cálculos mediante pruebas de conocimiento cero. EVM no fue diseñado pensando en la compatibilidad ZK, ya que los algoritmos de prueba de conocimiento cero, como zk-SNARKs, no fueron ampliamente adoptados hasta 2016 por Zcash. Algunas operaciones de EVM no son amigables con ZK, haciendo que la generación de pruebas sea difícil, lenta o grande.

Desarrollar ZK es notoriamente complejo, involucrando criptografía, matemáticas y experiencia en hardware. Construir un ZK-EVM añade a este desafío ya que requiere tanto compatibilidad con EVM como ser amigable con ZK. Afortunadamente, se han logrado avances significativos en la tecnología ZK en los últimos años. Los actores en el espacio ZK-EVM, incluyendo Starkware, zkSync 2.0, Polygon y Scroll, han estado acelerando el desarrollo de ZK-EVM, con la mayoría anunciando lanzamientos de mainnet a partir de 2023.

Comparación de Proyectos ZK-EVM

Los ZK-EVMs no siguen un diseño o estándar unificado, y cada proyecto encuentra su propio equilibrio entre la compatibilidad EVM y el soporte ZK. Hay dos enfoques principales:

1. Soporte a Nivel de Lenguaje de Programación: Personalizar los opcodes de EVM para optimizar para ZK, reestructurando la máquina virtual para soportar operaciones amigables con ZK y compilar Solidity en un nuevo opcode de VM.

2. Soporte a Nivel de Bytecode: Mantener la compatibilidad nativa con los opcodes de EVM.

Los proyectos en la primera categoría incluyen StarkNet de Starkware y zkSync 2.0. StarkNet puede ejecutar cualquier dApp de Ethereum compilando Solidity en el lenguaje de StarkNet, Cairo, para su implementación en su VM amigable con ZK. De manera similar, zkSync 2.0 logra la funcionalidad ZK-EVM a través de sus compiladores Yul y Zinc, con Yul como una representación intermedia de Solidity y Zinc, un lenguaje basado en Rust, para contratos inteligentes y circuitos ZK generales. Ambos están construidos sobre el marco LLVM para permitir bytecode ZK-EVM altamente eficiente.

Estos proyectos ofrecen compatibilidad con Solidity a nivel de lenguaje, permitiendo a los desarrolladores migrar contratos Solidity, aunque la arquitectura VM subyacente difiere de EVM y es técnicamente una zkVM. Algunas herramientas de desarrollo existentes pueden no funcionar directamente debido a los diferentes conjuntos de instrucciones VM, pero este enfoque es más amigable con ZK y puede generar pruebas de manera más eficiente.

En el segundo enfoque, proyectos como Polygon ZK-EVM y Scroll mantienen la compatibilidad nativa con los opcodes de EVM. El uVM de Polygon, una VM optimizada para ZK, utiliza opcodes personalizados para mejorar las operaciones de EVM compilando el bytecode de EVM en micro-opcodes para su ejecución. El ZK-EVM de Polygon es totalmente compatible con EVM, permitiendo la operación sin problemas de contratos inteligentes existentes, herramientas de desarrollo y billeteras. Scroll diseña de manera similar circuitos para cada bytecode, verificando cada paso de ejecución de EVM, incluyendo la carga de bytecode, la ejecución de opcodes y la actualización del almacenamiento.

En el blog de Vitalik, categoriza los ZK-EVMs en tipos. El Tipo 1 se refiere a ZK-EVMs desarrollados directamente en Ethereum, que es complejo e ineficiente, con investigación en curso por la Fundación Ethereum. Los Tipos 2, 2.5 y 3 son ZK-EVMs equivalentes a EVM, con Scroll y Polygon Hermez actualmente en Tipo 3, trabajando hacia el Tipo 2.5 o incluso Tipo 2. El Tipo 4 incluye ZK-EVMs compatibles con lenguajes de alto nivel, como Starkware y zkSync. Estos tipos no tienen ventaja o desventaja intrínseca, ya que no hay un modelo ZK-EVM estandarizado. Como Vitalik declaró, "Teóricamente, no hay necesidad de que Ethereum estandarice una única implementación ZK-EVM para uso L1; diferentes clientes podrían usar diferentes pruebas, por lo que continuamos beneficiándonos de la redundancia del código."

Conclusión

Cada solución ZK-EVM tiene fortalezas únicas, y dado que la mayoría de los proyectos aún no han liberado su código como código abierto, las comparaciones de eficiencia no están disponibles. Como la plataforma de contratos inteligentes más grande, el ecosistema de Ethereum y sus efectos de red son fuertes. ZK-EVM, la piedra angular de los ZK-Rollups, aprovecha el ecosistema y los efectos de red de Ethereum para heredar su seguridad, reducir tarifas y fomentar un ecosistema de desarrolladores vibrante. A principios de 2021, Vitalik sugirió en su blog que Optimistic Rollup podría superar en computación general EVM a corto plazo, mientras que ZK-Rollup podría destacar en pagos más simples, intercambios y casos de uso específicos de aplicaciones. Sin embargo, con los avances en la tecnología zk-SNARK, ZK-Rollup podría prevalecer en todos los casos de uso a medio y largo plazo. Con múltiples proyectos ZK-EVM lanzando mainnets, el panorama de escalado de capa 2 de Ethereum promete ser emocionante en el futuro cercano.