Vitalik Examina la EVM y State Tree de Ethereum: Un Cambio Radical en el Futuro

Las semanas pasadas han generado un profundo debate en la comunidad de Ethereum sobre la parte más importante de la arquitectura de blockchain. En el primer trimestre de 2025, Vitalik Buterin publicó un análisis exhaustivo sobre cómo debería cambiar Ethereum desde sus cimientos. Su tesis es clara: el EVM y la estructura del árbol de estado no son suficientes para el futuro de Ethereum en la era de las pruebas de conocimiento cero. La comunidad de desarrolladores profesionales reaccionó en diferentes niveles—desde apoyo hasta rechazo directo a las propuestas principales.

¿Por qué es necesario cambiar el EVM? La gran limitación de rendimiento

Para entender la urgencia del cambio, debemos saber dónde está el problema actualmente. Durante más de diez años, el EVM (Máquina Virtual de Ethereum) ha sido el centro del ecosistema de Ethereum. Pero a medida que la red crece y surgen tecnologías avanzadas como las ZK proofs, sus limitaciones se vuelven más evidentes.

Vitalik dio un diagnóstico concreto: el árbol de estado y la arquitectura de la máquina virtual constituyen más del 80 por ciento del cuello de botella computacional para las pruebas de blockchain. En otras palabras, por muy bien que funcionen otras partes del sistema, si no se corrigen estos dos aspectos, Ethereum no podrá escalar adecuadamente en el futuro. Es como tratar de acelerar un coche cuyo motor sigue siendo pesado y sin rendimiento.

Los dos pasos principales: revisión estructural del árbol de estado y reemplazo completo del EVM

Vitalik propuso dos soluciones interconectadas que no deben considerarse solo juntas. Cada una aborda diferentes aspectos del problema de rendimiento.

Primer paso: reemplazo del árbol de estado con estructura binaria

Actualmente, Ethereum usa una estructura compleja llamada “árbol de Merkle Patricia hexárquico Keccak”—el nombre refleja su nivel de complejidad. La propuesta EIP-7864 busca simplificar esto a una estructura de árbol binario.

La implicación práctica es significativa. En el sistema actual, para identificar una transacción o saldo específicos, hay que tomar muchas decisiones en cada nivel del árbol—seis posibles direcciones en cada nodo. Con un árbol binario, solo hay dos opciones: izquierda o derecha. El resultado es directo: la longitud de la rama de Merkle se reduce hasta en cuatro veces.

Para los clientes ligeros y sistemas de verificación distribuidos, esto es revolucionario. La cantidad de datos necesaria para verificar se reduce considerablemente. Para los usuarios finales, significa verificaciones de transacciones más rápidas y menor costo computacional.

Pero Vitalik no se detuvo allí. La propuesta también incluye cambiar la función hash—el “tipo” de cálculo, por así decirlo. Hay dos candidatos: Blake3 y Poseidon. Blake3 ofrece mejoras de rendimiento consistentes. Poseidon es más agresivo y, en teoría, puede aumentar la eficiencia de las pruebas varias decenas de veces—pero aún requiere más auditorías de seguridad antes de su aprobación.

Esta elección también indica indirectamente: Ethereum abandonó el enfoque de Árboles Verkle, que la comunidad discutía desde hace tiempo. En 2024, las amenazas de computación cuántica en criptografía de curvas elípticas redujeron el interés en la solución Verkle, y el camino del árbol binario se volvió más popular.

Segundo paso: trasladar el EVM a la arquitectura RISC-V

La segunda propuesta es de mayor alcance y más controvertida: reemplazar a largo plazo el EVM usando la arquitectura de instrucciones RISC-V.

RISC-V es un conjunto de instrucciones open-source, eficiente en energía, que surgió inicialmente de investigaciones académicas y ahora se ha convertido en estándar en todos los sistemas de pruebas de conocimiento cero. La lógica de Vitalik es elegante: si los generadores de pruebas ZK hablan RISC-V, ¿por qué la máquina virtual de blockchain debería hablar otro idioma y añadir una capa de traducción? Eliminando esa capa redundante, la eficiencia aumenta inmediatamente.

La implementación técnica no es tan complicada como se piensa. Un intérprete RISC-V puede codificarse en unas pocas centenas de líneas de código. Para Vitalik, esta es la filosofía de diseño correcta para blockchain: simplicidad enfocada en rendimiento.

El plan de transición tiene tres fases:

Primero, usar la máquina virtual RISC-V para ejecutar contratos precompilados. El 80 por ciento de los contratos precompilados existentes puede reescribirse en código RISC-V.

Segundo, permitir a los desarrolladores desplegar directamente contratos usando la nueva máquina virtual. El nuevo sistema y el EVM correrán en paralelo, permitiendo una migración gradual.

Tercero, eventualmente eliminar el EVM—pero no desaparecerá por completo. Se convertirá en un contrato inteligente que se ejecuta en la máquina virtual RISC-V, garantizando compatibilidad total hacia atrás. La imagen de Vitalik es poética: el volante permanece igual, pero el motor debajo ha sido silenciosamente cambiado.

El cuello de botella en producción: sin cambios en el EVM, no hay escalabilidad

El argumento central se basa en un número: 80 por ciento. Este es el porcentaje del cuello de botella de las pruebas de Ethereum que proviene directamente de la arquitectura del árbol de estado y la máquina virtual. En términos prácticos, significa que todas las demás optimizaciones tienen un efecto limitado si no se corrigen estos dos aspectos.

