Encrucijada arquitectónica de Ethereum: por qué RISC-V representa el futuro del cálculo verificable

El ecosistema de Ethereum se encuentra en un punto de inflexión. Lo que comenzó como una plataforma revolucionaria de contratos inteligentes ha acumulado capas de complejidad técnica que ahora amenazan sus ambiciones de escalabilidad. En el centro de este desafío se encuentra la Máquina Virtual de Ethereum—la capa de ejecución fundamental que ha impulsado el éxito de la plataforma pero que cada vez actúa más como un factor limitante en una era definida por pruebas de conocimiento cero y verificación de alto rendimiento.

La crisis de rendimiento: Cuando la EVM encontró las pruebas de conocimiento cero

La raíz del desafío de escalabilidad de Ethereum no es misteriosa. A medida que la red se desplazó hacia sistemas de verificación basados en pruebas de conocimiento cero, surgió una ineficiencia fundamental en cómo la EVM interactúa con las ZK proofs. Las implementaciones actuales de zkEVM no prueban directamente la máquina virtual en sí. En cambio, prueban el intérprete de la EVM, que luego se compila en código byte RISC-V. Esta indirecta arquitectónica crea una penalización de rendimiento enorme—las estimaciones sitúan la sobrecarga entre 50 y 800 veces más lenta que la ejecución nativa de programas.

El problema se agrava al considerar la economía de la red. Incluso con algoritmos hash optimizados como Poseidon, la generación de pruebas para la ejecución de bloques aún consume entre el 80 y el 90% del tiempo total de prueba. Vitalik Buterin articuló este problema directamente: si la arquitectura subyacente ya se compila a RISC-V, ¿por qué mantener la capa interpretativa de la EVM? La respuesta es simple—eliminarla.

Más allá de la sobrecarga del intérprete, la base técnica de la EVM revela restricciones más profundas. El diseño de pila de 256 bits fue optimizado para operaciones criptográficas en una era informática anterior. Los contratos inteligentes modernos trabajan típicamente con enteros de 32 o 64 bits, pero la EVM obliga a que todos los valores pasen por su arquitectura de 256 bits. En sistemas de conocimiento cero, esta ineficiencia resulta especialmente costosa—los números más pequeños consumen más recursos en la generación de pruebas, no menos, mientras que la complejidad computacional aumenta de dos a cuatro veces.

El problema de la deuda: Módulos precompilados como arena movediza técnica

Para compensar las limitaciones de rendimiento de la EVM en operaciones criptográficas específicas, Ethereum introdujo contratos precompilados—funciones codificadas en hardware que se integran directamente en el protocolo. Aunque pragmático a corto plazo, este enfoque creó lo que Vitalik Buterin caracterizó como una deuda técnica “catastrófica”.

La magnitud de este problema es asombrosa. El código envoltorio para un solo contrato precompilado (como modexp) supera toda la base de código de un intérprete RISC-V completo. Añadir nuevas funciones precompiladas requiere una gobernanza de bifurcación dura controvertida, limitando severamente la innovación del protocolo cuando las aplicaciones necesitan primitivas criptográficas novedosas. La superficie de seguridad se ha expandido peligrosamente, con la complejidad del protocolo aumentando de forma constante. Como concluyó Buterin: “Deberíamos dejar de añadir nuevos contratos precompilados a partir de hoy.”

La solución RISC-V: Por qué un estándar abierto supera a una arquitectura personalizada

RISC-V no es un producto, sino un conjunto de instrucciones de arquitectura de código abierto—un plano de construcción de procesadores de acceso libre. Su filosofía de diseño refleja lecciones aprendidas de décadas de evolución en arquitectura de computadoras, lo que lo hace excepcionalmente adecuado para la próxima fase de Ethereum.

Minimalismo arquitectónico

El conjunto de instrucciones básico de RISC-V contiene aproximadamente 47 instrucciones. Esta simplicidad extrema es intencional, no una limitación. Una base de código confiable más pequeña resulta mucho más fácil de auditar y verificar formalmente—requisitos críticos para protocolos que aseguran miles de millones en valor de usuario. Operaciones complejas se añaden mediante extensiones opcionales que mantienen la simplicidad central sin imponer una hinchazón innecesaria en el protocolo.

Aprovechamiento del ecosistema a través de LLVM

Al adoptar RISC-V, Ethereum accede a décadas de desarrollo de infraestructura de compiladores a través de LLVM (Low-Level Virtual Machine). Esta decisión única otorga soporte nativo para Rust, Go, C++, Python y docenas de otros lenguajes. Los desarrolladores en todo el mundo ya tienen competencia con estas herramientas. En lugar de construir un ecosistema de software novedoso desde cero, Ethereum puede heredar una infraestructura madura y probada que ya soporta a millones de desarrolladores.

La ventaja práctica no puede ser subestimada. Crear cadenas de herramientas de compilación es extraordinariamente difícil; aprovechar las existentes multiplica la eficiencia del desarrollo. A través de la adopción de RISC-V, Ethereum adquiere esencialmente acceso gratuito a infraestructura de compiladores de clase mundial que sería prohibitivamente costosa de construir de forma independiente.

El mercado zkVM ya ha decidido

La señal del ecosistema de pruebas de conocimiento cero es inequívoca. Entre diez backends de zkVM capaces de probar bloques de Ethereum, nueve ya han adoptado RISC-V como su arquitectura objetivo. Esta convergencia representa una validación práctica más que una especulación teórica. Los proyectos que construyen el futuro ZK han concluido de forma independiente que RISC-V es la opción óptima para la computación verificable. La adopción de Ethereum se alinea con el impulso del mercado, en lugar de crearlo.

Verificación formal mediante especificación SAIL

La especificación de la EVM existe principalmente en forma de lenguaje natural dentro del Yellow Paper—inherentemente ambigua y difícil de formalizar matemáticamente. RISC-V, en contraste, incluye una especificación SAIL legible por máquina que proporciona un “estándar de oro” para la verificación formal.

Esta distinción importa profundamente. La verificación formal permite pruebas matemáticas de la corrección del sistema—transformando la confianza de implementaciones humanas falibles a garantías criptográficas verificables. Los investigadores de la Ethereum Foundation ya trabajan en extraer circuitos zkVM RISC-V para verificación formal contra la especificación oficial en el asistente de pruebas Lean. Esto representa un momento decisivo: migrar de una seguridad dependiente de la implementación a una basada en la especificación.

La migración en tres fases: evolución, no revolución

Reconociendo los riesgos de una transformación arquitectónica, el liderazgo de Ethereum ha propuesto un enfoque deliberado y en varias etapas que prioriza la compatibilidad hacia atrás y la estabilidad operativa.

Fase uno: Introducción limitada de zkVM

Inicialmente, la funcionalidad RISC-V se introducirá mediante alternativas precompiladas—reemplazando efectivamente los contratos precompilados EVM obsoletos con funciones equivalentes implementadas como programas RISC-V en lista blanca. Esto permite pruebas en la mainnet en entornos controlados y de bajo riesgo. La nueva máquina virtual se prueba a través de validación práctica antes de un despliegue más amplio.

Fase dos: Coexistencia de dos máquinas virtuales

Una vez que se gane confianza, los contratos inteligentes podrán dirigirse explícitamente a código byte EVM o RISC-V mediante etiquetas de contrato. La innovación clave es la interoperabilidad sin fisuras—los contratos EVM y RISC-V se llaman entre sí mediante llamadas al sistema estandarizadas (ECALL). Esto crea un entorno de ejecución unificado donde ambas arquitecturas colaboran dentro del mismo protocolo.

Fase tres: La EVM como especificación formal

El objetivo final trata la EVM como un contrato inteligente formalmente verificado que se ejecuta en RISC-V nativo en la capa L1. Las aplicaciones heredadas reciben soporte permanente a través de la implementación, mientras que los desarrolladores del protocolo mantienen un único motor de ejecución. La complejidad desaparece; las cargas de mantenimiento disminuyen drásticamente.

Reorganización radical del ecosistema: ganadores y perdedores en la nueva arquitectura

La transición arquitectónica reordenará fundamentalmente la economía de Layer 2 y los incentivos de los desarrolladores en todo el ecosistema de Ethereum.

Los rollups optimistas enfrentan desafíos existenciales

