Cuando Ethereum abandona EVM por RISC-V: La revisión de arquitectura que podría redefinir la computación en blockchain

Ethereum se encuentra en un punto de inflexión. Mientras que la Máquina Virtual de Ethereum (EVM) ha impulsado una década de innovación en blockchain—creando la base para DeFi y NFTs—cada vez está más claro que esta capa de ejecución construida a medida no fue diseñada para el futuro computacional que ahora está llegando. El cambio hacia la verificación de conocimiento cero (ZK) y la aparición de una estructura de máquina general en los estándares de programación de sistemas están forzando un reconocimiento: ¿Puede la arquitectura envejecida de Ethereum adaptarse, o necesita una reinvención completa?

Según investigadores técnicos y líderes de la Fundación Ethereum, la respuesta se está volviendo inconfundible. El protocolo está trazando un rumbo hacia la sustitución de la EVM por RISC-V, una arquitectura de conjunto de instrucciones de código abierto que promete desbloquear escalabilidad, reducir la complejidad y alinear a Ethereum con el ecosistema más amplio de computación verificable.

La crisis de rendimiento de la que nadie habla: por qué la EVM no puede seguir el ritmo de ZK

El cuello de botella no es inmediatamente obvio, pero es fundamental. Cuando Ethereum comienza a probar sus transiciones de estado mediante pruebas de conocimiento cero—una vía esencial para escalar en capa 1—la implementación actual de zkEVM crea una penalización de rendimiento aplastante.

Aquí está la realidad técnica: La zkEVM de hoy no prueba directamente la ejecución de la EVM. En cambio, prueba un intérprete que ha sido compilado en código RISC-V. Esta capa adicional de abstracción es la culpable. ¿El coste de rendimiento? Las estimaciones varían de 50 a 800 veces más lento que la ejecución nativa. Incluso después de optimizar otros componentes—como cambiar a algoritmos de hash más eficientes—la ejecución de bloques sigue siendo el cuello de botella, representando el 80-90% de todo el tiempo de generación de pruebas.

Como Vitalik Buterin resumió el problema: Si la zkVM finalmente compila todo en RISC-V de todos modos, ¿por qué obligar a los desarrolladores de contratos inteligentes a trabajar a través de un intermediario EVM que no aporta más que sobrecarga?

Esto no es teórico. La brecha de rendimiento se traduce directamente en economía. Eliminar esta capa interpretativa podría mejorar la eficiencia de ejecución en aproximadamente 100 veces—una diferencia que separa una escalabilidad viable de una congestión continua.

Deuda técnica enterrada en el protocolo

Las decisiones de diseño de la EVM tenían mucho sentido en 2015, pero se han cristalizado en limitaciones. Considera tres problemas específicos:

Contratos precompilados como una solución que fracasó. Cuando la EVM no podía manejar de manera eficiente ciertas operaciones criptográficas, Ethereum añadió funciones codificadas en duro—contratos precompilados. Esto parecía pragmático temporalmente. Hoy, esto ha creado lo que Vitalik llama una situación “mala”: estos módulos han inflado la base de código de confianza de Ethereum a niveles insostenibles y han introducido riesgos de seguridad repetidos que han llegado peligrosamente cerca de causar fallos de consenso.

Agregar nuevos precompiles requiere bifurcaciones duras controvertidas e involucra código envoltorio más complejo que implementaciones completas de RISC-V. La conclusión de Vitalik: el protocolo debería dejar de añadir precompiles por completo.

Arquitectura de 256 bits para el caso de uso equivocado. La pila de 256 bits de la EVM fue diseñada para valores criptográficos, pero la mayoría de los contratos inteligentes operan con enteros de 32 o 64 bits. Este desajuste crea una ecuación de eficiencia cruel: números más pequeños no ahorran recursos, mientras que duplicar o cuadruplicar la complejidad. En sistemas de pruebas ZK, esta ineficiencia se magnifica.

Pila vs. registros. La arquitectura basada en pila de la EVM requiere más instrucciones que el modelo de registros de RISC-V para realizar operaciones idénticas, complicando la optimización del compilador y aumentando la carga de generación de pruebas.

