Vitalik propone cambios importantes en la máquina virtual y el árbol de estado de ethereum

Artículo por: Langosta Gris, Deep潮 TechFlow

Los desarrolladores de Ethereum tienen un hábito no dicho: evitar el EVM siempre que sea posible.

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 la capa de 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: la totalidad del propósito de Ethereum radica en su universalidad; si el EVM no es suficientemente bueno, deberíamos abordar directamente este problema y crear una máquina virtual superior.

Él proporcionó dos cuchillos quirúrgicos específicos.

El primer cambio se refiere al árbol de estado de Ethereum. Puedes entenderlo como el "sistema de índice de libros" de Ethereum, por el que se debe navegar cada vez que alguien consulta un saldo o verifica una transacción.

El problema es que ahora este árbol 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 caminos; ahora, solo tienes que decidir entre izquierda y 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 considerablemente.

Pero Vitalik no se conforma solo con cambiar la forma del árbol; también quiere cambiar la "fuente en las hojas", es decir, la función de hash. Las opciones candidatas son Blake3 y Poseidon. Blake3 ofrece un aumento estable en el rendimiento; Poseidon es más agresivo y teóricamente podría mejorar la eficiencia de las pruebas decenas de veces, pero su seguridad aún requiere más auditorías.

Es importante destacar que este plan en realidad reemplaza a los Verkle Trees, que durante años fueron el tema de discusión en la comunidad. Verkle era anteriormente la opción preferida para el hard fork de 2026, pero debido a que la criptografía de curva elíptica en la que se basa enfrenta amenazas de la computación cuántica, comenzó a perder popularidad a mediados de 2024, lo que permitió que los esquemas de árboles binarios ganaran terreno.

El segundo cambio es más audaz y más controvertido: reemplazar a largo plazo el EVM con la arquitectura RISC-V.

RISC-V es un conjunto de instrucciones 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 en la nueva máquina virtual, garantizando una compatibilidad total hacia atrás.

Los propietarios actuales no necesitan cambiar de coche. 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.

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 principal de desarrollo de Arbitrum, Offchain Labs, publicó una refutación técnica detallada. La opinión central de los cuatro investigadores fue que RISC-V efectivamente 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ía, pero eso no significa que el repartidor también deba usar 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, y cambiar forzosamente implicaría usar un emulador; 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: utilizar WASM como formato de entrega de contratos, luego compilarlo a RISC-V para pruebas ZK. Cada capa realiza su tarea sin interferir con la otra.

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 ha pasado de 32 bits a 64 bits. ¿Qué sucedería si ahora se soldara RISC-V directamente en Ethereum L1, pero dos años después surge una arquitectura de prueba superior? Apostar por un blanco en constante movimiento no es el estilo de Ethereum.

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 desencadenó 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, y ahora que Ethereum mismo se está volviendo más rápido, la posició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.

Vitalik también admitió que aún 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 de impulso. Pero ¿sustituir la EVM por RISC-V? Todavía se encuentra en la fase de "hoja de ruta" y está lejos de ser implementado en el código.

Pero 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 está moviendo esta vez es algo más profundo: no se trata de añadir nuevas funciones, sino de excavar y volver a verter la base antigua. ¿Será esta una renovación cuidadosamente planificada o 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.