Autor: Chloe, ChainCatcher
El 5 de julio de 2026, Vitalik Buterin publicó un extenso artículo en X, dando a conocer la hoja de ruta a largo plazo llamada "Lean Ethereum". Vitalik la posiciona como la tercera evolución importante de Ethereum después de "The Merge": no es una sola actualización, sino una serie de mejoras de protocolo que se implementarán por fases en los próximos tres o cuatro años, cubriendo casi todos los módulos centrales del protocolo, desde la forma de verificación, la criptografía, la finalidad hasta el almacenamiento del estado, todo reestructurado.
Esta hoja de ruta nace en un momento de reestructuración de la organización de Ethereum y debe entenderse dentro de un contexto temporal más completo. Para interpretar esta reestructuración integral, no solo es necesario aclarar el contenido específico de las actualizaciones técnicas, sino también ver cómo su diseño redistribuye los equilibrios entre el "costo de migración" y la "barrera de verificación", e investigar cómo eventualmente esta transformación subyacente se transmitirá al rendimiento del precio de ETH.
Las tres fases de desarrollo de Ethereum
Para situar esta actualización, primero se pueden enumerar las tres generaciones de Ethereum:
-
La primera generación es la arquitectura original de "PoW + EVM", cuyo núcleo era que todos los nodos volvían a ejecutar (re-execution) todas las transacciones. Este modelo, aunque seguro, general y abierto, tenía una escalabilidad limitada.
-
La segunda generación es Ethereum PoS después de "The Merge (Fusión)" en 2022. Este cambio en el mecanismo de consenso transformó por completo el modelo de seguridad, el modelo de emisión y el sistema de staking de Ethereum, al mismo tiempo que demostró al mercado la capacidad de ingeniería extremadamente alta de Ethereum para cambiar su motor central sin detenerse.
-
La tercera generación es el actual Lean Ethereum. Ya no se conforma con la división existente de "L1 para liquidación, L2 para escalabilidad", sino que integra el rendimiento de L1, la verificación mediante pruebas (Proved Verification), la privacidad, la resistencia cuántica, la estructura del estado y la arquitectura del cliente, todo dentro de un mismo marco de reestructuración a largo plazo.
Origen de la hoja de ruta Lean Ethereum
La hoja de ruta de Lean Ethereum se publicó en strawmap.org, un borrador público propuesto por primera vez en febrero de este año por el investigador de la Fundación, Justin Drake, que planifica siete actualizaciones de red hasta 2029. El término strawmap proviene de straw (paja), y el documento se posiciona como un borrador modificable. El strawmap también aclara que es una herramienta de coordinación en curso, no un cronograma fijo; cualquier actualización aún debe pasar por investigación, pruebas, implementación del cliente y consenso aproximado.

En esta visión, se delinean claramente cinco objetivos estratégicos a largo plazo: una finalidad (Finality) de L1 más rápida, un rendimiento (throughput) de L1 de 1 gigagas por segundo (capaz de manejar decenas de miles de TPS en condiciones límite), una escalabilidad de L2 de nivel teragas como visión del ecosistema, seguridad criptográfica cuántica con defensa integral y transferencias privadas nativas en L1.
Comparando con el estado actual, se puede sentir lo ambiciosos que son estos objetivos. Según datos de Etherscan, actualmente L1 de Ethereum procesa solo alrededor de 32 transacciones por segundo en promedio (aproximadamente 2.7 millones por día); el objetivo de 1 gigagas por segundo significa que la capacidad computacional de L1 experimentará un aumento de cientos de veces. Vale la pena señalar que la demanda en cadena de L1 en realidad ha estado en una tendencia alcista en el último año: el volumen diario de transacciones se recuperó significativamente desde los 1.4 millones a mediados de 2025, y desde 2026 se ha mantenido en su mayoría estable entre 2 y 2.9 millones, incluso acercándose a los 3.6 millones durante el pico del mercado en abril y mayo. El lanzamiento de esta hoja de ruta busca precisamente satisfacer esta demanda de actividad en cadena en recuperación.

La marca de tiempo también es muy clara: Hegotá, actualmente programada como la segunda actualización de 2026, probablemente sea el último hard fork de Ethereum de la "era anterior a Lean". Cada actualización posterior, en teoría, será parte de esta reestructuración. La más cercana actualización de Glamsterdam, que se espera que traiga un aumento considerable del límite de gas; esta actualización se esperaba originalmente para la primera mitad de 2026 y aún no se ha lanzado.
El cronograma también fue uno de los puntos de discusión más concentrados después del anuncio de la hoja de ruta. Dankrad Feist, ex investigador principal de la Fundación Ethereum y proponente del esquema Danksharding de Ethereum, publicó en X diciendo que apoya este strawmap, pero que un cronograma de tres a cuatro años es demasiado lento, y que a través de la tecnología actual de modelos de lenguaje grande, esta actualización debería completarse dentro de un año.

