Escrito por: imToken
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 los próximos tres años en temas como kEVM, sistemas de cifrado resistentes a la computación cuántica, Gas Limit, y otros, 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 lees detenidamente la última hoja de ruta, notarás que está emergiendo 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 la dirección de 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 de cifrado resistentes a la computación cuántica, y funciones nativas de transferencia privada; además, planea realizar siete bifurcaciones del 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 de contabilidad programable.
Este fue el núcleo inicial de la narrativa 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. Una gran cantidad de protocolos financieros descentralizados comenzaron a operar en la cadena, desde préstamos, DEX, hasta stablecoins, y Ethereum se convirtió en 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 los costos de transacción, por lo que Rollup empezó a ser el protagonista del escalado. Ethereum también se reorientó gradualmente como capa de liquidación, con el objetivo de ofrecer una base segura para las L2.
En resumen, se trasladó la mayor parte del cálculo de la capa de ejecución a las L2, expandiendo la capacidad mediante Rollup, mientras que L1 se encargaba solo de la disponibilidad de datos y la liquidación final. Durante este período, The Merge, EIP-4844 y otros esfuerzos sirvieron a esta narrativa, buscando que las L2 sean más baratas y seguras para usar la confianza en Ethereum.
La tercera etapa (2024–2025) se centra en la competencia interna y la reflexión sobre la narrativa.
Como es sabido, la prosperidad de las L2 ha traído un problema inesperado: Ethereum L1 en sí mismo ha perdido importancia, ya que los usuarios operan cada vez más en Arbitrum, Base, Optimism, y rara vez interactúan directamente con L1. La evolución del precio de ETH también refleja esta ansiedad.
Esto ha llevado a la comunidad a debatir: si las L2 capturan toda la actividad y usuarios, ¿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.
Al analizar las principales direcciones tecnológicas desde 2025, aparecen conceptos recurrentes como Verkle Tree, clientes sin estado (Stateless Clients), formalización de EVM, soporte nativo para ZK, entre otros. Todos apuntan a lo mismo: hacer que L1 de Ethereum sea verificable en sí mismo. Es importante notar que esto no solo significa que las pruebas de las L2 puedan verificarse en L1, sino que cada paso del estado de L1 pueda comprimirse y verificarse mediante pruebas de conocimiento cero.
Este es el gran 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 ello, si el zkEVM en L2 es construir un mundo ZK sobre Ethereum, el zkEVM en L1 es convertir a Ethereum en ese 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 incremental de los últimos años.
2. ¿Qué es realmente un zkEVM en L1?
Como siempre, en el modo tradicional, los validadores necesitan “re-ejecutar” cada transacción para verificar un bloque, pero en el modo zkEVM, solo deben 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 de la finalización de Ethereum?”).
Sin embargo, 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 un proyecto de varios años.
Línea de trabajo 1: Formalización del EVM
Toda prueba ZK requiere que el objeto probado tenga una definición matemática precisa. Hoy, 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 diferente en casos límite, dificultando la creación de circuitos ZK para el EVM, ya que no puedes probar un sistema con definiciones vagas.
El objetivo aquí es formalizar cada instrucción y cada regla de transición del EVM en una especificación verificable por máquina. Es la base de todo el proyecto zkEVM en L1. Sin esto, todo lo demás será solo una construcción frágil.
Línea de trabajo 2: Sustitución de funciones hash amigables con ZK
Ethereum usa principalmente Keccak-256, que no es amigable con circuitos ZK y aumenta mucho los costos de generación de pruebas. La tarea aquí es reemplazar progresivamente Keccak por funciones hash amigables con ZK, como Poseidon o Blake, especialmente en árboles de estado y caminos de prueba Merkle. Esto es un cambio profundo, ya que el hash permea toda la estructura del protocolo.
Línea de trabajo 3: Sustitución de Merkle Patricia Tree por Verkle Tree
Una de las mayores novedades 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 el tamaño de las pruebas en decenas de veces. Para zkEVM en L1, esto significa menos datos por prueba, mayor velocidad de generación y una infraestructura clave para la viabilidad del zkEVM en L1.
Línea de trabajo 4: Clientes sin estado (Stateless Clients)
Los clientes sin estado verifican bloques sin mantener toda la base de datos del estado, solo con pruebas adjuntas. Esto requiere que las pruebas sean pequeñas, lo cual depende de Verkle Tree. La ventaja es reducir los requisitos de hardware para los nodos, favoreciendo la descentralización, y también definir claramente las entradas para las pruebas ZK, simplificando la generación de pruebas.
Línea de trabajo 5: Estandarización e integración de sistemas de prueba ZK
Se necesita un sistema de prueba ZK robusto para generar pruebas de cada bloque. La comunidad ZK aún no tiene un estándar unificado. La meta es definir una interfaz de prueba en el protocolo Ethereum, permitiendo la competencia entre diferentes sistemas, en lugar de depender de uno solo. Esto mantiene la apertura tecnológica y permite la evolución continua. El equipo PSE de la Fundación Ethereum ya ha avanzado en esto.
Línea de trabajo 6: 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 API Engine. En zkEVM, cada estado requiere una prueba ZK, cuyo tiempo de generación puede superar el intervalo de un bloque. La clave es desacoplar la generación de pruebas del consenso, permitiendo que la ejecución sea rápida y las pruebas se generen de forma asíncrona, con validación final en momento oportuno. Esto requiere una profunda revisión del modelo de finalización.
Línea de trabajo 7: Pruebas recursivas y agregación de pruebas
Generar una prueba ZK para cada bloque es costoso, pero si se pueden recursivamente agregar 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 del zkEVM en L1.
Línea de trabajo 8: Herramientas para desarrolladores y compatibilidad con EVM
Todos los cambios tecnológicos deben ser transparentes para los desarrolladores de contratos inteligentes. Los millones de contratos existentes no deben fallar por la introducción de zkEVM, y las herramientas no deben tener que ser reescritas. Esta línea, aunque subestimada, es la más laboriosa, ya que cada actualización de EVM requiere pruebas de compatibilidad y adaptación de herramientas. La magnitud de estos trabajos será significativa.
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 rendimiento del precio de ETH. Desde esta perspectiva, la mayor aportación de esta hoja de ruta es redefinir a Ethereum como una “infraestructura”.
Para los desarrolladores, 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 Web3, permitiendo que cualquier estado en cadena pueda rastrearse matemáticamente hasta la cadena de pruebas ZK de Ethereum. Esto será decisivo para la captura de valor a largo plazo de Ethereum.
Además, influirá en la visión a largo plazo de las L2: si L1 tiene capacidades ZK, el papel de las L2 cambiará, de “solución de escalado segura” a “entorno de ejecución dedicado”. La forma en que las L2 encuentren su lugar en este nuevo escenario 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 —su capacidad para avanzar simultáneamente en ocho líneas de trabajo interdependientes, cada una de ellas un proyecto de varios años, manteniendo la descentralización en la coordinación—, lo cual es una característica única del protocolo Ethereum.
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 “Rollup-centric”, hasta 2026 con Strawmap, la evolución narrativa de Ethereum refleja una trayectoria clara: la escalabilidad 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. Todas apuntan a un mismo objetivo: que la cadena principal de Ethereum, sin sacrificar la descentralización, logre un aumento de rendimiento en órdenes 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 a su destino en 2029, probablemente veremos una verdadera “capa de liquidación global”— rápida, segura, privada y, como siempre, abierta.
Mantengamos la expectación.
