Estrategia de Capa Ethereum: Cómo L1 zkEVM Transforma la Economía de Blockchain a Corto y Largo Plazo

Desde 2026, Ethereum enfrenta un momento crítico en la evolución de su arquitectura en capas. La frecuencia de anuncios del equipo de desarrollo principal alcanza su punto más alto, reflejando un cambio estratégico fundamental sobre cómo debe desarrollarse el ecosistema. A corto plazo, Ethereum equilibra actualmente el rol de Layer 1 y Layer 2; sin embargo, su visión a largo plazo apunta a una transformación mucho más ambiciosa: convertir el L1 de Ethereum en un sistema zkEVM integrado, en lugar de ser solo una base de seguridad para L2.

Este cambio de comprensión se refleja en una serie de propuestas técnicas recientes. El 26 de febrero, Justin Drake de la Fundación Ethereum publicó un borrador de hoja de ruta llamado Strawmap, que describe la dirección del desarrollo del protocolo L1 de Ethereum para los próximos años. El documento contempla cinco objetivos principales: aumentar la velocidad de finalización a segundos, implementar un “Gigagas” L1 con un rendimiento de hasta 10,000 TPS mediante zkEVM, lanzar L2 de alta velocidad basado en DAS (Sampling de Disponibilidad de Datos), sistemas criptográficos resistentes a la computación cuántica y funciones de privacidad nativas—todo planificado a través de siete hard forks hasta 2029, con una frecuencia promedio de uno cada seis meses.

De un enfoque en L2 a una reintegración de L1: Tres olas de cambio en la narrativa de Ethereum

El recorrido de Ethereum en los últimos diez años puede trazarse a través de tres fases evolutivas claras, cada una reflejando diferentes prioridades en la capa.

Primera fase (2015–2020): Era del Ledger Programable

La narrativa central de Ethereum es la creación de una plataforma para contratos inteligentes Turing-complete. En este período, la principal ventaja de Ethereum sobre Bitcoin radicaba en su flexibilidad de ejecución: la capacidad de correr DeFi, NFT, DAO y otras aplicaciones descentralizadas. El protocolo L1 de Ethereum se convirtió en la capa principal de ejecución, alojando la mayor parte de la actividad en la criptoeconomía. Este rol posicionó a Ethereum como la “columna vertebral de la infraestructura Web3”, aunque sin cuestionamientos serios sobre escalabilidad.

Segunda fase (2021–2023): Era de Rollups en L2

Cuando los costos de gas en la mainnet de Ethereum se dispararon, la narrativa cambió. Los Rollups en L2 se convirtieron en la solución dominante, y Ethereum se reposicionó: de capa principal de ejecución a capa de liquidación. Actualizaciones como The Merge (2022) y EIP-4844 (Proto-Danksharding) fueron diseñadas para soportar este modelo—L1 responsable de la seguridad y disponibilidad de datos, mientras la computación principal migraba a L2. Esta estrategia permitió una escalabilidad significativa, pero generó un nuevo dilema.

Tercera fase (2024–2025): Reflexión y Reposicionamiento

El éxito de L2 trajo un paradoja inesperada: los usuarios migraron masivamente a Arbitrum, Base, Optimism y otras plataformas L2, dejando a L1 de Ethereum con actividad relativamente limitada. El valor capturado por L1 disminuyó, mientras L2 dominaba. Surgen preguntas fundamentales en la comunidad: si todos los usuarios y actividades están en L2, ¿qué relevancia tiene L1? ¿Cómo puede L1 captar valor a largo plazo?

Estas preguntas impulsaron una evolución radical. La comunidad se dio cuenta de que una estrategia basada únicamente en L2 no es sostenible. Es necesaria una reintegración y sinergia entre L1 y L2, no solo una división del trabajo.

Strawmap 2026: Ocho vías técnicas hacia un L1 zkEVM integrado

Esta nueva visión se concreta en ocho líneas de trabajo técnico estrechamente relacionadas. Cada línea es un proyecto plurianual, y el éxito global requiere avances simultáneos en todas ellas. Esto diferencia a L1 zkEVM de esfuerzos previos de escalabilidad: su complejidad no radica en un solo avance, sino en la orquestación de ocho innovaciones interdependientes.

Vía 1: Formalización de la especificación EVM

