El próximo decenio de Ethereum, según Vitalik

Autor: Chloe, ChainCatcher

El 5 de julio de 2026, Vitalik Buterin publicó en X un texto largo para anunciar una hoja de ruta a largo plazo llamada Lean Ethereum. Vitalik la enmarca como la tercera gran evolución de Ethereum después de la Merge: no es una sola actualización, sino una serie de mejoras de protocolo que se implementarán por fases en los próximos 3 a 4 años, abarcando casi cada módulo central del protocolo, desde el modo de verificación y la criptografía, pasando por la finalidad, hasta el almacenamiento de estado, todo reestructurado.

Esta hoja de ruta nace en medio de una reorganización de Ethereum, y debe entenderse dentro de un marco temporal más completo. Interpretar este rediseño integral no solo exige aclarar el contenido técnico concreto de la actualización, sino también ver cómo su diseño reequilibra los trade-offs entre “coste de migración” y “umbral de verificación”, y explorar cómo esta transformación de base terminará transmitiéndose al desempeño del precio de ETH.

Los tres periodos de desarrollo de Ethereum

Para ubicar esta actualización, primero conviene ordenar las tres generaciones de Ethereum:

• La primera generación es la arquitectura original de “PoW + EVM”, cuyo núcleo es que todos los nodos reejecutan directamente (Re-execution) todas las transacciones. Este modelo es seguro, universal y abierto, pero por ello mismo su escalabilidad queda limitada.

• La segunda generación es Ethereum PoS después de la “Merge” en 2022. El cambio del mecanismo de consenso alteró por completo el modelo de seguridad, el modelo de emisión y el sistema de staking de Ethereum, y además le dio al mercado una demostración: Ethereum tiene una capacidad de ingeniería muy alta para cambiar su motor central en un estado sin interrupciones.

• La tercera generación es, ahora, Lean Ethereum. Ya no se conforma con la división existente de “L1 se encarga del settlement, L2 se encarga de la expansión”, sino que integra en un mismo marco de reestructuración a largo plazo el rendimiento de L1, la verificación verificable (Proved Verification), la privacidad, la resistencia a lo cuántico, la estructura del estado y la arquitectura de clientes.

El origen de la hoja de ruta de Lean Ethereum

La hoja de ruta de Lean Ethereum se publicó en strawmap.org, un borrador público presentado primero por Justin Drake, investigador de la Fundación, en febrero de este año. Planifica siete actualizaciones de red hasta 2029. La palabra “strawmap” proviene de straw (paja); el documento se posiciona como un borrador modificable. También indica que es una herramienta de coordinación que aún está en curso, no un cronograma bloqueado; cualquier actualización todavía requiere investigación, pruebas, implementación en clientes y un consenso aproximado.

En esta visión, se trazan cinco objetivos estratégicos a largo plazo: lograr una mayor determinación final de L1 (Finality), alcanzar un rendimiento de L1 de 1 gigagas por segundo (en el estado límite, capaz de soportar TPS de nivel “decenas de miles”), la expansión de L2 con una visión de ecosistema a escala de teragas, seguridad integral mediante criptografía poscuántica, y transferencias de privacidad nativas en L1.

Al comparar con la situación actual, se percibe lo agresivo de estos objetivos. Según datos de Etherscan, actualmente el promedio de Ethereum L1 procesa solo unas 32 transacciones por segundo (alrededor de 2,7 millones al día); mientras que el objetivo de 1 gigagas implica que la capacidad de cómputo de L1 tendrá un estallido de cientos de veces. Es importante notar que, en el último año, la demanda on-chain de L1 realmente ha estado en una senda de crecimiento: el volumen diario de transacciones pasó de 1,4 millones en el mediados de 2025 y se recuperó de forma notable; desde 2026, la mayor parte del tiempo se ha mantenido entre 2 millones y 2,9 millones, llegando incluso a acercarse una vez a 3,6 millones durante los picos de mercado de abril y mayo. El lanzamiento de esta hoja de ruta justamente busca abordar esa demanda en recuperación de actividad on-chain.

Las marcas de tiempo también son bastante claras: Hegotá, prevista como la segunda actualización de 2026, es muy probable que sea el último hard fork “pre-Lean” de Ethereum. A partir de entonces, en teoría, cada actualización forma parte de esta reestructuración. Y la actualización más cercana, Glamsterdam, se espera que aporte un aumento considerable del límite de gas; originalmente se esperaba que iniciara en la primera mitad de 2026, pero hasta ahora no se ha puesto en marcha.

El cronograma también es uno de los temas más discutidos desde que se dio a conocer la hoja de ruta. Dankrad Feist, investigador principal de la Fundación Ethereum y proponente del plan de Danksharding de Ethereum, publicó en X diciendo que apoya esta strawmap, pero que un cronograma de 3 a 4 años es demasiado lento; con la tecnología actual de modelos de lenguaje a gran escala, esta actualización debería poder completarse en un año.

