La capa de ejecución de Ethereum en un punto de inflexión: por qué la arquitectura RISC-V se está volviendo inevitable

Ethereum se encuentra en un momento crucial. La arquitectura fundamental que impulsó la revolución DeFi y permitió el ecosistema NFT enfrenta crecientes limitaciones de rendimiento que la optimización tradicional ya no puede resolver. La respuesta que surge de la comunidad no es un parche—es una reestructuración fundamental: la transición de la Máquina Virtual de Ethereum (EVM) a RISC-V como entorno de ejecución principal.

Esto no es especulación. Nueve de cada diez implementaciones zkVM que actualmente apuntan a bloques de Ethereum ya han estandarizado en RISC-V. Este consenso de mercado indica lo que los desarrolladores de protocolos han concluido en silencio: el diseño del EVM, aunque innovador hace una década, ha acumulado deuda técnica incompatible con los sistemas de pruebas de conocimiento cero que representan el futuro computacional de Ethereum.

La crisis de rendimiento en sistemas de conocimiento cero

El problema raíz es elegante en su simplicidad: Ethereum no prueba directamente el EVM. En cambio, los proyectos construyen intérpretes que traducen el bytecode del EVM en instrucciones compatibles con pruebas—que en última instancia se compilan a RISC-V de todos modos. Esta capa arquitectónica añade una sobrecarga devastadora.

Las implementaciones actuales de zkEVM sufren una degradación de rendimiento de 50 a 800 veces en comparación con la ejecución nativa de instrucciones. Incluso tras optimizaciones agresivas de operaciones criptográficas (como cambiar a funciones de hash Poseidon), la ejecución de bloques sigue siendo el cuello de botella, consumiendo entre el 80 y el 90% del tiempo total de generación de pruebas. Eliminando por completo la capa del intérprete, los investigadores de protocolos estiman que la eficiencia de ejecución podría mejorar en un factor de 100—transformando la generación de pruebas de inviable económicamente a práctica.

Las ineficiencias van más allá de la sobrecarga del intérprete. La arquitectura de pila de 256 bits del EVM fue diseñada para operaciones criptográficas, pero desperdicia recursos en lógica de contratos inteligentes típicos que involucran enteros de 32 o 64 bits. En sistemas de pruebas de conocimiento cero, cada operación requiere generar evidencia criptográfica de corrección; este desperdicio se multiplica exponencialmente. La arquitectura basada en registros de RISC-V, en contraste, se alinea con los principios del diseño moderno de CPU y permite optimizaciones del compilador que el modelo de pila impide fundamentalmente.

Deuda técnica: la trampa de los precompilados

Para compensar las limitaciones computacionales del EVM, Ethereum introdujo contratos precompilados—funciones codificadas que se integran directamente en el protocolo para operaciones costosas como criptografía de curvas elípticas o exponenciación modular. Esta solución pragmática a corto plazo se ha convertido en una pesadilla de mantenimiento.

Cada nueva adición de precompilado requiere un hard fork controvertido. La “base de código confiable” del protocolo—el código que los validadores deben ejecutar y verificar—se ha inflado a proporciones peligrosas. La lógica envolvente para un solo precompilado (como modexp) supera en complejidad a un intérprete completo de RISC-V. Esta acumulación ha provocado incidentes de fallo de consenso en Ethereum varias veces, evitados por poco mediante coordinación de emergencia.

Los desarrolladores del protocolo han llegado a un consenso: no más precompilados nuevos. El camino arquitectónico hacia adelante requiere pasar a un sistema donde las innovaciones criptográficas puedan desplegarse mediante código programable y verificable, en lugar de enmiendas al protocolo.

Por qué RISC-V, no otra alternativa

RISC-V no es una invención nativa de criptomonedas. Es un estándar de conjunto de instrucciones de código abierto que ha sido probado en batalla a lo largo de décadas de investigación en ciencias de la computación. Esta madurez ofrece tres ventajas decisivas:

Fundación minimalista: El conjunto de instrucciones base contiene aproximadamente 47 instrucciones. Esta simplicidad radical crea una superficie lo suficientemente pequeña para verificar formalmente mediante sistemas de prueba matemática—un lujo que la especificación extensa del EVM nunca permite. La especificación RISC-V SAIL existe en formato legible por máquina en lugar de lenguaje natural ambiguo, permitiendo que los circuitos zkVM verifiquen directamente contra estándares oficiales.

