En el futuro plano de Ethereum, una nueva propuesta iniciada por el cofundador de Ethereum, Vitalik Buterin, ha suscitado un intenso debate en la comunidad: reemplazar la EVM (Máquina virtual de Ethereum) con RISC-V como el lenguaje de máquina virtual para contratos inteligentes. Esta idea ha sido comparada con una "gran actualización al nivel de beam chain" en la capa de ejecución, no solo para escalar, sino también para abordar los cuellos de botella fundamentales en la complejidad y eficiencia de la capa de ejecución actual.
¿Qué es RISC-V? ¿Por qué reemplazar EVM?
El núcleo de la propuesta es reemplazar la EVM actualmente utilizada por los contratos inteligentes de Ethereum por una arquitectura de conjunto de instrucciones modular y de código abierto: RISC-V. Esta transformación no derrocará las herramientas de desarrollo y las costumbres de los desarrolladores existentes de Ethereum, porque:
La capa de abstracción principal existente, como el sistema de cuentas, la llamada entre contratos y el método de almacenamiento, aún se conserva.
Los lenguajes Solidity y Vyper originalmente pueden compilarse utilizando RISC-V como backend, la experiencia del desarrollador no tendrá grandes cambios.
Los contratos EVM antiguos aún pueden comunicarse bidireccionalmente con los nuevos contratos RISC-V.
De esta manera, los desarrolladores no necesitan volver a aprender todo, pero se espera que el rendimiento y la simplicidad de la base de Ethereum mejoren significativamente.
ZK-EVM es el mayor cuello de botella de rendimiento
Con la implementación de varias propuestas de escalado en el futuro (como EIP-4444, ejecución retrasada y cliente sin estado), los verdaderos factores que limitarán la capacidad de escalado de Ethereum L1 se concentrarán en:
La disponibilidad de datos, la muestreo y la estabilidad del protocolo de almacenamiento histórico.
competencia de mercado en la producción de bloques
Eficiencia de prueba de ZK-EVM
Actualmente, en el proceso de prueba de un bloque de ZK-EVM, la ejecución de la lógica de la Máquina virtual EVM ocupa aproximadamente el 50% de los recursos. Esto significa que si se pudiera hacer que los contratos inteligentes se ejecutaran directamente en un entorno RISC-V, habría la oportunidad de que el rendimiento de la prueba ZK alcanzara mejoras de 50 veces, e incluso 100 veces.
Curiosamente, el proceso de prueba de ZK-EVM en la actualidad consiste en compilar EVM a RISC-V y luego el sistema ZK verifica esto. Por lo tanto, permitir que RISC-V se convierta en la máquina virtual nativa de la capa de ejecución de Ethereum no solo es lógico, sino que también ahorra el consumo de recursos en la conversión intermedia.
¿Por qué RISC-V es rápido? Optimización integral desde funciones hash hasta diseño estructural.
Actualmente, los cuatro principales elementos que consumen recursos en ZK-EVM son:
deserialize_inputs
initialize_witness_db
state_root_computation
ejecución de bloques
Los tres primeros se pueden optimizar significativamente utilizando funciones hash más amigables (como Poseidon) y árboles de estado binarios. Por ejemplo, Poseidon puede procesar 2 millones de hashes por segundo en una computadora portátil, muy superior a las 15,000 de Keccak. Si se implementan estas optimizaciones, se reducirá considerablemente la carga del 50% inicial.
pero el 50% restante proviene de
block_execution
Esta parte solo puede resolverse fundamentalmente a través de un diseño de VM más eficiente, como RISC-V.
Tres formas de implementación, hay opciones desde conservadoras hasta agresivas.
Vitalik propuso tres caminos de implementación técnica:
– Opción uno: coexistencia de dos máquinas virtuales (mínimo riesgo): permite que los contratos elijan usar EVM o RISC-V, ambos interconectados y compartiendo recursos, equilibrando compatibilidad e innovación.
– Opción dos: Interprete EVM empaquetado en RISC-V (actualización radical): Todos los contratos EVM se ejecutarán a través del intérprete EVM integrado en RISC-V, lo que permitirá la transición de la capa de ejecución general a una arquitectura subyacente unificada.
Opción tres: soporte del protocolo para el intérprete de la máquina virtual (enfoque moderado): se diseña un "módulo de máquina virtual" en el protocolo, implementando por defecto un intérprete EVM con RISC-V, y se permite la expansión futura a otros lenguajes, como Move.
Las ventajas comunes de estos caminos son: se puede simplificar la especificación de la capa de ejecución, mejorar la mantenibilidad y la transparencia de la verificación.
Sui desarrollador de la empresa Mysten Labs cofundador: si pudiera volver a empezar, elegiría Move, sin considerar múltiples lenguajes.
En relación con esta propuesta, Sam Blackshear, cofundador de Mysten Labs, la empresa desarrolladora de Sui, también expresó su opinión. Dijo: "Creo que adoptar un backend RISC-V es una buena opción para Ethereum (porque necesita soportar los contratos EVM existentes). Pero si tuviera que diseñar una nueva cadena desde cero, todavía elegiría Move, en lugar de soporte multilenguaje. Muchas de las ventajas de Sui provienen del uso de objetos de tipo fuerte como capa abstracta común en toda la pila."
Esto refleja los factores históricos en la "estrategia de selección de máquinas virtuales" de diferentes cadenas. Ethereum, al desarrollarse más temprano, no pudo prever muchas de las demandas y desarrollos futuros en su diseño inicial, y actualmente enfatiza la compatibilidad y el diseño de transición en respuesta a los cambios; mientras que la nueva cadena pública Sui se enfoca en una integración de pila completa desde el lenguaje hasta la capa base, permitiendo una estrecha integración entre desarrollo y seguridad.
Typus Finance creció y Kyrie también compartió una conversación que tuvo con Vitalik en el evento EthTaipei. Recordó: "En ese momento le pregunté a Vitalik: '¿Crees que el lenguaje Move y la configuración orientada a objetos pueden mejorar la seguridad de la blockchain?'"
Él respondió: "No creo que esto cambie nada, un proyecto que ha sido robado ha sido robado, no importa el idioma."
Pero Kyrie respondió en el acto que Move ciertamente puede reducir las oportunidades de cometer errores en el desarrollo, es más fácil de manejar que Rust, y el modelo orientado a objetos ayuda a limitar el alcance del riesgo. "Cuando un contrato es robado, la pérdida puede ser una cantidad limitada y no una exposición infinita," agregó.
Aunque Vitalik no se pronunció en ese momento, a partir de su disposición actual de proponer RISC-V como una alternativa más fuerte y modular, parece que ha habido un ligero cambio en su actitud hacia el diseño del lenguaje y la seguridad en la blockchain.
¿Cirugía de cambio de corazón de Ethereum? Vitalik propone que la capa de ejecución de Ethereum podría reemplazar completamente la EVM, utilizando RISC-V, apareció por primera vez en Chain News ABMedia.
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.
¿Cirugía de corazón para Ethereum? Vitalik propone que la capa de ejecución de Ethereum podría reemplazar completamente el EVM, utilizando RISC-V.
En el futuro plano de Ethereum, una nueva propuesta iniciada por el cofundador de Ethereum, Vitalik Buterin, ha suscitado un intenso debate en la comunidad: reemplazar la EVM (Máquina virtual de Ethereum) con RISC-V como el lenguaje de máquina virtual para contratos inteligentes. Esta idea ha sido comparada con una "gran actualización al nivel de beam chain" en la capa de ejecución, no solo para escalar, sino también para abordar los cuellos de botella fundamentales en la complejidad y eficiencia de la capa de ejecución actual.
¿Qué es RISC-V? ¿Por qué reemplazar EVM?
El núcleo de la propuesta es reemplazar la EVM actualmente utilizada por los contratos inteligentes de Ethereum por una arquitectura de conjunto de instrucciones modular y de código abierto: RISC-V. Esta transformación no derrocará las herramientas de desarrollo y las costumbres de los desarrolladores existentes de Ethereum, porque:
La capa de abstracción principal existente, como el sistema de cuentas, la llamada entre contratos y el método de almacenamiento, aún se conserva.
Los lenguajes Solidity y Vyper originalmente pueden compilarse utilizando RISC-V como backend, la experiencia del desarrollador no tendrá grandes cambios.
Los contratos EVM antiguos aún pueden comunicarse bidireccionalmente con los nuevos contratos RISC-V.
De esta manera, los desarrolladores no necesitan volver a aprender todo, pero se espera que el rendimiento y la simplicidad de la base de Ethereum mejoren significativamente.
ZK-EVM es el mayor cuello de botella de rendimiento
Con la implementación de varias propuestas de escalado en el futuro (como EIP-4444, ejecución retrasada y cliente sin estado), los verdaderos factores que limitarán la capacidad de escalado de Ethereum L1 se concentrarán en:
La disponibilidad de datos, la muestreo y la estabilidad del protocolo de almacenamiento histórico.
competencia de mercado en la producción de bloques
Eficiencia de prueba de ZK-EVM
Actualmente, en el proceso de prueba de un bloque de ZK-EVM, la ejecución de la lógica de la Máquina virtual EVM ocupa aproximadamente el 50% de los recursos. Esto significa que si se pudiera hacer que los contratos inteligentes se ejecutaran directamente en un entorno RISC-V, habría la oportunidad de que el rendimiento de la prueba ZK alcanzara mejoras de 50 veces, e incluso 100 veces.
Curiosamente, el proceso de prueba de ZK-EVM en la actualidad consiste en compilar EVM a RISC-V y luego el sistema ZK verifica esto. Por lo tanto, permitir que RISC-V se convierta en la máquina virtual nativa de la capa de ejecución de Ethereum no solo es lógico, sino que también ahorra el consumo de recursos en la conversión intermedia.
¿Por qué RISC-V es rápido? Optimización integral desde funciones hash hasta diseño estructural.
Actualmente, los cuatro principales elementos que consumen recursos en ZK-EVM son:
deserialize_inputs
initialize_witness_db
state_root_computation
ejecución de bloques
Los tres primeros se pueden optimizar significativamente utilizando funciones hash más amigables (como Poseidon) y árboles de estado binarios. Por ejemplo, Poseidon puede procesar 2 millones de hashes por segundo en una computadora portátil, muy superior a las 15,000 de Keccak. Si se implementan estas optimizaciones, se reducirá considerablemente la carga del 50% inicial.
pero el 50% restante proviene de
block_execution
Esta parte solo puede resolverse fundamentalmente a través de un diseño de VM más eficiente, como RISC-V.
Tres formas de implementación, hay opciones desde conservadoras hasta agresivas.
Vitalik propuso tres caminos de implementación técnica:
– Opción uno: coexistencia de dos máquinas virtuales (mínimo riesgo): permite que los contratos elijan usar EVM o RISC-V, ambos interconectados y compartiendo recursos, equilibrando compatibilidad e innovación.
– Opción dos: Interprete EVM empaquetado en RISC-V (actualización radical): Todos los contratos EVM se ejecutarán a través del intérprete EVM integrado en RISC-V, lo que permitirá la transición de la capa de ejecución general a una arquitectura subyacente unificada.
Opción tres: soporte del protocolo para el intérprete de la máquina virtual (enfoque moderado): se diseña un "módulo de máquina virtual" en el protocolo, implementando por defecto un intérprete EVM con RISC-V, y se permite la expansión futura a otros lenguajes, como Move.
Las ventajas comunes de estos caminos son: se puede simplificar la especificación de la capa de ejecución, mejorar la mantenibilidad y la transparencia de la verificación.
Sui desarrollador de la empresa Mysten Labs cofundador: si pudiera volver a empezar, elegiría Move, sin considerar múltiples lenguajes.
En relación con esta propuesta, Sam Blackshear, cofundador de Mysten Labs, la empresa desarrolladora de Sui, también expresó su opinión. Dijo: "Creo que adoptar un backend RISC-V es una buena opción para Ethereum (porque necesita soportar los contratos EVM existentes). Pero si tuviera que diseñar una nueva cadena desde cero, todavía elegiría Move, en lugar de soporte multilenguaje. Muchas de las ventajas de Sui provienen del uso de objetos de tipo fuerte como capa abstracta común en toda la pila."
Esto refleja los factores históricos en la "estrategia de selección de máquinas virtuales" de diferentes cadenas. Ethereum, al desarrollarse más temprano, no pudo prever muchas de las demandas y desarrollos futuros en su diseño inicial, y actualmente enfatiza la compatibilidad y el diseño de transición en respuesta a los cambios; mientras que la nueva cadena pública Sui se enfoca en una integración de pila completa desde el lenguaje hasta la capa base, permitiendo una estrecha integración entre desarrollo y seguridad.
Typus Finance creció y Kyrie también compartió una conversación que tuvo con Vitalik en el evento EthTaipei. Recordó: "En ese momento le pregunté a Vitalik: '¿Crees que el lenguaje Move y la configuración orientada a objetos pueden mejorar la seguridad de la blockchain?'"
Él respondió: "No creo que esto cambie nada, un proyecto que ha sido robado ha sido robado, no importa el idioma."
Pero Kyrie respondió en el acto que Move ciertamente puede reducir las oportunidades de cometer errores en el desarrollo, es más fácil de manejar que Rust, y el modelo orientado a objetos ayuda a limitar el alcance del riesgo. "Cuando un contrato es robado, la pérdida puede ser una cantidad limitada y no una exposición infinita," agregó.
Aunque Vitalik no se pronunció en ese momento, a partir de su disposición actual de proponer RISC-V como una alternativa más fuerte y modular, parece que ha habido un ligero cambio en su actitud hacia el diseño del lenguaje y la seguridad en la blockchain.
¿Cirugía de cambio de corazón de Ethereum? Vitalik propone que la capa de ejecución de Ethereum podría reemplazar completamente la EVM, utilizando RISC-V, apareció por primera vez en Chain News ABMedia.