El 20 de abril, Vitalik Buterin propuso una importante propuesta sobre la capa de ejecución L1 de Ethereum en la plataforma Ethereum Magicians. Sugirió 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, superando uno de los principales cuellos de botella de escalabilidad actuales, al mismo tiempo que simplifica significativamente 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 tecnológica. A continuación se presenta el contenido traducido de la propuesta original:
Este artículo presenta una idea radical sobre el futuro de la capa de ejecución de Ethereum, cuya ambición no es menor que la del plan Beam Chain de la capa de consenso. Esta propuesta tiene como objetivo mejorar significativamente la eficiencia de la capa de ejecución de Ethereum, abordar uno de los principales cuellos de botella de escalabilidad y simplificar notablemente la capa de ejecución; de hecho, puede ser la única forma de lograr este objetivo.
Idea central: Reemplazar EVM con RISC-V como un lenguaje de máquina virtual para contratos inteligentes.
Importante aviso:
El sistema de cuentas, las llamadas entre contratos y conceptos como el almacenamiento se conservará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, CALL se transformarán en llamadas del sistema RISC-V.
En este modo, los contratos inteligentes se pueden escribir en Rust, pero prevengo que la mayoría de los desarrolladores seguirán usando 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 tienen, en realidad, una legibilidad inferior, mientras que Solidity y Vyper son más claros y legibles. La experiencia de desarrollo podría verse prácticamente sin cambios, e incluso los desarrolladores podrían 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 discutirán en detalle más adelante en este artículo.
La VM de Nervos CKB ha establecido un precedente, que en esencia es una implementación de RISC-V.
¿Por qué hacerlo?
A corto plazo, las EIP que se implementarán próximamente (como las listas de acceso a nivel de bloque, la ejecución diferida, el almacenamiento histórico distribuido y la EIP-4444) podrán resolver los principales cuellos de botella de escalabilidad de Ethereum L1. A medio plazo, se abordarán más problemas a través de la ausencia de estado y el ZK-EVM. A largo plazo, los principales factores limitantes de la escalabilidad de Ethereum L1 se convertirán en:
La estabilidad del muestreo de disponibilidad de datos y el 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
Argumentaré que reemplazar ZK-EVM por RISC-V puede resolver los cuellos de botella clave en (2) y (3).
La tabla a continuación muestra el número de ciclos necesarios para cada etapa de la capa de ejecución EVM del 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 initialize_witness_db y state_root_computation están relacionados con el árbol de estados, deserialize_inputs implica el proceso de convertir los datos de bloques y testigos en una representación interna, de hecho, más del 50% es proporcional al tamaño de los datos de testigos.
Al reemplazar el árbol de Merkle patricia de 16 arios keccak actual por un árbol binario que utiliza funciones hash fáciles de probar, se pueden optimizar significativamente estas partes. Si utilizamos Poseidon, podemos probar 2 millones de hashes por segundo en una computadora portátil (en comparación, keccak es de aproximadamente 15,000 hash/sec). Además de Poseidon, hay muchas otras opciones. En general, estos componentes tienen un gran margen de optimización. Además, podemos eliminar accrue_logs_bloom al eliminar bloom.
El block_execution restante representa aproximadamente la mitad del ciclo de prueba actual (prover cycles). 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 directamente a los desarrolladores de contratos inteligentes acceder a esa máquina virtual RISC-V.
Algunos datos muestran que en ciertas circunstancias, la mejora de la eficiencia podría superar 100 veces:
En la práctica, el tiempo restante del prover puede estar principalmente ocupado por las operaciones de precompilación actuales. Si se utiliza RISC-V como la máquina virtual principal, el programa de Gas reflejará el tiempo real de prueba, y la presión económica incentivará a los desarrolladores a reducir el uso de precompilaciones de alto costo. Aun así, las ganancias no serán tan significativas, pero tenemos razones suficientes para creer que estas ganancias serán bastante considerables.
(Es importante señalar que en la ejecución regular de EVM, la proporción del tiempo de consumo de "operaciones EVM" y "otras operaciones" también se acerca al 50/50, por lo que creemos intuitivamente que eliminar EVM como "capa intermedia" traerá beneficios igualmente significativos.)
Detalles de implementación
Esta propuesta tiene múltiples formas de implementación. La opción menos destructiva es soportar simultáneamente dos máquinas virtuales, permitiendo que los contratos se escriban en cualquiera de ellas. Ambos tipos de contratos pueden acceder a las mismas funcionalidades: almacenamiento persistente (SLOAD/SSTORE), la capacidad de mantener un saldo de ETH, iniciar/recibir llamadas, etc. Los contratos EVM y RISC-V pueden llamarse entre sí: desde la perspectiva de RISC-V, llamar a un contrato EVM equivale a ejecutar una llamada al sistema con parámetros especiales; mientras que el contrato EVM que recibe el mensaje lo interpretará como CALL.
Desde el punto de vista del protocolo, un enfoque más agresivo sería convertir los contratos EVM existentes en contratos de intérprete EVM escritos en RISC-V, que ejecutan su código EVM existente. Es decir, si un contrato EVM tiene código C y el intérprete EVM se encuentra en la dirección X, entonces el contrato será reemplazado por una lógica de nivel superior que, al ser llamado externamente con el parámetro D, llama a X y pasa (C, D), y luego espera el valor de retorno y lo reenvía. Si el intérprete EVM llama al contrato, solicitando ejecutar CALL o SLOAD/SSTORE, entonces el contrato ejecutará estas operaciones.
La solución de compromiso es adoptar la segunda opción, pero mediante un acuerdo 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 se podrán soportar otros lenguajes (Move podría ser una opción candidata).
La principal ventaja de la segunda y tercera opción es que simplifican enormemente la especificación de la capa de ejecución. DADA LA DIFICULTAD DE INCLUSO ELIMINAR SIMPLIFICACIONES INCREMENTALES COMO LA AUTODESTRUCCIÓN, ESTA LÍNEA DE PENSAMIENTO PUEDE SER EL ÚNICO CAMINO VIABLE PARA SIMPLIFICAR. Tinygrad se adhiere a la regla estricta y rápida de "no más de 10,000 líneas de código", y la cadena de bloques subyacente óptima debería poder cumplir fácilmente con este límite y optimizarse aún más. La iniciativa Beam Chain promete simplificar drásticamente la capa de consenso de Ethereum, y un cambio tan radical puede ser la única forma de lograr un impulso similar en la capa de ejecución.
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.
Texto completo de la propuesta de capa de ejecución L1 a largo plazo de Vitalik: 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. Sugirió 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, superando uno de los principales cuellos de botella de escalabilidad actuales, al mismo tiempo que simplifica significativamente 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 tecnológica. A continuación se presenta el contenido traducido de la propuesta original:
Este artículo presenta una idea radical sobre el futuro de la capa de ejecución de Ethereum, cuya ambición no es menor que la del plan Beam Chain de la capa de consenso. Esta propuesta tiene como objetivo mejorar significativamente la eficiencia de la capa de ejecución de Ethereum, abordar uno de los principales cuellos de botella de escalabilidad y simplificar notablemente la capa de ejecución; de hecho, puede ser la única forma de lograr este objetivo.
Idea central: Reemplazar EVM con RISC-V como un lenguaje de máquina virtual para contratos inteligentes.
Importante aviso:
El sistema de cuentas, las llamadas entre contratos y conceptos como el almacenamiento se conservará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, CALL se transformarán en llamadas del sistema RISC-V.
En este modo, los contratos inteligentes se pueden escribir en Rust, pero prevengo que la mayoría de los desarrolladores seguirán usando 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 tienen, en realidad, una legibilidad inferior, mientras que Solidity y Vyper son más claros y legibles. La experiencia de desarrollo podría verse prácticamente sin cambios, e incluso los desarrolladores podrían 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 discutirán en detalle más adelante en este artículo.
La VM de Nervos CKB ha establecido un precedente, que en esencia es una implementación de RISC-V.
¿Por qué hacerlo?
A corto plazo, las EIP que se implementarán próximamente (como las listas de acceso a nivel de bloque, la ejecución diferida, el almacenamiento histórico distribuido y la EIP-4444) podrán resolver los principales cuellos de botella de escalabilidad de Ethereum L1. A medio plazo, se abordarán más problemas a través de la ausencia de estado y el ZK-EVM. A largo plazo, los principales factores limitantes de la escalabilidad de Ethereum L1 se convertirán en:
La estabilidad del muestreo de disponibilidad de datos y el 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
Argumentaré que reemplazar ZK-EVM por RISC-V puede resolver los cuellos de botella clave en (2) y (3).
La tabla a continuación muestra el número de ciclos necesarios para cada etapa de la capa de ejecución EVM del 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 initialize_witness_db y state_root_computation están relacionados con el árbol de estados, deserialize_inputs implica el proceso de convertir los datos de bloques y testigos en una representación interna, de hecho, más del 50% es proporcional al tamaño de los datos de testigos.
Al reemplazar el árbol de Merkle patricia de 16 arios keccak actual por un árbol binario que utiliza funciones hash fáciles de probar, se pueden optimizar significativamente estas partes. Si utilizamos Poseidon, podemos probar 2 millones de hashes por segundo en una computadora portátil (en comparación, keccak es de aproximadamente 15,000 hash/sec). Además de Poseidon, hay muchas otras opciones. En general, estos componentes tienen un gran margen de optimización. Además, podemos eliminar accrue_logs_bloom al eliminar bloom.
El block_execution restante representa aproximadamente la mitad del ciclo de prueba actual (prover cycles). 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 directamente a los desarrolladores de contratos inteligentes acceder a esa máquina virtual RISC-V.
Algunos datos muestran que en ciertas circunstancias, la mejora de la eficiencia podría superar 100 veces:
En la práctica, el tiempo restante del prover puede estar principalmente ocupado por las operaciones de precompilación actuales. Si se utiliza RISC-V como la máquina virtual principal, el programa de Gas reflejará el tiempo real de prueba, y la presión económica incentivará a los desarrolladores a reducir el uso de precompilaciones de alto costo. Aun así, las ganancias no serán tan significativas, pero tenemos razones suficientes para creer que estas ganancias serán bastante considerables.
(Es importante señalar que en la ejecución regular de EVM, la proporción del tiempo de consumo de "operaciones EVM" y "otras operaciones" también se acerca al 50/50, por lo que creemos intuitivamente que eliminar EVM como "capa intermedia" traerá beneficios igualmente significativos.)
Detalles de implementación
Esta propuesta tiene múltiples formas de implementación. La opción menos destructiva es soportar simultáneamente dos máquinas virtuales, permitiendo que los contratos se escriban en cualquiera de ellas. Ambos tipos de contratos pueden acceder a las mismas funcionalidades: almacenamiento persistente (SLOAD/SSTORE), la capacidad de mantener un saldo de ETH, iniciar/recibir llamadas, etc. Los contratos EVM y RISC-V pueden llamarse entre sí: desde la perspectiva de RISC-V, llamar a un contrato EVM equivale a ejecutar una llamada al sistema con parámetros especiales; mientras que el contrato EVM que recibe el mensaje lo interpretará como CALL.
Desde el punto de vista del protocolo, un enfoque más agresivo sería convertir los contratos EVM existentes en contratos de intérprete EVM escritos en RISC-V, que ejecutan su código EVM existente. Es decir, si un contrato EVM tiene código C y el intérprete EVM se encuentra en la dirección X, entonces el contrato será reemplazado por una lógica de nivel superior que, al ser llamado externamente con el parámetro D, llama a X y pasa (C, D), y luego espera el valor de retorno y lo reenvía. Si el intérprete EVM llama al contrato, solicitando ejecutar CALL o SLOAD/SSTORE, entonces el contrato ejecutará estas operaciones.
La solución de compromiso es adoptar la segunda opción, pero mediante un acuerdo 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 se podrán soportar otros lenguajes (Move podría ser una opción candidata).
La principal ventaja de la segunda y tercera opción es que simplifican enormemente la especificación de la capa de ejecución. DADA LA DIFICULTAD DE INCLUSO ELIMINAR SIMPLIFICACIONES INCREMENTALES COMO LA AUTODESTRUCCIÓN, ESTA LÍNEA DE PENSAMIENTO PUEDE SER EL ÚNICO CAMINO VIABLE PARA SIMPLIFICAR. Tinygrad se adhiere a la regla estricta y rápida de "no más de 10,000 líneas de código", y la cadena de bloques subyacente óptima debería poder cumplir fácilmente con este límite y optimizarse aún más. La iniciativa Beam Chain promete simplificar drásticamente la capa de consenso de Ethereum, y un cambio tan radical puede ser la única forma de lograr un impulso similar en la capa de ejecución.