Gran actualización técnica central: Verificación por pruebas y reestructuración del estado
El núcleo técnico de Lean Ethereum es cambiar fundamentalmente el modo de verificación. El modelo de seguridad actual de Ethereum es que cada nodo vuelve a ejecutar cada transacción para confirmar la corrección del estado. El nuevo diseño integra las pruebas recursivas STARK como componentes centrales nativos del protocolo: un probador realiza los cálculos pesados, y todos los demás nodos solo necesitan verificar una prueba matemática compacta.
Esta elección también aborda otro problema: STARK utiliza criptografía hash, y actualmente no se conocen rutas de ataque cuánticas, mientras que los esquemas de firma actuales de Ethereum tienen riesgos relacionados. Vitalik señaló que la prioridad de la seguridad cuántica se ha "elevado significativamente". La hoja de ruta planea reemplazar gradualmente todos los componentes vulnerables cuánticamente con la firma Winternitz, siendo la parte más urgente encontrar un diseño seguro cuánticamente para los blobs en los que los L2 confían para reducir las tarifas.
La capa de consenso también está dentro del alcance de los cambios. En el Ethereum actual, una transacción tarda unos segundos en incluirse en un bloque, pero para que sea definitiva, se requieren aproximadamente quince minutos. El nuevo diseño separa la "cadena que produce bloques continuamente" y la "finalidad" en dos cosas distintas, con el objetivo de que los validadores puedan finalizar en una o dos rondas de votación, comprimiendo los quince minutos a casi tiempo real. Además, hay precios multidimensionales de gas, lo que significa que recursos como cómputo, almacenamiento y transmisión de datos se tarifan por separado, como el agua y la electricidad, en lugar de mezclarse en un solo cargo.
Los cambios en la arquitectura del estado afectan directamente a los desarrolladores de aplicaciones. El estado se puede entender como el libro mayor en tiempo real de Ethereum, que registra los saldos de todas las cuentas y los datos de los contratos inteligentes. Este libro solo se vuelve más grande, y actualmente todos los nodos completos deben mantener una copia completa, lo que mantiene altos los costos de almacenamiento en cadena.
La solución de Vitalik es estratificar estructuralmente la arquitectura de almacenamiento: el "estado dinámico" (Dynamic State / zona núcleo) actual, con todas sus funciones, se limitará estrictamente al umbral de hardware de 2 TB, evitando su expansión ilimitada; simultáneamente, el protocolo abrirá una nueva "capa de almacenamiento de estado de nuevo tipo (gran almacén)" con una capacidad de hasta 100 TB y mayor escalabilidad. En la visión de Vitalik para 2030, la mayoría de los tokens (ERC-20), NFT y aplicaciones DeFi convencionales, siempre que estén dispuestos a reescribir sus contratos para mudarse a este gran almacén con la nueva arquitectura, podrían ver sus tarifas de transacción reducidas más de diez veces. La capa de protocolo no obliga ni subsidia, simplemente presenta la enorme diferencia de precio entre las dos capas, dejando que el mercado y las aplicaciones decidan el momento de la migración.
El estatus de la privacidad también se redefine. En el pasado, la división de Ethereum era: todo en cadena es público y transparente; los usuarios que querían privacidad buscaban protocolos de privacidad de terceros. Vitalik ahora escribe "Privacy is no longer an afterthought, it is a first class goal", lo que significa que la privacidad pasa de "algo que los residentes instalan por su cuenta" a "parte de las normas de construcción": en el futuro, cada nuevo componente del protocolo será examinado en la fase de diseño con una pregunta: ¿puede admitir funciones de privacidad sin intermediarios, de bajo costo y resistentes a la cuántica? Todavía está por verse si se puede lograr, pero el criterio de evaluación en sí ya está escrito en la hoja de ruta.
La controversia del reemplazo de EVM: La pugna del ecosistema L2
El motor que Ethereum ha usado durante diez años se llama EVM, todos los contratos, herramientas de desarrollo y lenguajes de programación del mundo se construyen a su alrededor. Y ahora Vitalik propone reemplazar este motor, por razones relacionadas con el STARK mencionado anteriormente: para generar pruebas matemáticas para las transacciones, ejecutarlas en EVM es costoso; cambiar a un motor más amigable con las pruebas sería mucho más barato.
Menciona como candidatos las arquitecturas RISC-V y leanISA. El escenario ideal final sería que el nuevo motor se convierta en el núcleo del protocolo, y EVM retroceda a una capa de traducción: los contratos antiguos seguirían funcionando, solo que primero se traducirían a instrucciones que el nuevo motor pueda entender antes de ejecutarse. Cambiar el motor es relativamente más complejo, por lo que esta propuesta ha generado controversias desde que Vitalik presentó por primera vez la idea de RISC-V en abril de 2025.
Offchain Labs, el desarrollador central detrás de Arbitrum L2, defendió públicamente en noviembre pasado que otra arquitectura, WebAssembly (WASM), era la mejor opción, pero esta vez WASM no figura en la lista de candidatos de Vitalik. ¿Por qué es importante esto? Porque Arbitrum es uno de los L2 más grandes de Ethereum, y su tecnología de contratos Stylus se basa en WASM.
Se puede entender así: cambiar el motor en L1 equivale a rediseñar las "especificaciones del enchufe" para todo el ecosistema. Si tu equipo usa exactamente el mismo tipo de enchufe, puedes continuar sin problemas; si no, tienes que pagar por un adaptador. Quién figure en la lista determinará qué L2 puede conectar sin problemas sus inversiones pasadas al L1 futuro, y cuál tendrá que pagar el costo del adaptador.
Ethereum no tiene un mecanismo de votación para resolver este tipo de desacuerdos. Si se cambia o no el motor, y por cuál, finalmente depende del consenso aproximado de los desarrolladores en las reuniones All Core Devs, y de si los equipos de clientes están dispuestos a implementarlo. Hasta la fecha, cambiar el motor sigue siendo un objetivo a largo plazo en palabras de Vitalik, y las reuniones de desarrolladores aún no han llegado a ninguna conclusión formal.
¿Afectará la hoja de ruta al precio de ETH?
Para correlacionar la hoja de ruta técnica con el precio de ETH, se pueden considerar dos niveles temporales.
El primer nivel es la ruta de transmisión mecánica. Desde EIP-1559, la tarifa base de cada transacción de Ethereum se quema, por lo que la escala de la actividad transaccional en L1 afecta directamente la dinámica de oferta y el valor de liquidación de ETH. Según este mecanismo, si se logra el objetivo de gigagas y el volumen de transacciones en L1 se recupera con el aumento del rendimiento, el consumo de gas y la cantidad quemada se amplificarán simultáneamente. Esta es la ruta de transmisión más directa entre la hoja de ruta y la valoración de ETH. Sin embargo, es importante enfatizar que esta ruta es válida bajo la premisa de que "la demanda regresa después de aumentar la capacidad"; la capacidad en sí misma no crea automáticamente la demanda.
El segundo nivel es el desfase temporal. La hoja de ruta describe un proyecto por fases de tres a cuatro años. Durante 2026, esta hoja de ruta no cambiará nada del estado actual de Ethereum; es un compromiso direccional, y los compromisos direccionales de Ethereum tienen un historial de retrasos en sus cronogramas; el propio Merge se retrasó varios años respecto a las estimaciones iniciales. En otras palabras, esta hoja de ruta aumenta el límite de capacidad a largo plazo de Ethereum, pero no aborda el problema de captura de valor a medio plazo de ETH; la crítica del analista Ignas a la hoja de ruta apunta precisamente a esto: no cubre los ajustes de la propia economía token de ETH.