Estas decisiones de diseño acumuladas no son errores—son restricciones arquitectónicas que tenían sentido en su momento, pero que se han vuelto incompatibles con el futuro de Ethereum.

RISC-V: por qué un estándar abierto supera el diseño personalizado

RISC-V no es una tecnología propietaria. Es un estándar de conjunto de instrucciones de código abierto—esencialmente, un plano de diseño de procesador de acceso libre. Su adopción para este rol no es arbitraria ni experimental.

Por qué la simplicidad es fortaleza. El conjunto de instrucciones fundamental de RISC-V contiene aproximadamente 47 instrucciones. Este minimalismo radical es intencional. Menos instrucciones significan una base de código de confianza más pequeña—más fácil de auditar, verificar formalmente y garantizar su seguridad. Como enfatizó Jeremy Bruestle en conferencias de la industria, este diseño es “casi perfecto para la máquina general ultra-minimalista que necesitamos.”

Madurez del ecosistema a través de LLVM. Al elegir un estándar establecido, Ethereum obtiene acceso a décadas de infraestructura de compiladores. Gracias al soporte de LLVM, los desarrolladores pueden usar cualquier lenguaje de programación principal—Rust, C++, Go, Python—y compilar directamente a RISC-V. Esto elimina la necesidad de reconstruir todo un ecosistema de desarrollo desde cero. Justin Drake articuló la ventaja estratégica: “Obtenemos todo el soporte de lenguajes de alto nivel soportados por LLVM de forma gratuita.”

La convergencia de zkVM ya está ocurriendo. El mercado ya ha votado. Entre las diez implementaciones de zkVM más avanzadas capaces de probar bloques de Ethereum, nueve han optado por RISC-V. Esto no es especulación—es validación práctica. El ecosistema de conocimiento cero ya ha estandarizado RISC-V como objetivo de ejecución, haciendo que la adopción de Ethereum no sea una apuesta, sino una alineación con hacia dónde se dirige la industria.

La verificación formal se vuelve posible. A diferencia de la especificación del Yellow Paper de la EVM—escrita en lenguaje natural y propensa a ambigüedades—RISC-V tiene una especificación oficial en SAIL que es legible por máquina. Este rigor matemático permite verificar directamente los circuitos zkVM contra la especificación, creando un camino hacia la corrección demostrable que la EVM nunca podría ofrecer.

Límites de seguridad de hardware integrados. RISC-V incluye una arquitectura privilegiada con modo usuario y modo supervisor. Los contratos inteligentes se ejecutan en modo usuario y no pueden acceder directamente al estado de la blockchain; en cambio, emiten solicitudes ECALL a un núcleo de confianza. Esto crea un límite de seguridad reforzado por la propia arquitectura del procesador—mucho más robusto que el sandboxing solo por software. Como explicó Diego de Cartesi, “Todos estos mecanismos de protección son parte del estándar RISC-V.”

La transición en tres fases: mitigación de riesgos mediante gradualismo

Ethereum no planea un cambio repentino. La migración sigue una hoja de ruta deliberadamente conservadora:

Fase 1: RISC-V como reemplazo de precompilados. Inicialmente, el protocolo deja de añadir nuevos precompilados EVM. En su lugar, la nueva funcionalidad criptográfica se implementa mediante programas RISC-V en lista blanca. Esto permite que la nueva arquitectura pase por pruebas en la red principal en un entorno controlado y de bajo riesgo antes de una adopción más amplia.

Fase 2: Coexistencia de doble máquina virtual. Los contratos inteligentes podrán declarar si su bytecode apunta a EVM o RISC-V. Crucialmente, los contratos en ambos entornos podrán llamarse entre sí mediante llamadas ECALL estandarizadas. Esto crea un período híbrido donde ambas arquitecturas operan juntas, validando la interoperabilidad antes de la migración completa.

