La evolución de las zkEVM: Equilibrando la compatibilidad y el rendimiento en el escalado de Ethereum
En 2022, Vitalik Buterin planteó una pregunta sencilla que definiría los siguientes cuatro años del escalamiento de Ethereum: ¿cuánta compatibilidad con Ethereum estás dispuesto a sacrificar a cambio de pruebas de conocimiento cero más rápidas? Su respuesta llegó en forma de un sistema de clasificación de cinco tipos para zkEVM que, desde entonces, se ha convertido en el estándar de la industria para evaluar estas soluciones críticas de escalamiento.
Avanzamos hasta 2026, y la respuesta ya no es tan simple. Los tiempos de prueba se han reducido de 16 minutos a 16 segundos. Los costos han bajado 45x. Varios equipos han demostrado una generación de pruebas en tiempo real más rápida que los tiempos de bloque de 12 segundos de Ethereum. Sin embargo, el compromiso fundamental que Vitalik identificó permanece, y entenderlo es esencial para cualquier desarrollador o proyecto que elija dónde construir.
La clasificación de Vitalik: Tipos del 1 al 4
El marco de Vitalik categoriza las zkEVM a lo largo de un espectro que va desde la equivalencia perfecta con Ethereum hasta la máxima eficiencia de prueba. Los números de tipo más altos significan pruebas más rápidas pero menos compatibilidad con la infraestructura existente de Ethereum.
Tipo 1: Totalmente equivalente a Ethereum
Las zkEVM de Tipo 1 no cambian nada de Ethereum. Prueban exactamente el mismo entorno de ejecución que utiliza la L1 de Ethereum: los mismos opcodes, las mismas estructuras de datos, absolutamente todo.
La ventaja: Compatibilidad perfecta. Los clientes de ejecución de Ethereum funcionan tal cual. Cada herramienta, cada contrato y cada pieza de infraestructura se transfiere directamente. Esto es, en última instancia, lo que Ethereum necesita para que la propia L1 sea más escalable.
La desventaja: Ethereum no fue diseñado para pruebas de conocimiento cero. La arquitectura basada en pila de la EVM es notoriamente ineficiente para la generación de pruebas ZK. Las primeras implementaciones de Tipo 1 requerían horas para generar una sola prueba.
Proyecto líder: Taiko aspira a la equivalencia de Tipo 1 como un rollup basado (based rollup) utilizando los validadores de Ethereum para el secuenciamiento, permitiendo la composibilidad sincrónica con otros rollups basados.
Tipo 2: Totalmente equivalente a la EVM
Las zkEVM de Tipo 2 mantienen la compatibilidad total con la EVM pero cambian las representaciones internas —cómo se almacena el estado, cómo se organizan las estructuras de datos— para mejorar la generación de pruebas.
La ventaja: Los contratos escritos para Ethereum se ejecutan sin modificaciones. La experiencia del desarrollador sigue siendo idéntica. La fricción de migración tiende a cero.
La desventaja: Los exploradores de bloques y las herramientas de depuración pueden necesitar modificaciones. Las pruebas de estado funcionan de manera diferente a como lo hacen en la L1 de Ethereum.
Proyectos líderes: Scroll y Linea apuntan a la compatibilidad de Tipo 2, logrando una equivalencia casi perfecta con la EVM a nivel de VM sin transpiladores ni compiladores personalizados.
Tipo 2.5: Equivalente a la EVM con cambios en los costos de gas
El Tipo 2.5 es un punto medio pragmático. La zkEVM sigue siendo compatible con la EVM pero aumenta los costos de gas para las operaciones que son particularmente costosas de probar en conocimiento cero.
El compromiso: Dado que Ethereum tiene un límite de gas por bloque, aumentar los costos de gas para opcodes específicos significa que se pueden ejecutar menos de esos opcodes por bloque. Las aplicaciones funcionan, pero ciertos patrones computacionales se vuelven prohibitivamente costosos.
Tipo 3: Casi equivalente a la EVM
Las zkEVM de Tipo 3 sacrifican características específicas de la EVM —a menudo relacionadas con precompilaciones, manejo de memoria o cómo se trata el código de los contratos— para mejorar drásticamente la generación de pruebas.
La ventaja: Pruebas más rápidas, costos más bajos, mejor rendimiento.
La desventaja: Algunas aplicaciones de Ethereum no funcionarán sin modificaciones. Es posible que los desarrolladores deban reescribir contratos que dependen de características no compatibles.
Control de realidad: Ningún equipo quiere quedarse realmente en el Tipo 3. Se entiende como una etapa de transición mientras los equipos trabajan en añadir el soporte de precompilaciones complejas necesario para alcanzar el Tipo 2.5 o el Tipo 2. Tanto Scroll como Polygon zkEVM operaron como Tipo 3 antes de avanzar en la escala de compatibilidad.
Tipo 4: Compatible con lenguajes de alto nivel
Los sistemas de Tipo 4 abandonan por completo la compatibilidad con la EVM a nivel de bytecode. En su lugar, compilan Solidity o Vyper a una VM personalizada diseñada específicamente para pruebas ZK eficientes.
La ventaja: Generación de pruebas más rápida. Costos más bajos. Máximo rendimiento.
La desventaja: Los contratos pueden comportarse de manera diferente. Es posible que las direcciones no coincidan con los despliegues de Ethereum. Las herramientas de depuración necesitan reescrituras completas. La migración requiere pruebas cuidadosas.
Proyectos líderes: zkSync Era y StarkNet representan el enfoque de Tipo 4. zkSync transpila Solidity a un bytecode personalizado optimizado para ZK. StarkNet utiliza Cairo, un lenguaje completamente nuevo diseñado para la demostrabilidad (provability).
Benchmarks de rendimiento: Dónde estamos en 2026
Las cifras se han transformado drásticamente desde la publicación original de Vitalik. Lo que era teórico en 2022 es una realidad de producción en 2026.
Tiempos de prueba
Las primeras zkEVM requerían aproximadamente 16 minutos para generar pruebas. Las implementaciones actuales completan el mismo proceso en aproximadamente 16 segundos, una mejora de 60x. Varios equipos han demostrado la generación de pruebas en menos de 2 segundos, más rápido que los tiempos de bloque de 12 segundos de Ethereum.
La Fundación Ethereum ha fijado un objetivo ambicioso: probar el 99 % de los bloques de la red principal en menos de 10 segundos utilizando menos de $ 100,000 en hardware y un consumo de energía de 10 kW. Varios equipos ya han demostrado una capacidad cercana a este objetivo.
Costos de Transacción
La actualización Dencun en marzo de 2024 (EIP-4844 que introdujo los "blobs") redujo las tarifas de L2 entre un 75 % y un 90 %, lo que hizo que todos los rollups fueran drásticamente más rentables. Los puntos de referencia actuales muestran:
| Plataforma | Costo de Transacción | Notas |
|---|---|---|
| Polygon zkEVM | $ 0.00275 | Por transacción para lotes completos |
| zkSync Era | $ 0.00378 | Costo de transacción mediano |
| Linea | $ 0.05 - 0.15 | Transacción promedio |
Rendimiento (Throughput)
El rendimiento en el mundo real varía significativamente según la complejidad de la transacción:
| Plataforma | TPS (DeFi Compleja) | Notas |
|---|---|---|
| Polygon zkEVM | 5.4 tx / s | Referencia de swap en AMM |
| zkSync Era | 71 TPS | Swaps DeFi complejos |
| Teórico (Linea) | 100,000 TPS | Con sharding avanzado |
Estas cifras seguirán mejorando a medida que maduren la aceleración de hardware, la paralelización y las optimizaciones algorítmicas.
Adopción del Mercado: TVL y Tracción de Desarrolladores
El panorama de las zkEVM se ha consolidado en torno a varios líderes claros, cada uno representando diferentes puntos en el espectro de tipos:
Clasificación Actual de TVL (2025)
- Scroll: $ 748 millones de TVL, la zkEVM pura más grande
- StarkNet: $ 826 millones de TVS
- zkSync Era: $ 569 millones de TVL, más de 270 dApps desplegadas
- Linea: ~ $ 963 millones de TVS, crecimiento de más del 400 % en direcciones activas diarias
El ecosistema general de Capa 2 ha alcanzado los $ 70 mil millones en TVL, y los ZK rollups capturan una cuota de mercado cada vez mayor a medida que los costos de generación de pruebas continúan disminuyendo.
Señales de Adopción por Desarrolladores
- Más del 65 % de los nuevos contratos inteligentes en 2025 se desplegaron en redes de Capa 2
- zkSync Era atrajo aproximadamente $ 1.9 mil millones en activos del mundo real (RWA) tokenizados, capturando ~ 25 % de la cuota de mercado de RWA on-chain
- Las redes de Capa 2 procesaron un estimado de 1.9 millones de transacciones diarias en 2025
El Dilema entre Compatibilidad y Rendimiento en la Práctica
Comprender los tipos teóricos es útil, pero lo que importa son las implicaciones prácticas para los desarrolladores.
Tipo 1-2: Fricción de Migración Cero
Para Scroll y Linea (Tipo 2), la migración significa literalmente cero cambios de código para la mayoría de las aplicaciones. Despliegue el mismo bytecode de Solidity, use las mismas herramientas (MetaMask, Hardhat, Remix) y espere el mismo comportamiento.
Ideal para: Aplicaciones de Ethereum existentes que priorizan una migración fluida; proyectos donde el código auditado y probado debe permanecer sin cambios; equipos sin recursos para pruebas y modificaciones extensas.
Tipo 3: Se Requieren Pruebas Cuidadosas
Para Polygon zkEVM e implementaciones similares de Tipo 3, la mayoría de las aplicaciones funcionan, pero existen casos extremos. Ciertas precompilaciones pueden comportarse de manera diferente o no ser compatibles.
Ideal para: Equipos con recursos para una validación exhaustiva en testnet; proyectos que no dependen de características exóticas de la EVM; aplicaciones que priorizan la eficiencia de costos sobre la compatibilidad perfecta.
Tipo 4: Modelo Mental Diferente
Para zkSync Era y StarkNet, la experiencia de desarrollo difiere significativamente de Ethereum:
zkSync Era es compatible con Solidity pero lo transpila a un bytecode personalizado. Los contratos se compilan y ejecutan, pero el comportamiento puede diferir de formas sutiles. No se garantiza que las direcciones coincidan con los despliegues en Ethereum.
StarkNet utiliza Cairo, lo que requiere que los desarrolladores aprendan un lenguaje completamente nuevo, aunque diseñado específicamente para la computación demostrable.
Ideal para: Proyectos nuevos (greenfield) no limitados por el código existente; aplicaciones que priorizan el máximo rendimiento; equipos dispuestos a invertir en herramientas y pruebas especializadas.
Seguridad: La Restricción No Negociable
La Fundación Ethereum introdujo requisitos claros de seguridad criptográfica para los desarrolladores de zkEVM en 2025:
- Seguridad demostrable de 100 bits para mayo de 2026
- Seguridad de 128 bits para finales de 2026
Estos requisitos reflejan la realidad de que las pruebas más rápidas no significan nada si la criptografía subyacente no es infalible. Se espera que los equipos cumplan con estos umbrales independientemente de su clasificación de tipo.
El enfoque en la seguridad ha ralentizado algunas mejoras de rendimiento —la Fundación Ethereum eligió explícitamente la seguridad sobre la velocidad hasta 2026— pero garantiza que la base para la adopción masiva permanezca sólida.
Cómo Elegir su zkEVM: Un Marco de Decisión
Elija Tipo 1-2 (Taiko, Scroll, Linea) si:
- Está migrando contratos existentes probados en batalla
- Los costos de auditoría son una preocupación (no se necesita una nueva auditoría)
- Su equipo es nativo de Ethereum sin experiencia en ZK
- La componibilidad con la L1 de Ethereum es importante
- Necesita interoperabilidad sincrónica con otros based rollups
Elija Tipo 3 (Polygon zkEVM) si:
- Desea un equilibrio entre compatibilidad y rendimiento
- Puede invertir en una validación exhaustiva en testnet
- La eficiencia de costos es una prioridad
- No depende de precompilaciones exóticas de la EVM
Elija Tipo 4 (zkSync Era, StarkNet) si:
- Está construyendo desde cero sin restricciones de migración
- El máximo rendimiento justifica la inversión en herramientas
- Su caso de uso se beneficia de patrones de diseño nativos de ZK
- Cuenta con recursos para el desarrollo especializado
Lo que Viene a Continuación
Las clasificaciones por tipos no permanecerán estáticas. Vitalik señaló que los proyectos zkEVM pueden "comenzar fácilmente en tipos de números más altos y saltar a tipos de números más bajos con el tiempo". Estamos viendo esto en la práctica: proyectos que se lanzaron como Tipo 3 están avanzando hacia el Tipo 2 a medida que completan las implementaciones de precompilaciones.
Más intrigante aún, si la L1 de Ethereum adopta modificaciones para ser más amigable con ZK, las implementaciones de Tipo 2 y Tipo 3 podrían convertirse en Tipo 1 sin cambiar su propio código.
El final del juego parece cada vez más claro: los tiempos de prueba continuarán comprimiéndose, los costos seguirán bajando y la distinción entre tipos se desvanecerá a medida que la aceleración de hardware y las mejoras algorítmicas cierren la brecha de rendimiento. La pregunta no es qué tipo ganará, sino qué tan rápido todo el espectro convergerá hacia una equivalencia práctica.
Por ahora, el marco sigue siendo valioso. Comprender dónde se ubica una zkEVM en el espectro de compatibilidad-rendimiento le indica qué esperar durante el desarrollo, el despliegue y la operación. Ese conocimiento es esencial para cualquier equipo que construya sobre el futuro impulsado por ZK de Ethereum.
¿Está construyendo sobre infraestructura zkEVM? BlockEden.xyz proporciona endpoints RPC de alto rendimiento en múltiples cadenas zkEVM, incluyendo Polygon zkEVM, Scroll y Linea. Explore nuestro marketplace de APIs para acceder a la capa de infraestructura que sus aplicaciones ZK necesitan.