Durante las últimas dos semanas, el fundador de Ethereum, Vitalik Buterin, ha publicado una serie de extensos artículos técnicos sobre X, que abarcan temas clave como hojas de ruta de escalado, resistencia a ataques cuánticos, abstracción de cuentas, refactorización de la capa de ejecución y desarrollo acelerado por IA. Estos artículos se han denominado "Hoja de Ruta de Renovación de Ethereum 2026". Tras esta serie de publicaciones se encuentra el lanzamiento simultáneo por parte de la Fundación Ethereum del marco de la hoja de ruta Strawmap, un documento que planea impulsar el rendimiento de Ethereum L1 a 10,000 TPS para 2029. Sin embargo, cuanto más ambiciosa es la hoja de ruta, más preguntas surgen sobre sus capacidades de entrega, dado el ritmo de entrega históricamente más lento de lo esperado de Ethereum. ¿Está Ethereum realmente listo para abandonar el "gradualismo" y adoptar una refactorización radical? Hoja de Ruta Strawmap: Ethereum alcanzará 10,000 TPS para 2029. El investigador de la Fundación Ethereum, Justin Drake, publicó una hoja de ruta llamada Strawmap el 25 de febrero, con el objetivo de revelar la visión para Ethereum L1 y su futuro cronograma de actualización. La hoja de ruta establece cinco objetivos clave: rendimiento ultrarrápido de L1, rendimiento de gigabits de L1, escalado de terabits de L2, seguridad postcuántica de L1 y transferencias de privacidad nativas de L1. El objetivo cuantitativo final es que L1 procese 10 000 transacciones por segundo y que L2 alcance los 10 millones de transacciones por segundo. Se espera que este plan se implemente mediante siete bifurcaciones, con un ciclo de actualización de seis meses, que abarcará cambios en la capa de consenso, la capa de datos y la capa de ejecución. El fundador de Ethereum, Vitalik Buterin, ha expresado su apoyo y ha publicado numerosos artículos técnicos sobre X durante las últimas dos semanas, desglosando las dimensiones principales de la hoja de ruta. Enfoque estratégico: Enfoque en el escalado de L1 de Ethereum y la reestructuración de la capa de ejecución. El argumento de Vitalik demuestra que, a diferencia de la estrategia de priorizar los rollups de L2 y minimizar la importancia de L1 en los últimos años, la visión actual es mejorar significativamente las capacidades de escalado de L1 a corto plazo, manteniendo al mismo tiempo una transición a largo plazo. 1. Progreso a corto plazo: La actualización de Glamsterdam forma parte del plan a corto plazo. La próxima actualización de Glamsterdam introducirá "Listas de Acceso a Nivel de Bloque (BAL)" para facilitar la verificación paralela, eliminando así el cuello de botella de eficiencia del procesamiento secuencial anterior. También promoverá la Separación Consagrada entre Proponente y Constructor (ePBS), optimizando el uso del intervalo de tiempo de 12 segundos por parte de los nodos. 2. Progreso a largo plazo: Evolución de ZK-EVM y Blob. El escalamiento a largo plazo se sustenta en dos pilares: ZK-EVM y Blob. En el camino hacia ZK-EVM, se espera que un pequeño número de validadores adopte el cliente ZK-EVM para finales de 2026, con un aumento de la tasa de adopción y un refuerzo de la seguridad a partir de 2027. El objetivo final es lograr un "mecanismo de prueba múltiple obligatorio 3 de 5", lo que significa que un bloque debe ser verificado por al menos tres de los cinco sistemas de prueba para ser válido.En la ruta de desarrollo 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 esencia de esta tecnología reside en que permite a los nodos completar la verificación descargando solo una pequeña cantidad de fragmentos de datos, lo que aumenta significativamente el rendimiento y reduce eficazmente la barrera de hardware para los nodos. Por otro lado, para satisfacer las necesidades de la futura adopción a gran escala, la red principal de Ethereum cambiará al almacenamiento de datos de bloques directamente en el espacio Blob, reemplazando el modelo de datos de llamada, anteriormente costoso y de almacenamiento permanente. Este cambio busca principalmente optimizar la estructura de transporte de datos, redefiniendo la ruta de escalado de Ethereum desde la capa de datos. 3. Reestructuración de la capa de ejecución: Cambio a un árbol de estados binarios para reemplazar EVM. Vitalik señaló que el 80 % de los cuellos de botella actuales en la eficiencia de las pruebas de Ethereum se deben a una arquitectura obsoleta. Según EIP-7864, se espera que, tras cambiar del actual "árbol de estados hexadecimal Keccak MPT" a un "árbol de estados binario", la longitud de la rama se reduzca cuatro veces. Esta transformación traerá mejoras significativas en la eficiencia de los datos: — Ancho de banda: Los costos se reducirán aproximadamente cuatro veces, un salto cualitativo para clientes ligeros como Helios; — Velocidad de prueba: Aproximadamente tres veces más rápida con el cálculo de BLAKE3; potencialmente hasta 100 veces más rápida con la variante Poseidon; — Optimización del acceso: El diseño de "página" de ranuras de almacenamiento (64-256 ranuras) permite a las DApps ahorrar más de 10 000 gas por transacción al leer y escribir datos adyacentes. Una propuesta más ambiciosa es la migración a máquinas virtuales (VM). Actualmente, los probadores ZK se escriben principalmente en RISC-V. Si la EVM puede ejecutarse directamente en RISC-V, eliminando la sobrecarga de traducción entre las dos capas de la máquina virtual, la capacidad de prueba de todo el sistema mejorará considerablemente. La ruta de implementación actual se planifica en tres pasos: 1. Primero, permitir que la nueva máquina virtual (VM) se haga cargo de los contratos precompilados existentes; 2. Luego, permitir que los usuarios implementen nuevos contratos de VM; 3. Finalmente, reescribir la propia EVM como un contrato inteligente que se ejecuta en la nueva VM. Esta medida garantiza la retrocompatibilidad, y el costo final de la conversión solo requiere una recalibración de las tarifas de gas. Hoja de ruta de resistencia a amenazas cuánticas: Abordando las cuatro principales vulnerabilidades técnicas de Ethereum. En cuanto al problema crítico de la seguridad L1 post-cuántica, Vitalik mencionó explícitamente en su artículo técnico que Ethereum actualmente presenta cuatro vulnerabilidades cuánticas, a saber: 1. Capa de consenso: La ruta de reemplazo para la capa de consenso de firmas BLS está tomando forma: Vitalik propuso el esquema de "consenso Lean", que introduce variantes de firma basadas en hash y las combina con STARK para la agregación y compresión, logrando así resistencia a los ataques cuánticos.Sin embargo, Vitalik añadió que antes de implementar un consenso simplificado completo, se lanzará primero una versión de cadena utilizable simplificada. Cada ranura solo necesitará procesar de 256 a 1024 firmas y, por el momento, puede operar sin agregación de STARK, lo que reduce significativamente el umbral de ingeniería. 2. Disponibilidad de datos: Compromisos y pruebas de KZG. En cuanto a la disponibilidad de datos, Vitalik propuso reemplazar los "compromisos de KZG" existentes con "STARKs resistentes a la cuántica", pero esto presenta dos desventajas importantes: primero, los STARKs carecen de la linealidad de KZG, lo que dificulta el soporte de un muestreo eficiente de datos 2D. Por lo tanto, Ethereum ha optado por una ruta DAS 1D más conservadora (como PeerDAS), priorizando la robustez de la red en lugar de buscar un escalamiento extremo. segundo, debido al gran tamaño de las pruebas de STARK, los desarrolladores deben resolver el problema de ingeniería de que "las pruebas sean más grandes que los datos" mediante ingeniería compleja, como las pruebas recursivas. En resumen, Vitalik cree que, al simplificar los objetivos técnicos y optimizar por etapas, esta vía de resistencia cuántica sigue siendo técnicamente viable, pero la carga de trabajo de ingeniería requerida es enorme. 3. Titular de Cuenta Externa (EOA): En cuanto a la protección de los Titulares de Cuenta Externa (EOA) en las firmas ECDSA, dado que las firmas ECDSA actuales son extremadamente vulnerables a las computadoras cuánticas, Vitalik prefiere utilizar la "abstracción de cuenta nativa" para contractualizar todas las cuentas, lo que permite a los usuarios cambiar con flexibilidad entre algoritmos de firma resistentes a la cuántica sin abandonar las direcciones de billetera existentes. 4. Capa de Aplicación: Pruebas ZK basadas en KZG o Groth16. Finalmente, en la capa de aplicación, el principal desafío es el altísimo coste del gas de las pruebas STARK resistentes a la cuántica, aproximadamente 20 veces superior al de las SNARK actuales, lo cual resulta demasiado caro para los protocolos de privacidad y la capa 2. Vitalik propone introducir un "Marco de Validación" a través de EIP-8141 para agregar una gran cantidad de firmas y pruebas complejas fuera de la cadena. Al aprovechar la tecnología de prueba recursiva, los datos de verificación, que originalmente ocupaban cientos de megabytes, pueden comprimirse en una pequeña prueba STARK en la cadena. Esto no solo ahorra espacio en bloque, sino que también reduce significativamente los costos de uso. La verificación puede incluso completarse instantáneamente en la etapa de Mempool, lo que permite a los usuarios operar diversas aplicaciones descentralizadas de forma rentable y eficiente, incluso en la era de las amenazas cuánticas. IA como acelerador: Hoja de ruta de Ethereum 2030 completada en semanas. Además de la actualización de la arquitectura técnica, los tuits recientes de Vitalik enfatizaron que la IA está acelerando el desarrollo de Ethereum. Retuiteó un experimento de desarrolladores que "construyeron un prototipo de la hoja de ruta de Ethereum 2030 en dos semanas utilizando vibe-coding", comentando: "Hace seis meses, esto ni siquiera era posible; ahora se ha convertido en tendencia".Incluso el propio Vitalik lo probó. Con una computadora portátil con el modelo gpt-oss:20b, completó el código backend del blog en una hora; con el más potente kimi-2.5, esperaba que incluso pudiera completarse de una sola vez. Cabe señalar que las mejoras de eficiencia de la IA no son lineales, lo que modifica la velocidad de entrega de la hoja de ruta de Ethereum. En respuesta, aboga por asignar la mitad de los beneficios de la IA a la velocidad y la otra mitad a la seguridad, utilizando la IA para generar casos de prueba a gran escala, verificar formalmente los módulos principales y generar múltiples implementaciones independientes de la misma lógica para realizar comparaciones cruzadas. La evaluación de Vitalik es que, en el futuro previsible, no se puede cambiar un prompt por código altamente seguro; la lucha contra errores e inconsistencias en la implementación seguirá existiendo, pero este proceso se puede quintuplicar. Finalmente, también propuso la posibilidad de que la hoja de ruta de Ethereum se complete más rápido de lo esperado y con estándares de seguridad más altos. «El código sin errores, considerado durante mucho tiempo una fantasía idealista, podría ahora convertirse en una posibilidad». Esta afirmación habría sido casi impensable en el contexto del desarrollo de Ethereum hace cinco años. El lento ritmo de entrega y los desafíos del mundo real son simplemente parte de los continuos esfuerzos de la hoja de ruta de Ethereum por revelar tanto contenido técnico complejo. La posibilidad de que estas promesas se cumplan a tiempo es un problema ineludible. Históricamente, el ritmo de entrega de Ethereum siempre ha sido más lento de lo esperado. La fusión, inicialmente prevista para finales de 2020, se retrasó hasta septiembre de 2022; la implementación de EIP-4844 (Proto-Danksharding) también tardó varios años. Estos retrasos suelen deberse a factores como las auditorías de seguridad, la coordinación multicliente y la gobernanza descentralizada. Sin embargo, esta vez, a Ethereum no le queda mucho tiempo para su enfoque gradual. La creciente presión de la competencia, el desafío real de la mecánica cuántica y la revolución de la productividad impulsada por la IA están obligando a Ethereum a abandonar por completo su "gradualismo". En un punto de inflexión histórico donde "no avanzar significa quedarse atrás", las iteraciones graduales y graduales del pasado podrían ya no ser suficientes para sustentar la visión de Ethereum de convertirse en una capa de liquidación global. Y Vitalik… Llamadas recientes destacan que esta transformación no es una mera reestructuración técnica; exige que la comunidad abandone por completo las dependencias de ruta en la capa de aplicación, defendiendo los principios fundamentales de resistencia a la censura, código abierto, privacidad y seguridad (CROPS) y reiniciando el diseño de aplicaciones desde sus principios básicos. La tecnología puede tener una hoja de ruta, pero la actualización del pensamiento no tiene un calendario de bifurcación; este podría ser el paso más difícil para decir adiós al "gradualismo". [ChainCatcher]