Ethereum podría adoptar la arquitectura RISC-V en lugar de EVM en el futuro

El cofundador de Ethereum propuso recientemente en un foro comunitario una propuesta a largo plazo, sugiriendo reemplazar la máquina virtual de ejecución actual (EVM) por una arquitectura de conjunto de instrucciones de código abierto RISC-V. Comparó esta idea con la Beam Chain de la capa de consenso, creyendo que podría ser el único camino viable para lograr un avance en el rendimiento de la capa de ejecución y simplificar la lógica del protocolo. Especialmente en términos de eficiencia de las pruebas de conocimiento cero (ZK Proof), se espera que al reemplazar la EVM, se pueda lograr una mejora de hasta 100 veces. Esta propuesta tiene como objetivo abordar los problemas actuales de Ethereum en cuanto a la eficiencia de las pruebas ZK, la complejidad de la construcción de bloques y la disponibilidad de datos.

Las limitaciones actuales de EVM y las ventajas de RISC-V

Los principales problemas de EVM incluyen:

1. Arquitectura obsoleta: utiliza una estructura de pila de 256 bits, incompatible con las CPU modernas, lo que provoca una baja eficiencia en la ejecución de ZK-EVM.
2. Cuello de botella en las pruebas ZK: aproximadamente la mitad de los recursos se utilizan para ejecutar la EVM en sí, lo que limita la eficiencia de las pruebas ZK.
3. Mantenimiento deficiente: la acumulación de funciones a lo largo de los años ha llevado a un desorden en las normas, y ciertas funciones son difíciles de eliminar.
4. Desarrollo limitado: el conjunto de instrucciones no estándar limita el soporte entre lenguajes, lo que dificulta la compilación eficiente de lenguajes populares en bytecode EVM.

En comparación, RISC-V tiene las siguientes ventajas:

1. Alto rendimiento: como un conjunto de instrucciones simplificado de una CPU real, amigable con el hardware, puede ser utilizado para optimización JIT e incluso aceleración por hardware.
2. Optimización ZK: generar circuitos directamente para instrucciones RISC-V en la prueba ZK es más simple que probar operaciones EVM.
3. Cadena de herramientas madura: Soporte para lenguajes de programación populares como Rust/C/C++, lo que reduce la barrera de entrada y amplía el ecosistema.
4. Estándares generales: Ya hay proyectos de blockchain adoptados, con casos de éxito.

Sustitución de rutas y desafíos

Se presentaron tres posibles alternativas de reemplazo:

1. Doble VM en coexistencia (el más conservador): EVM y RISC-V funcionan en paralelo, los nuevos contratos pueden optar por RISC-V, asegurando la compatibilidad durante el período de transición.
2. Solución de intérprete en cadena (radical): todos los contratos EVM son interpretados y ejecutados por contratos RISC-V en la cadena.
3. Mecanismo de plugin del intérprete (compromiso): Se permite insertar otros VM en el futuro al tratar al intérprete como un elemento del protocolo.

Los desafíos técnicos que enfrenta la implementación incluyen:

• Riesgo de pérdida de rendimiento de ejecución: RISC-V necesita simular la ejecución en chips x86, y la eficiencia inicial puede ser inferior a la del EVM optimizado.
• La valoración del Gas necesita ser reconstruida: se debe definir un nuevo modelo de Gas para las instrucciones RISC-V, asegurando equidad y seguridad.
• Diseño de sandbox seguro: limitar las llamadas al sistema, prevenir la automodificación del código, garantizar la ejecución determinista.
• Adaptación de herramientas de desarrollo: se necesita actualizar el compilador, el depurador y las herramientas de auditoría de seguridad, y se debe dar soporte al bytecode RISC-V.
• Problemas de compatibilidad de migración: algunos contratos dependen de características de EVM, la migración debe diseñarse con cuidado para una capa de compatibilidad o un mecanismo de retroceso.

Impacto en las rutas de escalabilidad existentes

RISC-V es una optimización de infraestructura, no reemplazará las rutas de escalado existentes.

• Capa 2: Rollup sigue siendo el principal impulsor de la escalabilidad de Ethereum, RISC-V mejora la eficiencia de procesamiento de L1 y el rendimiento de verificación ZK, en lugar de expandir directamente el rendimiento.
• Fragmentación de datos y EIP-4844: el cuello de botella en la disponibilidad de datos aún necesita ser resuelto por EIP-4844 y Danksharding, RISC-V no afecta la capacidad de datos en la cadena.
• FaaS, MEV: no dependen de la arquitectura de la máquina virtual y no se verán afectados por el avance de RISC-V.

Retroalimentación de la comunidad y esfuerzos relacionados

La comunidad tiene diferencias sobre esta propuesta:

• Los partidarios creen que esta es una actualización estratégica necesaria para enfrentar los desafíos de rendimiento y ayudar a atraer a desarrolladores tradicionales.
• Los conservadores temen la dificultad de implementación, la carga histórica y el alto costo de actualización de la cadena de herramientas ecológicas, y cuestionan la relación costo-beneficio de la inversión de recursos.

Proyectos similares de referencia:

• Move VM (Aptos/Sui): Nueva VM orientada a recursos, con fuerte seguridad del lenguaje, pero no compatible con EVM.
• FuelVM: Nueva VM diseñada para el procesamiento paralelo, junto con el lenguaje Sway, con compatibilidad limitada.
• WASM (Stylus): Introducción de WASM como lenguaje de contrato en L2, ya implementado en un L2, con viabilidad práctica.
• Una cadena pública: el uso de RISC-V como VM de contratos en la mainnet es un precedente que proporciona una referencia práctica para Ethereum.

Perspectivas de impacto futuro

Si Ethereum cambia a RISC-V, podría traer los siguientes efectos:

1. Experiencia del desarrollador:

   • Lenguajes como Solidity/Vyper todavía se pueden usar, el backend del compilador cambia y no el lenguaje en sí.
   • Podría abrirse la posibilidad de escribir contratos en nuevos lenguajes como Rust/C, pero no se obligará a la migración.

2. Costos de operación y rendimiento:

   • La mejora en la eficiencia de ejecución traerá un límite de Gas más alto y menores costos.
   • Los contratos RISC-V pueden reducir la dependencia de contratos precompilados, y el modelo de Gas se asemeja más al costo de la prueba ZK.

3. Compatibilidad y desarrollo ecológico:

   • Durante el período de coexistencia de las dos VM, los contratos existentes pueden seguir funcionando, y los nuevos contratos adoptarán gradualmente RISC-V.
   • La infraestructura debe soportar el nuevo formato de bytecode, lo que podría provocar cambios en la compatibilidad entre cadenas.

4. Seguridad y estabilidad:

   • La nueva arquitectura necesita pruebas exhaustivas y verificación formal para mejorar la fiabilidad del protocolo.
   • Una capa de ejecución más sencilla beneficia la auditoría y el control de la superficie de ataque.

Esta propuesta representa una profunda reflexión de Ethereum sobre los límites de rendimiento futuros y la simplicidad del protocolo. Se espera que su implementación sea un proceso que dure varios años, enfrentando múltiples desafíos técnicos, comunitarios y ecológicos. No se trata de derrocar la ruta existente, sino de fortalecer la base y prepararse para el futuro. Esto puede verse como una apuesta por el futuro, así como una profunda exploración sobre "si la base merece ser reestructurada".