Texto completo de la propuesta de capa ejecutiva L1 a largo plazo de Vitalik: reemplazar el EVM con RISC-V

Fuente: Vitalik Buterin

Compilación: KarenZ, Foresight News

El 20 de abril, Vitalik Buterin presentó una importante propuesta en la plataforma Ethereum Magicians para la capa de ejecución L1 a largo plazo de Ethereum. Propuso reemplazar la actual EVM (Ethereum Virtual Machine) por la arquitectura RISC-V como 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, romper uno de los principales cuellos de botella de escalado actuales y simplificar en gran medida la simplicidad de la capa de ejecución.

Foresight News ha compilado el texto completo de la propuesta para ayudar a los lectores a comprender esta visión técnica. La siguiente es una recopilación de la propuesta original:

Este artículo presenta una idea radical sobre el futuro de la capa de ejecución de Ethereum, no menos ambiciosa que las iniciativas Beam Chain de la capa de consenso. La propuesta tiene como objetivo mejorar drásticamente la eficiencia de la capa de ejecución de Ethereum, abordar uno de los principales cuellos de botella de escalado y simplificar significativamente la capa de ejecución, de hecho, esta puede ser la única forma de lograrlo.

Idea central: Reemplazar EVM con RISC-V como lenguaje de máquina virtual para contratos inteligentes.

Notas importantes:

• Conceptos como sistema de cuentas, llamadas entre contratos, almacenamiento, etc., se mantendrán en su totalidad. 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, ETC., SE CONVIERTEN EN LLAMADAS AL SISTEMA RISC-V.

• En este modo, los contratos inteligentes se pueden escribir en Rust, pero espero que la mayoría de los desarrolladores continúen escribiendo contratos en Solidity (o Vyper), que se adaptará a RISC-V como nuevo backend. Porque 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. Es posible que la experiencia de desarrollo apenas se vea afectada y que los desarrolladores ni siquiera noten el cambio.

• El antiguo contrato de EVM seguirá vigente y es totalmente bidireccional con el nuevo contrato RISC-V. Hay varias formas de hacer esto, que se discutirán con más detalle más adelante en este artículo.

Nervos CKB VM ha sentado un precedente y es esencialmente una implementación de RISC-V.

¿Por qué?

A corto plazo, las próximas EIP (por ejemplo, listas de acceso a nivel de bloque, ejecución diferida, almacenamiento de historial distribuido y EIP-4444) abordarán los principales cuellos de botella de escalado de Ethereum L1. A medio plazo se resolverán más problemas con la apatridia y la ZK-EVM. A largo plazo, los principales factores limitantes para el escalado de Ethereum L1 serán:

1. Estabilidad de la disponibilidad de datos, el muestreo y los protocolos de almacenamiento histórico

2. Mantener la demanda de competencia en el mercado de producción de bloques

3. Prueba de la ZK-EVM

Argumentaré que reemplazar ZK-EVM con RISC-V puede resolver los cuellos de botella clave en (2) y (3).

La siguiente tabla ilustra el número de ciclos necesarios para cada paso de la capa de ejecución de Succinct ZK-EVM Proof EVM:

Descripción del diagrama: Los cuatro segmentos principales que consumen mucho tiempo son deserialize_inputs, initialize_witness_db, state_root_computation y block_execution

initialize_witness_db y state_root_computation están relacionados con los árboles de estado, y deserialize_inputs implican el proceso de convertir los datos de bloques y testigos en representaciones internas, más del 50% de las cuales son realmente proporcionales al tamaño de los datos de los testigos.

Estas secciones se pueden optimizar en gran medida reemplazando el actual árbol de Merkle patricia keccak de 16 años 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 (en comparación con aproximadamente 15,000 hash / seg para keccak). 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 accrue_logs_bloom eliminando la floración.

El block_execution restante representa aproximadamente la mitad de los ciclos de prueba actuales. Para lograr un aumento de 100 veces en la eficiencia general de la prueba, se requiere una eficiencia de prueba de EVM de al menos 50 veces. Una solución es crear una implementación de prueba más eficiente para la EVM, y la otra es observar que el probador ZK-EVM actual en realidad compila la EVM a RISC-V para la prueba, lo que brinda a los desarrolladores de contratos inteligentes acceso directo a la máquina virtual RISC-V.

Algunos datos muestran que se pueden producir ganancias de eficiencia de más de 100 veces en ciertas situaciones:

En la práctica, el tiempo restante del probador puede estar ocupado principalmente por la operación de precompilación actual. Con RISC-V como máquina virtual principal, el programa de gas reflejará el tiempo de prueba real y la presión económica impulsará a los desarrolladores a reducir el uso de la precompilación de alto costo. Incluso entonces, las ganancias no serán tan significativas, pero tenemos buenas razones para creer que serán sustanciales.

(Vale la pena señalar que el tiempo necesario para las "operaciones de EVM" y "otras operaciones" en la ejecución regular de EVM también es cercano a 50/50, por lo que suponemos intuitivamente que eliminar la EVM como una "capa intermedia" traerá una ganancia igualmente significativa).

Detalles de la implementación

Hay varias formas de implementar esta propuesta. La solución menos disruptiva es admitir ambas máquinas virtuales y permitir 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 una perspectiva 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 interpretará como una LLAMADA.

Un enfoque más radical desde una perspectiva de protocolo es convertir un contrato de EVM existente en una llamada a un contrato de intérprete de EVM escrito en RISC-V para ejecutar su código de EVM existente. Es decir, si un contrato de EVM tiene código C y el intérprete de EVM está en la dirección X, entonces el contrato será reemplazado por una lógica de nivel superior que, cuando se llama desde el exterior con un argumento de llamada D, llama a X y pasa (C, D), luego espera el valor devuelto y reenvía. Si el propio intérprete de EVM llama al contrato, solicitando ejecutar CALL o SLOAD/SSTORE, el contrato realiza estas operaciones.

El compromiso es la segunda opción, pero con soporte explícito para el concepto de un "intérprete de máquina virtual" a través de un protocolo que requiere que su lógica esté escrita en RISC-V. EVM será la primera instancia, con soporte para otros idiomas en el futuro (Move puede ser un candidato).

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 ELIMINAR INCLUSO 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 de "no más de 10,000 líneas de código", y la cadena de bloques óptima subyacente debería poder cumplir fácilmente con este límite y simplificarlo 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.