Cómo L1 zkEVM reescribe la especificación de Ethereum: evolución de Rollup a computaciones verificables

Desde 2025, la comunidad de desarrolladores de Ethereum muestra una intensidad sin precedentes en actualizaciones y replanteamientos de su papel en la criptoeconomía. En medio de debates sobre la dinámica de precios de ETH, la Fundación Ethereum presentó un ambicioso plan de ruta (Strawmap), que describe la evolución técnica del protocolo para los próximos años. La especificación no es solo una mejora técnica: es una transformación cualitativa de Ethereum mismo, pasando de ser una capa de cálculo para L2 a una base verificable de confianza para toda la economía descentralizada.

Esta transformación significa que cada paso de ejecución del estado de L1 podrá comprimirse y verificarse mediante pruebas de conocimiento cero. No se trata de copiar proyectos zkEVM de L2 (zkSync, Starknet, Scroll), sino de un objetivo fundamentalmente diferente: convertir la capa de ejecución de Ethereum en un sistema compatible con ZK. Si L2 zkEVM es construir un mundo ZK sobre Ethereum, entonces L1 zkEVM es transformar Ethereum en ese nivel.

Tres líneas de transformación: de registro programable a infraestructura verificable

El desarrollo de Ethereum en la última década ha estado acompañado de una evolución gradual en su base conceptual y prioridades técnicas. El primer período (2015–2020) se centró en que Ethereum era un registro programable capaz de más que Bitcoin. Contratos inteligentes, DeFi, NFT, DAO — todo surgió de esta historia básica sobre la universalidad del cálculo en blockchain.

El segundo período (2021–2023) trasladó el foco a la escalabilidad mediante soluciones Layer 2. Con el aumento del coste del gas, los usuarios comunes no podían permitirse transacciones en L1, y las soluciones Rollup comenzaron a dominar. Ethereum se replanteó como un nivel de datos y finalización, proporcionando una base segura para L2. The Merge y EIP-4844 sirvieron precisamente a ese propósito.

El tercer período (2024–2025) marca una reflexión más profunda. El paradoja residía en que el auge de L2 llevó a desmantelar el valor de L1: los usuarios migraron a Arbitrum, Base, Optimism y rara vez interactuaron directamente con L1. Esto planteó una cuestión crítica en la comunidad: ¿dónde encontrar valor en L1 si L2 roba a todos los usuarios?

El análisis de las principales direcciones tecnológicas de Strawmap ofrece respuesta. Verkle Tree, Stateless Client, verificación formal de EVM, soporte nativo para ZK — todos estos vectores apuntan en una dirección: dotar a Ethereum L1 de su propia verificabilidad. Es un cambio cualitativo que será la culminación de L1 zkEVM.

La especificación es fundamental: por qué 8 líneas de trabajo cambian la arquitectura de Ethereum

La interconexión de los cambios técnicos en Strawmap se entiende mejor considerando las 8 líneas de trabajo como un sistema arquitectónico unificado, donde cada componente soporta a los demás.

Línea de trabajo 1: Especificación formal de la EVM como base

La especificación no es un concepto abstracto: es una definición matemática de cada instrucción y regla de transformación de estado. Actualmente, el comportamiento de la EVM está definido por implementaciones de clientes (Geth, Nethermind), no por una especificación formal. Esto significa que su comportamiento puede variar en casos límite. Para construir circuitos ZK, no se puede trabajar con un sistema impreciso. Por eso, la primera y más importante línea de trabajo es formalizar cada aspecto de la EVM para que pueda verificarse matemáticamente.

Línea de trabajo 2: Reemplazo de funciones hash por compatibles con ZK

Ethereum usa activamente Keccak-256, que es costoso para circuitos ZK. La tarea principal es reemplazar progresivamente Keccak por funciones amigables con ZK (Poseidon, serie Blake) en componentes internos, especialmente en árboles de estado y pruebas Merkle. Es un cambio sistémico, ya que las funciones hash impregnan todo el protocolo.

Línea de trabajo 3: Verkle Tree en lugar de Merkle Patricia Tree

Verkle Tree reemplaza las cadenas de hash por compromisos vectoriales, reduciendo en decenas de veces el tamaño de las pruebas. Para L1 zkEVM, esto significa menos datos para verificar un bloque, generación más rápida de pruebas, y que Verkle Tree sea una condición clave para la factibilidad de L1 zkEVM en general.

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

Los clientes sin estado pueden verificar bloques sin almacenar localmente toda la base de datos de estado, solo necesitan datos witness. Esto está estrechamente ligado a Verkle Tree, ya que la factibilidad práctica depende del tamaño de las pruebas. Para L1 zkEVM, esto tiene un doble efecto: reduce los requisitos hardware de los nodos y define límites claros en los datos de entrada para las pruebas.

Línea de trabajo 5: Estandarización de pruebas ZK

L1 zkEVM requiere un sistema maduro de generación de pruebas, pero el campo ZK está muy fragmentado. El objetivo de esta línea es definir una interfaz estandarizada a nivel de protocolo, permitiendo que diferentes sistemas compitan. El equipo PSE (Privacy and Scaling Explorations) tiene amplia experiencia en esto.

Línea de trabajo 6: Separación de niveles de ejecución y consenso

Actualmente, el nivel de ejecución (EL) y el nivel de consenso (CL) interactúan mediante el API Engine. En L1 zkEVM, cada cambio de estado requiere generar una prueba ZK, lo que puede superar el intervalo entre bloques. Es necesario separar la ejecución y la generación de pruebas sin romper el consenso: la ejecución será rápida, las pruebas se generarán de forma asíncrona.

Línea de trabajo 7: Pruebas recursivas y agregadas

Generar una prueba para un solo bloque es costoso, pero la agregación recursiva de varios bloques en una sola prueba reducirá mucho los costes de verificación. El progreso en esto determinará directamente el coste de trabajo de L1 zkEVM.

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

Todas las mejoras de bajo nivel deben ser transparentes para los desarrolladores de contratos inteligentes: decenas de miles de contratos no deben volverse inutilizables. Esta línea es la más subestimada, pero también la más costosa en tiempo. Cada actualización de la EVM ha requerido extensas pruebas de compatibilidad. Las modificaciones de L1 zkEVM superan las anteriores, y la carga de trabajo con herramientas aumentará exponencialmente.

Por qué ahora: repensar Ethereum como infraestructura verificable

El lanzamiento de Strawmap coincide con un período de dudas sobre la dinámica de precios de ETH, pero su valor real radica en replantear Ethereum como infraestructura a largo plazo.

Para los desarrolladores, Strawmap ofrece claridad en la dirección y confianza en la inversión de tiempo. Para los usuarios, estas mejoras se traducen en una experiencia tangible: transacciones confirmadas en segundos, activos moviéndose sin interrupciones entre L1 y L2, la privacidad integrada en lugar de un añadido.

Obviamente, L1 zkEVM no aparecerá rápidamente — se espera una implementación completa en 2028–2029 o más tarde. Sin embargo, esto replantea la propuesta de valor de Ethereum de forma fundamental. Si L1 zkEVM tiene éxito, Ethereum dejará de ser solo una capa de cálculo para L2 y se convertirá en una base verificable de confianza para todo el Web3, permitiendo que cualquier cadena de estado pueda rastrearse matemáticamente hasta la cadena de Ethereum mediante pruebas ZK.

Esto también afecta la posición a largo plazo del ecosistema L2. Cuando L1 tenga capacidades ZK propias, el papel de L2 evolucionará — de “solución para escalado seguro” a “entorno de ejecución especializado”. Qué L2 encontrarán su lugar en esta nueva arquitectura será uno de los procesos evolutivos más interesantes en los próximos años.

Lo más importante es que L1 zkEVM demuestra la capacidad única de Ethereum: impulsar simultáneamente ocho líneas técnicas interdependientes, cada una un proyecto de varios años, manteniendo un método descentralizado de coordinación. Esa es la verdadera ambición ingenieril.

Evolución a través de la especificación: de orientarse a Rollups a cálculos verificables

La evolución del relato de Ethereum — de un modelo “centrado en Rollups” en 2021 a Strawmap 2026 — refleja una trayectoria clara: la escalabilidad no puede depender solo de L2, sino que L1 y L2 deben desarrollarse conjuntamente y en sinergia.

Las ocho líneas de trabajo de L1 zkEVM son una traducción técnica de este cambio de paradigma. Cada línea apunta a un objetivo: garantizar un crecimiento exponencial en la productividad de la red principal sin perder descentralización. No es una negación del camino L2, sino su perfeccionamiento y complemento orgánico.

En los próximos tres años, la ecosistema atravesará siete bifurcaciones del protocolo, reemplazando muchos componentes de su arquitectura. Cuando en 2029 se alcance la siguiente fase, quizás veamos un “nivel global verificable de cálculos” — rápido, seguro, privado y abierto para todos. La especificación no es solo un mecanismo: es una promesa de que Ethereum seguirá siendo la infraestructura para un futuro descentralizado.