La narrativa de Ethereum está siendo reescrita: cuando el L1 zkEVM se convierta en la resolución definitiva, ¿cuándo llegará la próxima revolución?

Desde una perspectiva sensorial, desde 2025 en adelante, la frecuencia de actualizaciones en la comunidad de desarrolladores principales de Ethereum ha sido excepcionalmente intensa.

Desde la actualización Fusaka, pasando por Glamsterdam, hasta los planes a largo plazo centrados en kEVM, sistemas criptográficos resistentes a la computación cuántica, Gas Limit y otros temas para los próximos tres años, Ethereum ha lanzado en pocos meses múltiples hojas de ruta que cubren de tres a cinco años.

Este ritmo en sí mismo es una señal.

Si se lee detenidamente la última hoja de ruta, se puede percibir una dirección más clara y también más audaz: Ethereum está transformándose en una computadora verificable, y la meta final de este camino es el L1 zkEVM.

1. Tres cambios en el enfoque narrativo de Ethereum

El 26 de febrero, Justin Drake, investigador de la Fundación Ethereum, publicó en redes sociales que la fundación propuso un borrador de hoja de ruta llamado Strawmap, que describe las futuras actualizaciones del protocolo Ethereum L1 en los próximos años.

Este borrador presenta cinco objetivos principales: un L1 más rápido (confirmación final en segundos), un L1 «Gigagas» con 10,000 TPS mediante zkEVM, un L2 de alto rendimiento basado en muestreo de disponibilidad de datos (DAS), sistemas criptográficos resistentes a la computación cuántica y funciones nativas de privacidad en transferencias; además, planea realizar siete bifurcaciones de protocolo hasta 2029, aproximadamente cada seis meses.

Se puede decir que, en los últimos diez años, el desarrollo de Ethereum ha estado acompañado de una evolución constante en su narrativa y en su hoja de ruta técnica.

La primera etapa (2015–2020) fue la de un libro mayor programable.

Este fue el núcleo de la narrativa inicial de Ethereum, es decir, «contratos inteligentes Turing-completos». En ese momento, la mayor ventaja de Ethereum era que, en comparación con Bitcoin, podía hacer más cosas, como DeFi, NFT, DAO, que son productos de esa narrativa. Se comenzaron a ejecutar en cadena numerosos protocolos financieros descentralizados, desde préstamos, DEX hasta stablecoins, haciendo de Ethereum la principal red de liquidación en la economía cripto.

La segunda etapa (2021–2023) fue la de la narrativa de L2.

Con el aumento de las tarifas de gas en la cadena principal de Ethereum, los usuarios comunes tenían dificultades para pagar las transacciones, por lo que los Rollups comenzaron a ser protagonistas en la expansión. Ethereum se reorientó gradualmente como capa de liquidación, con el objetivo de ofrecer una base segura para L2.

En resumen, se trasladó la mayor parte del cálculo de la capa de ejecución a L2, expandiendo la capacidad mediante Rollups, mientras que L1 se encargaba solo de la disponibilidad de datos y la liquidación final. Durante este período, The Merge y EIP-4844 sirvieron a esta narrativa, buscando que L2 fuera más barato y seguro para usar la confianza en Ethereum.

La tercera etapa (2024–2025) se centra en la autorreflexión y en la competencia narrativa.

Como es sabido, la prosperidad de L2 trajo un problema inesperado: Ethereum L1 en sí mismo se volvió menos relevante, ya que los usuarios comenzaron a operar más en Arbitrum, Base, Optimism y menos directamente en L1. La evolución del precio de ETH también refleja esta ansiedad.

Esto llevó a la comunidad a debatir: si L2 capta todos los usuarios y actividades, ¿dónde queda el valor de L1? Hasta las turbulencias internas de Ethereum en 2025 y la serie de hojas de ruta lanzadas en 2026, esta lógica está experimentando una profunda evolución.

De hecho, al analizar las principales direcciones tecnológicas desde 2025, aparecen recurrentemente Verkle Tree, clientes sin estado (Stateless Clients), formalización del EVM, soporte nativo para ZK, entre otros. Todos estos enfoques técnicos apuntan a una misma cosa: hacer que L1 de Ethereum sea verificable, y no solo que las pruebas de L2 puedan verificarse en L1, sino que cada paso del estado de L1 pueda comprimirse y verificarse mediante pruebas de conocimiento cero.

Este es precisamente el ambicioso objetivo del zkEVM en L1. A diferencia del zkEVM en L2 (como zkSync, Starknet, Scroll), el zkEVM en L1 (zkEVM embebido) implica integrar directamente la tecnología de pruebas de conocimiento cero en la capa de consenso de Ethereum.

