Gran actualización de Ethereum 2026: esta vez, dejar atrás el "progresismo"

Autor: Chloe, ChainCatcher

En las últimas dos semanas, Vitalik Buterin, fundador de Ethereum, ha publicado en X una serie de extensos artículos técnicos que abordan temas clave como la hoja de ruta de escalabilidad, resistencia a ataques cuánticos, abstracción de cuentas, reconstrucción de la capa de ejecución y aceleración del desarrollo con IA. A esto se le ha denominado el “Plan maestro de gran revisión de Ethereum 2026”. Detrás de estas publicaciones, la Fundación Ethereum ha lanzado un esquema preliminar llamado Strawmap, un marco de planificación que contempla llevar la capacidad de procesamiento de Ethereum L1 a 10,000 TPS para 2029.

Sin embargo, cuanto más ambiciosa es la hoja de ruta, mayor es la duda sobre su capacidad de cumplimiento, ya que históricamente Ethereum ha avanzado más lentamente de lo previsto. ¿Está Ethereum realmente listo para abandonar el gradualismo y embarcarse en una reestructuración radical?

Hoja de ruta Strawmap: Ethereum con 10,000 TPS en 2029

El investigador de la Fundación Ethereum, Justin Drake, publicó el 25 de febrero un esquema llamado Strawmap, que revela la visión y el calendario de futuras actualizaciones de Ethereum L1. La hoja de ruta establece cinco objetivos principales: rendimiento ultra rápido de L1, capacidad de gigagas en L1, expansión de teragas en L2, seguridad post-cuántica en L1 y transferencias privadas nativas en L1. La meta final es que L1 procese 10,000 transacciones por segundo y L2 alcance 10 millones de transacciones por segundo.

El plan prevé siete bifurcaciones, con ciclos de actualización de seis meses, que abarcan cambios en las capas de consenso, datos y ejecución. Vitalik Buterin, fundador de Ethereum, ha expresado su apoyo y en las últimas semanas ha publicado en X artículos que desglosan los aspectos centrales del esquema.

Enfoque estratégico: escalabilidad de Ethereum L1 y reconstrucción de la capa de ejecución

Vitalik argumenta que, a diferencia de los últimos años, centrados en rollups L2 y L1 liviano, la visión actual busca mantener una orientación a largo plazo mientras se aumenta significativamente la capacidad de escalado de L1 en el corto plazo.

1. Corto plazo: actualización Glamsterdam

En el corto plazo, la próxima actualización Glamsterdam introducirá listas de acceso a nivel de bloque (BALs) para permitir la verificación paralela, rompiendo el cuello de botella de procesamiento secuencial, y promoverá la separación entre proposers y constructores (Enshrined Proposer-Builder Separation, ePBS), optimizando el uso de los nodos en los slots de 12 segundos.

2. Largo plazo: evolución de ZK-EVM y Blob

Para la expansión a largo plazo, se apoyará en dos pilares: ZK-EVM y Blob. En la ruta ZK-EVM, se espera que a finales de 2026 unos pocos validadores adopten primero clientes ZK-EVM, y en 2027 se amplíe su uso y se refuercen las medidas de seguridad, con el objetivo de implementar un mecanismo de múltiples pruebas forzadas (3 de 5), donde un bloque requiere la validación de al menos tres de cinco sistemas de prueba.

En cuanto a Blob, PeerDAS (muestreo de disponibilidad de datos) continuará evolucionando para aumentar la capacidad de procesamiento de datos a aproximadamente 8 MB/s. La tecnología permite que los nodos verifiquen datos descargando solo fragmentos pequeños, mejorando el rendimiento y reduciendo los requisitos de hardware. Además, para soportar adopciones masivas, Ethereum planea almacenar los datos de los bloques directamente en Blob, reemplazando el costoso modelo de calldata que requiere almacenamiento permanente. Este cambio busca optimizar la estructura de datos y rediseñar la escalabilidad desde la capa de datos.

3. Reconstrucción de la capa de ejecución: cambio a árboles binarios de estado en lugar de EVM

Vitalik señala que el 80% de la ineficiencia en la verificación proviene de arquitecturas obsoletas. Según la propuesta EIP-7864, cambiar del actual árbol de estado en hexadecimal Keccak MPT a un árbol binario de estado reduciría la longitud de las ramas en un factor de cuatro, mejorando notablemente la eficiencia de datos:

• Ancho de banda: reducción de costos en aproximadamente 4 veces, un avance cualitativo para clientes ligeros como Helios.
• Velocidad de prueba: con BLAKE3, se acelera aproximadamente 3 veces; con variantes de Poseidon, hasta 100 veces.
• Optimización de acceso: el diseño de “páginas” de slots (64-256) permite que las transacciones ahorren más de 10,000 Gas al leer o escribir datos adyacentes.

Un plan aún más ambicioso es migrar la máquina virtual (VM). Actualmente, los ZK provienen en su mayoría de RISC-V; si EVM pudiera ejecutarse directamente en RISC-V, eliminaría la sobrecarga de traducción entre máquinas virtuales, mejorando la verificabilidad del sistema. La hoja de ruta contempla tres pasos:

1. Permitir que la nueva VM maneje los contratos precompilados existentes.
2. Permitir a los usuarios desplegar contratos en la nueva VM.
3. Finalmente, reescribir EVM como un contrato inteligente que funcione en la nueva VM.

