Solo desde una percepción sensorial, desde 2025, la comunidad de desarrolladores centrales de Ethereum ha tenido una frecuencia de actualizaciones inusualmente intensa.
Desde la actualización Fusaka, hasta Glamsterdam, y luego la planificación a largo plazo para los próximos tres años en torno a temas como kEVM, el sistema criptográfico resistente a la cuántica, el Límite de Gas, Ethereum ha publicado de manera intensiva múltiples documentos de hoja de ruta que cubren de tres a cinco años en solo unos pocos meses.
Este ritmo en sí mismo es una señal.
Si lees detenidamente la hoja de ruta más reciente, encontrarás que está surgiendo una dirección más clara y más radical: Ethereum se está transformando en una computadora verificable, y el final de este camino es el zkEVM de L1.
一、Las tres derivas del centro de gravedad de la narrativa de Ethereum
El 26 de febrero, el investigador de la Fundación Ethereum, Justin Drake, publicó en una plataforma social que la Fundación Ethereum había propuesto un borrador de hoja de ruta llamado Strawmap, que describe la dirección de actualización del protocolo L1 de Ethereum en los próximos años.
Esta hoja de ruta propone cinco objetivos centrales: un L1 más rápido (confirmación final en segundos), un L1 "Gigagas" de 10,000 TPS a través de zkEVM, un L2 de alto rendimiento basado en Muestreo de Disponibilidad de Datos (DAS), un sistema criptográfico resistente a la cuántica, y funcionalidad de transferencia de privacidad nativa; al mismo tiempo, la hoja de ruta planea siete bifurcaciones (forks) del protocolo para 2029, aproximadamente una cada seis meses en promedio.
Se puede decir que, en la última década, el desarrollo de Ethereum siempre ha estado acompañado por la evolución constante de su narrativa y su ruta tecnológica.
La primera etapa (2015–2020) fue la del libro mayor programable.
Este era el núcleo narrativo inicial de Ethereum, es decir, los "contratos inteligentes completos de Turing". La mayor ventaja de Ethereum en ese entonces residía en que podía hacer muchas más cosas en comparación con Bitcoin, por ejemplo, DeFi, NFT, DAO son productos de esta narrativa. Una gran cantidad de protocolos financieros descentralizados comenzaron a operar en la cadena, desde préstamos, DEX hasta stablecoins. Ethereum se convirtió gradualmente en la principal red de liquidación de la economía cripto.
La segunda etapa (2021–2023) fue la toma de control de la narrativa de L2.
Con el aumento de las tarifas de Gas en la cadena principal de Ethereum, los usuarios comunes no podían costear los gastos de transacción, y Rollup comenzó a convertirse en el protagonista de la escalabilidad. Ethereum también se redefinió gradualmente como una capa de liquidación, destinada a ser la base de seguridad para L2.
En pocas palabras, se trataba de migrar la mayor parte del cómputo de la capa de ejecución a L2, escalando a través de Rollup, mientras que L1 solo se encargaba de la disponibilidad de datos y la liquidación final. Durante este período, The Merge, EIP-4844, etc., sirvieron a esta narrativa, con el objetivo de que L2 utilizara la confianza de Ethereum de manera más económica y segura.
La tercera etapa (2024–2025) se centró en la introspección y reflexión de la narrativa.
Como es bien sabido, la prosperidad de L2 trajo un problema inesperado: la propia L1 de Ethereum se volvió menos importante. Los usuarios comenzaron a operar más en Arbitrum, Base, Optimism, rara vez interactuaban directamente con L1, y el desempeño del precio de ETH de Ethereum también reflejó esta ansiedad.
Esto llevó a la comunidad a debatir: si L2 acapara todos los usuarios y la actividad, ¿dónde queda la captura de valor para L1? Hasta la conmoción interna de Ethereum en 2025 y la serie de hojas de ruta desplegadas en 2026, esta lógica está experimentando una evolución profunda.
De hecho, al revisar las direcciones técnicas centrales desde 2025, Verkle Tree, cliente sin estado (Stateless Client), verificación formal de EVM, soporte nativo para ZK, etc., aparecen repetidamente. Estas direcciones técnicas apuntan todas a lo mismo: dotar a la L1 de Ethereum de verificabilidad por sí misma. Es importante señalar que esto no se trata solo de que las pruebas de L2 puedan verificarse en L1, sino de que cada paso de transición de estado de L1 pueda comprimirse y verificarse mediante pruebas de conocimiento cero (ZK).
Esta es la ambición del zkEVM de L1. A diferencia del zkEVM de L2, el zkEVM de L1 (zkEVM encapsulado) significa integrar directamente la tecnología de pruebas de conocimiento cero en la capa de consenso de Ethereum.
No es una réplica del zkEVM de L2 (como zkSync, Starknet, Scroll), sino transformar la propia capa de ejecución de Ethereum en un sistema amigable con ZK. Por lo tanto, si el zkEVM de L2 consiste en construir un mundo ZK sobre Ethereum, entonces el zkEVM de L1 consiste en convertir a Ethereum en ese mundo ZK.
Una vez que se logre este objetivo, la narrativa de Ethereum se actualizará de ser la capa de liquidación de L2 a ser la "raíz de confianza para el cómputo verificable".
Esto será un cambio cualitativo, no el cambio cuantitativo de los últimos años.
二、¿Qué es el verdadero zkEVM de L1?
Volvemos a un punto ya conocido: en el modo tradicional, los validadores necesitan "reejecutar" cada transacción para verificar un bloque, mientras que en el modo zkEVM, los validadores solo necesitan verificar una Prueba ZK. Esto permite a Ethereum aumentar el Límite de Gas a 100 millones o más sin aumentar la carga de los nodos (lectura extendida "El 'amanecer' de la ruta ZK: ¿Se acelera el mapa de ruta del final de Ethereum?").
Sin embargo, transformar la L1 de Ethereum en un zkEVM no es en absoluto un problema de un solo punto de ruptura, sino que requiere avances simultáneos en ocho direcciones, cada una de las cuales es un proyecto de varios años.
Línea de trabajo 1: Especificación formal de EVM (EVM Formalization)
El prerrequisito para cualquier prueba ZK es que el objeto a probar tenga una definición matemática precisa. Sin embargo, el EVM actual define su comportamiento mediante implementaciones de clientes (Geth, Nethermind, etc.), no mediante una especificación formal estricta. El comportamiento de diferentes clientes en casos límite puede ser inconsistente, lo que hace extremadamente difícil escribir circuitos ZK para EVM; después de todo, no se puede escribir una prueba para un sistema con una definición vaga.
Por lo tanto, el objetivo de esta línea de trabajo es escribir cada instrucción del EVM, cada regla de transición de estado, en una especificación formal verificable por máquina. Este es el cimiento de todo el proyecto zkEVM de L1. Sin él, todo lo que sigue es construir sobre arena.
Línea de trabajo 2: Reemplazo de la función hash amigable con ZK
Ethereum actualmente utiliza ampliamente Keccak-256 como función hash. Keccak es extremadamente hostil para los circuitos ZK, con un costo computacional enorme, lo que aumenta significativamente el tiempo y el costo de generación de pruebas.
El núcleo de esta línea de trabajo es reemplazar gradualmente el uso interno de Keccak en Ethereum con funciones hash amigables con ZK (como Poseidon, la familia Blake), especialmente en el árbol de estado y las rutas de prueba Merkle. Este es un cambio que afecta a todo el organismo, ya que la función hash impregina cada rincón del protocolo Ethereum.
Línea de trabajo 3: Reemplazo de Merkle Patricia Tree por Verkle Tree
Este es uno de los cambios más esperados en la hoja de ruta 2025–2027. Ethereum actualmente utiliza Merkle Patricia Tree (MPT) para almacenar el estado global. Verkle Tree, al reemplazar los enlaces hash con compromisos vectoriales (Vector Commitment), puede comprimir el volumen del testigo (witness) decenas de veces.
Para el zkEVM de L1, esto significa que la cantidad de datos necesarios para probar cada bloque disminuye drásticamente y la velocidad de generación de pruebas mejora significativamente. También significa que la introducción de Verkle Tree es una premisa infraestructural clave para la viabilidad del zkEVM de L1.
Línea de trabajo 4: Clientes sin estado (Stateless Clients)
Un cliente sin estado se refiere a que un nodo, al verificar un bloque, no necesita almacenar localmente la base de datos completa del estado de Ethereum, solo necesita los datos de testigo (witness) adjuntos al bloque mismo para completar la verificación.
Esta línea de trabajo está profundamente ligada a Verkle Tree, porque solo es factible un cliente sin estado si el testigo es lo suficientemente pequeño. Por lo tanto, el significado del cliente sin estado para el zkEVM de L1 es doble: por un lado, reduce enormemente el umbral de hardware para ejecutar nodos, contribuyendo a la descentralización; por otro lado, proporciona un límite de entrada claro para las pruebas ZK, de modo que el probador solo necesita procesar los datos contenidos en el testigo, y no todo el estado mundial.
Línea de trabajo 5: Estandarización e integración del sistema de pruebas ZK
El zkEVM de L1 necesita un sistema de pruebas ZK maduro para generar pruebas para la ejecución de bloques. Sin embargo, el panorama tecnológico actual en el campo ZK está muy fragmentado, sin una solución óptima reconocida. El objetivo de esta línea de trabajo es definir una interfaz de prueba estandarizada (proof interface) a nivel de protocolo de Ethereum, de modo que diferentes sistemas de prueba puedan conectarse de manera competitiva, en lugar de designar uno específico.
Esto mantiene la apertura tecnológica y también deja espacio para la evolución continua de los sistemas de prueba. El equipo PSE (Privacy and Scaling Explorations) de la Fundación Ethereum ya tiene una gran acumulación preliminar en esta dirección.
Línea de trabajo 6: Desacoplamiento de la capa de ejecución y la capa de consenso (Evolución de Engine API)
Actualmente, la capa de ejecución (EL) y la capa de consenso (CL) de Ethereum se comunican a través de Engine API. En la arquitectura del zkEVM de L1, cada transición de estado de la capa de ejecución necesita generar una prueba ZK, y el tiempo de generación de esta prueba puede exceder en gran medida el intervalo de creación de bloques.
El problema central que esta línea de trabajo necesita resolver es cómo desacoplar la ejecución y la generación de pruebas sin destruir el mecanismo de consenso: la ejecución puede completarse rápidamente primero, y la prueba puede generarse de manera asíncrona con retraso, para que luego los validadores completen la confirmación final en el momento adecuado. Esto implica una modificación profunda del modelo de finalidad (Finality) del bloque.
Línea de trabajo 7: Prueba recursiva y agregación de pruebas
El costo de generar una prueba ZK para un solo bloque es alto, pero si se pueden agregar recursivamente las pruebas de múltiples bloques en una sola prueba, el costo de verificación se reduce enormemente. El progreso en esta línea de trabajo determinará directamente a qué costo podrá funcionar el zkEVM de L1.
Línea de trabajo 8: Cadena de herramientas para desarrolladores y garantía de compatibilidad con EVM
Todas las transformaciones tecnológicas subyacentes finalmente ser transparentes para los desarrolladores de contratos inteligentes en Ethereum. Los cientos de miles de contratos existentes no pueden fallar debido a la introducción de zkEVM, y la cadena de herramientas de los desarrolladores no puede verse obligada a reescribirse.
Esta línea de trabajo es la que se subestima más fácilmente, pero a menudo es la que más tiempo consume. Históricamente, cada actualización de EVM ha requerido una gran cantidad de pruebas de compatibilidad hacia atrás y trabajo de adaptación de la cadena de herramientas. Los cambios del zkEVM de L1 son mucho mayores que las actualizaciones anteriores, y el trabajo de la cadena de herramientas y la compatibilidad también aumentará en órdenes de magnitud.
三、¿Por qué ahora es el momento correcto para entender esto?
La publicación de Strawmap coincide con un momento en el que el mercado alberga dudas sobre el desempeño del precio de ETH. Desde esta perspectiva, el valor más importante de esta hoja de ruta radica precisamente en redefinir Ethereum como "infraestructura".
Para los constructores (Builders), representados por los desarrolladores, Strawmap proporciona certeza direccional; para los usuarios, estas actualizaciones tecnológicas finalmente se traducirán en una experiencia perceptible: transacciones confirmadas finales en segundos, activos que fluyen sin problemas entre L1 y L2, protección de privacidad como una función integrada y no un complemento.
Por supuesto, objetivamente hablando, el zkEVM de L1 no será un producto que se materialice en el corto plazo; su implementación completa podría llevar hasta 2028-2029 o incluso más tarde.
Pero al menos redefine la propuesta de valor de Ethereum. Si el zkEVM de L1 tiene éxito, Ethereum ya no será solo la capa de liquidación de L2, sino la raíz de confianza verificable de todo el mundo Web3, permitiendo que cualquier estado en cadena pueda rastrearse matemáticamente hasta la cadena de pruebas ZK de Ethereum. Esto es decisivo para la captura de valor a largo plazo de Ethereum.
En segundo lugar, también afecta el posicionamiento a largo plazo de L2. Después de todo, cuando la L1 misma tenga capacidad ZK, el papel de L2 cambiará: evolucionará de "solución de escalado de seguridad" a "entorno de ejecución especializado". Qué L2 podrán encontrar su lugar en este nuevo panorama será la evolución ecológica más digna de observar en los próximos años.
Lo más importante es que el autor cree que también es una ventana excelente para observar la cultura de los desarrolladores de Ethereum: poder avanzar simultáneamente en ocho líneas de trabajo tecnológico interdependientes, cada una de las cuales es un proyecto de varios años, y mantener una forma de coordinación descentralizada, esto en sí mismo es la capacidad única de Ethereum como protocolo.
Comprender esto ayuda a evaluar con mayor precisión la posición real de Ethereum en varias narrativas competitivas.
En general, desde el "centrado en Rollup" de 2020 hasta el Strawmap de 2026, la evolución narrativa de Ethereum refleja una trayectoria clara: la escalabilidad no puede depender solo de L2, L1 y L2 deben evolucionar de manera coordinada.
Por lo tanto, las ocho líneas de trabajo del zkEVM de L1 son precisamente el mapeo técnico de este cambio de percepción. Apuntan conjuntamente a un objetivo, que es permitir que la red principal de Ethereum obtenga una mejora de rendimiento de orden de magnitud sin sacrificar la descentralización. Esto no es una negación de la ruta L2, sino un perfeccionamiento y complemento de la misma.
En los próximos tres años, este "Barco de Teseo" experimentará siete bifurcaciones, reemplazando innumerables "tablones". Cuando llegue a la siguiente estación en 2029, es posible que veamos una "capa de liquidación global" verdaderamente significativa — rápida, segura, privada y, como siempre, abierta.
Esperémoslo juntos.