En la era de la escalabilidad con ZK, esta limitación arquitectónica será un lastre. Ethereum ve que necesita evolucionar más allá de mejoras puntuales.

La contraoferta: el desafío de Arbitrum a la estrategia RISC-V

Pero la historia no es solo consenso. En noviembre pasado, el equipo de Offchain Labs—principales desarrolladores de Arbitrum—publicó una refutación técnica detallada.

Su principal observación es matizada y importante: sí, RISC-V es ideal para las pruebas ZK, pero no debe ser el “formato de ejecución” para contratos inteligentes. Hicieron una distinción clave: “conjunto de instrucciones de entrega” (dISA) y “conjunto de instrucciones de prueba” (pISA) no tienen que ser iguales.

Su analogía práctica es: un almacén puede ser muy eficiente usando un montacargas, pero eso no significa que el repartidor de paquetes también deba usarlo para entregarlos en tu puerta. Cada herramienta tiene su contexto adecuado.

Para la capa de ejecución de contratos, Offchain Labs aboga por WebAssembly (WASM) como mejor solución. Su razonamiento técnico es sólido:

Primero, WASM ha demostrado alta eficiencia en hardware estándar. La mayoría de los nodos de Ethereum no usan chips especializados RISC-V, y la emulación sería un gran overhead.

Segundo, WASM cuenta con mecanismos de verificación tipada maduros, probados en millones de entornos de ejecución en todo el mundo.

Tercero, el ecosistema de herramientas de WASM está establecido, con amplio soporte para desarrolladores.

Más aún, no solo teorizan. Offchain Labs ya construyó un prototipo en Arbitrum: usan WASM como formato de entrega de contratos, que luego se compila a RISC-V para las pruebas ZK. Cada capa realiza tareas especializadas sin conflicto.

También resaltan un riesgo crítico: la tecnología ZK está evolucionando rápidamente. La implementación de RISC-V mismo pasó de 32 bits a 64 bits en años recientes. ¿Qué pasa si en dos años aparece una arquitectura de pruebas superior? Apostar a una tecnología en constante cambio no es el estilo de Ethereum.

Un cambio industrial mayor: Ethereum y Layer 2 se alejan

Para entender mejor este debate técnico, hay que analizar las dinámicas industriales más amplias.

Hace poco más de un mes, Vitalik expresó escepticismo sobre la necesidad de una “hoja de ruta L2 dedicada para Ethereum”. Esto generó una respuesta reflexiva profunda de los operadores de Layer 2.

Ben Fisch, CEO de Espresso Systems, explicó a los medios: el propósito original de Layer 2 era ayudar a escalar Ethereum. Pero ahora que Ethereum busca sus propias mejoras de escalabilidad, la posición de Layer 2 debe evolucionar. Ya no solo es una capa auxiliar, sino un ecosistema más independiente.

Los operadores de Layer 2 no entraron en pánico. Más bien, se están reposicionando activamente. El cofundador de OP Labs describió los Layer 2 como “sitios web independientes”, mientras que Ethereum sería el estándar de liquidación periódica. El CEO de Polygon fue más directo: el verdadero desafío no es solo escalar, sino crear espacios de bloque especializados para casos de uso reales—como infraestructura de pagos.

En otras palabras, este gran cambio técnico en la capa de ejecución de Ethereum refleja una tendencia estructural mayor: Ethereum vuelve a tomar control de sus competencias centrales, mientras Layer 2s son empujados o, en última instancia, descubren su propia razón de ser.

¿Se convertirá en realidad? El camino a seguir y los desafíos

Vitalik mismo admitió que aún no hay consenso amplio en la comunidad de desarrolladores sobre el reemplazo del EVM. La reforma del árbol de estado tiene una base más sólida—el borrador de la EIP-7864 y equipos de desarrollo activos.

Pero el reemplazo del EVM con RISC-V todavía está en etapa de “hoja de ruta”, lejos de una implementación concreta.

Sin embargo, Vitalik expresó confianza la semana pasada: Ethereum ya realizó un cambio de motor durante el “Merge”. Puede aún realizar cuatro cambios mayores más—optimización del árbol de estado, consenso simplificado, verificación ZK-EVM y reemplazo de la máquina virtual.

El calendario comienza a definirse. Ethereum apunta a la actualización Glamsterdam en la primera mitad de 2026, seguida de Hegota. Los detalles técnicos aún se están finalizando, pero las reformas del árbol de estado y las mejoras en la capa de ejecución son la dirección principal confirmada.

La pregunta no es “puede o no”. Ethereum ha demostrado múltiples veces su capacidad—desde PoW a PoS, desde una visión centrada en L1 hasta un ecosistema basado en Rollups. El reto no es solo estético, sino de arquitectura: reconstruir la base mientras el sistema sigue en operación—no solo agregar funciones, sino reemplazar fundamentalmente la arquitectura antigua.

El debate técnico mismo—sobre si estos cambios son beneficiosos o conducen a una complejidad interminable—puede ser más valioso que la resolución final. Ethereum ha decidido conscientemente no ser un “sistema legacy parcheado” en la era ZK. Cómo romper las piezas del motor y qué nuevo modelo será el estándar solo se verá en 2027.