Autor: Gris Lobster, Deep Tide TechFlow
Los desarrolladores de Ethereum tienen una costumbre tácita: si no es necesario, no tocan EVM.
En los últimos años, cada vez que en la cadena se requiere 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ó en X un largo mensaje que rompió completamente esa barrera. Su declaración principal fue: 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.
Presentó 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, que se recorre cada vez que alguien consulta saldo o verifica transacciones.
El problema es que, actualmente, ese árbol es 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 varias ramas 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 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 una velocidad estable.
- Poseidon es más agresivo, y en teoría puede mejorar la eficiencia de las pruebas en decenas de veces, aunque su seguridad aún necesita más auditorías.
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 que la criptografía de curvas elípticas en la base enfrentaba amenazas de la computación cuántica, y la solución de árboles binarios tomó ventaja.
Segunda solución: cambiar “máquina virtual”, convertir EVM en un contrato inteligente
El segundo cambio es más audaz y polémico: reemplazar a largo plazo EVM por una arquitectura RISC-V.
RISC-V es un conjunto de instrucciones de código abierto, que originalmente no tenía relación con blockchain, pero ahora casi todos los sistemas de pruebas ZK lo usan. La lógica de Vitalik es simple: si los generadores de pruebas ya están usando RISC-V, ¿por qué mantener una máquina virtual que interprete otra cosa y luego traduzca? Eliminando esa capa de traducción, la eficiencia aumenta.
Un intérprete RISC-V requiere solo unos pocos cientos 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% de estos en la nueva VM; segundo, permitir a los desarrolladores desplegar contratos en la nueva VM en paralelo con EVM; tercero, retirar EVM, pero no eliminarlo, sino reescribirlo 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 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.
Discrepancia con Arbitrum: no puedes usar un montacargas en el almacén y esperar que el repartidor también lo haga
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) no tienen que ser iguales. Tu almacén puede usar un montacargas para mover mercancías de manera eficiente, pero eso no significa que el repartidor también deba usar uno para entregarlas en tu puerta.
Offchain Labs propone usar WebAssembly (WASM) como capa de contratos, con argumentos sólidos: 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 emuladores; WASM cuenta con mecanismos de verificación de seguridad de tipos maduros; y su ecosistema de herramientas ya ha sido probado en miles de millones de entornos.
Más aún, no solo hablan teóricamente. Offchain Labs ya ha implementado un prototipo en Arbitrum: usar WASM como formato de entrega de contratos, luego compilar 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 avanza rápidamente. Recientemente, la implementación de RISC-V cambió de 32 bits a 64 bits. Si ahora se fija RISC-V en Ethereum Layer 1, ¿qué pasa si en unos años aparece una arquitectura de pruebas mejor? Apostar a una tecnología en rápida evolución no es típico en 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 objetivo inicial de L2 era ampliar Ethereum, pero ahora que Ethereum mismo se vuelve más rápido, el papel de L2 debe cambiar.
Curiosamente, los L2 no solo no entraron en pánico, sino que comenzaron a “desasociarse” de Ethereum. Jing Wang, cofundador de OP Labs, comparó a L2 con sitios web independientes, con Ethereum como 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 bloques único para escenarios de pago reales.
En otras palabras, la gran tendencia de la actualización de Vitalik en la capa de ejecución es que Ethereum está recuperando el control de sus capacidades centrales, y los L2 están encontrando o reafirmando su razón de ser de forma independiente.
¿Será posible esto?
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 con 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 VM.
Se espera que la actualización Glamsterdam de Ethereum ocurra 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 las optimizaciones en la capa de ejecución son las líneas principales confirmadas.
La historia de Ethereum nunca ha sido cuestión de “si se puede” — desde PoW a PoS, de L1 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 estratégica y pensada, o un agujero 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 con parches” en la era ZK. Cómo se apliquen los parches y qué tipo de motor se instale, esta discusión en sí misma puede ser más valiosa que la conclusión.