Gran salto técnico central: verificación verificable y reestructuración del estado

El núcleo técnico de Lean Ethereum consiste en cambiar el modo de verificación desde la raíz. Hoy, el modelo de seguridad de Ethereum es que cada nodo reejecute cada transacción para confirmar que el estado es correcto. El nuevo diseño incorpora la prueba STARK recursiva como componente nativo del protocolo: un probador realiza los cálculos pesados y los demás nodos solo necesitan verificar una prueba matemática concisa.

Esta elección también responde a otro problema: STARK usa criptografía basada en hash, y actualmente no hay una ruta conocida de ataques cuánticos; en cambio, el esquema de firmas vigente de Ethereum tiene riesgos asociados. Vitalik afirma que la prioridad de la seguridad poscuántica se “incrementa sustancialmente”, y la hoja de ruta planea reemplazar gradualmente los componentes frágiles frente a lo cuántico mediante firmas Winternitz, siendo el componente más urgente el hallar un diseño poscuántico para los blobs que L2 usa para reducir costos.

La capa de consenso también se modifica. En el Ethereum actual, las transacciones se registran en la cadena en solo una docena de segundos, pero para que exista finalidad (finalidad definitiva) se requieren aproximadamente 15 minutos. El nuevo diseño separa el “chain de bloques continuos” y la “finalidad” como dos tareas distintas: el objetivo es que los validadores puedan cerrar la decisión tras 1 o 2 rondas de votación, reduciendo esos 15 minutos a algo cercano al tiempo real. Además, existe una tarificación de gas multidimensional: operaciones, almacenamiento y transferencia de datos se calculan con tarifas separadas, como el agua y la electricidad por separado, en lugar de mezclar todo en una sola cuenta.

El cambio en la arquitectura del estado impacta directamente a los desarrolladores de aplicaciones. El estado puede entenderse como el libro mayor contable en tiempo real de Ethereum, donde se registran los saldos de todas las cuentas y los datos de los contratos inteligentes. Este libro solo se hará cada vez más grueso, y hoy todos los nodos completos deben mantener una copia completa, lo que mantiene altos los costos de almacenamiento on-chain.

El plan de Vitalik es realizar una segmentación estructural del almacenamiento: la “Dynamic State” actual (estado dinámico / núcleo esencial) se restringirá estrictamente al umbral de hardware de 2 TB, evitando su expansión ilimitada; al mismo tiempo, el protocolo abrirá una nueva “capa de almacenamiento de estado de tipo nuevo” (un “gran almacén”) con una capacidad de hasta 100 TB y mayor extensibilidad. En el panorama de 2030 descrito por Vitalik, la mayoría de los tokens (ERC-20), NFT y aplicaciones DeFi convencionales, si están dispuestos a reescribir los contratos para mudarse a ese “gran almacén” con arquitectura nueva, podrían ver que las comisiones de transacción bajen directamente más de diez veces. A nivel de protocolo no se fuerza ni se subsidia: solo se coloca la enorme diferencia de precios entre esas dos capas, y se deja al mercado decidir el momento de la migración según la conveniencia de las aplicaciones.

La posición de la privacidad también se redefine. Antes, la división de trabajo de Ethereum era: toda la actividad en la cadena es pública y transparente; los usuarios que quieren privacidad buscan por su cuenta protocolos de privacidad de terceros. En esta ocasión, Vitalik escribe: Privacy is no longer an afterthought, it is a first class goal, lo que significa que la privacidad pasa de ser algo “que el usuario instala” a ser parte de las normas de construcción: en el futuro, cada componente nuevo del protocolo se evaluará en la fase de diseño con una pregunta: ¿puede brindar funciones de privacidad sin intermediarios y resistentes a lo cuántico con un costo bajo? Si se puede lograr o no aún debe validarse, pero el criterio de evaluación ya quedó escrito en la hoja de ruta.

Controversia por reemplazar EVM: el pulso del ecosistema L2

Durante una década, el motor usado por Ethereum se llama EVM, y alrededor de él se han construido contratos, herramientas de desarrollo y lenguajes de programación de todo el mundo. Ahora, Vitalik propone cambiar ese motor, y la razón está relacionada con los STARK del punto anterior: para ayudar a generar pruebas matemáticas para las transacciones, usar EVM para ejecutar ese trabajo es costoso; cambiar a un motor más amigable para la prueba hará que salga mucho más barato.

