Autor: Chloe, ChainCatcher
Durante las últimas dos semanas, Vitalik Buterin, fundador de Ethereum, publicó una serie de artículos técnicos extensos en X, abordando temas centrales como la hoja de ruta de escalabilidad, la resistencia a ataques cuánticos, la abstracción de cuentas, la reestructuración de la capa de ejecución y la aceleración del desarrollo mediante IA, lo que ha sido denominado por el exterior como el "plan de gran renovación de Ethereum para 2026". Detrás de esta serie de publicaciones se encuentra el marco Strawmap lanzado simultáneamente por la Fundación Ethereum, un documento que planea elevar el rendimiento de Ethereum L1 a 10.000 TPS para 2029.
Sin embargo, cuanto más ambicioso es el plan, más crecen las dudas sobre su capacidad de cumplimiento, ya que, al revisar el historial, el ritmo de entrega de Ethereum siempre ha sido más lento de lo previsto. ¿Está realmente Ethereum listo para dejar atrás el “gradualismo” y dar paso a una reestructuración radical?
Strawmap de ruta: Ethereum alcanza 10000 TPS en 2029
El investigador de la Ethereum Foundation, Justin Drake, publicó el 25 de febrero un esquema de ruta denominado Strawmap, que busca revelar la visión y el calendario de actualizaciones futuras de Ethereum L1. Este plan establece cinco objetivos principales “estrellas polares”: rendimiento extremadamente rápido de L1, capacidad de throughput de gigagas en L1, escalabilidad de teragas en L2, seguridad post-cuántica de L1 y transferencias privadas nativas en L1. Los objetivos cuantitativos finales son de 10.000 transacciones por segundo en L1 y 10 millones de transacciones por segundo en L2.
Este plan se espera que avance a través de 7 bifurcaciones, con un ciclo de actualización cada 6 meses, abarcando cambios en las capas de consenso, datos y ejecución. Al respecto, el fundador de Ethereum, Vitalik Buterin, ha expresado su apoyo y ha publicado extensos artículos técnicos en X durante las últimas dos semanas, desglosando las dimensiones clave del roadmap.
Enfoque estratégico: centrarse en la escalabilidad de Ethereum L1 y la reestructuración de la capa de ejecución
El argumento de Vitalikdemuestra: a diferencia de la estrategia de los últimos años, que priorizaba L2 Rollup y minimizaba L1, la visión actual es mantener la transición a largo plazo mientras se mejora significativamente la capacidad de escalabilidad de L1 a corto plazo.
1. Proceso a corto plazo: Actualización Glamsterdam
En la planificación a corto plazo, la próxima actualización Glamsterdam introducirá "Listas de acceso a nivel de bloque (Block-Level Access Lists, BALs)" para respaldar la verificación paralela, superando el cuello de botella de eficiencia del procesamiento secuencial anterior, y avanzando simultáneamente en la separación nativa de propuesta y construcción (Enshrined Proposer-Builder Separation, ePBS), optimizando la utilización de los nodos para los intervalos de 12 segundos.
2. Proceso a largo plazo: Evolución de ZK-EVM y Blob
La expansión a largo plazo se sustenta en dos pilares principales: ZK-EVM y Blob. En la ruta de ZK-EVM, se espera que a finales de 2026, un pequeño número de validadores adopten inicialmente clientes ZK-EVM; a partir de 2027, se aumentará la proporción y se fortalecerá la seguridad, con el objetivo final de lograr un mecanismo de prueba múltiple obligatorio "3 de 5", es decir, un bloque solo se considerará válido si es verificado por al menos tres de cinco sistemas de prueba.
En la hoja de ruta de Blob, PeerDAS (muestreo de disponibilidad de datos) continuará iterando con el objetivo de aumentar la capacidad de procesamiento de datos a aproximadamente 8 MB/s. La tecnología clave permite que los nodos realicen la validación descargando solo fragmentos pequeños de datos, reduciendo significativamente el umbral de hardware necesario mientras aumenta enormemente el rendimiento. Por otro lado, para satisfacer la demanda futura de adopción a gran escala, la red principal de Ethereum migrará hacia el almacenamiento directo de los datos de los bloques en el espacio Blob, reemplazando el antiguo modelo de calldata, que era costoso y requería almacenamiento permanente. Este cambio tiene como principal objetivo optimizar la estructura de carga de datos y redefinir la ruta de escalabilidad de Ethereum desde el nivel de datos.
3. Reestructuración de la capa de ejecución: cambiar al árbol de estado binario en lugar del EVM
Vitalik 指出, el cuello de botella actual de eficiencia de prueba de Ethereum proviene en un 80 % de una arquitectura obsoleta. Según EIP-7864, se espera que al cambiar del actual "árbol de estado MPT Keccak hexadecimal" al "árbol de estado binario", la longitud de las ramas se reduzca eficazmente en 4 veces. Este cambio traerá una mejora significativa en la eficiencia de datos:
Ancho de banda de datos: reducción de costos de aproximadamente 4 veces, lo que supone un salto cualitativo para clientes ligeros como Helios.
Velocidad de prueba: si se utiliza BLAKE3, la velocidad aumenta aproximadamente 3 veces; si es una variante Poseidon, el aumento potencial puede alcanzar 100 veces.
Optimización de depósito y retiro: El diseño del “bloque” de ranuras de almacenamiento (ranuras 64–256) permite que los dapps ahorren más de 10,000 Gas por transacción al leer y escribir datos adyacentes.
Más ambiciosoel propuesto movimiento de la VM (máquina virtual), actualmente los probadores ZK se escriben principalmente en RISC-V; si la EVM pudiera ejecutarse directamente en RISC-V, eliminando la pérdida de traducción entre las dos capas de máquinas virtuales, la probabilidad del sistema completo aumentaría significativamente. La ruta de implementación actual se planea en tres pasos:
1. Primero, permita que el nuevo VM asuma los contratos precompilados existentes
2. Volver a habilitar la implementación de nuevos contratos VM por parte de los usuarios
3. Reescribir finalmente el propio EVM como un contrato inteligente que se ejecuta en una nueva VM.
This ensures backward compatibility, with the final conversion cost requiring only a gas fee recalibration.
Hoja de ruta contra amenazas cuánticas: cerrar las 4 vulnerabilidades técnicas clave de Ethereum
En relación con la cuestión clave de la seguridad post-cuántica L1, Vitalik en un artículo técnico detallado mencionó explícitamenteque Ethereum actualmente tiene cuatro puntos vulnerables a la computación cuántica, que son los siguientes:
1. Capa de consenso: firmas BLS
Ya se ha esbozado una ruta de reemplazo para la capa de consenso: Vitalik propone la solución “Lean consensus”, que introduce una variante de firma basada en hash, combinada con STARKs para compresión y agregación, con el fin de lograr resistencia cuántica. Sin embargo, Vitalik añade que antes de la implementación completa de “Lean consensus”, se lanzará una versión “Lean usable chain” que solo necesitará procesar entre 256 y 1.024 firmas por slot, operando temporalmente sin agregación STARK, reduciendo significativamente la barrera técnica.
2. Disponibilidad de datos: Compromisos y pruebas KZG
En cuanto a la disponibilidad de datos, Vitalik propone reemplazar los "compromisos KZG" existentes con "STARKs resistentes a la computación cuántica", pero esto enfrenta dos trade-offs:
En primer lugar, los STARKs carecen de la propiedad lineal de KZG, lo que dificulta el soporte de muestreo 2D eficiente; por ello, Ethereum optó por una ruta más conservadora de DAS 1D (como PeerDAS), priorizando la robustez de la red sobre la expansión máxima.
En segundo lugar, debido a que las pruebas STARK son de gran tamaño, los desarrolladores deben resolver el problema de ingeniería de que "la prueba es más grande que los datos" mediante técnicas complejas como pruebas recursivas. En resumen, Vitalik considera que, al simplificar los objetivos técnicos y optimizarlos por etapas, esta ruta抗量子 sigue siendo viable desde el punto de vista de la ingeniería, pero requiere una cantidad considerable de trabajo de ingeniería.
3. Cuenta externa poseída (EOA): firma ECDSA
En cuanto a la protección de las cuentas externas (EOA), dado que las firmas ECDSA actuales son extremadamente vulnerables ante computadoras cuánticas, Vitalik prefiere convertir todas las cuentas en contratos mediante "abstracción de cuenta nativa (native AA)", permitiendo a los usuarios cambiar flexiblemente los algoritmos de firma resistentes a la computación cuántica sin tener que abandonar sus direcciones de billetera actuales.
4. Capa de aplicación: pruebas ZK que dependen de KZG o Groth16
Finalmente, en el nivel de aplicación, el principal desafío es que el costo de Gas de las pruebas STARK resistentes a la computación cuántica es extremadamente alto, aproximadamente 20 veces mayor que el de los SNARKs actuales, lo que resulta demasiado costoso para protocolos de privacidad y L2. Vitalik propone introducir mediante EIP-8141 un “marco de validación (Validation Frame)” que permita agrupar en off-chain una gran cantidad de firmas y pruebas complejas.
Mediante la técnica de prueba recursiva, los datos de verificación que originalmente alcanzaban cientos de MB se pueden comprimir finalmente en una prueba STARK extremadamente pequeña en la cadena, no solo ahorrando espacio en los bloques, sino también reduciendo significativamente los costos de uso, e incluso permitiendo la verificación en tiempo real en la etapa de Mempool, lo que permite a los usuarios operar diversas aplicaciones descentralizadas de forma económica y eficiente en la era de las amenazas cuánticas.
AI como acelerador: completar la hoja de ruta de Ethereum 2030 en semanas
Además de la actualización de la arquitectura técnica, el reciente tweet de Vitalik enfatiza que la IA está acelerando el proceso de desarrollo de Ethereum. Él compartió un experimento de un desarrollador que construyó un prototipo de la hoja de ruta de Ethereum 2030 en dos semanas mediante "vibe-coding", y comentó: "Hace seis meses, esto ni siquiera estaba dentro del rango de lo posible; ahora se ha convertido en una tendencia."
Incluso Vitalik lo probó personalmente: utilizó un modelo gpt-oss:20b ejecutado en una laptop y completó el código del backend del blog en una hora; si usara el más potente kimi-2.5, espera poder hacerlo “de una sola vez”. Se puede decir que la mejora de eficiencia por parte de la IA ya no es lineal, sino que está cambiando la velocidad de entrega de la hoja de ruta de Ethereum.
Para ello, propone asignar "la mitad de los beneficios de la IA a la velocidad y la mitad a la seguridad", utilizar la IA para generar grandes conjuntos de casos de prueba, realizar verificación formal de módulos clave y generar múltiples implementaciones independientes para la misma lógica con el fin de realizar comparaciones cruzadas. La evaluación de Vitalik es que, en el futuro previsible, no puedes intercambiar un solo prompt por un código de programa de alta seguridad; aún existirá la lucha contra errores e inconsistencias de implementación, pero este proceso puede mejorar hasta cinco veces.
Finalmente, también planteó la posibilidad de que la hoja de ruta de Ethereum se complete a un ritmo más rápido del esperado por el exterior, y que los estándares de seguridad superen las expectativas externas. “El código de programa libre de errores, durante mucho tiempo considerado una ilusión idealista, ahora podría volverse posible.” Esta frase, si se hubiera dicho hace cinco años en el contexto del desarrollo de Ethereum, habría sido casi imposible.
Lentitud en el ritmo de entrega y desafíos reales
Sin embargo, al hacer públicos tantos contenidos técnicos complejos en el mercado, la hoja de ruta de Ethereum siempre debe enfrentar la posibilidad de cumplir con estos compromisos a tiempo.
Según los registros históricos, el ritmo de entrega de Ethereum siempre ha sido más lento de lo previsto. The Merge se retrasó desde la expectativa inicial de “finales de año” en principios de 2020 hasta septiembre de 2022; la implementación de EIP-4844 (Proto-Danksharding) también tomó varios años. Estos retrasos suelen deberse a factores como auditorías de seguridad, coordinación entre múltiples clientes y gobernanza descentralizada.
Pero esta vez, el tiempo tranquilo para Ethereum se está agotando. La presión creciente de los competidores, el desafío real de la amenaza cuántica y la revolución de productividad impulsada por la IA están obligando a Ethereum a despedirse por completo del “gradualismo”; en este punto histórico de “avanzar o retroceder”, las iteraciones suaves y paulatinas del pasado quizás ya no puedan sostener la visión de convertir a Ethereum en una capa global de liquidación.
And Vitalik his recent appealalso highlights that this transformation is not merely a technical restructuring; he calls on the community to completely abandon path dependency at the application layer and uphold the core principles of censorship resistance, open source, privacy, and security (CROPS), rethinking application design from first principles.
La tecnología puede tener una hoja de ruta, pero la actualización de la mentalidad no tiene un cronograma de bifurcación; quizás este sea el paso más difícil para dejar atrás el "gradualismo".