Este enfoque garantiza compatibilidad hacia atrás, con un costo de transición limitado a la recalibración de tarifas Gas.

Hoja de ruta contra amenazas cuánticas: reforzar las 4 vulnerabilidades principales de Ethereum

Vitalik identifica cuatro puntos débiles en la seguridad cuántica de Ethereum:

1. Capa de consenso: firmas BLS

La sustitución de la capa de consenso está en etapas iniciales. Vitalik propone un esquema de “Lean consensus” que usa firmas basadas en hash (Hash-based) y STARKs para agregarlas y comprimirlas, logrando resistencia cuántica. Antes de implementar un “cadena ligera” completamente optimizada, se lanzará una versión “lean” que solo procesa entre 256 y 1024 firmas por slot, sin necesidad de STARKs, reduciendo la complejidad.

2. Disponibilidad de datos: KZG y STARKs

Para la disponibilidad de datos, Vitalik sugiere reemplazar las promesas KZG por STARKs con resistencia cuántica, aunque esto presenta desafíos:

• La falta de linealidad en STARKs dificulta el muestreo eficiente en 2D, por lo que Ethereum opta por una estrategia conservadora con DAS unidimensional (PeerDAS), priorizando la robustez.
• Los tamaños de las pruebas STARK son grandes, requiriendo técnicas como pruebas recursivas para reducir su volumen, lo que implica ingeniería compleja.

En resumen, con objetivos simplificados y fases de optimización, esta vía cuántica es factible, aunque requiere mucho trabajo.

3. Cuentas externas (EOA): firmas ECDSA

Dado que las firmas ECDSA son vulnerables a la computación cuántica, Vitalik propone que las cuentas externas se vuelvan contratos con abstracción nativa, permitiendo a los usuarios cambiar el esquema de firma por uno resistente a cuánticos sin abandonar las direcciones actuales.

4. Capa de aplicaciones: pruebas ZK con KZG o Groth16

El principal reto en la capa de aplicaciones es que las pruebas ZK cuánticas (STARKs) son muy costosas en Gas, aproximadamente 20 veces más que SNARKs, lo que las hace inviables para privacidad y L2. Vitalik propone un marco de validación (Validation Frame, EIP-8141) que permite agrupar muchas firmas y pruebas en off-chain, usando pruebas recursivas para comprimir datos de verificación de cientos de MB en una prueba STARK pequeña en la cadena, reduciendo costos y permitiendo verificaciones rápidas incluso en mempool, asegurando operaciones eficientes en la era cuántica.

IA como acelerador: completar la hoja de ruta de Ethereum 2030 en semanas

Además de las mejoras técnicas, Vitalik destaca que la IA está acelerando el desarrollo de Ethereum. Compartió un experimento donde, en dos semanas, un desarrollador construyó un prototipo de la hoja de ruta 2030 usando “vibe-coding”. Comentó: “Hace seis meses, esto era impensable; ahora, es tendencia.”

Él mismo probó con modelos como gpt-oss:20b en una laptop, generando código en una hora; con modelos más potentes como kimi-2.5, espera poder hacerlo en una sola pasada. La IA está transformando la velocidad de entrega de la hoja de ruta.

Propone que los beneficios de la IA se dividan en “mitad velocidad, mitad seguridad”, usando IA para generar casos de prueba, verificar formalmente módulos críticos y crear múltiples implementaciones independientes para comparación cruzada. Su juicio es que, en el futuro cercano, no será posible reemplazar toda la seguridad con un solo prompt, pero este proceso puede aumentar la eficiencia en 5 veces.

Finalmente, sugiere que la hoja de ruta de Ethereum podría completarse más rápido de lo esperado y con estándares de seguridad superiores. “Código sin bugs, que antes parecía una fantasía, ahora puede ser posible.” Si esto se hubiera dicho hace cinco años, en el contexto de Ethereum, sería impensable.

Retos y realidad: ritmo de entrega lento y desafíos

No obstante, cuanto más se divulguen estos complejos avances, más difícil será garantizar que Ethereum cumpla con sus promesas a tiempo.

Históricamente, Ethereum ha avanzado más lentamente de lo previsto. The Merge, inicialmente esperado para finales de 2020, se retrasó hasta septiembre de 2022; la implementación de EIP-4844 (Proto-Danksharding) también tomó años. Estos retrasos suelen deberse a auditorías de seguridad, coordinación entre múltiples clientes y gobernanza descentralizada.

Pero esta vez, el tiempo apremia. La competencia se acerca, las amenazas cuánticas son reales y la revolución productiva de la IA presiona a Ethereum a abandonar el gradualismo. En un punto de inflexión, las pequeñas iteraciones del pasado parecen insuficientes para alcanzar la visión de convertir a Ethereum en la capa de liquidación global.

Vitalik también ha señalado que esta transformación no es solo técnica, sino que requiere que la comunidad abandone dependencias de caminos tradicionales, defendiendo los valores de resistencia a la censura, código abierto, privacidad y seguridad (CROPS), y replanteando el diseño desde principios fundamentales.

Las hojas de ruta pueden tener un plan, pero la actualización del pensamiento no tiene un cronograma. Esa quizás sea la mayor dificultad para dejar atrás el gradualismo.