El cofundador de Ethereum, Vitalik Buterin, hizo recientemente una propuesta a largo plazo en la comunidad de Ethereum Magicians para reemplazar la actual máquina virtual de capa de ejecución (EVM) con la arquitectura de conjunto de instrucciones RISC-V de código abierto. Compara esta idea con la cadena de haces de la capa de consenso, que ve como el único camino potencial para lograr un avance en el rendimiento en la capa de ejecución y simplificar la lógica del protocolo. Especialmente en términos de eficiencia de prueba de conocimiento cero (prueba ZK), Vitalik espera lograr una mejora de optimización de hasta 100 veces al reemplazar las EVM. La propuesta tiene como objetivo abordar los cuellos de botella actuales de Ethereum en términos de eficiencia a prueba de ZK, complejidad de construcción de bloques, disponibilidad de datos, etc.
Este artículo analizará en lenguaje sencillo la motivación, los detalles técnicos, la ruta de implementación y los desafíos de la propuesta, explorando su impacto en la ruta de escalabilidad existente de Ethereum, así como revisando la reacción de la comunidad y los intentos similares.
Una, las limitaciones actuales de EVM y las ventajas de RISC-V
Problema de EVM:
Arquitectura anticuada: EVM utiliza una estructura de pila de 256 bits, incompatible con las CPU modernas, lo que resulta en una baja eficiencia al ejecutar ZK-EVM.
Bottleneck de ZK: Como se menciona 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, regulaciones desordenadas, como que SELFDESTRUCT es difícil de eliminar.
Desarrollo limitado: las restricciones del conjunto de instrucciones no estándar limitan el soporte multilingüe, y es difícil compilar eficazmente los lenguajes de programación más utilizados en código de bytes EVM.
Ventajas de RISC-V:
Rendimiento eficiente: RISC-V es un conjunto de instrucciones reducido de CPU real, amigable con el hardware, que puede ser utilizado para optimización JIT e incluso aceleración de hardware.
Optimización ZK: La generación de circuitos directamente a partir de las instrucciones RISC-V en la prueba ZK es más sencilla que la prueba de las operaciones EVM.
Cadena de bloques madura: soporta lenguajes populares como Rust/C/C++, lo que reduce la barrera de entrada y amplía el ecosistema.
Estándares generales: ya 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 mejoraría fundamentalmente la eficiencia de ejecución y el potencial de escalabilidad.
Dos, rutas de reemplazo y desafíos: ¿cómo migrar desde EVM?
Tres soluciones de reemplazo:
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 se interpretan y ejecutan a través de contratos RISC-V en cadena.
Mecanismo de complemento del intérprete (compromiso): el intérprete se utiliza como un elemento de protocolo, lo que permite la inserción futura de otras máquinas virtuales (como Move).
Desafíos técnicos enfrentados en la implementación:
Riesgo de degradación del rendimiento: RISC-V necesita simular la ejecución en chips x 86, lo que puede resultar en una eficiencia inicial inferior a la del EVM optimizado.
La valoración de Gas necesita ser reestructurada: es necesario definir un nuevo modelo de Gas para las instrucciones RISC-V, asegurando equidad y seguridad.
Diseño de caja 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 bytecode RISC-V.
Problemas de compatibilidad de migración: algunos contratos dependen de las características de EVM, por lo que la migración requiere un diseño cuidadoso de la capa de compatibilidad o un mecanismo 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 no sientan la actualización.
Tres, el impacto en la ruta de escalabilidad existente: ¿RISC-V reemplazará a L 2, fragmentación de datos, etc.?
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 motor de escalabilidad de Ethereum, RISC-V mejora la eficiencia de procesamiento de L 1 y el rendimiento de verificación ZK, en lugar de expandir directamente el rendimiento.
La validación L 1 más rápida puede ayudar a Rollup a presentar datos a un costo más bajo y de manera más rápida, 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.
El cambio en la arquitectura no altera los requisitos de almacenamiento de datos de L 1.
FaaS, MEV:
No está relacionado con la arquitectura de la máquina virtual y no se volverá obsoleto debido a la promoción de RISC-V.
Resumen: RISC-V es «cambio de motor», L 2/fragmentación es «red de expansión», ambos son dimensiones diferentes y no se contradicen en paralelo.
Cuatro, retroalimentación de la comunidad y intentos relacionados
División en la comunidad:
Partidarios: creen que esta es una actualización estratégica necesaria para abordar los desafíos de rendimiento de Solana/Sui y ayudar a atraer a desarrolladores tradicionales.
Conservadores: preocupan la dificultad de implementación, la carga histórica y el alto costo de actualización de la cadena de herramientas ecológicas, cuestionando la relación entre inversión de recursos y rendimiento.
Proyectos similares de referencia:
Move VM (Aptos/Sui): Nueva máquina virtual orientada a recursos, con alta seguridad del lenguaje, pero no compatible con EVM.
FuelVM: nueva VM diseñada para el procesamiento paralelo, compatible con el lenguaje Sway, con compatibilidad limitada.
WASM (Stylus): Introducción de WASM como lenguaje de contrato en L 2, ya implementado en Arbitrum, con viabilidad práctica.
Nervos CKB: El uso de RISC-V como VM de contratos en la red principal es un precedente que proporciona una referencia práctica para Ethereum.
Vitalik propuso que RISC-V no significa que se rechacen otras opciones, y cree que en el futuro, el mecanismo de intérprete también se puede usar para insertar máquinas virtuales como Move y WASM para construir un ecosistema de ejecución múltiple.
Cinco, perspectivas de impacto futuro: ¿qué pasará si Ethereum cambia a RISC-V?
Experiencia del desarrollador:
Los lenguajes como Solidity/Vyper aún se pueden utilizar, 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 obligará a migrar.
Costos de operación y rendimiento:
La mejora en la eficiencia de ejecución traerá un límite de Gas más alto y tarifas más bajas.
Los contratos RISC-V pueden reducir la dependencia de contratos precompilados, y el modelo de Gas está más alineado con el costo de las pruebas ZK.
Compatibilidad y desarrollo ecológico:
Durante el período de coexistencia de 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 de BSC y Polygon).
Seguridad y estabilidad:
La nueva arquitectura necesita pruebas extensas 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 etapa temprana de discusión 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 magnitud, este cambio radical puede ser el único camino viable."
Podemos verlo como una apuesta por el futuro, así como una profunda exploración sobre si "la base merece ser reconstruida".
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 radical propuesta de Vitalik: ¿qué significa reemplazar la EVM de Ethereum con RISC-V?
Escrito por: GaryMa Wu dijo Cadena de bloques
Introducción
El cofundador de Ethereum, Vitalik Buterin, hizo recientemente una propuesta a largo plazo en la comunidad de Ethereum Magicians para reemplazar la actual máquina virtual de capa de ejecución (EVM) con la arquitectura de conjunto de instrucciones RISC-V de código abierto. Compara esta idea con la cadena de haces de la capa de consenso, que ve como el único camino potencial para lograr un avance en el rendimiento en la capa de ejecución y simplificar la lógica del protocolo. Especialmente en términos de eficiencia de prueba de conocimiento cero (prueba ZK), Vitalik espera lograr una mejora de optimización de hasta 100 veces al reemplazar las EVM. La propuesta tiene como objetivo abordar los cuellos de botella actuales de Ethereum en términos de eficiencia a prueba de ZK, complejidad de construcción de bloques, disponibilidad de datos, etc.
Este artículo analizará en lenguaje sencillo la motivación, los detalles técnicos, la ruta de implementación y los desafíos de la propuesta, explorando su impacto en la ruta de escalabilidad existente de Ethereum, así como revisando la reacción de la comunidad y los intentos similares.
Una, las limitaciones actuales de EVM y las ventajas de RISC-V
Problema de EVM:
Arquitectura anticuada: EVM utiliza una estructura de pila de 256 bits, incompatible con las CPU modernas, lo que resulta en una baja eficiencia al ejecutar ZK-EVM.
Bottleneck de ZK: Como se menciona 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, regulaciones desordenadas, como que SELFDESTRUCT es difícil de eliminar.
Desarrollo limitado: las restricciones del conjunto de instrucciones no estándar limitan el soporte multilingüe, y es difícil compilar eficazmente los lenguajes de programación más utilizados en código de bytes EVM.
Ventajas de RISC-V:
Rendimiento eficiente: RISC-V es un conjunto de instrucciones reducido de CPU real, amigable con el hardware, que puede ser utilizado para optimización JIT e incluso aceleración de hardware.
Optimización ZK: La generación de circuitos directamente a partir de las instrucciones RISC-V en la prueba ZK es más sencilla que la prueba de las operaciones EVM.
Cadena de bloques madura: soporta lenguajes populares como Rust/C/C++, lo que reduce la barrera de entrada y amplía el ecosistema.
Estándares generales: ya 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 mejoraría fundamentalmente la eficiencia de ejecución y el potencial de escalabilidad.
Dos, rutas de reemplazo y desafíos: ¿cómo migrar desde EVM?
Tres soluciones de reemplazo:
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 se interpretan y ejecutan a través de contratos RISC-V en cadena.
Mecanismo de complemento del intérprete (compromiso): el intérprete se utiliza como un elemento de protocolo, lo que permite la inserción futura de otras máquinas virtuales (como Move).
Desafíos técnicos enfrentados en la implementación:
Riesgo de degradación del rendimiento: RISC-V necesita simular la ejecución en chips x 86, lo que puede resultar en una eficiencia inicial inferior a la del EVM optimizado.
La valoración de Gas necesita ser reestructurada: es necesario definir un nuevo modelo de Gas para las instrucciones RISC-V, asegurando equidad y seguridad.
Diseño de caja 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 bytecode RISC-V.
Problemas de compatibilidad de migración: algunos contratos dependen de las características de EVM, por lo que la migración requiere un diseño cuidadoso de la capa de compatibilidad o un mecanismo 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 no sientan la actualización.
Tres, el impacto en la ruta de escalabilidad existente: ¿RISC-V reemplazará a L 2, fragmentación de datos, etc.?
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 motor de escalabilidad de Ethereum, RISC-V mejora la eficiencia de procesamiento de L 1 y el rendimiento de verificación ZK, en lugar de expandir directamente el rendimiento.
La validación L 1 más rápida puede ayudar a Rollup a presentar datos a un costo más bajo y de manera más rápida, 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.
El cambio en la arquitectura no altera los requisitos de almacenamiento de datos de L 1.
FaaS, MEV:
No está relacionado con la arquitectura de la máquina virtual y no se volverá obsoleto debido a la promoción de RISC-V.
Resumen: RISC-V es «cambio de motor», L 2/fragmentación es «red de expansión», ambos son dimensiones diferentes y no se contradicen en paralelo.
Cuatro, retroalimentación de la comunidad y intentos relacionados
División en la comunidad:
Partidarios: creen que esta es una actualización estratégica necesaria para abordar los desafíos de rendimiento de Solana/Sui y ayudar a atraer a desarrolladores tradicionales.
Conservadores: preocupan la dificultad de implementación, la carga histórica y el alto costo de actualización de la cadena de herramientas ecológicas, cuestionando la relación entre inversión de recursos y rendimiento.
Proyectos similares de referencia:
Move VM (Aptos/Sui): Nueva máquina virtual orientada a recursos, con alta seguridad del lenguaje, pero no compatible con EVM.
FuelVM: nueva VM diseñada para el procesamiento paralelo, compatible con el lenguaje Sway, con compatibilidad limitada.
WASM (Stylus): Introducción de WASM como lenguaje de contrato en L 2, ya implementado en Arbitrum, con viabilidad práctica.
Nervos CKB: El uso de RISC-V como VM de contratos en la red principal es un precedente que proporciona una referencia práctica para Ethereum.
Vitalik propuso que RISC-V no significa que se rechacen otras opciones, y cree que en el futuro, el mecanismo de intérprete también se puede usar para insertar máquinas virtuales como Move y WASM para construir un ecosistema de ejecución múltiple.
Cinco, perspectivas de impacto futuro: ¿qué pasará si Ethereum cambia a RISC-V?
Experiencia del desarrollador:
Los lenguajes como Solidity/Vyper aún se pueden utilizar, 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 obligará a migrar.
Costos de operación y rendimiento:
La mejora en la eficiencia de ejecución traerá un límite de Gas más alto y tarifas más bajas.
Los contratos RISC-V pueden reducir la dependencia de contratos precompilados, y el modelo de Gas está más alineado con el costo de las pruebas ZK.
Compatibilidad y desarrollo ecológico:
Durante el período de coexistencia de 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 de BSC y Polygon).
Seguridad y estabilidad:
La nueva arquitectura necesita pruebas extensas 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 etapa temprana de discusión 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 magnitud, este cambio radical puede ser el único camino viable."
Podemos verlo como una apuesta por el futuro, así como una profunda exploración sobre si "la base merece ser reconstruida".