El terremoto arquitectónico de Ethereum: por qué la EVM debe abrir paso a RISC-V

El protocolo de Ethereum enfrenta su transformación más radical desde su génesis, no solo una actualización, sino una revisión arquitectónica fundamental. La Máquina Virtual de Ethereum (EVM), que impulsó toda la revolución DeFi y NFT, se está convirtiendo en el mayor cuello de botella de rendimiento de la red en un futuro dominado por pruebas de conocimiento cero. La respuesta: reemplazarla por RISC-V.

La crisis de rendimiento de la que nadie habla

Aquí está la dura verdad: las implementaciones actuales de EVM de conocimiento cero son 50 a 800 veces más lentas que la ejecución nativa. ¿Por qué? Porque no prueban directamente la EVM, sino que prueban un intérprete de la EVM, que en sí mismo se compila a bytecode RISC-V de todos modos.

Como planteó el propio Vitalik Buterin: Si en última instancia estamos compilando la ejecución de EVM a RISC-V debajo, ¿por qué añadir una capa de abstracción innecesaria entre los desarrolladores y la capa de ejecución real? Eliminar esa sobrecarga del intérprete podría desbloquear ganancias de eficiencia de 100 veces para la verificación de la capa 1.

Las decisiones de diseño actuales están creando problemas en cascada:

Contratos precompilados: Ethereum añadió funciones criptográficas codificadas (modexp, ecrecover, etc.) como soluciones temporales a las limitaciones de rendimiento de la EVM. Esto hizo que la base de código de confianza creciera catastróficamente—el código envoltorio para un solo precompilado es ahora más complejo que todo el intérprete RISC-V. Añadir nuevos requiere bifurcaciones duras controvertidas, frenando la innovación.

Desalineación arquitectónica: El diseño de pila de 256 bits de la EVM tenía sentido para primitivas criptográficas en 2015. Hoy, es una carga—la mayoría de las operaciones de contratos inteligentes usan enteros de 32 o 64 bits, pero la EVM aún consume los mismos recursos para valores más pequeños, añadiendo 2-4x de complejidad innecesaria para las pruebas de conocimiento cero.

Por qué gana RISC-V: La ventaja del estándar abierto

RISC-V no es una máquina virtual propietaria, sino un estándar abierto de conjunto de instrucciones, disponible gratuitamente para cualquiera. Esto crea tres ventajas decisivas:

Simplicidad radical: Solo 47 instrucciones básicas. Comparado con los miles de x86. Este minimalismo es intencional—significa menos superficies de ataque, verificación formal más sencilla y límites de código de confianza más pequeños.

Ecosistema de software maduro: Al adoptar RISC-V, Ethereum obtiene décadas de infraestructura de compiladores gratis. La cadena de herramientas LLVM ya soporta Rust, Go, C++, Python y docenas de lenguajes. Los desarrolladores no necesitarán aprender una sintaxis nueva—pueden escribir contratos inteligentes en el lenguaje que ya conocen y compilar directamente a la capa de ejecución de la capa 1. Vitalik llama a esto la experiencia “NodeJS”—escribir código cliente y servidor en el mismo lenguaje.

Convergencia del mercado: 9 de cada 10 proyectos zkVM ya han elegido RISC-V como su conjunto de instrucciones nativo. Esto no es teórico—es el estándar de facto del ecosistema de computación de conocimiento cero. La adopción en la capa 1 alinearía el núcleo de Ethereum con la infraestructura hacia la que construye todo su ecosistema L2.

El plan de migración: Tres etapas, sin revolución

No es un Big Bang. Vitalik delineó un enfoque deliberadamente cauteloso:

Fase 1: Reemplazo de precompilados
Las funciones RISC-V debutan dentro de la EVM mediante programas en lista blanca. Sin cambios en el formato de bytecode. Los desarrolladores no lo notan. La red gana experiencia operativa con la nueva VM en la mainnet en condiciones controladas—el entorno de prueba de menor riesgo posible.

Fase 2: Era de doble máquina virtual
Ambos contratos EVM y RISC-V coexisten. Los contratos inteligentes pueden etiquetar su formato de bytecode. Innovación crítica: pueden llamarse entre sí mediante llamadas al sistema (ECALL). Esto significa que podrías tener un pool central de Uniswap V3 en RISC-V llamando a un oráculo basado en EVM heredado—interoperabilidad transparente.

Fase 3: EVM como simulación (La estrategia “Rosetta”)
La EVM clásica se convierte en un contrato inteligente formalmente verificado que corre sobre RISC-V. Es la simplificación definitiva—en lugar de mantener dos motores de ejecución, los desarrolladores principales mantienen una única capa de confianza optimizada, con soporte heredado integrado como software a nivel de aplicación. Esta fase puede tomar años, pero es inevitable.

Quién gana, quién pierde: La reconfiguración de los rollups

Este cambio será sísmico para la infraestructura de capa 2:

Los Rollups optimistas enfrentan una amenaza existencial: Proyectos como Arbitrum y Optimism dependen de mecanismos de prueba de fraude que re-ejecutan transacciones disputadas a través de la EVM de capa 1. Cuando la EVM desaparezca de la capa 1, todo su modelo de seguridad colapsará. Enfrentan dos decisiones brutales: (1) reconstruir sistemas de prueba de fraude para RISC-V desde cero, o (2) abandonar completamente el modelo de seguridad de Ethereum.

