El objetivo es mejorar significativamente la eficiencia de la capa de ejecución y la simplicidad de la capa de ejecución, así como superar los cuellos de botella de escalabilidad.
**Fuente:**Vitalik Buterin
Compilado por: KarenZ, Foresight News
El 20 de abril, Vitalik Buterin propuso una importante propuesta sobre la capa de ejecución L1 de Ethereum en la plataforma Ethereum Magicians. Sugerió adoptar la arquitectura RISC-V en lugar de la actual EVM (Máquina Virtual de Ethereum) como el lenguaje de máquina virtual para escribir contratos inteligentes, con el objetivo de mejorar fundamentalmente la eficiencia operativa de la capa de ejecución de Ethereum, superar uno de los principales cuellos de botella de escalabilidad actuales y simplificar en gran medida la simplicidad de la capa de ejecución.
Foresight News ha realizado una traducción completa de esta propuesta, con el objetivo de ayudar a los lectores a comprender esta idea técnica. A continuación se presenta el contenido traducido del texto original de la propuesta:
Este artículo presenta una idea radical sobre el futuro de la capa de ejecución de Ethereum, cuya ambición es comparable a la del plan Beam Chain para la capa de consenso. La propuesta tiene como objetivo aumentar significativamente la eficiencia de la capa de ejecución de Ethereum, abordar uno de los principales cuellos de botella en la escalabilidad y simplificar drásticamente la capa de ejecución; de hecho, esta podría ser la única forma de lograr este objetivo.
Idea central: reemplazar EVM con RISC-V como el lenguaje de máquina virtual para la redacción de contratos inteligentes.
Nota importante:
El sistema de cuentas, las llamadas entre contratos y conceptos de almacenamiento se mantendrán completamente. Estos diseños abstractos funcionan bien y los desarrolladores están acostumbrados a usarlos. Los códigos de operación como SLOAD, SSTORE, BALANCE y CALL se transformarán en llamadas del sistema RISC-V.
En este modo, los contratos inteligentes se pueden escribir en Rust, pero espero que la mayoría de los desarrolladores sigan utilizando Solidity (o Vyper) para escribir contratos, ya que estos lenguajes se adaptarán a RISC-V como nuevo backend. Esto se debe a que los contratos inteligentes escritos en Rust son en realidad menos legibles, mientras que Solidity y Vyper son más claros y fáciles de leer. La experiencia de desarrollo puede verse casi sin cambios, y los desarrolladores incluso pueden no notar la diferencia.
Los contratos EVM de la versión anterior seguirán funcionando y serán completamente compatibles en ambas direcciones con los contratos RISC-V de la nueva versión. Hay varias formas de implementación, que se explorarán en detalle más adelante en este artículo.
Nervos CKB VM ha establecido un precedente, que esencialmente es una implementación de RISC-V.
¿Por qué hacer esto?
A corto plazo, las EIP que se implementarán próximamente (como la lista de acceso a nivel de bloque, la ejecución diferida, el almacenamiento histórico distribuido y la EIP-4444) pueden resolver los principales cuellos de botella de escalabilidad de Ethereum L1. A medio plazo, se resolverán más problemas mediante la falta de estado y ZK-EVM. A largo plazo, los principales factores limitantes de la escalabilidad de Ethereum L1 se convertirán en:
Estabilidad del muestreo de disponibilidad de datos y del protocolo de almacenamiento histórico
Mantener la demanda de competitividad en el mercado de producción de bloques
La capacidad de prueba de ZK-EVM
Demostraré que reemplazar ZK-EVM por RISC-V puede resolver los cuellos de botella clave en (2) y (3).
La siguiente tabla muestra el número de ciclos necesarios para cada etapa de la ejecución de EVM en Succinct ZK-EVM:
Descripción del gráfico: las cuatro etapas principales que consumen tiempo son deserialize_inputs, initialize_witness_db, state_root_computation y block_execution
Entre ellos, initialize_witness_db y state_root_computation están relacionados con el árbol de estados, mientras que deserialize_inputs implica el proceso de convertir bloques y datos de testigos en una representación interna; de hecho, más del 50% es proporcional al tamaño de los datos de testigos.
Estas secciones se pueden optimizar en gran medida reemplazando el actual árbol de Merkle patricia keccak 16-ary con un árbol binario que utiliza una función hash fácil de probar. Si usamos Poseidón, podemos probar 2 millones de hashes por segundo en una computadora portátil (a modo de comparación, keccak es de aproximadamente 15,000 hash / seg). Además de Poseidón, hay muchas otras opciones. En general, hay mucho espacio para la optimización de estos componentes. Además, podemos eliminar la acumulación de _logs _bloom eliminando la floración.
El block_execution restante representa aproximadamente la mitad del ciclo de prueba actual (ciclos de probador). Para lograr un aumento de 100 veces en la eficiencia general de la prueba, la eficiencia de la prueba de EVM debe aumentar al menos 50 veces. Una de las soluciones es crear una implementación de prueba más eficiente para EVM, otra solución es notar que el actual probador ZK-EVM en realidad prueba compilando EVM a RISC-V, permitiendo que los desarrolladores de contratos inteligentes accedan directamente a esa máquina virtual RISC-V.
Algunos datos muestran que en ciertas circunstancias la mejora de eficiencia puede superar 100 veces:
!
En la práctica, el tiempo restante del prover puede estar ocupado principalmente por las operaciones de precompilación actuales. Si RISC-V se utiliza como la máquina virtual principal, el cronograma de Gas reflejará el tiempo de prueba real, y la presión económica incentivará a los desarrolladores a reducir el uso de precompilaciones de alto costo. Aun así, las ganancias pueden no ser tan significativas, pero tenemos razones suficientes para creer que estas ganancias serán muy considerables.
(Es importante notar que en la ejecución regular de EVM, la proporción de tiempo de "operaciones EVM" y "otras operaciones" se acerca al 50/50, por lo que creemos intuitivamente que eliminar EVM como "capa intermedia" traerá beneficios igualmente significativos.)
detalles de implementación
Hay varias formas de implementar esta propuesta. La solución menos disruptiva es dar soporte a ambas máquinas virtuales al mismo tiempo, permitiendo que el contrato se escriba en una de ellas. Ambos tipos de contratos tienen acceso a las mismas características: almacenamiento persistente (SLOAD/SSTORE), la capacidad de mantener saldos de ETH, iniciar/recibir llamadas y más. Los contratos EVM y RISC-V se pueden llamar entre sí: desde la perspectiva de RISC-V, llamar al contrato EVM equivale a ejecutar una llamada al sistema con parámetros especiales; El contrato de EVM que recibe el mensaje lo interpreta como una LLAMADA.
Desde la perspectiva del protocolo, un enfoque más agresivo es convertir los contratos EVM existentes en contratos del intérprete EVM escritos en RISC-V, ejecutando su código EVM existente. Es decir, si un contrato EVM tiene código C, el intérprete EVM se encuentra en la dirección X, entonces el contrato será reemplazado por la lógica de nivel superior, cuando sea llamado externamente con los parámetros D, llamando a X y pasando (C, D), y luego esperando el valor de retorno y reenviándolo. Si el intérprete EVM llama al contrato, solicitando ejecutar CALL o SLOAD/SSTORE, entonces el contrato realiza estas operaciones.
La solución de compromiso es adoptar la segunda opción, pero a través de un protocolo que apoye claramente el concepto de "intérprete de máquina virtual", exigiendo que su lógica esté escrita en RISC-V. EVM será el primer ejemplo, y en el futuro también podrá soportar otros lenguajes (Move podría ser una opción candidata).
Las principales ventajas de la segunda y tercera opción radican en que pueden simplificar en gran medida las especificaciones de la capa de ejecución. Considerando que incluso la eliminación de SELFDESTRUCT presenta grandes dificultades, esta idea podría ser el único camino viable para la simplificación. Tinygrad sigue la estricta regla de "no más de 10,000 líneas de código", y la base óptima de la cadena de bloques debería poder cumplir fácilmente con esta limitación y simplificarse aún más. El plan de Beam Chain espera simplificar significativamente la capa de consenso de Ethereum, y si la capa de ejecución desea lograr mejoras similares, esta transformación radical podría ser el único camino viable.
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 completa de Vitalik para la capa de ejecución L1 a largo plazo: reemplazar EVM por RISC-V
**Fuente:**Vitalik Buterin
Compilado por: KarenZ, Foresight News
El 20 de abril, Vitalik Buterin propuso una importante propuesta sobre la capa de ejecución L1 de Ethereum en la plataforma Ethereum Magicians. Sugerió adoptar la arquitectura RISC-V en lugar de la actual EVM (Máquina Virtual de Ethereum) como el lenguaje de máquina virtual para escribir contratos inteligentes, con el objetivo de mejorar fundamentalmente la eficiencia operativa de la capa de ejecución de Ethereum, superar uno de los principales cuellos de botella de escalabilidad actuales y simplificar en gran medida la simplicidad de la capa de ejecución.
Foresight News ha realizado una traducción completa de esta propuesta, con el objetivo de ayudar a los lectores a comprender esta idea técnica. A continuación se presenta el contenido traducido del texto original de la propuesta:
Este artículo presenta una idea radical sobre el futuro de la capa de ejecución de Ethereum, cuya ambición es comparable a la del plan Beam Chain para la capa de consenso. La propuesta tiene como objetivo aumentar significativamente la eficiencia de la capa de ejecución de Ethereum, abordar uno de los principales cuellos de botella en la escalabilidad y simplificar drásticamente la capa de ejecución; de hecho, esta podría ser la única forma de lograr este objetivo.
Idea central: reemplazar EVM con RISC-V como el lenguaje de máquina virtual para la redacción de contratos inteligentes.
Nota importante:
Nervos CKB VM ha establecido un precedente, que esencialmente es una implementación de RISC-V.
¿Por qué hacer esto?
A corto plazo, las EIP que se implementarán próximamente (como la lista de acceso a nivel de bloque, la ejecución diferida, el almacenamiento histórico distribuido y la EIP-4444) pueden resolver los principales cuellos de botella de escalabilidad de Ethereum L1. A medio plazo, se resolverán más problemas mediante la falta de estado y ZK-EVM. A largo plazo, los principales factores limitantes de la escalabilidad de Ethereum L1 se convertirán en:
Demostraré que reemplazar ZK-EVM por RISC-V puede resolver los cuellos de botella clave en (2) y (3).
La siguiente tabla muestra el número de ciclos necesarios para cada etapa de la ejecución de EVM en Succinct ZK-EVM:
Descripción del gráfico: las cuatro etapas principales que consumen tiempo son deserialize_inputs, initialize_witness_db, state_root_computation y block_execution
Entre ellos, initialize_witness_db y state_root_computation están relacionados con el árbol de estados, mientras que deserialize_inputs implica el proceso de convertir bloques y datos de testigos en una representación interna; de hecho, más del 50% es proporcional al tamaño de los datos de testigos.
Estas secciones se pueden optimizar en gran medida reemplazando el actual árbol de Merkle patricia keccak 16-ary con un árbol binario que utiliza una función hash fácil de probar. Si usamos Poseidón, podemos probar 2 millones de hashes por segundo en una computadora portátil (a modo de comparación, keccak es de aproximadamente 15,000 hash / seg). Además de Poseidón, hay muchas otras opciones. En general, hay mucho espacio para la optimización de estos componentes. Además, podemos eliminar la acumulación de _logs _bloom eliminando la floración.
El block_execution restante representa aproximadamente la mitad del ciclo de prueba actual (ciclos de probador). Para lograr un aumento de 100 veces en la eficiencia general de la prueba, la eficiencia de la prueba de EVM debe aumentar al menos 50 veces. Una de las soluciones es crear una implementación de prueba más eficiente para EVM, otra solución es notar que el actual probador ZK-EVM en realidad prueba compilando EVM a RISC-V, permitiendo que los desarrolladores de contratos inteligentes accedan directamente a esa máquina virtual RISC-V.
Algunos datos muestran que en ciertas circunstancias la mejora de eficiencia puede superar 100 veces:
!
En la práctica, el tiempo restante del prover puede estar ocupado principalmente por las operaciones de precompilación actuales. Si RISC-V se utiliza como la máquina virtual principal, el cronograma de Gas reflejará el tiempo de prueba real, y la presión económica incentivará a los desarrolladores a reducir el uso de precompilaciones de alto costo. Aun así, las ganancias pueden no ser tan significativas, pero tenemos razones suficientes para creer que estas ganancias serán muy considerables.
(Es importante notar que en la ejecución regular de EVM, la proporción de tiempo de "operaciones EVM" y "otras operaciones" se acerca al 50/50, por lo que creemos intuitivamente que eliminar EVM como "capa intermedia" traerá beneficios igualmente significativos.)
detalles de implementación
Hay varias formas de implementar esta propuesta. La solución menos disruptiva es dar soporte a ambas máquinas virtuales al mismo tiempo, permitiendo que el contrato se escriba en una de ellas. Ambos tipos de contratos tienen acceso a las mismas características: almacenamiento persistente (SLOAD/SSTORE), la capacidad de mantener saldos de ETH, iniciar/recibir llamadas y más. Los contratos EVM y RISC-V se pueden llamar entre sí: desde la perspectiva de RISC-V, llamar al contrato EVM equivale a ejecutar una llamada al sistema con parámetros especiales; El contrato de EVM que recibe el mensaje lo interpreta como una LLAMADA.
Desde la perspectiva del protocolo, un enfoque más agresivo es convertir los contratos EVM existentes en contratos del intérprete EVM escritos en RISC-V, ejecutando su código EVM existente. Es decir, si un contrato EVM tiene código C, el intérprete EVM se encuentra en la dirección X, entonces el contrato será reemplazado por la lógica de nivel superior, cuando sea llamado externamente con los parámetros D, llamando a X y pasando (C, D), y luego esperando el valor de retorno y reenviándolo. Si el intérprete EVM llama al contrato, solicitando ejecutar CALL o SLOAD/SSTORE, entonces el contrato realiza estas operaciones.
La solución de compromiso es adoptar la segunda opción, pero a través de un protocolo que apoye claramente el concepto de "intérprete de máquina virtual", exigiendo que su lógica esté escrita en RISC-V. EVM será el primer ejemplo, y en el futuro también podrá soportar otros lenguajes (Move podría ser una opción candidata).
Las principales ventajas de la segunda y tercera opción radican en que pueden simplificar en gran medida las especificaciones de la capa de ejecución. Considerando que incluso la eliminación de SELFDESTRUCT presenta grandes dificultades, esta idea podría ser el único camino viable para la simplificación. Tinygrad sigue la estricta regla de "no más de 10,000 líneas de código", y la base óptima de la cadena de bloques debería poder cumplir fácilmente con esta limitación y simplificarse aún más. El plan de Beam Chain espera simplificar significativamente la capa de consenso de Ethereum, y si la capa de ejecución desea lograr mejoras similares, esta transformación radical podría ser el único camino viable.