Fase 3: La EVM como contrato simulado. La fase final trata la EVM como un lenguaje de alto nivel—un contrato inteligente formalmente verificado que corre de forma nativa en RISC-V en capa 1. Las aplicaciones heredadas permanecen soportadas de forma permanente, pero la capa de ejecución central del protocolo se vuelve pura RISC-V, simplificando drásticamente el desarrollo y mantenimiento del cliente.

Este enfoque por fases transforma una migración potencialmente catastrófica en una evolución manejable.

La reorientación del ecosistema: ganadores y perdedores

El cambio no afecta por igual a todos los Layer 2—crea ganadores y perdedores.

Las Rollups optimistas enfrentan desafíos arquitectónicos. Proyectos como Arbitrum y Optimism dependen de pruebas de fraude: disputar una transacción requiere re-ejecutarla en L1. Si la VM de L1 cambia de EVM a RISC-V, este modelo de seguridad colapsa. Estos proyectos enfrentan una elección: realizar esfuerzos de ingeniería masivos para rediseñar las pruebas de fraude para la nueva arquitectura, o desacoplarse completamente del modelo de seguridad de Ethereum. Ambas opciones son costosas.

Las ZK Rollups ganan una ventaja estratégica enorme. Proyectos como Polygon, zkSync y Scroll ya han estandarizado internamente en RISC-V. Un L1 que “habla su idioma” elimina capas de traducción. Lo que la Fundación Ethereum llama “Rollups nativos” se vuelve posible: L2 se convierte en una instancia especializada del entorno de ejecución de L1, compartiendo herramientas, compiladores e infraestructura de verificación formal. El resultado práctico: los equipos de L2 ya no construyen puentes entre VMs incompatibles, los costos de desarrollo se reducen y la economía del gas se alinea de manera más racional.

La experiencia del desarrollador se transforma. En lugar de aprender solo Solidity, los desarrolladores pueden programar en Rust, Go o cualquier lenguaje soportado por LLVM. Los contratos pueden usar bibliotecas maduras del ecosistema de software más amplio. Vitalik lo compara con Node.js: código en cadena y fuera de cadena unificado en el mismo lenguaje, con las mismas herramientas. Esta reducción de barreras probablemente remodelará quién puede participar en el desarrollo blockchain.

La economía del usuario mejora drásticamente. Los costos de prueba caen aproximadamente 100 veces. Las tarifas de transacción para liquidaciones en L1 y L2 disminuyen en consecuencia. Esto desbloquea “Gigagas L1”—aproximadamente 10,000 transacciones por segundo—permitiendo aplicaciones complejas que requieren tanto rendimiento como seguridad.

Succinct Labs y SP1: La prueba de que la visión funciona hoy

La transición no es solo teórica. Succinct Labs ya ha demostrado las ventajas prácticas de RISC-V a través de SP1, un zkVM de código abierto que prueba que la tesis arquitectónica funciona.

La innovación de SP1: adopta un diseño “centrado en precompilados” que resuelve el cuello de botella criptográfico de la EVM sin crear el problema de complejidad. Operaciones intensivas como el hash Keccak se ejecutan en circuitos ZK especializados, llamados mediante instrucciones ECALL estándar. Esto combina el rendimiento del hardware personalizado con la flexibilidad del software.

El impacto práctico es inmediato. El producto OP Succinct de Succinct proporciona capacidades de conocimiento cero a las Rollups optimistas. El resultado: en lugar de esperar siete días para la confirmación final y retiro, las transacciones se finalizan en aproximadamente una hora. Para todo el ecosistema OP Stack, esta mejora de velocidad aborda un punto crítico de dolor.

Succinct también opera una Red de Proveedores descentralizada, creando un mercado para la generación de pruebas. Esto no es una prueba de concepto—es un plano para el modelo económico que gobernará la computación verificable a escala.

Los riesgos ocultos: qué aún puede salir mal

A pesar de las ventajas de RISC-V, la transformación introduce riesgos novedosos:

Complejidad en la medición de gas. Asignar un coste de gas justo y determinista a instrucciones de propósito general es un problema sin resolver. Contar instrucciones simples es vulnerable a ataques de denegación de servicio. Un atacante podría diseñar programas que disparen repetidamente fallos de caché, consumiendo recursos masivos con un coste de gas mínimo. Esto amenaza la estabilidad de la red y los modelos económicos.