Proyectos como Arbitrum y Optimism construyeron sus modelos de seguridad en torno a mecanismos de prueba de fraude que funcionan re-ejecutando transacciones disputadas a través de la EVM en L1. Cuando la EVM desaparezca, su base de seguridad colapsará. Estos proyectos enfrentan decisiones duras: realizar esfuerzos de ingeniería masivos para rediseñar sistemas de prueba de fraude para RISC-V, o desacoplarse por completo de las garantías de seguridad de Ethereum. La transición probablemente acelerará la convergencia hacia modelos basados en ZK.

Los rollups de conocimiento cero ganan ventaja estratégica

Lo inverso aplica a los ZK Rollups. La mayoría de los proyectos ya estandarizaron internamente en RISC-V. Cuando L1 “habla el mismo idioma”, la eficiencia de integración se dispara. La visión de Justin Drake de “rollups nativos” describe a los L2 como instancias especializadas del entorno de ejecución de L1—logrando liquidaciones sin capas de traducción.

Los beneficios prácticos son profundos:

• Unificación del compilador: Las herramientas desarrolladas para RISC-V en L1 sirven inmediatamente a los constructores de L2
• Alineación del modelo de gas: L1 y L2 verifican usando conjuntos de instrucciones idénticos, creando precios económicos más racionales
• Reutilización de código: Las herramientas de depuración, verificación formal y optimización se vuelven universalmente aplicables

Transformación en la experiencia de desarrolladores y usuarios

Para los desarrolladores, el cambio representa una liberación de las limitaciones de la EVM sin requerir abandonar el ecosistema. Los lenguajes de programación convencionales de repente se vuelven herramientas viables para el desarrollo en cadena. Los desarrolladores pueden escribir contratos en Rust manteniendo la familiaridad con los marcos estándar del ecosistema. Como sugirió Buterin, “Solidity y Vyper seguirán siendo populares durante mucho tiempo dada su elegante diseño para lógica de contratos inteligentes,” pero se convierten en opciones de implementación en lugar de enfoques obligatorios.

Esto es paralelo a cómo Node.js permitió a los desarrolladores escribir JavaScript tanto para cliente como para servidor. El mismo desarrollador ahora puede usar lenguajes idénticos para computación fuera de cadena y en cadena, simplificando drásticamente los flujos de trabajo de desarrollo.

Para los usuarios, las implicaciones son aún más transformadoras. Se espera que los costos de prueba disminuyan aproximadamente 100 veces—lo que traduce los costos actuales de varias dólares a unos pocos centavos o menos. Esta viabilidad económica desbloquea la visión de “Gigagas L1”, apuntando a aproximadamente 10,000 transacciones por segundo. Las aplicaciones complejas y de alto valor en cadena se vuelven económicamente factibles.

Succinct Labs y SP1: Prueba de que la transición funciona

La transición de Ethereum de una propuesta teórica a una realidad práctica ganó impulso gracias a equipos como Succinct Labs, cuyo implementación zkVM SP1 demuestra que la verificación basada en RISC-V no solo es factible sino operativamente eficiente.

SP1 adopta una arquitectura “centrada en precompilados” que aborda directamente los cuellos de botella criptográficos que impiden la escalabilidad de la EVM. En lugar de depender de funciones precompiladas lentas y codificadas en hardware, SP1 descarga operaciones intensivas como el hash Keccak a circuitos ZK especializados invocados mediante instrucciones ECALL estándar. Este enfoque híbrido combina el rendimiento del hardware personalizado con la flexibilidad del software.

El impacto práctico se materializó de inmediato. El producto OP Succinct de Succinct añadió capacidades de prueba de conocimiento cero a las pilas de Rollup optimistas. El resultado: la finalización de retiros se redujo de siete días a aproximadamente una hora. Este avance aborda puntos críticos de dolor en todo el ecosistema optimista y demuestra cómo la arquitectura RISC-V permite mejoras cualitativas en la experiencia del usuario.

Más allá de proyectos individuales, la Red de Provers de Succinct representa un modelo económico viable para la generación descentralizada de pruebas—estableciendo plantillas prácticas para el futuro de la computación verificable.

La transformación conlleva riesgos reales