Él menciona como candidatos dos arquitecturas: RISC-V y leanISA. El objetivo ideal de llegada (finalidad) es que el nuevo motor se convierta en el propio cuerpo del protocolo, mientras que EVM pase a ser una capa de traducción: los contratos antiguos seguirán funcionando, pero el nivel inferior primero se traducirá a instrucciones que el nuevo motor entienda para luego ejecutarse. Como cambiar el motor implica modificaciones relativamente más complejas, esta propuesta ha generado controversia desde que Vitalik lanzó por primera vez la idea de RISC-V en abril de 2025.

Offchain Labs, el equipo de desarrollo principal detrás de L2 Arbitrum, el mes pasado noviembre defendió públicamente que otra arquitectura, WebAssembly (WASM), es la mejor opción; pero en esta lista de candidatos que Vitalik presenta, WASM no aparece. ¿Por qué es importante esto? Porque Arbitrum es uno de los L2 más grandes de Ethereum, y su tecnología de contratos, Stylus, está construida sobre WASM.

Se puede entender así: si L1 cambia el motor, equivale a redefinir la “especificación de tipo de enchufe” de todo el ecosistema. Si el enchufe de tu dispositivo coincide, lo usas directamente; si no coincide, tendrás que pagar por un adaptador. El que se elija en la lista decide qué inversión de qué L2 puede conectarse sin problemas a la futura L1, y qué L2 tendrá que pagar el costo de adaptación.

Ethereum no tiene un mecanismo de votación para resolver esta discrepancia: si se cambia o por cuál se cambia, lo determina el consenso aproximado de los desarrolladores en la reunión All Core Devs, y si los equipos de cada cliente están dispuestos a ponerse manos a la obra para implementarlo. A la fecha, el cambio de motor sigue siendo un objetivo a largo plazo mencionado por Vitalik; la reunión de desarrolladores aún no ha llegado a ninguna conclusión oficial.

¿La hoja de ruta afectará al precio de ETH?

Al mapear la hoja de ruta técnica al precio de ETH, se pueden distinguir dos capas temporales.

La primera es la ruta de transmisión a nivel de mecanismo. Desde EIP-1559, en Ethereum, la tarifa base de cada transacción se destruye, por lo que el tamaño de la actividad de transacciones de L1 influye directamente en la dinámica de la oferta dinámica y el valor de settlement de ETH. Bajo este mecanismo, si se alcanza el objetivo de gigagas y el volumen de transacciones de L1 vuelve a subir con el aumento del throughput, el consumo de gas y el monto destruido se amplificarían al mismo tiempo. Esta es la vía más directa de transmisión entre la hoja de ruta y la fijación del precio de ETH. Pero conviene subrayar que esta ruta solo se sostiene si “la demanda regresa después del aumento de capacidad”: la capacidad en sí no crea automáticamente demanda.

La segunda es la diferencia temporal. La hoja de ruta se publica como un esfuerzo de ingeniería por fases durante 3 a 4 años; dentro de 2026, esta hoja de ruta no cambiará la realidad de Ethereum en ningún sentido. Es una promesa de dirección, y las promesas de dirección en el tiempo de Ethereum tienen un historial de retrasos: la Merge en sí se retrasó varios años respecto de las estimaciones tempranas. En otras palabras, esta hoja de ruta eleva el límite de capacidad a largo plazo de Ethereum, pero no aborda el problema de captura de valor de ETH en el mediano plazo; la crítica del analista Ignas apunta precisamente a eso: no incluye ajustes de la economía del token ETH en sí.

Lista de observación para la próxima década

Si se condensan los puntos anteriores, la respuesta final apunta a una misma estructura: esta strawmap aumenta el techo a largo plazo de Ethereum, pero no resuelve de inmediato el problema de captura de valor de ETH a mediano plazo; y no es un momento para perseguirlo con FOMO solo por el calendario de la hoja de ruta.

Más que intentar valorar la hoja de ruta en sí, lo más accionable es seguir algunos nodos que se pueden comprobar en el corto plazo:

• Si la actualización Glamsterdam puede iniciarse y completarse sin problemas, y si logra el aumento del límite de gas

• Si la demanda de blob puede continuar creciendo junto con la actividad de L2

• Si los ingresos por comisiones de L1 y el volumen de ETH destruido pueden mejorar

• Si el crecimiento de L2 puede retroalimentar a L1 vía pago de blobs y demanda de settlement

• Si el rendimiento relativo de ETH frente a BTC puede recuperarse

Estos indicadores corresponden cada uno a etapas de la hoja de ruta, y se pueden verificar semana a semana en las páginas de gráficos de Etherscan y en paneles públicos como DefiLlama. Cualquier cambio en cualquiera de estos indicadores se acerca más a la base para el pricing que el propio documento de la hoja de ruta. Cualquier cambio en cualquiera de estos indicadores le dirá al mercado antes que el propio documento de la hoja de ruta si esta reconstrucción de 3 a 4 años está cumpliéndose o si se está retrasando.