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

Autor: Chloe, ChainCatcher

Durante 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. Esto ha sido denominado por el público como el “Plan maestro de gran revisión de Ethereum 2026”. Detrás de estas publicaciones, se encuentra el esquema preliminar Strawmap, un marco de planificación que apunta a llevar la capacidad de transacción de Ethereum L1 a 10,000 TPS para 2029.

Sin embargo, cuanto más ambicioso es el plan, mayor es la duda sobre su capacidad de entrega, 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 alcanzará 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. Este plan 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 procesar 10,000 transacciones por segundo en L1 y 10 millones en L2.

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 ha expresado su apoyo, y en las últimas semanas ha publicado en X artículos técnicos que desglosan los aspectos centrales de esta hoja de ruta.

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, donde se priorizó L2 Rollups y L1 liviano, la visión actual busca mantener una orientación a largo plazo, pero con una mejora significativa en 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 soportar validación paralela, rompiendo el cuello de botella de procesamiento secuencial, y avanzará en la separación de 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

El escalado a largo plazo se apoya en dos pilares: ZK-EVM y Blob. En la vía ZK-EVM, se espera que a finales de 2026 unos pocos validadores adopten primero clientes ZK-EVM, y en 2027 se amplíe la adopción y se refuercen las medidas de seguridad, con el objetivo de implementar un mecanismo de “prueba múltiple 3-de-5”, donde un bloque requiere al menos tres de cinco sistemas de prueba para ser válido.

En la ruta Blob, PeerDAS (muestreo de disponibilidad de datos) continuará iterando para aumentar la capacidad de procesamiento de datos a aproximadamente 8 MB/s. La clave está en que los nodos solo necesitan descargar fragmentos de datos para verificar, lo que aumenta el rendimiento y reduce los requisitos de hardware. Además, para soportar adopciones masivas futuras, Ethereum migrará a almacenar los datos de los bloques directamente en Blob, reemplazando el costoso y permanente modelo de calldata. Esto busca optimizar la estructura de datos y redefinir 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 prueba de Ethereum proviene de su arquitectura obsoleta. Según EIP-7864, cambiar del actual árbol de estado Keccak en hexadecimal a un árbol binario de estado reducirá la longitud de las ramas en un factor de cuatro, mejorando significativamente 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 Poseidon, hasta 100 veces.
• Optimización de acceso: el diseño de “páginas” de almacenamiento (de 64 a 256 ranuras) permite que las transacciones ahorren más de 10,000 Gas al leer o escribir datos adyacentes.

Una propuesta aún más ambiciosa es migrar la máquina virtual (VM). Actualmente, los ZK-Proofs se escriben en RISC-V; si EVM pudiera ejecutarse directamente en RISC-V, se eliminarían las pérdidas por traducción entre máquinas virtuales, mejorando la verificabilidad del sistema. La hoja de ruta para esto incluye 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. Reescribir la EVM como un contrato inteligente que se ejecute en la nueva VM.

Este enfoque garantiza compatibilidad hacia atrás, con un costo final limitado a reajustar las tarifas de Gas.

Hoja de ruta contra amenazas cuánticas: cubrir las cuatro vulnerabilidades principales de Ethereum

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

1. Capa de consenso: firmas BLS

El reemplazo de la capa de consenso está en etapas iniciales: Vitalik propone un esquema de “consenso simplificado” (Lean consensus) que usa firmas basadas en hash y agregación con STARKs para resistencia cuántica. Antes de implementar completamente “consenso simplificado”, se lanzará una versión “ligera” 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, se propone reemplazar las “promesas KZG” por STARKs resistentes a cuánticos, aunque esto presenta desafíos: los STARKs no soportan muestreo 2D eficiente, por lo que Ethereum opta por una estrategia conservadora con DAS unidimensional (PeerDAS). Además, los STARKs generan pruebas de gran tamaño, requiriendo técnicas complejas como pruebas recursivas para reducir el tamaño de la prueba en la cadena. En resumen, la ruta cuántica es factible, pero requiere mucho trabajo técnico.

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 abstraigan en contratos inteligentes nativos, permitiendo a los usuarios cambiar los algoritmos de firma resistentes a cuánticos sin abandonar sus direcciones actuales.

4. Capa de aplicaciones: pruebas ZK basadas en KZG o Groth16

El principal reto en la capa de aplicaciones es que las pruebas ZK resistentes a cuánticos, como STARKs, son muy costosas en Gas, aproximadamente 20 veces más que SNARKs. Vitalik sugiere introducir un “Marco de Validación” (Validation Frame) mediante EIP-8141, que permita agrupar muchas firmas y pruebas complejas fuera de la cadena. La recursividad en las pruebas permitirá comprimir datos de verificación de cientos de MB en una prueba STARK pequeña en la cadena, ahorrando espacio y costos, y permitiendo verificaciones rápidas en mempool, asegurando que las aplicaciones puedan operar con bajo costo y alta seguridad en un escenario cuántico.

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 parecía imposible; ahora, es tendencia.”

Él mismo probó con su portátil un modelo GPT-OSS:20B, que en una hora generó el backend de un blog; con un modelo más potente como kimi-2.5, espera poder hacerlo en una sola vez. 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”: generando casos de prueba a gran escala, verificando formalmente módulos críticos y creando múltiples implementaciones independientes para comparación cruzada. Su juicio es que, en el futuro cercano, no será posible reemplazar un código seguro solo con un prompt, pero este proceso puede aumentar la eficiencia en un factor de cinco.

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. “Un código sin errores, que durante mucho tiempo fue una fantasía idealista, ahora quizás sea posible.” Si esto se hubiera dicho hace cinco años, en el contexto de Ethereum, sería casi impensable.

Ritmo de entrega lento y desafíos reales

No obstante, cuanto más se divulguen estos complejos avances técnicos, más incertidumbre hay sobre si Ethereum podrá cumplir 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 para Ethereum se acorta. La competencia se acerca, las amenazas cuánticas son reales, y la revolución productiva impulsada por la IA obliga 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 llamado a la comunidad a abandonar la dependencia de caminos tradicionales y a centrarse en principios fundamentales como resistencia a la censura, código abierto, privacidad y seguridad (CROPS), desde una perspectiva de primer principio en el diseño de aplicaciones.

Aunque la hoja de ruta técnica puede tener un cronograma, la actualización del pensamiento y la mentalidad no tiene una fecha fija. Esa quizás sea la mayor dificultad para dejar atrás el gradualismo.