El fundamento de toda prueba de conocimiento cero (zero-knowledge) es una definición matemática precisa. Actualmente, el comportamiento de la EVM se define por la implementación de clientes (Geth, Nethermind, Besu, etc.), no por una especificación formal estricta. La inconsistencia en los límites de casos entre clientes dificulta mucho el desarrollo de circuitos ZK. Esta vía busca convertir cada instrucción y regla de transición de estado de la EVM en una especificación formal verificable por máquina. Sin esto, todos los pasos siguientes se construyen sobre arena.

Vía 2: Migración a funciones hash amigables con ZK

Ethereum usa ampliamente Keccak-256, que no es óptimo para circuitos ZK—el overhead computacional es muy alto, incrementando significativamente el tiempo y costo de generación de pruebas. Esta vía implica sustituir progresivamente Keccak por funciones hash ZK-friendly como Poseidon y la familia Blake, especialmente en árboles Merkle y caminos de prueba. Este cambio tendrá un impacto amplio, dado que las funciones hash están en toda la capa de protocolo.

Vía 3: Verkle Trees en lugar de Merkle Patricia Trees

La infraestructura del árbol de estado de Ethereum usa actualmente Merkle Patricia Trees (MPT). Verkle Trees los reemplazan con compromisos vectoriales, comprimiendo el tamaño de los witnesses en decenas de veces. Para L1 zkEVM, esto significa reducir drásticamente los datos necesarios para probar cada bloque, acelerar la generación de pruebas y hacer económicamente viable L1 zkEVM. Verkle Trees son un prerequisito clave para la viabilidad de L1 zkEVM.

Vía 4: Clientes sin estado (Stateless Clients)

Un cliente sin estado es un nodo que verifica bloques sin mantener toda la base de datos de estado de Ethereum localmente—solo usando witnesses incluidos en el propio bloque. Esto está estrechamente relacionado con Verkle Trees (solo es factible si los witnesses son pequeños), y tiene doble propósito: reducir la barrera de hardware para correr nodos (aumentando la descentralización) y proporcionar límites claros de entrada para las pruebas ZK (el probador solo necesita procesar el witness, no todo el estado global).

Vía 5: Estandarización de sistemas de prueba ZK

L1 zkEVM requiere sistemas de prueba ZK maduros para generar proof de la ejecución de bloques. El panorama ZK actual es muy fragmentado, sin una solución universalmente aceptada. Esta vía define una interfaz de prueba estandarizada en el protocolo Ethereum, permitiendo que diferentes sistemas de prueba compitan mediante una interfaz consistente, sin monopolizar una sola solución. Esto mantiene la apertura técnica y deja espacio para evolución continua. El equipo de Exploraciones de Privacidad y Escalabilidad (PSE) de la Fundación Ethereum ya ha acumulado muchas experiencias iniciales en esta dirección.

Vía 6: Desacoplar capa de ejecución y capa de consenso

Actualmente, la capa de ejecución (EL) y la capa de consenso (CL) de Ethereum se comunican vía Engine API. En la arquitectura de L1 zkEVM, cada transición de estado en la capa de ejecución requiere generar un proof ZK. La generación de proof puede tomar mucho más tiempo que la producción del bloque, creando un cuello de botella. Esta vía busca resolver el problema central: cómo separar ejecución y generación de proof sin dañar el mecanismo de consenso—la ejecución puede completarse rápidamente, mientras el proof se genera de forma asíncrona y se verifica por los validadores en el momento adecuado para completar la finalización. Esto implica modificaciones profundas en el modelo de finalización de bloques.

Vía 7: Proofs recursivos y agregación de proof

El costo de generar un proof ZK para un solo bloque es muy alto. Pero si los proofs de múltiples bloques se pueden comprimir recursivamente en un solo proof, el costo de verificación se distribuye mucho más eficientemente. El avance en esta vía determina directamente cuánto puede reducirse el costo total de L1 zkEVM.

Vía 8: Herramientas para desarrolladores y compatibilidad EVM

Todas las reformas técnicas definitivas deben ser transparentes para los desarrolladores de contratos inteligentes en Ethereum. Cientos de miles de contratos existentes no deben romperse, y las herramientas de desarrollo no deben requerir reescritura total. Esta vía suele subestimarse, pero es la más laboriosa: cada actualización previa de la EVM requiere extensas pruebas de compatibilidad y ajustes en las herramientas. La transición a L1 zkEVM será mucho mayor, y la carga en tooling y compatibilidad crecerá exponencialmente.