Lista de seguimiento para la próxima década
Resumiendo lo anterior, la respuesta final en realidad apunta a la misma estructura: este strawmap aumenta el límite a largo plazo de Ethereum, pero no resuelve inmediatamente el problema de captura de valor a medio plazo de ETH. Este no es el momento de entrar en FOMO basándose únicamente en la hoja de ruta.
En lugar de valorar la hoja de ruta en sí, un enfoque más operativo es seguir algunos hitos que se pueden verificar en un futuro próximo:
-
Si la actualización de Glamsterdam puede iniciarse y completar con éxito el aumento del límite de gas.
-
Si la demanda de blobs puede crecer continuamente con la actividad en L2.
-
Si los ingresos por tarifas de L1 y la cantidad de ETH quemado pueden mejorar.
-
Si el crecimiento de L2 puede retroalimentarse a L1 a través del pago de blobs y la demanda de liquidación.
-
Si el rendimiento relativo de ETH frente a BTC puede recuperarse.
Cada uno de estos indicadores corresponde a un aspecto de la hoja de ruta y se puede verificar semana a semana en páginas de gráficos como Etherscan y paneles públicos como DefiLlama. Cualquier cambio en uno de ellos estará más cerca de ser una base de valoración que el documento de la hoja de ruta en sí. Cualquier cambio en ellos le dirá al mercado, antes que el documento de la hoja de ruta, si esta reestructuración de tres a cuatro años se está cumpliendo o retrasando.







