Autor: Gray Lobster, Shenchao TechFlow
Los desarrolladores de Ethereum tienen un hábito tácito: si se puede evitar el EVM, se evita el EVM.
En los últimos años, cada vez que la cadena necesitaba una nueva operación criptográfica, la primera reacción de los desarrolladores no era implementarla en el EVM, sino solicitar la adición de un "contrato precompilado", una forma directa y codificada en el nivel del protocolo que evita la máquina virtual.
El 1 de marzo, Vitalik Buterin publicó una entrada larga en X, desvelando por completo esta cuestión. En esencia, sus palabras fueron: el propósito completo de Ethereum radica en su universalidad; si el EVM no es suficientemente bueno, debemos abordar directamente este problema y crear una mejor máquina virtual.
Él proporcionó dos bisturís específicos.
Primera tajada: cambia "estructura de datos"
El primer cambio se refiere al árbol de estado de Ethereum. Puedes entenderlo como el "sistema de índice de libros mayores" de Ethereum, por el que se debe navegar cada vez que alguien consulta un saldo o verifica una transacción.
El problema es que este árbol ahora es demasiado "gordo". Ethereum utiliza una estructura llamada "árbol de Merkle Patricia hexa Keccak" (el nombre suena como un hechizo). EIP-7864, propuesto por Vitalik, busca reemplazarlo por un árbol binario más simple.
Por ejemplo: antes, al buscar un dato, tenías que elegir continuamente entre seis rutas; ahora, solo tienes dos opciones: izquierda o derecha. ¿El resultado? La longitud de la rama Merkle se reduce directamente a una cuarta parte del original. Para los clientes ligeros, el ancho de banda necesario para verificar los datos disminuye significativamente.
Pero Vitalik no se conforma solo con cambiar la forma del árbol; también quiere cambiar la "fuente de las hojas", es decir, la función hash. Las opciones candidatas son dos: Blake3 y Poseidon.
- Blake3 puede ofrecer un aumento de velocidad constante;
- Poseidon es más agresivo y teóricamente podría aumentar la eficiencia de la prueba decenas de veces, pero la seguridad aún requiere más auditorías.
Cabe destacar que este plan en realidad reemplaza a los Verkle Trees, que durante años fueron el方案 preferido por la comunidad. Verkle era originalmente la opción elegida para el hard fork de 2026, pero debido a las amenazas que la criptografía de curva elíptica subyacente enfrenta frente a la computación cuántica, comenzó a perder popularidad a mediados de 2024, permitiendo que los esquemas de árboles binarios ganaran terreno.
Segundo corte: reemplaza la "máquina virtual", convierte la EVM en un contrato inteligente
El segundo cambio es más audaz y más controvertido: reemplazar gradualmente el EVM con la arquitectura RISC-V.
RISC-V es un conjunto de instrucciones de código abierto que originalmente no tenía relación con la blockchain, pero ahora casi todos los sistemas de prueba ZK lo utilizan internamente. La lógica de Vitalik es muy directa: si los probadores ya hablan el lenguaje RISC-V, ¿por qué la máquina virtual debería hablar otro lenguaje y requerir una capa de traducción intermedia? Eliminar la capa de traducción aumenta naturalmente la eficiencia.
Un intérprete RISC-V solo requiere unas pocas centenas de líneas de código. Vitalik dice que así es como debería ser la máquina virtual de blockchain.
Él planeó un enfoque en tres pasos: primero, ejecutar contratos precompilados en una nueva máquina virtual y reescribir el 80% de los contratos precompilados existentes con el código de la nueva VM; segundo, permitir a los desarrolladores desplegar contratos directamente en la nueva máquina virtual, ejecutándose en paralelo con el EVM; tercer paso, retirar el EVM, pero no desaparecerá: será reescrito como un contrato inteligente que se ejecuta sobre la nueva máquina virtual, garantizando una compatibilidad total hacia atrás.
Los propietarios actuales no necesitan cambiar de vehículo. Solo se cambió discretamente el motor; el volante sigue siendo el mismo.
¿Qué tan importante es la combinación de estos dos aspectos? Vitalik dio un número: el árbol de estado y la máquina virtual representan más del 80% del cuello de botella de prueba de Ethereum. En otras palabras, si no se tocan estas dos partes, la escalabilidad de Ethereum en la era ZK será simplemente dar vueltas en círculos.
Arbitrum no está de acuerdo: no puedes exigir que el repartidor maneje un montacargas solo porque el almacén lo usa.
Pero este no es un cuento en el que todos asienten con la cabeza y dicen que sí.
En noviembre del año pasado, el equipo de desarrollo principal de Arbitrum, Offchain Labs, publicó una refutación técnica detallada. La opinión central de los cuatro investigadores fue que RISC-V sí es adecuado para pruebas ZK, pero no es adecuado como "formato de entrega" para contratos.
Plantearon una distinción clave: el conjunto de instrucciones de entrega (dISA) y el conjunto de instrucciones de prueba (pISA) no necesitan ser lo mismo. Tu almacén puede ser más eficiente con un montacargas para mover mercancías, pero eso no significa que el repartidor también deba conducir un montacargas para llevarte el paquete a la puerta de casa.
Offchain Labs defiende el uso de WebAssembly (WASM) para la capa de contratos, con argumentos sólidos: WASM ofrece alta eficiencia en hardware estándar, mientras que la mayoría de los nodos de Ethereum no ejecutan chips RISC-V, lo que implicaría la necesidad de un emulador si se intentara cambiar; WASM cuenta con mecanismos maduros de verificación de seguridad de tipos; y su ecosistema de herramientas ha sido probado en la práctica en miles de millones de entornos de ejecución.
Más importante aún, no solo lo han mencionado: Offchain Labs ya ha implementado un prototipo en Arbitrum que utiliza WASM como formato de entrega de contratos, luego lo compila a RISC-V para generar pruebas ZK. Ambas capas operan independientemente sin interferirse.
También plantearon un riesgo digno de reflexión: el campo de las pruebas ZK evoluciona extremadamente rápido, y recientemente la implementación de RISC-V ya pasó de 32 bits a 64 bits. ¿Qué sucedería si ahora se fija RISC-V directamente en Ethereum L1, pero dentro de dos años surge una arquitectura de prueba superior? Apostar por un blanco en constante movimiento no es el estilo de Ethereum.
Un contexto más amplio: Las L2 comienzan a "dejar el pecho"
Para comprender esta propuesta, se necesita un contexto más amplio.
Hace justo un mes, Vitalik cuestionó públicamente si Ethereum aún necesitaba un "plan de ruta L2 dedicado", lo que generó una respuesta colectiva de la comunidad L2. Ben Fisch, CEO de Espresso Systems, dijo a CoinDesk una frase muy acertada: lo que Vitalik quiere decir en realidad es que el propósito original de L2 era ayudar a Ethereum a escalar; ahora que Ethereum mismo se está volviendo más rápido, la función de L2 debe cambiar naturalmente.
Lo interesante es que, en lugar de entrar en pánico, los L2 comenzaron a "desethereumizarse" activamente. Jing Wang, cofundador de OP Labs, comparó a los L2 con sitios web independientes, y a Ethereum como el estándar abierto de liquidación subyacente. Marc Boiron, CEO de Polygon, lo expresó de manera más directa: el verdadero desafío no es la escalabilidad, sino crear espacios de bloque únicos para escenarios reales como los pagos.
En otras palabras, este importante cambio de Vitalik en la capa de ejecución es una nota técnica de una tendencia más amplia: Ethereum está recuperando el control sobre sus capacidades fundamentales, mientras que las L2 se ven obligadas, o finalmente encuentran, su razón de ser independiente.
¿Podrá hacerse esto?
Vitalik también admitió que actualmente no existe un amplio consenso en la comunidad de desarrolladores sobre la sustitución de la máquina virtual. La reforma del árbol de estado es más madura, y EIP-7864 ya tiene un borrador concreto y un equipo encargado de su avance. Pero ¿sustituir la EVM por RISC-V? Aún se encuentra en la fase de "hoja de ruta" y está lejos de ser implementado en el código.
Sin embargo, Vitalik dio el pasado semana una declaración impresionante: Ethereum ya ha cambiado un motor de reacción mientras volaba (refiriéndose a The Merge), y aún puede cambiar aproximadamente cuatro veces más: el árbol de estado, el consenso simplificado, la verificación ZK-EVM y la sustitución de la máquina virtual.
La actualización Ethereum Glamsterdam se espera que se implemente en la primera mitad de 2026, seguida de cerca por Hegota. Aún no se han definido completamente los detalles de ambos hard forks, pero la reforma del árbol de estado y la optimización de la capa de ejecución son las líneas maestras confirmadas.
La historia de Ethereum nunca ha sido una cuestión de "si se puede". Ha demostrado tener la capacidad y el coraje para desmontar motores a 10,000 metros de altura, desde la transición de PoW a PoS hasta convertirse en un centro de Rollups.
Lo que se va a modificar esta vez es algo más profundo: no se trata de añadir nuevas funciones, sino de excavar la antigua base y volver a verterla. ¿Se trata realmente de una renovación bien planificada o de un agujero sin fondo que se vuelve cada vez más complejo? La respuesta probablemente no se verá hasta 2027.
Pero al menos una cosa es segura: Ethereum no tiene intención de ser un "sistema antiguo con parches" en la era ZK. En cuanto a cómo desmontar los parches y qué motor reemplazar, el debate mismo podría ser más valioso que la conclusión.