Impacto a corto plazo en las capas: ¿Qué cambia para L2 y el ecosistema?

Esta transformación tiene implicaciones inmediatas y a largo plazo para diferentes actores.

Implicaciones a corto plazo (2026–2027)

En el horizonte cercano, en cuanto a capas, L2 seguirá siendo la principal solución de escalabilidad. La Fundación Ethereum ha comunicado explícitamente que L1 zkEVM no reemplaza a L2, sino que es una evolución complementaria. Los Rollups en L2 seguirán siendo la capa principal de ejecución para altos volúmenes de transacciones, brindando confianza a constructores y usuarios para seguir desarrollando en un ecosistema Layer 2 ya maduro.

Pero a medida que Ethereum L1 se vuelva más capaz en los próximos años, el posicionamiento de L2 evolucionará de “solución de escalado segura” a “entorno de ejecución especializado”. La supervivencia y éxito de cada L2 dependerá de encontrar un valor diferencial—ya sea mediante VM especializada, optimización de costos o funciones de privacidad—en el nuevo orden.

Implicaciones a largo plazo (2028–2029)

Cuando L1 zkEVM esté completamente integrado, Ethereum dejará de ser solo una capa de liquidación para L2. Se convertirá en la “raíz de computación verificable” para todo el ecosistema Web3. Cada cadena, cada L2, podrá anclar su procedencia matemáticamente a la cadena de proof ZK de Ethereum, creando una jerarquía de confianza unificada pero descentralizada.

Por qué este impulso es importante: confianza en los constructores y posicionamiento a largo plazo de Ethereum

El anuncio de Strawmap llega en un momento en que el mercado duda del rendimiento de ETH. Desde esta perspectiva, el valor más importante de esta hoja de ruta es la reafirmación de Ethereum como “infraestructura primitiva”, no como una commodity.

Para los constructores: Strawmap ofrece certeza direccional. Tras un período de incertidumbre sobre si Ethereum seguiría siendo relevante, ahora está claro que el ecosistema central continuará creciendo con ambiciones técnicas grandes. Esto inspira confianza para comprometerse a largo plazo.

Para los usuarios: Estas mejoras técnicas se traducen finalmente en una experiencia tangible—finalidad en segundos, flujo de activos fluido entre L1 y L2, privacidad como función nativa, no como complemento.

Para los inversores: Es momento de reevaluar el posicionamiento de Ethereum. Si se implementa con éxito L1 zkEVM, Ethereum dejará de ser solo una capa de liquidación para L2, convirtiéndose en la raíz de confianza verificada para Web3. Es un cambio en la narrativa, no solo una mejora cuantitativa.

En realidad, L1 zkEVM no será un producto que se lance de inmediato. La implementación completa puede concretarse en 2028–2029 o incluso más tarde. Pero redefine fundamentalmente la propuesta de valor de Ethereum.

Estas ocho vías técnicas no son solo una hoja de ruta—son la manifestación de una cultura de desarrollo única en Ethereum: la capacidad de impulsar simultáneamente ocho flujos de trabajo técnicos interdependientes, cada uno un proyecto de ingeniería de años, manteniendo la coordinación descentralizada. Es una ventaja competitiva difícil de copiar por otros.

En conjunto, desde la narrativa “centrada en Rollups” en 2020 hasta Strawmap 2026, la evolución de la narrativa de Ethereum muestra una lección clave: la escalabilidad no puede depender solo de L2. L1 y L2 deben co-evolucionar de manera sinérgica. Las ocho vías de L1 zkEVM representan el mapeo técnico de este cambio de paradigma, apuntando a un destino: mejorar drásticamente la mainnet de Ethereum sin sacrificar la descentralización, no rechazando L2 sino perfeccionándola.

En los próximos tres años, este “Barco de Teseo” experimentará siete forks y reemplazará muchas “piezas” y “pantallas”. Cuando llegue a su próximo destino en 2029, probablemente veremos una “capa de liquidación global” verdaderamente revolucionaria—rápida, segura, privada y aún abierta como desde el principio. Sigamos atentos a esta evolución.