Ethereum va a cambiar de motor

Esta vez se trata de algo más profundo, no de agregar nuevas funciones, sino de abrir y volver a verter los cimientos antiguos.

Por Gray Lobster, Deep Tide TechFlow

Los desarrolladores de Ethereum tienen una costumbre tácita: si pueden evitar tocar EVM, la evitan.

En los últimos años, cada vez que en la cadena se necesita una nueva operación criptográfica, la primera reacción de los desarrolladores no es implementarla en EVM, sino solicitar la adición de un “contrato precompilado”, una forma rápida de evitar la máquina virtual y codificar directamente en la capa del protocolo.

El 1 de marzo, Vitalik Buterin publicó un largo mensaje en X que rompió completamente esa barrera. Su declaración fue en esencia: el significado de Ethereum radica en su versatilidad; si EVM no es suficiente, debemos resolverlo de frente y crear una máquina virtual mejor.

Propuso dos soluciones concretas.

Primera solución: cambiar “estructura de datos”

El primer cambio afecta al árbol de estado de Ethereum. Esto se puede entender como el “sistema de índices de libros de contabilidad” de Ethereum, donde cada consulta de saldo o verificación de transacción requiere recorrer ese árbol.

El problema es que ahora ese árbol está demasiado “gordo”. Ethereum usa una estructura llamada “árbol Merkle de Keccak de seis ramas” (un nombre que suena a hechizo). La propuesta de Vitalik, EIP-7864, es reemplazarlo por un árbol binario más simple.

Por ejemplo: antes, consultar un dato requería decidir en una encrucijada de seis caminos; ahora solo hay izquierda y derecha. ¿Qué pasa? La longitud de las ramas Merkle se reduce a una cuarta parte. Para los clientes ligeros, la verificación requiere mucho menos ancho de banda.

Pero Vitalik no se conforma solo con cambiar la forma del árbol. También quiere cambiar “el tipo de letra en las hojas”, es decir, la función hash. Hay dos candidatos: Blake3 y Poseidon. Blake3 ofrece velocidad estable; Poseidon es más radical, teóricamente puede multiplicar por varias decenas la eficiencia de las pruebas, pero su seguridad aún necesita más auditorías.

Cabe destacar que esta solución en realidad reemplaza a los Verkle Trees, que habían sido la opción preferida en la comunidad durante años. Los Verkle Trees fueron la opción para la bifurcación dura de 2026, pero debido a que la criptografía de curvas elípticas en su base enfrenta amenazas de la computación cuántica, empezaron a perder popularidad desde mediados de 2024, y la solución de árboles binarios tomó ventaja.

Segunda solución: cambiar “la máquina virtual”, convertir EVM en un contrato inteligente

El segundo cambio es más audaz y polémico: reemplazar a largo plazo la EVM por una arquitectura RISC-V.

RISC-V es un conjunto de instrucciones de código abierto, originalmente sin relación con blockchain, pero ahora casi todos los sistemas de pruebas ZK lo usan. La lógica de Vitalik es simple: dado que los generadores de pruebas ya hablan RISC-V, ¿por qué mantener una máquina virtual que hable otro idioma y agregar una capa de traducción? Eliminando esa capa, la eficiencia aumenta.

Un intérprete RISC-V requiere solo unas pocas centenas de líneas de código. Vitalik dice que así debería ser la máquina virtual de blockchain.

Planea tres pasos: primero, usar la nueva VM para ejecutar contratos precompilados, reescribiendo el 80% actual con la nueva VM; segundo, permitir a los desarrolladores desplegar contratos en la nueva VM en paralelo con EVM; tercero, retirar EVM, pero no eliminarla, sino reescribirla como un contrato inteligente que funcione en la nueva VM, logrando compatibilidad total.

Los usuarios no necesitan cambiar de vehículo. Solo el motor se reemplaza silenciosamente, el volante sigue siendo el mismo.

¿Qué tan importante es esto? Vitalik da un número: el árbol de estado y la máquina virtual en conjunto representan más del 80% del cuello de botella en las pruebas de Ethereum. En otras palabras, si no se modifican estas dos partes, la expansión de Ethereum en la era ZK será estancada.

Arbitrum no está de acuerdo: no puedes usar una carretilla en el almacén y esperar que el repartidor también la use

Pero no todos están de acuerdo con esta historia.

