La Propuesta Radical de Vitalik Buterin: Reemplazar la EVM con RISC-V
El cofundador de Ethereum, Vitalik Buterin, ha presentado una propuesta audaz y a largo plazo para reemplazar la actual Máquina Virtual de Ethereum (EVM) con la arquitectura del conjunto de instrucciones RISC-V. Esta iniciativa busca mejorar significativamente la velocidad y la eficiencia de la capa de ejecución de Ethereum, abordando así uno de los principales cuellos de botella en la escalabilidad de la red. La propuesta, detallada en el foro Ethereum Magicians con fecha del 20 de abril de 2025, plantea una transformación fundamental en el corazón de cómo Ethereum procesa los contratos inteligentes.
El Cuello de Botella de la EVM
Buterin argumenta que la capa de ejecución es uno de los mayores obstáculos para la escalabilidad de Ethereum. La única forma de lograr mejoras sustanciales en este ámbito podría ser una revisión profunda, un «empezar de nuevo» para la capa de ejecución, similar al esfuerzo de la «beam chain» para la capa de consenso. En un contexto donde Ethereum busca mantener su competitividad frente a blockchains de nueva generación como Solana y Sui, que ofrecen mayor rendimiento, esta propuesta adquiere especial relevancia. La disminución de las tarifas de red de Ethereum, atribuida a la migración de usuarios a soluciones de capa 2, también ha generado preocupación sobre la generación de ingresos en la capa base, lo que subraya la necesidad de mejorar la eficiencia.
¿Por qué RISC-V?
La elección de RISC-V no es casual. Buterin señala que las herramientas criptográficas utilizadas para escalar Ethereum, los probadores de conocimiento cero (ZK), actualmente simulan la EVM traduciéndola a RISC-V. Al dar a los desarrolladores acceso directo a RISC-V, en lugar de enrutar todo a través de la EVM, se podría eliminar una cantidad significativa de complejidad innecesaria. Esto podría traducirse en ganancias de eficiencia de hasta 100 veces en casos limitados. Además, la adopción de RISC-V en los contratos inteligentes podría mantener competitivos los mercados de producción de bloques y mejorar la eficiencia de las funciones de conocimiento cero dentro de la capa de ejecución. Nervos CKB VM y Polkadot son mencionados como proyectos que ya están experimentando con RISC-V.
Beneficios Potenciales
La implementación de esta propuesta podría generar varios beneficios clave:
- Mejora drástica de la eficiencia y la velocidad de la capa de ejecución. Se sugieren ganancias de eficiencia de hasta 100 veces.
- Simplificación de la arquitectura de la capa de ejecución, considerada quizás la única manera de lograr una simplificación significativa.
- Mantenimiento de la competitividad en el mercado de producción de bloques.
- Optimización de la eficiencia de las pruebas de conocimiento cero (ZK). Al eliminar la necesidad de traducir la EVM a RISC-V para las pruebas ZK, se podría reducir la complejidad y mejorar el rendimiento.
Implementación y Continuidad para Desarrolladores
Es crucial destacar que los conceptos básicos de los contratos inteligentes, como cuentas, almacenamiento y llamadas entre contratos, se mantendrían exactamente igual. Se espera que la mayoría de los desarrolladores continúen escribiendo contratos inteligentes en Solidity (o Vyper), que se adaptarían para agregar RISC-V como backend. Esto significa que el proceso de desarrollo podría cambiar mínimamente y los desarrolladores apenas notarían la transformación. Además, los contratos EVM antiguos seguirán funcionando y serán totalmente interoperables con los nuevos contratos RISC-V. Se han propuesto varias formas de llevar a cabo esta transición, incluyendo:
- Soportar dos VMs simultáneamente, permitiendo que los contratos se escriban en cualquiera de ellas.
- Convertir los contratos EVM existentes en contratos que llamen a un intérprete EVM escrito en RISC-V para ejecutar su código actual.
- Consagrar el concepto de un «intérprete de máquina virtual» como una característica del protocolo, exigiendo que su lógica se escriba en RISC-V, siendo la EVM el primero, pero permitiendo otros en el futuro. Esta última opción simplificaría enormemente la especificación de la capa de ejecución.
Desafíos y Consideraciones
A pesar de los prometedores beneficios, la adopción de RISC-V también presenta desafíos y genera preocupaciones importantes:
- Optimización y Hardware: Existe la preocupación de que descender a una arquitectura de CPU de bajo nivel como RISC-V dificultaría la optimización de nuevo a operaciones de nivel superior (como las operaciones UInt256 utilizadas en la EVM), lo que podría deteriorar el rendimiento de la construcción y ejecución de bloques en hardware AMDx64 o ARM64, que son los más utilizados por los validadores. Actualmente no existe hardware RISC-V de alto rendimiento ampliamente adoptado por los validadores.
- Syscalls y Precompilados: Opcodes fundamentales como SLOAD y CALL se convertirían en syscalls en un sistema RISC-V. Existe la incertidumbre sobre la dificultad de probar estos elementos específicos en ZK y si podrían convertirse en nuevos cuellos de botella. Algunos argumentan que RISC-V no funcionaría sin precompilados para la carga útil de la EVM, lo que implicaría la necesidad de escribir y auditar circuitos para estas primitivas criptográficas, sin ofrecer una simplificación real en este aspecto.
- Prioridades de Ethereum: Se cuestiona si la prioridad actual de Ethereum debería ser la ejecución de L1, la simplicidad, la descentralización o la habilitación de L2, ya que esta propuesta parece beneficiar principalmente la ejecución de L1 con un beneficio limitado para el modelo L2. Se han propuesto otras mejoras que podrían beneficiar tanto a L1 como a L2.
- RISC-V y Computación Verificable: Algunos expertos sugieren que RISC-V podría no ser la mejor opción para la computación verificable, ya que no fue diseñado con ese propósito en mente. Una ISA diseñada específicamente para pruebas SNARK podría ser más adecuada. Se ha propuesto la construcción de una arquitectura amigable para pruebas con una MMU mínima que permita ejecutar contratos como ejecutables separados.
- Madurez de las Implementaciones de RISC-V: Se señala que ninguna de las máquinas virtuales RISC-V está lista para producción y que su complejidad es considerable. Además, los compiladores como LLVM, que podrían usarse para compilar a RISC-V, tienen sus propios problemas de errores.
Conclusión
La propuesta de Vitalik Buterin de reemplazar la EVM con RISC-V representa una visión ambiciosa para el futuro de Ethereum, con el potencial de desbloquear mejoras significativas en la eficiencia y la velocidad de la red. La posibilidad de simplificar la capa de ejecución y optimizar las pruebas de conocimiento cero son argumentos convincentes a su favor. Sin embargo, existen desafíos técnicos sustanciales relacionados con la optimización del rendimiento, la gestión de syscalls y precompilados, y la idoneidad de RISC-V para la computación verificable. La decisión final sobre la implementación de este cambio radical dependerá de una cuidadosa evaluación de estos desafíos y de las prioridades estratégicas a largo plazo de la red Ethereum. Aunque aún se encuentra en una etapa de propuesta, esta idea subraya el compromiso continuo de la comunidad Ethereum con la innovación y la mejora de la escalabilidad.
Eventos Principales:
Semana del 30 de marzo de 2025: Las tarifas de blob de Ethereum, que son tarifas de transacción de redes de escalado de capa 2 de Ethereum, cayeron a un mínimo semanal de 3.18 Ether (ETH), equivalentes a aproximadamente $5,000.
Abril de 2025: Las tarifas de la red Ethereum alcanzaron sus niveles más bajos desde 2020, promediando alrededor de $0.16 por transacción.
20 de abril de 2025: Vitalik Buterin publica una propuesta en el foro Ethereum Magicians titulada «Long-term L1 execution layer proposal: replace the EVM with RISC-V». En esta propuesta, sugiere reemplazar la actual Ethereum Virtual Machine (EVM) con la arquitectura del conjunto de instrucciones RISC-V para mejorar la velocidad y eficiencia de la capa de ejecución de Ethereum.
Abril de 2025 (posterior al 20): Diversos medios de noticias criptográficas, como Binance News, Cointelegraph y The Crypto Times, informan sobre la propuesta de Vitalik Buterin de reemplazar la EVM con RISC-V. Estos artículos destacan los posibles beneficios en términos de eficiencia (hasta 100 veces mayor), la simplificación de la capa de ejecución y la mejora de la competitividad de Ethereum frente a blockchains más recientes como Solana y Sui. También se mencionan las preocupaciones sobre la disminución de las tarifas de la red Ethereum y la posible pérdida de confianza de los inversores.
7 de mayo de 2025 (mencionado como futuro): Se menciona que la próxima gran actualización de Ethereum, Pectra, está prevista para el 7 de mayo y se centrará en la escalabilidad de los rollups, la experiencia del usuario y los límites de participación de los validadores. La propuesta de RISC-V se considera un esfuerzo a largo plazo, posterior a esta actualización inmediata.
Personajes Principales:
Vitalik Buterin: Co-fundador de Ethereum. Autor de la propuesta de reemplazar la EVM con la arquitectura RISC-V. Argumenta que este cambio podría mejorar significativamente la eficiencia de la capa de ejecución de Ethereum, mantener competitivo el mercado de producción de bloques y optimizar las funciones de conocimiento cero.
Brian Quinlivan: Director de marketing de Santiment. Atribuye la significativa reducción de las tarifas de la red Ethereum a la disminución de usuarios que envían transacciones en la capa base, optando en cambio por contratos inteligentes o soluciones de escalado de capa 2.
Benaadams: Participante del foro Ethereum Magicians. Expresa preocupaciones sobre la dificultad de optimizar las operaciones de bajo nivel de RISC-V de vuelta a operaciones de 256 bits utilizadas en la EVM, lo que podría afectar el rendimiento de la construcción y ejecución de bloques.
pcaversaccio: Participante del foro Ethereum Magicians. Cuestiona la eficiencia de probar en ZK las syscalls necesarias para interactuar con el estado de Ethereum (SLOAD, SSTORE, CALL) en un sistema RISC-V, preguntando si estas operaciones podrían convertirse en nuevos cuellos de botella.
AdamCochran: Participante del foro Ethereum Magicians. Si bien está de acuerdo con el argumento de la simplicidad, cuestiona si la mejora de la ejecución de la capa 1 es la prioridad actual de Ethereum, dado el costo técnico y el posible impacto en la propuesta de valor de las capas 2.
levs57: Participante del foro Ethereum Magicians. Se opone a la propuesta, argumentando que se basa en premisas incorrectas sobre los sistemas de prueba y su rendimiento. Señala que cualquier implementación de RISC-V requeriría precompilados para operaciones computacionalmente intensas, similar a la EVM actual, y que para obtener ventajas de escalabilidad se necesitaría un sistema diferente, más parecido a la ejecución de código compilado con una Unidad de Gestión de Memoria (MMU) mínima. Sugiere que una ISA diseñada específicamente para la computación verificable podría ser una mejor opción que RISC-V.
SirSpudlington: Participante del foro Ethereum Magicians. Está de acuerdo con Benaadams en que la abstracción a RISC-V desde la arquitectura basada en U256 de la EVM podría disminuir el rendimiento de la ejecución. Sugiere alternativas como Cairo o una pseudo-arquitectura similar a RISC-V pero diseñada para la emulación con registros de 256 bits.
eigmax: Participante del foro Ethereum Magicians. Señala que la mejora en la velocidad de las pruebas con Poseidon se debe al árbol de Merkle Patricia (MPT) y no a la ISA en sí. Cuestiona si la Fundación Ethereum debería mantener su propio conjunto de instrucciones RISC-V y sus herramientas, o reutilizar LLVM. También plantea la cuestión de si la adopción masiva de RISC-V para la generación de pruebas por parte de los mineros podría hacer que el poder de cómputo total para probar y verificar sea menor que el de minar y validar.
underflow: Participante del foro Ethereum Magicians. Está de acuerdo con levs57 en que la virtualización es un paso intermedio y que se necesitará una mejor ISA que RISC-V, diseñada para la computación verificable, junto con pruebas de compilación correctas para lograr una escalabilidad y mantenimiento óptimos.