Herencia del ecosistema: Al adoptar RISC-V, Ethereum accede a la cadena de herramientas del compilador LLVM—que representa décadas de esfuerzo colectivo en ingeniería. Los desarrolladores que programan en Rust, Go, C++ o Python pueden compilar directamente a RISC-V mediante herramientas maduras y de producción. Esto elimina la necesidad de construir un ecosistema de software paralelo desde cero, una carga que retrasaría la adopción en años.

Estándar de facto para ZK: El mercado ya ha decidido. Nueve de los principales proyectos zkVM (incluyendo implementaciones de Succinct Labs, Nervos, Cartesi y otros) convergieron en RISC-V de forma independiente. Esto no es solo consenso—es una inevitabilidad tecnológica. La adopción de RISC-V por parte de Ethereum alinea el protocolo con las infraestructuras que ya han comenzado a construirse.

La estrategia de transición en tres fases

En lugar de una sustitución revolucionaria, Ethereum ejecutará una migración cuidadosamente secuenciada diseñada para mantener la compatibilidad hacia atrás y la estabilidad operativa:

Fase 1: Sustitución de precompilados

Las nuevas capacidades criptográficas que anteriormente requerían precompilados en el protocolo pueden implementarse como programas RISC-V en lista blanca. Esto introduce el entorno de ejecución en la mainnet en condiciones de bajo riesgo, proporcionando datos de prueba en el mundo real antes de un despliegue más amplio. La transición se gestiona completamente a nivel de cliente sin cambios en la capa de consenso.

Fase 2: Coexistencia de dos máquinas virtuales

Los contratos inteligentes declaran explícitamente si su bytecode apunta a ejecución en EVM o en RISC-V mediante un sistema de etiquetas. Los dos entornos logran una interoperabilidad fluida mediante llamadas al sistema (ECALL), permitiendo invocaciones cruzadas entre capas de ejecución. Este período permite que el ecosistema migre gradualmente sin decisiones inmediatas forzadas.

Fase 3: EVM como contrato implementado

La etapa final trata al EVM legado como especificaciones formales que se ejecutan dentro del entorno RISC-V—similar a cómo Linux puede ejecutarse en RISC-V a pesar de que originalmente apuntaba a x86. El protocolo mantiene soporte permanente para aplicaciones existentes, mientras que los desarrolladores de clientes mantienen un motor de ejecución único y simplificado. La deuda técnica se transforma en código implementable en lugar de carga protocolar.

Reorganización del ecosistema: la divergencia de Rollups

El paso a la ejecución nativa en RISC-V crea resultados radicalmente diferentes para las arquitecturas de Capa 2 en competencia:

Optimistic Rollups bajo presión

Los Optimistic Rollups (Arbitrum, Optimism) se aseguran re-ejecutando transacciones disputadas a través de L1, usando el EVM como entorno de resolución de disputas. Si el modelo de ejecución de L1 cambia fundamentalmente, este mecanismo de seguridad colapsa. Estos proyectos enfrentan una reconstrucción de ingeniería—ya sea construyendo sistemas de prueba de fraude compatibles con la ejecución en RISC-V o desacoplando las garantías de seguridad de la capa de consenso de Ethereum.

Ventaja estratégica de los zk Rollups

Los ZK Rollups ya operan de forma nativa en arquitecturas RISC-V. Un L1 que “habla el mismo idioma” permite lo que Justin Drake llama “Rollups nativos”—instancias de L2 que funcionan como configuraciones especializadas del entorno de ejecución de L1. Las implicaciones prácticas son sustanciales:

• Velocidad de desarrollo: Los equipos de L2 eliminan código de puente complejo entre la ejecución interna en RISC-V y las capas de liquidación externas. Las cadenas de herramientas del compilador, depuradores y utilidades de verificación desarrolladas para L1 son directamente aplicables a L2 sin modificaciones.
• Alineación económica: La tarifa de gas en L1 refleja directamente los costos computacionales de la verificación ZK basada en RISC-V en lugar de la operación en EVM. Esto crea incentivos más precisos y elimina distorsiones económicas entre capas.
• Economía de las pruebas: Generar la evidencia criptográfica que asegura la liquidación en L2 se vuelve mucho más barato. El costo de liquidación en L1 cae de varios dólares por transacción a centavos, permitiendo nuevos modelos económicos para aplicaciones de alta frecuencia.