En noviembre pasado, el equipo principal de desarrollo de Arbitrum, Offchain Labs, publicó una refutación técnica detallada. Cuatro investigadores argumentaron que: RISC-V es adecuado para pruebas ZK, pero no para el “formato de entrega” de contratos.

Hicieron una distinción clave: “conjunto de instrucciones de entrega” (dISA) y “conjunto de instrucciones de prueba” (pISA), que no tienen que ser iguales. Usar una carretilla en el almacén para mover mercancías es eficiente, pero eso no significa que el repartidor también deba usarla para entregarte en la puerta.

Offchain Labs propone usar WebAssembly (WASM) como formato de entrega de contratos, con una base sólida: WASM tiene alta eficiencia en hardware estándar; la mayoría de los nodos de Ethereum no usan chips RISC-V, por lo que forzar esa transición requiere simuladores; WASM tiene mecanismos maduros de verificación de seguridad de tipos; y su ecosistema de herramientas ya ha sido probado en miles de millones de entornos.

Lo más importante es que no solo hablan, sino que ya han implementado un prototipo en Arbitrum: usar WASM como formato de entrega, luego compilarlo a RISC-V para pruebas ZK. Cada capa hace su trabajo sin interferir.

También advierten sobre un riesgo importante: en el campo de las pruebas ZK, la tecnología evoluciona rápidamente. Recientemente, la implementación de RISC-V pasó de 32 bits a 64 bits. Si ahora se fija RISC-V en Ethereum L1, ¿qué pasa si en unos años aparece una arquitectura de pruebas aún mejor? Apostar a una tecnología en rápida evolución no es propio de Ethereum.

Un contexto más amplio: las L2 empiezan a “independizarse”

Para entender esta propuesta, hay que considerar un contexto más macro.

Hace un mes, Vitalik cuestionó públicamente si Ethereum aún necesita una “hoja de ruta específica para L2”, lo que provocó respuestas en el ecosistema L2. Ben Fisch, CEO de Espresso Systems, dijo a CoinDesk que en realidad, Vitalik quería decir que el propósito inicial de L2 era ampliar la capacidad de Ethereum, pero ahora que Ethereum mismo se vuelve más rápido, la función de L2 debe cambiar.

Curiosamente, las L2 no solo no entraron en pánico, sino que comenzaron a “des-ethereumizarse”. Jing Wang, cofundador de OP Labs, comparó las L2 con sitios web independientes, mientras que Ethereum sería el estándar de liquidación subyacente. Marc Boiron, CEO de Polygon, fue más directo: el verdadero desafío no es escalar, sino crear un espacio de bloque único para escenarios de pago reales.

En otras palabras, esta gran reforma en la capa de ejecución de Vitalik es una señal de una tendencia mayor: Ethereum está recuperando el control de sus capacidades centrales, y las L2 están encontrando o reafirmando su razón de ser de forma independiente.

¿Será posible?

Vitalik admite que el reemplazo de la máquina virtual aún no cuenta con consenso amplio en la comunidad de desarrolladores. La reforma del árbol de estado está más avanzada, con borradores y equipos en marcha para EIP-7864. Pero reemplazar EVM por RISC-V todavía está en la etapa de “hoja de ruta”, lejos de codificarse.

Sin embargo, la semana pasada, Vitalik dio una declaración que impresiona: Ethereum ya cambió una vez su motor a reacción en The Merge, y puede hacerlo unas cuatro veces más — incluyendo la reforma del árbol de estado, la simplificación del consenso, la verificación ZK-EVM y el reemplazo de la VM.

Se espera que la actualización Glamsterdam de Ethereum ocurra en la primera mitad de 2026, seguida por Hegota. Los detalles de estas bifurcaciones aún no están finalizados, pero la reforma del árbol de estado y la optimización de la capa de ejecución son las líneas principales confirmadas.

La historia de Ethereum nunca ha sido cuestión de “si se puede” o no. Desde la transición de PoW a PoS, de L1 a Rollups, ha demostrado tener la capacidad y el valor de desmontar motores en altitudes extremas.

Lo que se va a mover ahora es algo más profundo: no agregar funciones nuevas, sino abrir y volver a verter los cimientos antiguos. ¿Será esto una renovación cuidadosamente planificada o un pozo sin fondo que se vuelve cada vez más complejo? La respuesta probablemente se conocerá en 2027.

Pero hay una cosa segura: Ethereum no planea ser un “sistema viejo parcheado” en la era ZK. Cómo quitar parches y qué tipo de motor reemplazar, esta disputa en sí misma puede ser más valiosa que la conclusión.