Los desarrolladores de Ethereum siguen una regla no escrita: evitar la EVM siempre que sea posible.
En los últimos años, cuando se requiere una nueva operación criptográfica en la cadena, el instinto de los desarrolladores no es implementarla en la EVM, sino pedir un “contrato precompilado”, un atajo que omite la máquina virtual y codifica la operación directamente en el protocolo.
El 1 de marzo, Vitalik Buterin publicó un largo hilo en X, rompiendo abiertamente esta regla implícita. En esencia, defendió: el valor de Ethereum está en su carácter generalista. Si la EVM se queda corta, debemos afrontar el problema directamente y construir una máquina virtual mejor.
Propuso dos soluciones concretas.
Primera solución: cambiar la “estructura de datos”
La primera modificación apunta al árbol de estado de Ethereum, que actúa como sistema de indexación del libro mayor de la red. Cada vez que alguien consulta un saldo o verifica una transacción, recorre este árbol.
El problema es que el árbol actual resulta demasiado “pesado”. Ethereum utiliza una estructura denominada “árbol hexario Keccak Merkle Patricia” (el nombre parece un hechizo). La EIP-7864 de Vitalik propone sustituirlo por un árbol binario más eficiente.
Para comparar: antes, consultar un dato implicaba elegir entre seis direcciones en cada bifurcación. Ahora, solo hay que decidir entre izquierda o derecha. ¿El resultado? La longitud de las ramas Merkle se reduce a una cuarta parte de su tamaño original. Para los clientes ligeros, el ancho de banda necesario para verificar datos baja considerablemente.
Vitalik no se limita a rediseñar el árbol. También quiere cambiar la “fuente en las hojas”: la función hash. Los dos candidatos son Blake3 y Poseidon. Blake3 aporta mejoras de velocidad constantes; Poseidon es más disruptivo y, en teoría, podría multiplicar la eficiencia de las pruebas, aunque su seguridad necesita más auditoría.
Es relevante que esta propuesta reemplaza a los Verkle Trees previamente debatidos. Verkle era el favorito para el hard fork de 2026, pero su criptografía de curva elíptica enfrenta amenazas de computación cuántica. Desde mediados de 2024, Verkle ha ido perdiendo apoyo, permitiendo que la solución del árbol binario gane fuerza.
Segunda solución: cambiar la “máquina virtual”—convertir la EVM en un contrato inteligente
El segundo cambio es aún más atrevido y polémico: sustituir la EVM por la arquitectura RISC-V a largo plazo.
RISC-V es un conjunto de instrucciones de código abierto, originalmente ajeno a blockchain, pero ahora casi todos los sistemas de pruebas ZK lo emplean internamente. La lógica de Vitalik es clara: si los generadores de pruebas ya usan RISC-V, ¿por qué la máquina virtual debe emplear otro sistema, obligando a crear una capa de traducción? Eliminar esa capa mejora la eficiencia de forma natural.
Un intérprete RISC-V requiere solo unas pocas centenas de líneas de código. Vitalik sostiene que esto es lo que debería ser una máquina virtual de blockchain.
Su plan tiene tres pasos: primero, usar la nueva máquina virtual para contratos precompilados, reescribiendo el 80 % de los precompilados actuales con código de la nueva VM; segundo, permitir que los desarrolladores desplieguen contratos para la nueva VM, funcionando en paralelo con la EVM; tercero, retirar la EVM, no eliminándola, sino reescribiéndola como un contrato inteligente ejecutándose sobre la nueva máquina virtual, logrando plena compatibilidad retroactiva.
Los usuarios actuales no tienen que cambiar de coche—solo se sustituye el motor discretamente, mientras el volante permanece igual.
¿Qué importancia tienen estos dos cambios juntos? Vitalik ofreció una cifra: el árbol de estado y la máquina virtual representan más del 80 % del cuello de botella de pruebas de Ethereum. Sin abordar estos dos aspectos, la escalabilidad de Ethereum en la era ZK se estancaría.
Arbitrum discrepa: que el almacén use montacargas no implica que los repartidores deban conducirlos
No todos están de acuerdo.
En noviembre del año pasado, el equipo principal de desarrollo de Arbitrum, Offchain Labs, publicó una refutación técnica detallada. Sus cuatro investigadores sostienen que, aunque RISC-V es adecuado para pruebas ZK, no es apropiado como “formato de entrega” para contratos.
Introdujeron una distinción clave: el “conjunto de instrucciones de entrega” (dISA) y el “conjunto de instrucciones de prueba” (pISA) no tienen por qué ser iguales. Usar montacargas en el almacén puede maximizar la eficiencia, pero eso no significa que los repartidores deban usarlos para entregar paquetes en la puerta.
Offchain Labs defiende el uso de WebAssembly (WASM) en la capa de contratos, por motivos sólidos: WASM se ejecuta eficientemente en hardware estándar, y la mayoría de los nodos de Ethereum no usan chips RISC-V—obligar al cambio requeriría emuladores; WASM ofrece verificación madura de seguridad de tipos; el ecosistema de herramientas de WASM ha sido probado en miles de millones de entornos de ejecución.
Importante: no es solo una teoría. Offchain Labs ya ha ejecutado un prototipo en Arbitrum: usando WASM como formato de entrega de contratos y compilándolo a RISC-V para pruebas ZK. Las dos capas operan de forma independiente.
También plantearon un riesgo relevante: la tecnología de pruebas ZK evoluciona rápido, y recientemente las implementaciones de RISC-V pasaron de 32 bits a 64 bits. Si se fija RISC-V en Ethereum L1 ahora, ¿qué ocurre si surge una arquitectura de pruebas mejor en dos años? Apostar por un objetivo en constante movimiento no es el estilo de Ethereum.
Un contexto más amplio: las L2 empiezan a “desvincularse”
Entender esta propuesta requiere una perspectiva más amplia.
Hace apenas un mes, Vitalik cuestionó públicamente si Ethereum aún necesita una “hoja de ruta dedicada para L2”, lo que provocó una respuesta colectiva del ecosistema L2. Ben Fisch, CEO de Espresso Systems, declaró a CoinDesk: el punto de Vitalik es que las L2 originalmente ayudaban a escalar Ethereum, pero ahora que Ethereum se acelera, el papel de las L2 cambia de forma natural.
Curiosamente, en vez de entrar en pánico, las L2 se están “desethereumizando” de forma proactiva. Jing Wang, cofundador de OP Labs, comparó las L2 con sitios web independientes, y a Ethereum como el estándar abierto de liquidación subyacente. Marc Boiron, CEO de Polygon, fue directo: el verdadero reto no es la escalabilidad, sino crear espacio de bloque único para escenarios reales como pagos.
En otras palabras, la reforma de Vitalik en la capa de ejecución es una nota técnica dentro de una tendencia mayor: Ethereum recupera el control sobre sus capacidades esenciales, mientras las L2 se ven obligadas—o finalmente encuentran—sus propias razones para existir de forma independiente.
¿Puede esto funcionar?
Vitalik reconoce que reemplazar la máquina virtual no ha logrado consenso entre los desarrolladores. La reforma del árbol de estado está más avanzada, con EIP-7864 ya en borrador y un equipo dedicado. Pero sustituir la EVM por RISC-V aún está en fase de “hoja de ruta”, lejos de su implementación.
Sin embargo, la semana pasada, Vitalik hizo una declaración memorable: Ethereum ya ha cambiado un motor a reacción en pleno vuelo (refiriéndose a The Merge), y puede hacerlo unas cuatro veces más—árbol de estado, consenso simplificado, verificación ZK-EVM y reemplazo de la máquina virtual.
La actualización Glamsterdam de Ethereum se espera para la primera mitad de 2026, seguida de Hegota. El contenido exacto de los dos hard forks aún no está definido, pero la reforma del árbol de estado y la optimización de la capa de ejecución están confirmadas como temas principales.
La historia de Ethereum nunca ha sido sobre “si se puede hacer”. De PoW a PoS, de L1 total a enfoque Rollup, ha demostrado su capacidad y valentía para desmontar motores en pleno vuelo.
Esta vez, se trata de algo más profundo—no añadir nuevas funciones, sino desmontar la base antigua y reconstruirla. ¿Es una reforma cuidadosamente pensada, o una fosa de complejidad cada vez más profunda? La respuesta probablemente no se sabrá hasta 2027.
Pero al menos hay una certeza: Ethereum no quiere ser un “sistema viejo parcheado” en la era ZK. Y sobre cómo quitar los parches y qué motor instalar, el debate puede ser más valioso que la conclusión.
Aviso legal:
-
Este artículo se ha republicado desde TechFlow, con derechos de autor del autor original [Gray Lobster]. Si tiene alguna objeción a esta republicación, contacte con el equipo de Gate Learn, que gestionará el asunto conforme a los procedimientos pertinentes.
-
Aviso legal: las opiniones expresadas en este artículo corresponden únicamente al autor y no constituyen asesoramiento de inversión.
-
Las versiones en otros idiomas de este artículo han sido traducidas por el equipo de Gate Learn. Sin mención explícita de Gate, no copie, distribuya ni plagie los artículos traducidos.