Experiencia del desarrollador: del sandbox al ecosistema

La transformación democratiza el desarrollo en cadena. Actualmente, Solidity y Vyper representan los únicos lenguajes prácticos para contratos inteligentes—herramientas específicas del dominio que los desarrolladores deben aprender para trabajar en blockchain. Bajo RISC-V, los desarrolladores escriben en Rust, Go o Python usando las mismas bibliotecas, frameworks y herramientas de depuración que en el desarrollo de software tradicional.

Vitalik Buterin ha descrito esto como lograr una experiencia similar a “Node.js”—donde los desarrolladores escriben lógica tanto en cadena como fuera de ella en entornos de lenguaje idéntico, usando las mismas cadenas de herramientas. La fricción psicológica y práctica de “desarrollo en blockchain” como dominio especializado se evapora en gran medida. Los nuevos desarrolladores pueden aplicar conocimientos existentes directamente sin necesidad de reentrenamiento.

Para los desarrolladores de Solidity existentes, la línea de tiempo de transición se extiende en años. Las abstracciones elegantes de los contratos inteligentes en ese lenguaje seguirán siendo populares. Pero la opción de construir máquinas de estado complejas y lógica computacional en lenguajes de sistemas tradicionales transforma lo que es factible construir en cadena—especialmente para aplicaciones que requieren cálculo intensivo o estructuras de datos sofisticadas.

El punto de prueba de Succinct Labs

La teoría se convierte en realidad con SP1, un zkVM de alto rendimiento desarrollado por Succinct Labs que opera de forma nativa en RISC-V. SP1 valida toda la tesis técnica mediante implementación en producción en lugar de un artículo académico. Demuestra que la ejecución en RISC-V genera pruebas a costos económicamente viables manteniendo la compatibilidad con el modelo de seguridad de Ethereum.

Más importante aún, el producto OP Succinct de Succinct muestra el beneficio práctico inmediato: los Optimistic Rollups usando el stack OP pueden desplegar verificación de pruebas de conocimiento cero, reduciendo el tiempo de retiro de siete días a una hora. Este avance aborda simultáneamente dos puntos críticos del ecosistema—la lentitud en la finalización de confirmaciones en sistemas optimistas y la complejidad de integración de la verificación zk.

La Prover Network de Succinct funciona como un mercado descentralizado para la generación de pruebas, estableciendo el modelo económico para la computación verificable a escala. El modelo funciona: los validadores compiten para generar pruebas, los usuarios reciben un servicio de calidad, y el mercado descubre precios eficientes. Esto no es solo conceptual—es infraestructura operativa que procesa transacciones reales hoy.

Seguridad mediante simplicidad y formalización

Una de las ventajas subestimadas de RISC-V es su simplicidad arquitectónica que permite la verificación formal—probar matemáticamente la corrección del sistema en lugar de confiar en que las implementaciones estén libres de errores. Las especificaciones del Yellow Paper del EVM existen en lenguaje natural, creando ambigüedad irreducible. La especificación RISC-V SAIL es legible por máquina, proporcionando lo que los investigadores de seguridad llaman una “referencia dorada” para un comportamiento correcto.

Los investigadores de la Ethereum Foundation ya extraen circuitos zkVM para verificación formal contra las especificaciones oficiales de RISC-V usando probadores de teoremas como Lean. Esto representa una mejora de seguridad generacional: trasladar la confianza de implementaciones humanas susceptibles a pruebas matemáticas verificables.

La arquitectura privilegiada de RISC-V (que distingue la ejecución de aplicaciones en modo usuario del funcionamiento del núcleo en modo supervisor) proporciona capas adicionales de seguridad. Los contratos inteligentes en modo usuario no pueden acceder directamente al estado de la blockchain; emiten solicitudes a núcleos confiables mediante instrucciones ECALL estandarizadas. Esto refuerza los límites de seguridad a nivel arquitectónico en lugar de depender de implementaciones de sandbox de software, que tienen un historial más largo de vulnerabilidades.