No es una réplica del zkEVM en L2, sino que transforma la capa de ejecución de Ethereum en un sistema amigable con ZK, por lo que si el zkEVM en L2 es construir un mundo ZK sobre Ethereum, el zkEVM en L1 es convertir a Ethereum en ese mismo mundo ZK.

Una vez alcanzado este objetivo, la narrativa de Ethereum pasará de ser una capa de liquidación en L2 a convertirse en la «raíz de confianza verificable para cálculos».

Esto representará un cambio cualitativo, no solo una evolución cuantitativa como en los últimos años.

2. ¿Qué es realmente el zkEVM en L1?

Es un concepto que ya hemos mencionado: en el modo tradicional, los validadores deben «re-ejecutar» cada transacción para verificar un bloque, mientras que en zkEVM solo necesitan verificar una prueba ZK, lo que permite a Ethereum aumentar el Gas Limit a 100 millones o más sin incrementar la carga en los nodos (leer más en «La ruta ZK: ¿el amanecer del fin de Ethereum?»).

Pero transformar Ethereum L1 en un zkEVM no es una tarea de un solo paso, sino que requiere avanzar en ocho frentes simultáneamente, cada uno de ellos de nivel de varios años.

Línea de trabajo uno: Formalización del EVM (EVM Formalization)

Toda prueba ZK requiere que el objeto a probar tenga una definición matemática precisa. Sin embargo, hoy en día, el comportamiento del EVM está definido por la implementación del cliente (Geth, Nethermind, etc.), no por una especificación formal estricta. Diferentes clientes pueden comportarse de manera distinta en casos límite, dificultando la creación de circuitos ZK para el EVM, ya que no se puede probar un sistema con definiciones vagas.

Por ello, el objetivo de esta línea de trabajo es formalizar cada instrucción y cada regla de transición del EVM en un formato verificable por máquina. Es la base de todo el proyecto zkEVM en L1. Sin ella, todo lo demás será solo una construcción en la arena.

Línea de trabajo dos: Reemplazo de funciones hash amigables con ZK

Ethereum usa principalmente Keccak-256 como función hash. Keccak no es amigable con circuitos ZK, ya que su cálculo es muy costoso, lo que aumenta significativamente el tiempo y costo de las pruebas.

El trabajo aquí consiste en reemplazar progresivamente Keccak por funciones hash amigables con ZK, como Poseidon o Blake, especialmente en los árboles de estado y en las rutas de prueba Merkle. Es un cambio que afecta toda la estructura del protocolo, ya que las funciones hash están en todos lados.

Línea de trabajo tres: Sustitución de Merkle Patricia Tree por Verkle Tree

Una de las modificaciones más relevantes en la hoja de ruta 2025–2027. Actualmente, Ethereum usa Merkle Patricia Tree (MPT) para almacenar el estado global. Verkle Tree, mediante compromisos vectoriales, puede reducir en decenas de veces el tamaño de los testigos (witness).

Para L1 zkEVM, esto significa que la cantidad de datos necesarios para probar cada bloque disminuirá drásticamente, acelerando la generación de pruebas y siendo una infraestructura clave para la viabilidad del zkEVM en L1.

Línea de trabajo cuatro: Clientes sin estado (Stateless Clients)

Los clientes sin estado permiten verificar bloques sin mantener toda la base de datos del estado de Ethereum, solo con los testigos adjuntos en el bloque.

Esta línea está estrechamente vinculada a Verkle Tree, ya que solo con testigos pequeños los clientes sin estado son viables. Su importancia para L1 zkEVM radica en reducir los requisitos de hardware para correr nodos, favoreciendo la descentralización, y en ofrecer entradas claras para las pruebas ZK, ya que los validadores solo necesitan procesar los datos del testigo, no todo el estado.

Línea de trabajo cinco: Estandarización e integración de sistemas de pruebas ZK

L1 zkEVM requiere un sistema de pruebas ZK maduro para generar pruebas de ejecución de bloques. Actualmente, el ecosistema ZK es muy fragmentado y no existe una solución estándar aceptada. La meta aquí es definir una interfaz de pruebas (proof interface) en la capa de protocolo de Ethereum, que permita la competencia entre diferentes sistemas de pruebas, en lugar de favorecer a uno solo.

Esto mantiene la apertura tecnológica y deja espacio para la evolución continua de los sistemas de pruebas. El equipo de PSE (Privacy and Scaling Explorations) de la Fundación Ethereum ya ha avanzado en este aspecto.

