De alguna manera noté que en Ethereum en los últimos años se ha formado una interesante tradición: en lugar de mejorar la máquina virtual en sí, los desarrolladores simplemente la rodean mediante contratos precompilados. Pero Vitalik no se detiene allí. Recientemente publicó un plan detallado de cómo rehacer todo desde cero.

La primera parte del plan se refiere al árbol de estado de Ethereum. Si simplificamos, es como un sistema de índices, a través del cual el sistema busca constantemente datos. El problema es que la estructura actual — el mismo árbol Merkle de Keccak de seis ramas — es demasiado volumosa. La EIP-7864, que propone Vitalik, la reemplaza por un árbol binario. En lugar de elegir entre seis direcciones, simplemente eliges izquierda o derecha. ¿El resultado? La longitud del árbol Merkle se reduce en cuatro veces. Para los clientes ligeros, esto significa una reducción significativa en los requisitos de ancho de banda.

Pero eso no es todo. Vitalik quiere cambiar también la función hash. En la mesa hay dos candidatos: Blake3, que ofrece una aceleración estable, y Poseidon, que teóricamente puede aumentar la eficiencia de las pruebas en decenas de veces, aunque la seguridad aún está en revisión. Este plan reemplaza efectivamente a los Árboles Verkle, que se discutieron durante años en la comunidad, pero perdieron popularidad debido a la amenaza de los cálculos cuánticos.

El segundo paso es aún más ambicioso: reemplazar la propia arquitectura de la EVM por RISC-V. La lógica es simple: si los sistemas de pruebas ZK ya entienden RISC-V, ¿por qué la máquina debe usar otro lenguaje? Al eliminar la capa de traducción, todo se acelera automáticamente. Vitalik planea tres etapas: primero, reescribir el 80% de los contratos precompilados en la nueva máquina virtual, luego permitir a los desarrolladores desplegar contratos directamente, y finalmente retirar la antigua EVM de la operación — pero no eliminarla, sino reescribirla como un contrato inteligente en la nueva máquina. Los contratos antiguos seguirán funcionando, como un motor con un motor reemplazable.

Vitalik afirmó que el árbol de estado y la máquina virtual en conjunto representan más del 80% de las limitaciones de la escalabilidad de Ethereum. Sin estos cambios, la escalabilidad en la era ZK simplemente no avanzará.

Pero no todos están de acuerdo. El equipo de Arbitrum Offchain Labs publicó una objeción técnica detallada. Su posición: RISC-V es bueno para las pruebas ZK, pero no necesariamente como formato para contratos. Hicieron una distinción entre el conjunto de instrucciones para la entrega de (dISA) y el conjunto para las pruebas (pISA). En su opinión, no deben ser iguales. Proponen WebAssembly para el nivel de contratos, y luego compilación a RISC-V para las pruebas. Ya lanzaron un prototipo en Arbitrum, y funciona. Además, señalaron el riesgo: las tecnologías ZK cambian rápidamente, y si ahora se fija RISC-V en la capa L1, ¿qué pasará en dos años?

Esta discusión ocurre en medio de un cambio mayor. Vitalik recientemente cuestionó la necesidad de una hoja de ruta separada para L2 en Ethereum. Curiosamente, L2 no entró en pánico, sino que comenzó a repensar activamente su papel. Si Ethereum mismo se vuelve más rápido, entonces L2 debe encontrar sus espacios únicos — no solo en escalabilidad, sino en escenarios de aplicación reales.

El propio Vitalik reconoció que aún no hay consenso sobre reemplazar la EVM. La reforma del árbol de estado avanzó más — la EIP-7864 ya tiene un proyecto concreto. Pero ¿el cambio a RISC-V? Eso todavía está en la hoja de ruta. Se esperaba que el hard fork Glamsterdam ocurriera en la primera mitad de 2026, seguido por Hegota. Los detalles específicos aún no están aprobados, pero la reforma del árbol de estado y la optimización del nivel de ejecución son direcciones definidas.

La historia de Ethereum siempre ha sido sobre lo posible. Desde la transición de PoW a PoS, desde L1 a Rollup — el sistema ya ha demostrado estar listo para desarmar motores a altitudes de diez mil metros. Esta vez, se trata de cosas más profundas: no agregar funciones, sino renovar los cimientos mismos. ¿Es esto una reparación cuidadosamente planificada, o un pozo que se hace más profundo? La respuesta llegará no antes de 2027. Pero una cosa está clara: Ethereum no planea ser un sistema viejo con parches. Esta misma controversia sobre cómo desarmar los parches y qué motor instalar — quizás sea más valiosa que cualquier conclusión.