Ethereum va a cambiar de motor

Escrita por: Dragón gris, Deep Tide TechFlow

Los desarrolladores de Ethereum tienen una costumbre tácita: si pueden evitar usar 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 saltarse la máquina virtual y codificar directamente en la capa de protocolo.

El 1 de marzo, Vitalik Buterin publicó una larga publicación en X que rompió por completo esa barrera. Sus palabras principales fueron: el significado de Ethereum radica en su versatilidad; si EVM no es suficiente, debemos resolver ese problema de frente, creando una máquina virtual mejor.

Proporcionó 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 índice de libros contables” 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 Patricia 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 recorrer un cruce 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 de datos 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 del árbol”, es decir, la función hash. Hay dos candidatos: Blake3 y Poseidon. Blake3 ofrece velocidad estable; Poseidon es más radical, teóricamente puede mejorar la eficiencia de las pruebas en decenas de veces, pero aún necesita más auditorías de seguridad.

Cabe destacar que esta propuesta en realidad reemplaza a los Verkle Trees, que habían sido la opción preferida en la comunidad para la bifurcación dura de 2026. Los Verkle Trees perdieron popularidad desde mediados de 2024 debido a la amenaza de la criptografía de curvas elípticas basada en computación cuántica, y la solución binaria 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 la EVM por una arquitectura RISC-V a largo plazo.

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 traducir entre ellas? Eliminando esa capa de traducción, 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 máquina virtual para ejecutar contratos precompilados, reescribiendo el 80% 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 cambia silenciosamente, el volante sigue siendo el mismo.

¿Qué tan importante es esto? Vitalik da un número: más del 80% del cuello de botella en las pruebas de Ethereum proviene del árbol de estado y la máquina virtual. Es decir, si no se modifican esas dos partes, la expansión en la era ZK será limitada.

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 la “forma de entrega” de contratos.

Hicieron una distinción clave: “conjunto de instrucciones de entrega” (dISA) y “conjunto de instrucciones de prueba” (pISA) 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 ese cambio requiere un emulador; además, WASM tiene mecanismos maduros de verificación de seguridad de tipos; su ecosistema de herramientas ya ha sido probado en miles de millones de entornos de ejecución.

Lo más importante es que no solo hablan, sino que ya han implementado un prototipo en Arbitrum: usar WASM como formato de entrega y compilarlo a RISC-V para pruebas ZK. Cada capa trabaja por separado, 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 cambió 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 prueba mejor? Apostar a un objetivo en rápida evolución no es típico de Ethereum.

Un contexto más amplio: las soluciones L2 comienzan 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, la intención de Vitalik es que, dado que Ethereum ahora puede escalar más rápido, la función de L2 debe cambiar.

Curiosamente, los L2 no solo no entraron en pánico, sino que comenzaron a “des-ethereumizarse”. Jing Wang, cofundador de OP Labs, comparó los 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 reales como pagos.

En otras palabras, la gran tendencia es que la reforma en la capa de ejecución de Vitalik refleja un movimiento más amplio: Ethereum está recuperando el control de sus capacidades centrales, mientras que los L2 están siendo forzados o, en realidad, finalmente encuentran su razón de ser independiente.

¿Será posible?

Vitalik admite que la sustitución 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 madura, 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 ser código.

Sin embargo, la semana pasada, Vitalik dio una declaración que impresiona: Ethereum ya cambió una vez su motor a reacción en el vuelo (refiriéndose a The Merge), y puede hacerlo unas cuatro veces más: árbol de estado, consenso simplificado, verificación ZK-EVM, reemplazo de la máquina virtual.

Se espera que la actualización Glamsterdam de Ethereum se implemente en la primera mitad de 2026, seguida por Hegota. Los detalles de las 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 PoW a PoS, de una capa principal a Rollups, ha demostrado tener la capacidad y el valor de desmontar motores en altitudes elevadas.

Lo que se pretende ahora es algo más profundo: no agregar funciones nuevas, sino abrir y reconstruir los cimientos antiguos. ¿Será esto una renovación planificada y profunda, o un agujero sin fondo que se vuelve más complejo? La respuesta probablemente se conocerá en 2027.

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