A pesar de las ventajas arquitectónicas de RISC-V, la transición introduce desafíos novedosos que requieren estrategias de mitigación rigurosas.

Complejidad en la medición de gas

Crear modelos de gas deterministas y justos para conjuntos de instrucciones de propósito general sigue siendo en gran medida un problema sin resolver. Contar instrucciones simples se vuelve vulnerable a vectores de denegación de servicio. Los atacantes pueden diseñar programas que disparen fallos repetidos en caché, consumiendo recursos sustanciales mientras minimizan el costo en gas. Esta amenaza plantea serios desafíos para la estabilidad de la red y los modelos económicos.

Seguridad en compiladores y cadenas de herramientas

Un riesgo sutil pero crítico, a menudo subestimado: las dependencias de seguridad se desplazan de las máquinas virtuales en cadena a los compiladores externos como LLVM. Estas herramientas son extraordinariamente complejas y contienen vulnerabilidades conocidas. Los atacantes sofisticados podrían explotar errores en los compiladores para transformar código fuente inocente en bytecode malicioso. El problema de “reconstrucción reproducible” agrava este desafío—pequeñas variaciones en el entorno producen binarios diferentes, amenazando la transparencia y las garantías de confianza.

Fragmentación del ecosistema

Sin una estandarización, diferentes configuraciones de RISC-V podrían proliferar en los proyectos, fragmentando el ecosistema y negando muchas de las ventajas de RISC-V. La coordinación en torno a una única configuración estándar (probablemente RV64GC con ABI compatible con Linux) es esencial.

Mitigación mediante capas: Verificación formal, pruebas intensivas y estandarización

Abordar estos riesgos requiere estrategias de defensa en múltiples capas.

El despliegue en fases en sí mismo funciona como una estrategia de mitigación—el despliegue inicial en escenarios precompilados de bajo riesgo construye confianza operativa antes de una migración más amplia. Al mismo tiempo, la comunidad debe perseguir esfuerzos agresivos de verificación formal combinados con pruebas adversariales continuas.

Valentine de Diligence Security demostró que incluso los zkVM líderes contienen vulnerabilidades críticas que solo se descubren mediante pruebas fuzz rigurosas. Las estrategias de seguridad integrales combinan la verificación formal (el fundamento teórico) con pruebas intensivas (validación práctica).

La estandarización en torno a una única configuración de RISC-V maximiza la coherencia del ecosistema, asegura soporte para múltiples lenguajes de programación y previene la fragmentación que socavaría los beneficios de la transición.

El futuro verificable toma forma

La propuesta de Ethereum de migrar de la EVM a RISC-V representa más que una simple optimización incremental—constituyó una reestructuración fundamental de la capa de ejecución del protocolo. Este cambio aborda cuellos de botella profundos de escalabilidad, elimina la deuda técnica de los contratos precompilados y alinea a Ethereum con el ecosistema más amplio de computación verificable y especificación formal de código en cadena.

El camino por delante requiere equilibrar demandas contrapuestas: ganancias de rendimiento extraordinarias mediante una arquitectura nativa ZK frente a la compatibilidad hacia atrás; beneficios de seguridad por simplificación del protocolo frente a los efectos en red de la infraestructura EVM existente; y las capacidades de un ecosistema de computación de propósito general frente a los riesgos de cadenas de herramientas de terceros complejas.

En última instancia, esta evolución arquitectónica encarna el compromiso de Ethereum con el “Ejecución Lean” y la visión más amplia de “Ethereum Lean”. En lugar de seguir siendo una plataforma de contratos inteligentes, Ethereum se convertirá en una capa de liquidación eficiente, segura y de disponibilidad de datos diseñada para soportar el vasto universo de la computación verificable.

La visión final de Vitalik Buterin—“proveer ZK-snarks para todo”—se acerca cada vez más a la realidad, a medida que proyectos como Succinct Labs demuestran que RISC-V no es solo una arquitectura especulativa, sino una ingeniería práctica a corto plazo. Al adoptar RISC-V, Ethereum se posiciona como la capa de confianza fundamental para la próxima generación de infraestructura de internet—impulsada por pruebas criptográficas en lugar de intermediarios de confianza.

La era del software verificable ha llegado.