El cofundador de Ethereum, Vitalik Buterin, propuso recientemente en la comunidad Ethereum Magicians una propuesta a largo plazo: 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 es el único camino potencial 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), Vitalik espera que al reemplazar la EVM, se pueda lograr una optimización 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.
Este artículo analizará en lenguaje sencillo la motivación, los detalles técnicos, el camino de implementación y los desafíos de esta propuesta, explorando su impacto en la ruta de escalado existente de Ethereum, y revisará la reacción de la comunidad y los intentos similares.
Uno. Las limitaciones actuales de EVM y las ventajas de RISC-V
Problema de EVM:
Arquitectura obsoleta: EVM utiliza una estructura de pila de 256 bits, incompatible con las CPU modernas, lo que provoca una baja eficiencia al ejecutar ZK-EVM.
Bottleneck de ZK: Como se describe en Succinct, aproximadamente la mitad de los recursos de ZK-EVM se utilizan para ejecutar EVM en sí, lo que limita la eficiencia de la prueba ZK.
Mala mantenibilidad: acumulación de funciones complejas a lo largo de los años, normas desordenadas, como la dificultad para eliminar SELFDESTRUCT.
Desarrollo limitado: el conjunto de instrucciones no estándar restringe el soporte multilingüe, lo que dificulta la compilación eficiente de los lenguajes principales en bytecode EVM.
Ventajas de RISC-V:
Rendimiento eficiente: RISC-V es un conjunto de instrucciones reducido de CPU reales, amigable con el hardware, que puede ser utilizado para optimización JIT e incluso aceleración por hardware.
Optimización ZK: Generación de circuitos directamente a partir de instrucciones RISC-V en pruebas ZK es más simple que probar operaciones EVM.
Cadena de bloques madura: soporta lenguajes principales como Rust/C/C++, lo que reduce la barrera de entrada y amplía el ecosistema.
Estándar universal: ya ha sido adoptado por cadenas de bloques como Nervos CKB, y cuenta con casos de éxito.
Vitalik señaló que, en lugar de compilar EVM a RISC-V en ZK-EVM, sería mejor utilizar RISC-V directamente como la arquitectura de ejecución de contratos, lo que aumentaría fundamentalmente la eficiencia de ejecución y el potencial de escalabilidad.
二、Rutas de reemplazo y desafíos: ¿cómo migrar desde EVM?
Tres soluciones alternativas:
Doble VM coexistente (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.
Solución de intérprete en cadena (radical): todos los contratos EVM son interpretados y ejecutados por contratos RISC-V en cadena.
Mecanismo de plugins de intérprete (compromiso): se incorpora el intérprete como elemento del protocolo, permitiendo la inserción futura de otras VM (como Move).
Desafíos técnicos que enfrenta la implementación:
Riesgo de pérdida de rendimiento en la ejecución: RISC-V necesita simular la ejecución en chips x86, lo que puede resultar en una eficiencia inicial inferior a la de un 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 de seguridad: limitar las llamadas al sistema, prevenir la auto-modificación del código, garantizar la ejecución determinista.
Adaptación de herramientas de desarrollo: es necesario actualizar el compilador, el depurador y las herramientas de auditoría de seguridad, y soportar el código de bytes RISC-V.
Problemas de compatibilidad de migración: algunos contratos dependen de características de EVM, por lo que la migración debe diseñarse cuidadosamente con una capa de compatibilidad o un mecanismo de reversión.
Vitalik se inclina por la opción uno como un camino de transición y se compromete a que los nuevos y antiguos contratos mantendrán la interoperabilidad, asegurando que la experiencia del desarrollador permanezca sin cambios y que los usuarios actualicen sin darse cuenta.
3. Impacto en las rutas de escalabilidad horizontal existentes: ¿RISC-V reemplazará a L2 y al particionamiento de datos?
La respuesta es negativa: RISC-V es una optimización de infraestructura, no reemplazará las rutas de escalado existentes.
Capa 2：
Rollup sigue siendo el principal protagonista de la escalabilidad de Ethereum, RISC-V mejora la eficiencia de procesamiento de L1 y el rendimiento de verificación ZK, en lugar de ampliar directamente el rendimiento.
La verificación L1 más rápida puede ayudar a Rollup a enviar datos a un costo más bajo y más rápido, mejorando la escalabilidad general.
Partición de datos y EIP-4844：
Las limitaciones de disponibilidad de datos aún necesitan ser resueltas por EIP-4844 (blob) y Danksharding, RISC-V no afecta la capacidad de datos en la cadena.
La implementación de cambios en la arquitectura no modifica los requisitos de almacenamiento de datos de L1.
FaaS, MEV：
No depende de la arquitectura de la máquina virtual y no se volverá obsoleto por el avance de RISC-V.
Resumen: RISC-V es "cambiar motor", L2/fragmentación es "red de expansión", ambos son dimensiones diferentes y no son contradictorios en paralelo.
Cuatro, retroalimentación de la comunidad y intentos relacionados
Discrepancias en la comunidad:
Partidarios: consideran que esta es una actualización estratégica necesaria para hacer frente a los desafíos de rendimiento de Solana/Sui, y ayuda a atraer a desarrolladores tradicionales.
Conservadores: preocupan la dificultad de implementación, la carga histórica, el alto costo de actualización de la cadena de herramientas ecológicas y cuestionan la relación entre los recursos invertidos y los resultados.
Referencias de proyectos similares:
Move VM (Aptos/Sui): una nueva VM orientada a recursos, con una fuerte seguridad del lenguaje, pero no compatible con EVM.
FuelVM: una nueva VM diseñada para el procesamiento en paralelo, junto con el lenguaje Sway, con compatibilidad limitada.
WASM (Stylus): Introducción de WASM como lenguaje de contrato en L2, ya implementado en Arbitrum, con viabilidad real.
Nervos CKB: Un precedente en el uso de RISC-V como VM de contratos en la red principal, proporcionando una referencia práctica para Ethereum.
Vitalik propuso que RISC-V no significa rechazar otras opciones, él cree que en el futuro los mecanismos de intérpretes también se pueden usar para insertar VM como Move, WASM, construyendo un ecosistema de ejecución diverso.
Cinco, Perspectivas de impacto futuro: si Ethereum cambia a RISC-V
Experiencia del desarrollador:
Lenguajes como Solidity/Vyper todavía se pueden usar, el backend del compilador cambia y no el lenguaje en sí.
Es posible que se abran nuevos lenguajes como Rust/C para escribir contratos, pero no se obliga a la migración.
Costos de operación y rendimiento:
La mejora en la eficiencia de ejecución traerá un límite de Gas más alto y costos más bajos.
Los contratos RISC-V pueden reducir la dependencia de los contratos precompilados, y el modelo de Gas se aproxima más al costo de las pruebas ZK.
Compatibilidad y desarrollo ecológico:
Durante el período de coexistencia de doble VM, los contratos existentes pueden seguir funcionando, y los nuevos contratos adoptan gradualmente RISC-V.
La infraestructura debe soportar el nuevo formato de código de bytes, lo que podría provocar cambios en la compatibilidad entre cadenas (como el problema de permanencia de BSC y Polygon).
Seguridad y estabilidad:
La nueva arquitectura necesita pruebas amplias y verificación formal para mejorar la confiabilidad del protocolo.
Una capa de ejecución más simple es beneficiosa para la auditoría y el control de la superficie de ataque.
Conclusión
Vitalik propuso reemplazar el EVM de Ethereum con RISC-V, lo que representa una profunda reflexión de Ethereum sobre los límites de rendimiento futuros y la simplicidad del protocolo. Esta propuesta aún se encuentra en una fase de discusión temprana, y se espera que su implementación sea un proceso que durará varios años, enfrentando múltiples desafíos técnicos, comunitarios y ecológicos. No se trata de derrocar la ruta actual, sino de fortalecer la base y prepararse para el futuro.
Como dijo Vitalik: "Para lograr un aumento de magnitud, este cambio radical podría ser el único camino viable."
Podemos considerarlo como una apuesta por el futuro, así como una profunda exploración sobre si "la base merece ser reconfigurada".
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Propuesta radical de V神: reemplazar el EVM de Ethereum por RISC-V, ¿es ZK la solución final para la escalabilidad?
Autor | GaryMa 吴 dijo Cadena de bloques
Introducción
El cofundador de Ethereum, Vitalik Buterin, propuso recientemente en la comunidad Ethereum Magicians una propuesta a largo plazo: 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 es el único camino potencial 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), Vitalik espera que al reemplazar la EVM, se pueda lograr una optimización 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.
Este artículo analizará en lenguaje sencillo la motivación, los detalles técnicos, el camino de implementación y los desafíos de esta propuesta, explorando su impacto en la ruta de escalado existente de Ethereum, y revisará la reacción de la comunidad y los intentos similares.
Uno. Las limitaciones actuales de EVM y las ventajas de RISC-V
Problema de EVM:
Arquitectura obsoleta: EVM utiliza una estructura de pila de 256 bits, incompatible con las CPU modernas, lo que provoca una baja eficiencia al ejecutar ZK-EVM.
Bottleneck de ZK: Como se describe en Succinct, aproximadamente la mitad de los recursos de ZK-EVM se utilizan para ejecutar EVM en sí, lo que limita la eficiencia de la prueba ZK.
Mala mantenibilidad: acumulación de funciones complejas a lo largo de los años, normas desordenadas, como la dificultad para eliminar SELFDESTRUCT.
Desarrollo limitado: el conjunto de instrucciones no estándar restringe el soporte multilingüe, lo que dificulta la compilación eficiente de los lenguajes principales en bytecode EVM.
Ventajas de RISC-V:
Rendimiento eficiente: RISC-V es un conjunto de instrucciones reducido de CPU reales, amigable con el hardware, que puede ser utilizado para optimización JIT e incluso aceleración por hardware.
Optimización ZK: Generación de circuitos directamente a partir de instrucciones RISC-V en pruebas ZK es más simple que probar operaciones EVM.
Cadena de bloques madura: soporta lenguajes principales como Rust/C/C++, lo que reduce la barrera de entrada y amplía el ecosistema.
Estándar universal: ya ha sido adoptado por cadenas de bloques como Nervos CKB, y cuenta con casos de éxito.
Vitalik señaló que, en lugar de compilar EVM a RISC-V en ZK-EVM, sería mejor utilizar RISC-V directamente como la arquitectura de ejecución de contratos, lo que aumentaría fundamentalmente la eficiencia de ejecución y el potencial de escalabilidad.
二、Rutas de reemplazo y desafíos: ¿cómo migrar desde EVM?
Tres soluciones alternativas:
Doble VM coexistente (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.
Solución de intérprete en cadena (radical): todos los contratos EVM son interpretados y ejecutados por contratos RISC-V en cadena.
Mecanismo de plugins de intérprete (compromiso): se incorpora el intérprete como elemento del protocolo, permitiendo la inserción futura de otras VM (como Move).
Desafíos técnicos que enfrenta la implementación:
Riesgo de pérdida de rendimiento en la ejecución: RISC-V necesita simular la ejecución en chips x86, lo que puede resultar en una eficiencia inicial inferior a la de un 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 de seguridad: limitar las llamadas al sistema, prevenir la auto-modificación del código, garantizar la ejecución determinista.
Adaptación de herramientas de desarrollo: es necesario actualizar el compilador, el depurador y las herramientas de auditoría de seguridad, y soportar el código de bytes RISC-V.
Problemas de compatibilidad de migración: algunos contratos dependen de características de EVM, por lo que la migración debe diseñarse cuidadosamente con una capa de compatibilidad o un mecanismo de reversión.
Vitalik se inclina por la opción uno como un camino de transición y se compromete a que los nuevos y antiguos contratos mantendrán la interoperabilidad, asegurando que la experiencia del desarrollador permanezca sin cambios y que los usuarios actualicen sin darse cuenta.
3. Impacto en las rutas de escalabilidad horizontal existentes: ¿RISC-V reemplazará a L2 y al particionamiento de datos?
La respuesta es negativa: RISC-V es una optimización de infraestructura, no reemplazará las rutas de escalado existentes.
Capa 2：
Rollup sigue siendo el principal protagonista de la escalabilidad de Ethereum, RISC-V mejora la eficiencia de procesamiento de L1 y el rendimiento de verificación ZK, en lugar de ampliar directamente el rendimiento.
La verificación L1 más rápida puede ayudar a Rollup a enviar datos a un costo más bajo y más rápido, mejorando la escalabilidad general.
Partición de datos y EIP-4844：
Las limitaciones de disponibilidad de datos aún necesitan ser resueltas por EIP-4844 (blob) y Danksharding, RISC-V no afecta la capacidad de datos en la cadena.
La implementación de cambios en la arquitectura no modifica los requisitos de almacenamiento de datos de L1.
FaaS, MEV：
No depende de la arquitectura de la máquina virtual y no se volverá obsoleto por el avance de RISC-V.
Resumen: RISC-V es "cambiar motor", L2/fragmentación es "red de expansión", ambos son dimensiones diferentes y no son contradictorios en paralelo.
Cuatro, retroalimentación de la comunidad y intentos relacionados
Discrepancias en la comunidad:
Partidarios: consideran que esta es una actualización estratégica necesaria para hacer frente a los desafíos de rendimiento de Solana/Sui, y ayuda a atraer a desarrolladores tradicionales.
Conservadores: preocupan la dificultad de implementación, la carga histórica, el alto costo de actualización de la cadena de herramientas ecológicas y cuestionan la relación entre los recursos invertidos y los resultados.
Referencias de proyectos similares:
Move VM (Aptos/Sui): una nueva VM orientada a recursos, con una fuerte seguridad del lenguaje, pero no compatible con EVM.
FuelVM: una nueva VM diseñada para el procesamiento en paralelo, junto con el lenguaje Sway, con compatibilidad limitada.
WASM (Stylus): Introducción de WASM como lenguaje de contrato en L2, ya implementado en Arbitrum, con viabilidad real.
Nervos CKB: Un precedente en el uso de RISC-V como VM de contratos en la red principal, proporcionando una referencia práctica para Ethereum.
Vitalik propuso que RISC-V no significa rechazar otras opciones, él cree que en el futuro los mecanismos de intérpretes también se pueden usar para insertar VM como Move, WASM, construyendo un ecosistema de ejecución diverso.
Cinco, Perspectivas de impacto futuro: si Ethereum cambia a RISC-V
Experiencia del desarrollador:
Lenguajes como Solidity/Vyper todavía se pueden usar, el backend del compilador cambia y no el lenguaje en sí.
Es posible que se abran nuevos lenguajes como Rust/C para escribir contratos, pero no se obliga a la migración.
Costos de operación y rendimiento:
La mejora en la eficiencia de ejecución traerá un límite de Gas más alto y costos más bajos.
Los contratos RISC-V pueden reducir la dependencia de los contratos precompilados, y el modelo de Gas se aproxima más al costo de las pruebas ZK.
Compatibilidad y desarrollo ecológico:
Durante el período de coexistencia de doble VM, los contratos existentes pueden seguir funcionando, y los nuevos contratos adoptan gradualmente RISC-V.
La infraestructura debe soportar el nuevo formato de código de bytes, lo que podría provocar cambios en la compatibilidad entre cadenas (como el problema de permanencia de BSC y Polygon).
Seguridad y estabilidad:
La nueva arquitectura necesita pruebas amplias y verificación formal para mejorar la confiabilidad del protocolo.
Una capa de ejecución más simple es beneficiosa para la auditoría y el control de la superficie de ataque.
Conclusión
Vitalik propuso reemplazar el EVM de Ethereum con RISC-V, lo que representa una profunda reflexión de Ethereum sobre los límites de rendimiento futuros y la simplicidad del protocolo. Esta propuesta aún se encuentra en una fase de discusión temprana, y se espera que su implementación sea un proceso que durará varios años, enfrentando múltiples desafíos técnicos, comunitarios y ecológicos. No se trata de derrocar la ruta actual, sino de fortalecer la base y prepararse para el futuro.
Como dijo Vitalik: "Para lograr un aumento de magnitud, este cambio radical podría ser el único camino viable."
Podemos considerarlo como una apuesta por el futuro, así como una profunda exploración sobre si "la base merece ser reconfigurada".
Referencia: