Vitalik Buterin ha propuesto una revisión a largo plazo al entorno de ejecución de Ethereum para reemplazar la máquina virtual Ethereum con RISC-V, una arquitectura estandarizada y extensible del conjunto de instrucciones.
La propuesta, compartida en el Foro Ethereum Magicians el 20 de abril, describe un cambio de fase múltiple para mejorar la eficiencia de prueba y simplificar la capa de ejecución, sin cambiar las abstracciones centrales como cuentas, almacenamiento o llamadas de contrato cruzado.
El cambio conservaría la solidez y Vyper como lenguas de desarrollo primarias, que se adaptarían para compilar a RISC-V.
Por buterin, mientras que escribir contratos directamente en óxido sería técnicamente posible, las preocupaciones de legibilidad y la familiaridad del desarrollador con los idiomas existentes sugieren que Rust no reemplazará la solidez en la capa de aplicación. Los contratos de EVM existentes continuarían operando e interactuando plenamente con los nuevos contratos basados en RISC-V, preservando la compatibilidad atrasada.
Cuellos de botella de ejecución y escala a largo plazo
Buterin identificó la ejecución como uno de los cuellos de botella finales a largo plazo de Ethereum, después de que los problemas a corto plazo son mitigados por EIP como la ejecución retrasada, las listas de acceso a nivel de bloque y el almacenamiento histórico distribuido.
En particular, señaló probar los costos en ZK-EVM como la restricción clave para la escalabilidad futura. El análisis de ZK-EVM de sucinto indica que la ejecución del bloque solo representa casi la mitad de todos los ciclos de Prover, mientras que el resto se consume por el manejo de datos de los testigos y las operaciones de árboles estatales.
Mientras que la sobrecarga relacionada con el estado puede reducirse cambiando de árboles Patricia con sede en Keccak a árboles binarios con funciones hash optimizadas como Poseidón, la eficiencia de ejecución de bloques seguirá siendo limitante a menos que el EVM se aborde directamente.
Buterin señaló que ZK-EVM ya se compiló a RISC-V debajo del capó, lo que sugiere que exponer RISC-V como VM primario podría eliminar una capa de abstracción y ganancias de eficiencia de rendimiento. Según los informes, algunos escenarios de prueba muestran mejoras de 100x en el rendimiento de Prover eludiendo por completo la traducción EVM.
Rutas de coexistencia, migración y simplificación
Se están considerando múltiples vías de implementación. El más conservador permitiría un doble apoyo para los contratos EVM y RISC-V, manteniendo llamadas interoperables y acceso compartido al estado persistente. Los contratos de EVM continuarían funcionando y podrían llamar o ser llamados por contratos RISC-V a través de llamadas del sistema asignadas a códigos de operación tradicionales como llamadas, Sload y Sstore.
Un enfoque más agresivo implica transformar los contratos EVM existentes en envoltorios que delegan la ejecución a un intérprete EVM escrito en RISC-V. Según este modelo, el código de bytEnt de un contrato se reemplazaría con la lógica de que enruta las llamadas y los parámetros de ejecución a un contrato de intérprete RISC-V designado, recibe el valor de devolución y lo reenvía a la persona que llama.
Una estrategia intermedia propone soporte a nivel de protocolo para intérpretes de máquinas virtuales, consagrando este proceso de delegación y permitiendo que coexistan múltiples formatos de ejecución. Si bien EVM sería la primera VM compatible con este modelo, otros, incluido el movimiento, podrían agregarse en el futuro.
Cada enfoque busca equilibrar la compatibilidad con la simplificación a largo plazo. Según Buterin, las simplificaciones incrementales para el EVM, como la eliminación de la autocomprobación, han demostrado ser difíciles debido a casos de borde complejos y comportamientos heredados.
Una transición completa a RISC-V podría habilitar una capa base más mantenible con una lógica de ejecución mínima, comparable en compacto a proyectos como Tinygrad que imponen límites estrictos de base de código.
Filosofía de diseño más amplia y alineación con la cadena de vigas
La propuesta se alinea con los esfuerzos continuos como la iniciativa de la cadena del haz, cuyo objetivo es simplificar el mecanismo de consenso de Ethereum. El plan RISC-V traería mejoras paralelas a la capa de ejecución, lo que permite a la red seguir modularidad y una complejidad reducida en ambos dominios.
Como se publicó en Ethereum Magicians, Buterin caracterizó la propuesta como un paso radical pero posiblemente necesario para realizar la eficiencia y simplicidad de L1 a largo plazo. Si bien los EIP activos y los marcos de apatorgas abordan mejoras de escalabilidad a corto y mediano plazo, el futuro de Ethereum como protocolo de rendimiento y sostenible puede depender de los cambios arquitectónicos de esta magnitud.
No se ha anunciado ninguna línea de tiempo para ninguna fase de implementación. Se espera que la comunidad de Ethereum participe en una discusión adicional para evaluar las compensaciones, el impacto de las herramientas y las rutas de migración de desarrolladores como parte de un ciclo de deliberación más largo.
La propuesta sigue siendo exploratoria y está destinada a abrir una conversación más amplia sobre la dirección del entorno de ejecución de Ethereum en los próximos años.
Respuesta comunitaria
Algunos miembros de la comunidad plantearon reservas estratégicas y técnicas en respuesta a la propuesta de Buterin. Adam Cochran cuestionó la priorización de la eficiencia de L1 a expensas potenciales de la habilitación de L2, lo que sugiere que consagrar RISC-V podría reducir la hoja de ruta modular de Ethereum.
Destacó propuestas alternativas, como la agregación de prueba recursiva, las raíces de compromiso sin estado y la unificación de firma BLS, que podría ofrecer ganancias sistémicas más amplias con menos costos de implementación.
Otros, incluido Ben A Adams, cofundador y CTO de Illyad Games, y LEVS57, un desarrollador de Web3, señalaron las compensaciones de rendimiento, particularmente en torno a la compatibilidad del hardware y el papel persistente de los precompilos.
Las preocupaciones incluyeron la dificultad de optimizar las instrucciones de RISC-V de bajo nivel en operaciones eficientes de 256 bits y dudas sobre si los sistemas actuales de ZK-RISC-V son suficientemente maduros o auditables para justificar un cambio fundamental.
Buterin respondió minimizando la medida en que el tamaño de la palabra de 256 bits del EVM restringe la ejecución, indicando que la mayoría de los valores en la práctica son más pequeños, típicamente U32, U64 o U128, que los compiladores pueden asignar eficientemente las instrucciones RISC-V.
Reiteró que los ZK-EVM de hoy ya funcionan como entornos RISC-V que incorporan un intérprete EVM, enmarcando la exposición directa de RISC-V como una forma de eliminar las capas redundantes. Si bien reconoció la gestión de la pila y salta como posibles puntos de fricción, sostuvo que eliminar la sobrecarga interpretativa sigue siendo una ganancia neta.
Mencionado en este artículo
(Tagstotranslate) Análisis Ethereum (T) (T) People (T) People (T) Web3