Navegando riesgos genuinos

El camino de transición incluye desafíos sin resolver que requieren atención seria:

Complejidad en la contabilidad de gas

Crear un modelo de gas justo y determinista para conjuntos de instrucciones de propósito general sigue sin resolverse. La simple contabilización de instrucciones permite ataques de denegación de servicio donde programas cuidadosamente diseñados disparan fallos costosos en caché consumiendo poco gas. Los atacantes explotan esta arbitraria para agotar recursos de la red a bajo costo. La comunidad carece de mecanismos establecidos para medir y valorar el costo computacional real de instrucciones arbitrarias sin reintroducir especificaciones centralizadas.

Seguridad en la cadena de suministro del compilador

El modelo de seguridad pasa de confiar en máquinas virtuales en cadena a confiar en cadenas de herramientas fuera de cadena como LLVM. Los compiladores son extremadamente complejos—implementaciones de miles de líneas que realizan optimizaciones, creando superficies de ataque. Un adversario que explote vulnerabilidades en el compilador podría transformar código fuente inofensivo en bytecode malicioso indetectable mediante análisis estático.

El problema de “reconstrucción reproducible” agrava este riesgo: los desarrolladores no pueden verificar que el código binario en cadena coincida con el código fuente público sin reproducir exactamente el entorno de compilación. Diferencias menores en versiones, banderas del compilador o variables ambientales producen bytecode diferente, haciendo que las garantías de transparencia sean inútiles.

Estos problemas representan desafíos genuinos de ingeniería sin soluciones sencillas, especialmente a medida que la madurez del ecosistema y los incentivos de ataque aumentan.

Estrategia de defensa en múltiples capas

Mitigar estos riesgos requiere enfoques integrados y en capas, no soluciones únicas:

Despliegue gradual

La línea de tiempo de las tres fases de transición es una estrategia clave de gestión de riesgos. Las fases iniciales introducen RISC-V en condiciones donde los fallos tienen impacto limitado. El ecosistema acumula experiencia operativa y confianza de manera incremental, evitando compromisos irreversibles antes de reunir suficiente evidencia.

Pruebas y verificaciones agresivas

La verificación formal ofrece seguridad asintótica, pero requiere años para una implementación completa. Mientras tanto, las pruebas adversariales con herramientas de fuzzing (como la plataforma Argus de Diligence) ya han descubierto 11 vulnerabilidades críticas en la solidez de zkVM líderes. La combinación de fuzzing continuo con verificación formal proporciona una defensa en profundidad contra vulnerabilidades de implementación.

Configuración estandarizada

En lugar de fragmentarse en múltiples configuraciones de RISC-V, la comunidad debería converger en RV64GC con ABI compatible con Linux. Esta configuración maximiza la compatibilidad con lenguajes de programación principales y ecosistemas de herramientas existentes, reduciendo la superficie de ataque creada por extensiones personalizadas.

La capa verificable de Internet

La transición de EVM a RISC-V representa la evolución estructural de Ethereum, de una máquina virtual de contratos inteligentes especializada a algo fundamentalmente diferente: una infraestructura mínima y verificable de confianza para Internet mismo.

Esta transformación implica compromisos técnicos específicos: equilibrar las mejoras de rendimiento de 100x de la ejecución nativa ZK contra las obligaciones de compatibilidad hacia atrás; sopesar los beneficios de simplificación frente a los efectos de red que defienden el EVM existente; elegir la generalidad del ecosistema mientras se gestionan dependencias de herramientas de terceros.

En conjunto, esta reestructuración constituye el componente de ejecución de “Ethereum Lean”—una visión de simplificación del protocolo más amplia que modulariza los niveles de consenso, disponibilidad de datos y ejecución de forma independiente. Al seguir este camino, Ethereum se posiciona no como una plataforma monolítica de contratos inteligentes, sino como la capa de liquidación y confianza para un ecosistema interconectado de sistemas de computación verificable especializados.

Como dice el refrán: probar el mundo del software, abrir una nueva era de criptografía. La infraestructura existe. El caso técnico es abrumador. La única variable que queda es la ejecución.