Línea de trabajo seis: Desacoplamiento de la capa de ejecución y la capa de consenso (Evolución del Engine API)

Actualmente, la capa de ejecución (EL) y la capa de consenso (CL) se comunican mediante el Engine API. En la arquitectura zkEVM en L1, cada transformación de estado requiere generar una prueba ZK, cuyo tiempo puede superar el intervalo de creación de bloques.

El desafío es cómo desacoplar la ejecución y la generación de pruebas sin romper el mecanismo de consenso: la ejecución puede realizarse rápidamente, mientras que la prueba se genera de forma asincrónica y se verifica en el momento adecuado. Esto requiere una profunda reformulación del modelo de finalización (Finality).

Línea de trabajo siete: Pruebas recursivas y agregación de pruebas

Generar una prueba ZK para cada bloque es costoso, pero si se pueden recursivamente agrupar varias pruebas en una sola, el costo de verificación se reduce mucho. El avance en esta línea determinará cuánto puede reducirse el costo de operación de L1 zkEVM.

Línea de trabajo ocho: Herramientas para desarrolladores y compatibilidad con EVM

Todos los cambios tecnológicos deben ser transparentes para los desarrolladores de contratos inteligentes en Ethereum. Los millones de contratos existentes no deben fallar por la introducción de zkEVM, y las herramientas no deben requerir una reescritura completa.

Esta línea, aunque subestimada, es la más laboriosa, ya que cada actualización de EVM en el pasado implicó extensas pruebas de compatibilidad y adaptación de herramientas. La magnitud de los cambios en L1 zkEVM será mucho mayor, por lo que la compatibilidad y las herramientas serán un esfuerzo de gran escala.

3. ¿Por qué ahora es el momento adecuado para entender esto?

La publicación de Strawmap coincide con un momento en que el mercado duda del precio de ETH. Desde esta perspectiva, el valor más importante de esta hoja de ruta radica en redefinir a Ethereum como «infraestructura».

Para los desarrolladores y constructores, Strawmap ofrece una dirección clara; para los usuarios, estas mejoras tecnológicas se traducirán en experiencias perceptibles: confirmaciones en segundos, transferencias sin fricciones entre L1 y L2, privacidad integrada en lugar de complementos.

Por supuesto, el zkEVM en L1 no será un producto que se implemente en corto plazo; su realización completa podría tardar hasta 2028–2029 o más.

Pero, al menos, redefine la propuesta de valor de Ethereum: si el zkEVM en L1 tiene éxito, Ethereum dejará de ser solo una capa de liquidación en L2 y se convertirá en la raíz de confianza verificable para todo el ecosistema Web3, permitiendo que cualquier estado en cadena pueda rastrearse matemáticamente hasta la cadena de pruebas ZK de Ethereum, lo cual será decisivo para su valor a largo plazo.

Además, influirá en la percepción a largo plazo de L2: si L1 tiene capacidades ZK, el papel de L2 cambiará — de «solución de escalabilidad segura» a «entorno de ejecución dedicado». La forma en que los L2 encuentren su lugar en este nuevo esquema será uno de los principales focos de evolución en los próximos años.

Lo más importante, en opinión del autor, es que esto también es una ventana excelente para observar la cultura de los desarrolladores de Ethereum: la capacidad de avanzar simultáneamente en ocho líneas de trabajo interdependientes, cada una de ellas de nivel de varios años, y mantener una coordinación descentralizada, es una característica única de Ethereum como protocolo.

Comprender esto ayuda a evaluar con mayor precisión la posición real de Ethereum en medio de diversas narrativas competitivas.

En resumen, desde 2020, con el enfoque en «Rollups como núcleo», hasta 2026 con Strawmap, la narrativa de Ethereum refleja una trayectoria clara: la expansión no puede depender solo de L2, sino que L1 y L2 deben evolucionar en conjunto.

Por ello, las ocho líneas de trabajo del zkEVM en L1 representan esta transformación tecnológica, apuntando a un objetivo común: que la red principal de Ethereum, sin sacrificar la descentralización, logre mejoras de rendimiento en orden de magnitud. Esto no es una negación de la hoja de ruta de L2, sino su perfeccionamiento y complemento.

En los próximos tres años, esta «barca de Teseo» enfrentará siete bifurcaciones y reemplazará innumerables «tablas de madera». Cuando llegue 2029, probablemente veremos una verdadera « capa de liquidación global» — rápida, segura, privada y, como siempre, abierta.

Queda mucho por ver.