La jugada RISC-V de Ethereum: Por qué Vitalik quiere eliminar la EVM y qué significa para cada desarrollador de dApps

¿Qué pasaría si el motor que impulsa 600 mil millones de dólares en contratos inteligentes estuviera frenando a Ethereum por órdenes de magnitud? Esa es la provocadora tesis que Vitalik Buterin planteó en abril de 2025 —y reforzó en marzo de 2026— cuando propuso reemplazar gradualmente la Máquina Virtual Ethereum (EVM) con RISC-V, una arquitectura de conjunto de instrucciones de CPU de código abierto. El movimiento podría desbloquear ganancias de eficiencia de 100x en la generación de pruebas de conocimiento cero (zero-knowledge proving), pero también amenaza con remodelar la experiencia del desarrollador, encender una guerra de arquitectura con los defensores de WebAssembly y obligar a todo el ecosistema de Ethereum a repensar cómo debería ser una máquina virtual de blockchain.

El impuesto oculto de la EVM

La EVM fue revolucionaria en 2015. Una máquina de pila de 256 bits diseñada para la computación sin confianza (trustless), dio a luz a un ecosistema de más de 4,000 aplicaciones descentralizadas e hizo que el término "contrato inteligente" fuera conocido por todos. Pero una década de uso en producción ha expuesto limitaciones estructurales que ninguna cantidad de optimización incremental puede solucionar.

El problema central es la sobrecarga (overhead). La EVM se ejecuta como un intérprete de software en CPUs modernas de 64 bits, traduciendo cada opcode a través de una capa de abstracción que nunca fue diseñada para un rendimiento bruto. Para la ejecución de transacciones ordinarias, esta sobrecarga es manejable. Para la generación de pruebas de conocimiento cero (ZK) —la tecnología de la que depende cada vez más la hoja de ruta de Ethereum— es devastadora.

Los probadores (provers) ZK actuales ya trabajan traduciendo internamente el bytecode de la EVM a RISC-V antes de generar las pruebas. Esta doble traducción introduce lo que Buterin describe como una "sobrecarga de 800x" en los tiempos de prueba de las zkVM. El árbol de estado y la VM juntos representan más del 80 por ciento del cuello de botella en la generación eficiente de pruebas, lo que significa que no importa qué tan rápidos se vuelvan los probadores, la propia EVM sigue siendo el techo.

Entra RISC-V: La oportunidad de 100x

RISC-V es una arquitectura de conjunto de instrucciones (ISA) de código abierto nacida de dos décadas de investigación de CPUs en la UC Berkeley. A diferencia de las arquitecturas propietarias de ARM o Intel, RISC-V es modular, extensible y libre de regalías. Su diseño basado en registros se mapea limpiamente en el hardware moderno, y su simplicidad —un intérprete RISC-V mínimo puede escribirse en unas pocas cientos de líneas de código— lo hace ideal para la verificación formal.

El caso del rendimiento es convincente. Al ejecutar contratos inteligentes de forma nativa en RISC-V en lugar de interpretar el bytecode de la EVM, Ethereum podría:

• Eliminar la penalización por doble traducción: Los probadores ZK ya no necesitarían convertir EVM a RISC-V antes de generar pruebas, lo que potencialmente reduciría la sobrecarga de las pruebas entre 50 y 100 veces.
• Simplificar el protocolo: Las operaciones del sistema como SLOAD y CALL se convertirían en llamadas al sistema (syscalls) en lugar de opcodes personalizados, reduciendo la superficie de ataque y la carga de mantenimiento.
• Aprovechar las herramientas existentes: RISC-V ya cuenta con compiladores maduros GCC y LLVM, emuladores QEMU y cadenas de herramientas (toolchains) verificadas formalmente; un ecosistema de soporte que la EVM nunca podrá igualar.
• Alinearse con el ecosistema ZK: Las principales zkVM, incluyendo SP1 de Succinct, RISC Zero, Jolt de a16z, OpenVM de Axiom y Miden de Polygon, están construidas sobre RISC-V, creando un punto de convergencia natural.

Los números de los sistemas en producción respaldan esto. El Hypercube SP1 de Succinct puede generar pruebas de conocimiento cero para bloques de Ethereum en menos de 12 segundos utilizando 16 GPUs NVIDIA RTX 5090. El R0VM 2.0 de RISC Zero redujo los tiempos de prueba de 35 minutos a 44 segundos. Estas ganancias se lograron mientras aún se trabajaba a través de la capa de traducción de la EVM; la ejecución nativa de RISC-V las ampliaría aún más.

El plan de migración en tres fases

La propuesta de Buterin no es una reescritura imprudente. Es una migración cuidadosamente planificada y diseñada para mantener la compatibilidad con versiones anteriores en todo momento:

Fase 1 — Reemplazo de precompilaciones (Precompiles): El código RISC-V reemplaza aproximadamente el 80% de los contratos precompilados existentes de Ethereum. Estas son las operaciones criptográficas y aritméticas (como los emparejamientos de curvas elípticas y el hash SHA-256) que actualmente existen como funciones nativas codificadas. Al implementarlas en RISC-V, el protocolo se vuelve más auditable y extensible sin sacrificar el rendimiento.

Fase 2 — Despliegue de VM dual: Los desarrolladores obtienen la capacidad de desplegar contratos inteligentes compilados a bytecode de RISC-V junto con los contratos de la EVM existentes. El código de Solidity y Vyper se compilaría a RISC-V en lugar de bytecode de la EVM; la experiencia del desarrollador sigue siendo familiar, pero la capa de ejecución cambia por debajo.

Fase 3 — Retiro de la EVM: La propia EVM se convierte en un contrato inteligente escrito en RISC-V. Cada contrato de la EVM existente continúa ejecutándose exactamente como antes, procesado por este intérprete "EVM-en-RISC-V". El único cambio de cara al usuario serían los cambios en los costos de gas a medida que la nueva arquitectura redefine el precio de las operaciones.

Esta fase final es la parte más elegante de la propuesta. En lugar de romper la compatibilidad con versiones anteriores, la preserva por completo: la EVM no desaparece; se convierte en una librería que se ejecuta sobre una base más eficiente.

El compañero del EIP-7864: Árboles de estado binarios

En marzo de 2026, Buterin amplió la propuesta con el EIP-7864, que aborda la otra mitad del cuello de botella de la generación de pruebas: el árbol de estado de Ethereum. El actual Árbol Patricia de Merkle Keccak hexario sería reemplazado por un árbol binario utilizando una función de hash más eficiente — ya sea Blake3 o una variante de Poseidon.

El impacto es sustancial:

• Las ramas de Merkle se vuelven cuatro veces más cortas, reduciendo el ancho de banda de datos para clientes ligeros como Helios.
• La sustitución de la función de hash ofrece una mejora adicional de 3 a 100 veces en la eficiencia de la generación de pruebas.
• Junto con el cambio de la VM, las dos actualizaciones apuntan al más del 80 % de los costos de prueba que actualmente limitan la escalabilidad de Ethereum.

La secuencia de Buterin es deliberada: árboles binarios primero (potencialmente en las actualizaciones Glamsterdam o Hegota en 2026), seguidos por el reemplazo de la VM una vez que la infraestructura de generación de pruebas madure.

El contraargumento de WASM

No todo el mundo está convencido de que RISC-V sea la respuesta correcta. En noviembre de 2025, investigadores de Offchain Labs — el equipo detrás de Arbitrum — publicaron una refutación técnica detallada argumentando que WebAssembly (WASM) es la mejor opción a largo plazo.

Su argumento central se basa en una distinción importante: la "ISA de entrega" (el formato en el que se almacenan y distribuyen los contratos) y la "ISA de prueba" (el formato utilizado para la generación de pruebas ZK) no necesitan ser la misma. Offchain Labs ya está demostrando esto en la práctica: los bloques de Arbitrum, incluidos los contratos inteligentes Stylus basados en WASM, se prueban mediante ZK compilando WASM a RISC-V en el momento de la prueba.

El bando de WASM plantea varias preocupaciones:

• Compatibilidad de hardware: La mayoría de los nodos de Ethereum carecen de CPUs RISC-V y requerirían emulación, mientras que WASM se ejecuta de forma nativa en miles de millones de entornos de ejecución.
• Bloqueo del ecosistema: Consagrar RISC-V en la L1 podría encadenar a Ethereum a una tecnología de prueba específica justo cuando surgen mejores alternativas.
• Madurez de las herramientas: El ecosistema de herramientas de WASM está probado en navegadores web, infraestructura en la nube y computación en el borde (edge computing).
• Alternativas emergentes: Las ZK-VM basadas en WASM, como Ligetron de Ligero, ya están demostrando ventajas que las ISA centradas en hardware podrían no igualar.

El debate está lejos de resolverse. Ambas partes coinciden en que la EVM debe evolucionar; no están de acuerdo en si el formato de ejecución debe optimizarse para la generación de pruebas (RISC-V) o para la flexibilidad de despliegue (WASM).

La apuesta paralela de Polkadot

Ethereum no es la única cadena de bloques que adopta RISC-V. El protocolo JAM de Polkadot, que avanza hacia su especificación 1.0, utiliza PolkaVM — un recompilador "ahead-of-time" basado en RISC-V — como su motor de ejecución. La actualización de la red principal de JAM está prevista para el primer trimestre de 2026, con velocidades de bloque que aumentarán 10 veces hasta alcanzar bloques de 500 milisegundos.

El proyecto Revive de Polkadot combina el backend RISC-V de PolkaVM con un intérprete de EVM totalmente compatible, lo que permite a los desarrolladores elegir entre la compatibilidad con Ethereum y el máximo rendimiento de Polkadot. Este enfoque de modo dual refleja el período de transición que Buterin prevé para la Fase 2 de Ethereum.

La convergencia es notable: dos de los ecosistemas más grandes de blockchain concluyeron de forma independiente que RISC-V ofrece el mejor camino a seguir para la ejecución de contratos inteligentes de alto rendimiento.

Qué cambia para los desarrolladores

Para el desarrollador promedio de Solidity, el impacto inmediato es sorprendentemente pequeño. En el futuro de RISC-V:

• Solidity y Vyper sobreviven: Los desarrolladores continúan escribiendo en lenguajes familiares. El backend del compilador cambia de bytecode de EVM a bytecode de RISC-V, pero el código fuente y el flujo de trabajo de desarrollo siguen siendo prácticamente los mismos.
• Surgen nuevas opciones de lenguaje: Rust — el lenguaje que ya domina en el desarrollo de Solana, Polkadot y NEAR — se convierte en un ciudadano de primera clase para los contratos inteligentes de Ethereum. Esto podría atraer a desarrolladores de ecosistemas competidores.
• Cambian los costos de gas: Las operaciones se retasarán para reflejar los costos de ejecución de RISC-V en lugar de los costos de los opcodes de la EVM. Algunas operaciones se volverán más baratas; otras podrían volverse más caras.
• Las pruebas y herramientas se adaptan: Entornos como Hardhat y Foundry necesitarían objetivos de compilación para RISC-V, aunque la infraestructura LLVM existente hace que esto sea más manejable que construir herramientas para EVM desde cero.

El cambio más importante es filosófico. La capa de ejecución de Ethereum pasa de una máquina virtual hecha a medida y específica para blockchain a una arquitectura de computación de propósito general respaldada por décadas de investigación académica y herramientas industriales. Esto no es solo una mejora de rendimiento — es una apuesta a que las cadenas de bloques deben converger con la informática convencional en lugar de mantener una infraestructura separada.

El camino por delante

La propuesta de RISC-V aún no cuenta con consenso dentro de la comunidad de desarrollo de Ethereum. Es probable que las actualizaciones Glamsterdam y Hegota previstas para 2026 prioricen los cambios en el árbol de estado del EIP-7864, mientras que el reemplazo de la VM sigue siendo un objetivo a más largo plazo.

Pero la dirección del viaje es clara. El ecosistema de generación de pruebas ZK ya se ha estandarizado en RISC-V. Los datos de rendimiento son inequívocos. Y el diseño de retrocompatibilidad significa que Ethereum puede realizar esta transición sin romper ni un solo contrato existente.

La verdadera pregunta no es si Ethereum eventualmente superará la EVM, sino qué tan rápido puede alinearse la comunidad sobre el reemplazo — y si RISC-V o WASM ganan ese debate. Para los desarrolladores que construyen hoy en Ethereum, el mensaje es tranquilizador: sus contratos de Solidity seguirán funcionando pase lo que pase. Pero los constructores más astutos ya se están preparando para un mundo donde Ethereum hable RISC-V de forma nativa, y para la eficiencia de prueba de 100 veces que eso conlleva.

BlockEden.xyz proporciona infraestructura de RPC y API de grado empresarial para Ethereum y las principales redes de Capa 2. A medida que la capa de ejecución evoluciona, nuestra infraestructura se adapta — asegurando que los desarrolladores puedan construir a la vanguardia sin gestionar la complejidad subyacente. Explore nuestros servicios de API de Ethereum para preparar la infraestructura de su dApp para el futuro.