Seguridad de la cadena de herramientas y construcciones reproducibles. Este es el riesgo más peligroso y subestimado. La seguridad pasa de depender de VMs en cadena a depender de compiladores fuera de cadena como LLVM—software complejo que se sabe que contiene vulnerabilidades. Un atacante que explote errores del compilador podría transformar código fuente aparentemente seguro en bytecode malicioso. Igualmente desafiante: garantizar que los binarios compilados coincidan con el código fuente públicamente disponible (el problema de las “construcciones reproducibles”) en diferentes entornos de compilación. Variaciones menores en el entorno producen salidas diferentes, creando problemas de confianza y transparencia.

Estos riesgos son solucionables, pero no triviales.

Mitigación: defensa en profundidad

Implementación por fases como estrategia principal. Introduciendo RISC-V de forma gradual mediante precompilados, luego doble VM, y finalmente reemplazo completo, el protocolo construye experiencia operativa y confianza antes de comprometerse de forma irreversible. Este enfoque escalonado es la herramienta fundamental de gestión de riesgos.

Pruebas agresivas y verificación formal. Aunque la verificación formal es la meta a largo plazo, debe acompañarse de pruebas continuas de alta intensidad. Empresas de seguridad como Diligence ya han descubierto 11 vulnerabilidades críticas en solidez e integridad en zkVMs líderes mediante pruebas fuzz. Este patrón—vulnerabilidades ocultas en sistemas bien diseñados— exige estrategias paralelas de prueba y verificación, no secuenciales.

Estandarización para prevenir fragmentación. La comunidad debería adoptar una única configuración estándar de RISC-V, probablemente RV64GC con ABI compatible con Linux. Esto maximiza el soporte del conjunto de herramientas y evita la fragmentación del ecosistema, permitiendo que los desarrolladores aprovechen plenamente las ventajas del ecosistema LLVM.

La capa de Internet verificable: el juego a largo plazo de Ethereum

La transición de EVM a RISC-V no se trata principalmente de ganancias incrementales de rendimiento. Se trata de reposicionar a Ethereum desde una “máquina virtual de contratos inteligentes” para convertirse en la base verificable de confianza para la computación en internet de propósito general.

La visión de Vitalik captura el objetivo final: “El objetivo final incluye… hacer todo ZK-snarkificado.”

Esta transformación aborda el pilar de “Ejecución Lean” de Ethereum—parte de la visión más amplia de “Ethereum Lean”. El protocolo se simplifica de una VM monolítica a una capa minimalista de liquidación y disponibilidad de datos optimizada para la computación verificable. La aceleración de pruebas en hardware (ASICs y FPGAs de SP1, Nervos, Cartesi) se vuelve factible una vez que el conjunto de instrucciones se estabilice en torno a RISC-V.

La transición es inevitable no porque sea óptima en aislamiento, sino porque se alinea con hacia dónde se dirige la computación misma. Las pruebas ZK representan la tercera primitiva criptográfica después de hashes y firmas. La apuesta de Ethereum es que quien proporcione la capa de confianza fundamental para la computación verificable—integración nativa de una estructura de máquina general en la programación de sistemas—controlará la próxima era de internet.

A pesar de obstáculos técnicos y sociales sustanciales, esta reestructuración de la capa de ejecución de Ethereum representa una de las decisiones arquitectónicas más trascendentales en la historia del blockchain. Cambia los efectos de red de la familiaridad con la EVM por la posición estratégica de liderar la revolución de la computación verificable.

La transformación comienza ahora. Proyectos como Ethproofs agregan los datos colaborativos necesarios para ejecutar este cambio. Equipos como Succinct Labs ofrecen los planos prácticos. En 6-12 meses, se espera que las primeras alternativas de precompilados que ejecuten código RISC-V en la red principal de Ethereum marquen el comienzo del fin de la Máquina Virtual de Ethereum tal como la conocemos.