Los zk Rollups obtienen un impulso: Polygon, zkSync, Scroll y otros construyeron sus L2 en torno a zkVMs RISC-V. Una capa 1 que “habla su idioma” permite rollups nativos—sin necesidad de capa de traducción. Los equipos de L2 pueden reutilizar compiladores, depuradores y herramientas de verificación de L1. Esto transforma la economía de L2:

• Sin lógica de puente personalizada entre L2 RISC-V y VM de L1
• Los cálculos de gas son precisos—las tarifas de L1 reflejan con exactitud los costos reales de verificación RISC-V
• La liquidación se vuelve atómica, no heurística

¿El resultado? La visión de Justin Drake de “rollups como instancias especializadas de L1”—una integración más estrecha, menor latencia, capital más eficiente.

Para desarrolladores y usuarios: El impacto real

Experiencia del desarrollador: Los desarrolladores dejan de estar atados a Solidity/Vyper/Yul. Escriben en Rust, Go o Python—usan sus bibliotecas favoritas de npm o crates.io—y se ejecuta directamente en L1. La compilación es transparente. Vitalik predice que Solidity sobrevivirá de todos modos por los efectos de red del ecosistema, pero se libera la válvula de presión.

Economía del usuario: Los costos de prueba caen ~100x (de dólares por transacción a centavos). Esto no es teórico—los resultados de zkVM SP1 de Succinct Labs ya demuestran esto. Combinado con liquidaciones más rápidas en L2 (Los Rollups optimistas actualmente requieren ventanas de retiro de 7 días; OP Succinct las reduce a 1 hora), la experiencia del usuario se vuelve cualitativamente diferente.

El objetivo final es “Gigagas L1”—aproximadamente 10,000 transacciones por segundo en capa 1, con finalización atómica. Eso desbloquea aplicaciones en cadena actualmente imposibles debido a costo y latencia.

Los riesgos que deben gestionarse

Caos en la medición de gas: Contar instrucciones de manera justa en un ISA de propósito general es un problema sin resolver. Un atacante podría diseñar código que active repetidamente fallos de caché—alto costo de CPU, gas mínimo cobrado. Esto podría habilitar nuevos vectores de denegación de servicio.

Explosión de confianza en el compilador: El modelo de seguridad pasa de “probar la ejecución en cadena” a “confiar en el compilador LLVM”. LLVM es miles de líneas de código complejo con un historial de vulnerabilidades. Si un atacante explota un bug del compilador, podría ocultar comportamientos maliciosos en código fuente aparentemente inofensivo. Peor aún, el problema de “compilación reproducible” hace difícil demostrar que el binario en cadena coincide con el código fuente público—una pesadilla para la transparencia.

Fragmentación del ecosistema: Si diferentes proyectos adoptan diferentes configuraciones de RISC-V (RV32I vs. RV64GC), diferentes estándares ABI(, el ecosistema se fragmenta. La ventaja de la cadena de herramientas desaparece.

La pila de mitigación:

• Implementación en fases )pre-Fase 1( que prueba el modelo en escenarios de bajo riesgo
• Pruebas adversariales continuas )las pruebas fuzz ya han encontrado 11 errores críticos de solidez en los zkVM líderes(
• Verificación formal )la especificación SAIL permite pruebas de corrección matemática, a diferencia de la ambigüedad del Yellow Paper(
• Configuración unificada y estandarizada )probablemente RV64GC + ABI Linux( para prevenir fragmentación

El futuro verificable de Ethereum

Esto no se trata solo de velocidad. La visión más amplia es que Ethereum evolucione de ser una “máquina de contratos inteligentes” a una capa minimalista de liquidación y confianza para internet. La hoja de ruta “Lean Ethereum” )Lean Consensus + Lean Data + Lean Execution( está diseñada explícitamente para eliminar complejidad—y Lean Execution es la más profunda.

El zkVM SP1 de Succinct Labs demuestra que esto funciona en la práctica. Su producto OP Succinct ajusta zk-pruebas en Rollups optimistas, reduciendo los tiempos de retiro 7x. Su red de probadores de prueba (Prover Network) bosqueja el mercado de generación de pruebas. No son artículos de investigación—son sistemas de producción.

El momento histórico se cristaliza: las herramientas de verificación formal maduran )el probador de teoremas Lean(, la aceleración de pruebas en hardware ya está en marcha )los ASICs SP1 están en prueba, y el 90% del ecosistema zkVM ya ha elegido RISC-V. La visión de Vitalik de “snarkificar todo” ya no es especulativa—es infraestructura esperando que la capa 1 se ponga al día.

Ethereum enfrenta una decisión: evolucionar arquitectónicamente ahora, o ver cómo su techo de rendimiento se calcifica a medida que la computación de conocimiento cero se vuelve la norma. Los datos sugieren que la red elegirá la evolución—en fases cuidadosamente medidas, pero fases inevitables.

La base criptográfica de internet no está escrita en Solidity. Está escrita en RISC-V.