Nueva propuesta de Vitalik: reemplazar el EVM actual con RISC-V

Este artículo propone una idea radical para el futuro de la capa de ejecución de Ethereum, que es tan ambiciosa como los esfuerzos de Beam Chain en la capa de consenso. Su objetivo es aumentar significativamente la eficiencia de la capa de ejecución de Ethereum, resolver uno de los principales cuellos de botella de escalabilidad, y también puede mejorar enormemente la simplicidad de la capa de ejecución; de hecho, quizás sea el único método.

Idea: utilizar RISC-V en lugar de EVM como lenguaje de máquina virtual para la escritura de contratos inteligentes (Nota del traductor: RISC-V se refiere a una arquitectura de conjunto de instrucciones abierta basada en los principios de la computación de conjunto de instrucciones reducidas RISC, donde V representa la quinta generación de RISC).

Importante aclaración:

• Conceptos como cuentas, llamadas entre contratos, almacenamiento, etc., seguirán siendo exactamente los mismos. Estas abstracciones funcionan muy bien y los desarrolladores se acostumbran a ellas. LOS CÓDIGOS DE OPERACIÓN COMO SLOAD, SSTORE, BALANCE Y CALL SE CONVIERTEN EN LLAMADAS AL SISTEMA RISC-V.
• En un mundo así, los contratos inteligentes pueden ser escritos en Rust, pero espero que la mayoría de los desarrolladores continúen escribiendo contratos inteligentes en Solidity (o Vyper), lo que se adaptará a la adición de RISC-V como backend. Esto se debe a que los contratos inteligentes escritos en Rust son realmente bastante feos, mientras que la legibilidad de Solidity y Vyper es mucho mayor. Quizás el cambio en devex sea pequeño, y los desarrolladores casi no noten este cambio.
• Los contratos EVM antiguos seguirán siendo válidos y serán completamente interoperables en ambas direcciones con los contratos RISC-V nuevos. Hay varias maneras de lograr esto, que presentaré más adelante en este artículo.

Un precedente es Nervos CKB VM, que básicamente es RISC-V.

¿Por qué hacer esto?

A corto plazo, los principales cuellos de botella en la escalabilidad de Ethereum L1 se solucionarán con los próximos EIP, como las listas de acceso a bloques, la ejecución diferida y el almacenamiento histórico distribuido, así como el EIP-4444. A mediano plazo, abordaremos problemas adicionales relacionados con el estado nulo y ZK-EVM. A largo plazo, los principales factores limitantes de la escalabilidad de Ethereum Layer1 son:

• Estabilidad del muestreo de disponibilidad de datos y del protocolo de almacenamiento histórico
• Esperamos mantener la competitividad del mercado de producción de bloques
• Capacidad de verificación ZK-EVM

Creo que reemplazar ZK-EVM con RISC-V puede resolver un cuello de botella clave en (2) y (3).

Esta es la tabla de conteo de ciclos de las diferentes partes de la capa de ejecución de EVM utilizada por Succinct ZK-EVM:

Hay cuatro partes que consumen mucho tiempo: deserialize_inputs, initialize_witness_db, state_root_computation y block_execution.

initialize_witness_db y state_root_computation están relacionados con el árbol de estado; deserialize_inputs se refiere al proceso de convertir los datos de bloque y testigo en una representación interna; por lo tanto, en realidad más del 50% es proporcional al tamaño del testigo.

Se puede optimizar en gran medida estas partes reemplazando el árbol Merkle patricia de 16 elementos keccak actual por un árbol binario que utiliza una función hash amigable para los probadores. Si usamos Poseidon, podemos demostrar 2 millones de valores hash por segundo en una computadora portátil (mientras que keccak genera aproximadamente 15,000 valores hash por segundo). Además de Poseidon, hay muchas otras opciones. En resumen, tenemos la oportunidad de reducir significativamente estos componentes. Como recompensa, podemos deshacernos de accrue_logs_bloom eliminando bloom.

Lo que queda es block_execution, que representa aproximadamente la mitad del ciclo de prueba gastado hoy. Si queremos aumentar la eficiencia del probador general en 100 veces, no podemos evitar el hecho de que al menos necesitamos aumentar la eficiencia del probador EVM en 50 veces. Una cosa que podemos hacer es intentar crear una implementación de EVM que sea más eficiente en términos de ciclo de prueba. Otra cosa que podemos hacer es notar que el probador ZK-EVM ya está funcionando hoy mediante la compilación de pruebas a una implementación de EVM en RISC-V, y permitir que los desarrolladores de contratos inteligentes accedan directamente a esa VM RISC-V.

Algunos datos indican que, en circunstancias limitadas, esto puede aumentar la eficiencia en más de 100 veces:

En realidad, espero que el tiempo restante de prueba esté dominado principalmente por la precompilación de hoy. Si utilizamos RISC-V como la máquina virtual principal, entonces el plan de gas reflejará el tiempo de prueba, por lo que habrá presión económica para dejar de usar precompilaciones más caras; pero aun así, los rendimientos no serán tan impresionantes, aunque tenemos razones suficientes para creer que los rendimientos serán muy significativos.

(Por cierto, una división de aproximadamente 50/50 entre “EVM” y “otras cosas” también aparece en la ejecución regular de EVM, y intuitivamente esperamos que los beneficios derivados de eliminar a EVM como “intermediario” deberían ser igualmente grandes)

Detalles de implementación

Hay varias formas de implementar tales sugerencias. El método de menor impacto es soportar dos máquinas virtuales y permitir la escritura de contratos en cualquiera de las máquinas virtuales. Ambos tipos de contratos pueden utilizar el mismo tipo de instalaciones: almacenamiento persistente (SLOAD y SSTORE), capacidad para mantener un saldo de ETH, capacidad para realizar y recibir llamadas, etc. Los contratos EVM y RISC-V pueden invocarse libremente entre sí; desde la perspectiva de RISC-V, llamar a un contrato EVM parece ser una llamada al sistema con algunos parámetros especiales; 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 que llaman a un intérprete EVM escrito en RISC-V, el cual ejecuta su código EVM existente. Es decir, si el contrato EVM tiene el código C y el intérprete EVM se encuentra en la dirección X, entonces el contrato sería reemplazado por la lógica de nivel superior, que al ser invocada externamente con el parámetro de llamada D, utiliza (C, D) para llamar a X, y luego espera el valor de retorno para reenvíarlo. Si el intérprete EVM llama al contrato, solicitando ejecutar CALL o SLOAD/SSTORE, entonces el contrato lo hará.

La ruta intermedia es adoptar la segunda opción, pero crear una función de protocolo clara para ello: básicamente, consagrar el concepto de “intérprete de máquina virtual” como un principio, y exigir que su lógica esté escrita en RISC-V. EVM será el primero, pero también podría haber otros (por ejemplo, Move podría ser un candidato).

Una de las principales ventajas de la segunda y tercera propuesta es que simplifican enormemente las especificaciones de la capa de ejecución; de hecho, esta idea podría ser el único enfoque viable, ya que incluso simplificaciones progresivas como la eliminación de SELFDESTRUCT son muy difíciles. Tinygrad tiene una regla estricta de que la cantidad de código nunca exceda las 10,000 líneas; la mejor capa base de blockchain debería ser capaz de adaptarse bien a estos límites, e incluso ser más pequeña. Los esfuerzos de Beam Chain tienen una gran esperanza de simplificar drásticamente la capa de consenso de Ethereum. Pero, para la capa de ejecución, este cambio radical podría ser la única forma de lograr beneficios similares.