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. En particular, en términos de eficiencia de la prueba de conocimiento cero (ZK Proof), Vitalik espera que al reemplazar la EVM, se pueda lograr una optimización de hasta 100 veces. La propuesta tiene como objetivo abordar los problemas de cuellos de botella actuales de Ethereum en eficiencia de prueba ZK, complejidad de construcción de bloques y disponibilidad de datos.
Este artículo analizará en un lenguaje sencillo las motivaciones, detalles técnicos, caminos de implementación y 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 Proof: 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: a lo largo de los años, se han acumulado funciones complejas y las normas son confusas, como la dificultad para eliminar SELFDESTRUCT.
Desarrollo limitado: las restricciones del conjunto de instrucciones no estándar limitan el soporte multilingüe, lo que dificulta la compilación eficiente de los lenguajes principales en código de bytes EVM.
Ventajas de RISC-V:
Rendimiento eficiente: RISC-V es un conjunto de instrucciones reducido de una CPU real, amigable con el hardware, que se puede utilizar para optimización JIT e incluso aceleración de hardware.
Optimización ZK: Generar circuitos directamente para instrucciones RISC-V en pruebas ZK es más sencillo que probar operaciones EVM.
Cadena de herramientas madura: soporta lenguajes principales como Rust/C/C++, lo que reduce la barrera de entrada y amplía el ecosistema.
Estándares generales: ya han sido adoptados por cadenas de bloques como Nervos CKB, 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.
Dos, ruta de sustitución y desafíos: ¿cómo migrar desde EVM?
Tres soluciones de reemplazo:
Dual VM coexistencia (más conservadora): 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 la cadena.
Mecanismo de plugins del intérprete (compromiso): se utiliza el intérprete como elemento del protocolo, permitiendo la inserción futura de otras VM (como Move).
Desafíos técnicos a los que se enfrenta la implementación:
Riesgo de deterioro del rendimiento de ejecución: RISC-V necesita simular la ejecución en chips x86, lo que puede resultar en una eficiencia inicial 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 caja de seguridad: limitar llamadas al sistema, prevenir la auto-modificació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, que soporten 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 capas de compatibilidad o mecanismos de retroceso.
Vitalik se inclina por la opción uno como camino de transición y promete que los contratos antiguos y nuevos mantendrán la interoperabilidad, asegurando que la experiencia del desarrollador no cambie y que los usuarios actualicen sin darse cuenta.
Tres, el impacto en la ruta de expansión existente: ¿RISC-V reemplazará a L2, a las particiones de datos, etc.?
La respuesta es negativa: RISC-V es una optimización de la infraestructura y 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 ampliar directamente el rendimiento.
Una validació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.
Fragmentación de datos y EIP-4844:
El cuello de botella de la disponibilidad de datos aún necesita ser resuelto por EIP-4844 (blob) y Danksharding, RISC-V no afecta la capacidad de datos en la cadena.
La ejecución de cambios en la arquitectura no altera los requisitos de almacenamiento de datos de L1.
FaaS、MEV：
No depende de la arquitectura de la máquina virtual y no se verá afectado por el avance de RISC-V.
Resumen: RISC-V es "cambiar motor", L2/fragmentación es "red de expansión", ambos son dimensiones diferentes, paralelas y no se contradicen.
Cuarta, retroalimentación de la comunidad y esfuerzos relacionados
Discrepancias en la comunidad:
Partidarios: creen que esta es una actualización estratégica necesaria para abordar los desafíos de rendimiento de Solana/Sui, lo que ayudará a atraer a desarrolladores tradicionales.
Conservadores: preocupan la dificultad de implementación, la carga histórica, los altos costos 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): Una nueva VM orientada a recursos, con alta seguridad de lenguaje, pero no es compatible con EVM.
FuelVM: una nueva VM diseñada para el procesamiento paralelo, compatible con el lenguaje Sway, con compatibilidad limitada.
WASM (Stylus): Introducir WASM como lenguaje de contrato en L2, ya implementado en Arbitrum, con viabilidad práctica.
Nervos CKB: El uso de RISC-V como VM de contratos en la red principal establece un precedente y proporciona 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 podrían utilizarse para insertar VMs como Move, WASM, etc., construyendo un ecosistema de ejecución diverso.
Cinco, Perspectivas de impacto futuro: ¿Qué pasaría si Ethereum cambiara a RISC-V?
Experiencia del desarrollador:
Los lenguajes como Solidity/Vyper aún son utilizables, el backend del compilador cambia y no el lenguaje en sí.
Es posible abrir nuevos lenguajes como Rust/C para escribir contratos, pero no se obliga a migrar.
Costos de operación y rendimiento:
La mejora de la eficiencia de ejecución traerá un límite de Gas más alto y menores costos.
El contrato RISC-V puede reducir la dependencia de los contratos precompilados, el modelo de Gas está más cerca del costo de prueba ZK.
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 (como el problema de permanencia o salida de BSC y Polygon).
Seguridad y estabilidad:
La nueva arquitectura necesita pruebas amplias y verificación formal para mejorar la fiabilidad 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 la 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 etapa de discusión temprana, y 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 preparar el futuro.
Como dijo Vitalik: "Para lograr un aumento de orden de magnitud, este cambio radical puede 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 reestructurada".
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.
La visión radical de Vitalik: ¿qué significa reemplazar la EVM de Ethereum con RISC-V?
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. En particular, en términos de eficiencia de la prueba de conocimiento cero (ZK Proof), Vitalik espera que al reemplazar la EVM, se pueda lograr una optimización de hasta 100 veces. La propuesta tiene como objetivo abordar los problemas de cuellos de botella actuales de Ethereum en eficiencia de prueba ZK, complejidad de construcción de bloques y disponibilidad de datos.
Este artículo analizará en un lenguaje sencillo las motivaciones, detalles técnicos, caminos de implementación y 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 Proof: 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: a lo largo de los años, se han acumulado funciones complejas y las normas son confusas, como la dificultad para eliminar SELFDESTRUCT.
Desarrollo limitado: las restricciones del conjunto de instrucciones no estándar limitan el soporte multilingüe, lo que dificulta la compilación eficiente de los lenguajes principales en código de bytes EVM.
Ventajas de RISC-V:
Rendimiento eficiente: RISC-V es un conjunto de instrucciones reducido de una CPU real, amigable con el hardware, que se puede utilizar para optimización JIT e incluso aceleración de hardware.
Optimización ZK: Generar circuitos directamente para instrucciones RISC-V en pruebas ZK es más sencillo que probar operaciones EVM.
Cadena de herramientas madura: soporta lenguajes principales como Rust/C/C++, lo que reduce la barrera de entrada y amplía el ecosistema.
Estándares generales: ya han sido adoptados por cadenas de bloques como Nervos CKB, 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.
Dos, ruta de sustitución y desafíos: ¿cómo migrar desde EVM?
Tres soluciones de reemplazo:
Dual VM coexistencia (más conservadora): 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 la cadena.
Mecanismo de plugins del intérprete (compromiso): se utiliza el intérprete como elemento del protocolo, permitiendo la inserción futura de otras VM (como Move).
Desafíos técnicos a los que se enfrenta la implementación:
Riesgo de deterioro del rendimiento de ejecución: RISC-V necesita simular la ejecución en chips x86, lo que puede resultar en una eficiencia inicial 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 caja de seguridad: limitar llamadas al sistema, prevenir la auto-modificació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, que soporten 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 capas de compatibilidad o mecanismos de retroceso.
Vitalik se inclina por la opción uno como camino de transición y promete que los contratos antiguos y nuevos mantendrán la interoperabilidad, asegurando que la experiencia del desarrollador no cambie y que los usuarios actualicen sin darse cuenta.
Tres, el impacto en la ruta de expansión existente: ¿RISC-V reemplazará a L2, a las particiones de datos, etc.?
La respuesta es negativa: RISC-V es una optimización de la infraestructura y 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 ampliar directamente el rendimiento.
Una validació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.
Fragmentación de datos y EIP-4844:
El cuello de botella de la disponibilidad de datos aún necesita ser resuelto por EIP-4844 (blob) y Danksharding, RISC-V no afecta la capacidad de datos en la cadena.
La ejecución de cambios en la arquitectura no altera los requisitos de almacenamiento de datos de L1.
FaaS、MEV：
No depende de la arquitectura de la máquina virtual y no se verá afectado por el avance de RISC-V.
Resumen: RISC-V es "cambiar motor", L2/fragmentación es "red de expansión", ambos son dimensiones diferentes, paralelas y no se contradicen.
Cuarta, retroalimentación de la comunidad y esfuerzos relacionados
Discrepancias en la comunidad:
Partidarios: creen que esta es una actualización estratégica necesaria para abordar los desafíos de rendimiento de Solana/Sui, lo que ayudará a atraer a desarrolladores tradicionales.
Conservadores: preocupan la dificultad de implementación, la carga histórica, los altos costos 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): Una nueva VM orientada a recursos, con alta seguridad de lenguaje, pero no es compatible con EVM.
FuelVM: una nueva VM diseñada para el procesamiento paralelo, compatible con el lenguaje Sway, con compatibilidad limitada.
WASM (Stylus): Introducir WASM como lenguaje de contrato en L2, ya implementado en Arbitrum, con viabilidad práctica.
Nervos CKB: El uso de RISC-V como VM de contratos en la red principal establece un precedente y proporciona 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 podrían utilizarse para insertar VMs como Move, WASM, etc., construyendo un ecosistema de ejecución diverso.
Cinco, Perspectivas de impacto futuro: ¿Qué pasaría si Ethereum cambiara a RISC-V?
Experiencia del desarrollador:
Los lenguajes como Solidity/Vyper aún son utilizables, el backend del compilador cambia y no el lenguaje en sí.
Es posible abrir nuevos lenguajes como Rust/C para escribir contratos, pero no se obliga a migrar.
Costos de operación y rendimiento:
La mejora de la eficiencia de ejecución traerá un límite de Gas más alto y menores costos.
El contrato RISC-V puede reducir la dependencia de los contratos precompilados, el modelo de Gas está más cerca del costo de prueba ZK.
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 (como el problema de permanencia o salida de BSC y Polygon).
Seguridad y estabilidad:
La nueva arquitectura necesita pruebas amplias y verificación formal para mejorar la fiabilidad 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 la 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 etapa de discusión temprana, y 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 preparar el futuro.
Como dijo Vitalik: "Para lograr un aumento de orden de magnitud, este cambio radical puede 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 reestructurada".
Referencia: