Esta publicación propone una idea radical para el futuro de la capa de ejecución de Ethereum, igual de ambiciosa que el esfuerzo de la cadena de rayos para la capa de consenso. Su objetivo es mejorar enormemente la eficiencia de la capa de ejecución de Ethereum, resolviendo uno de los principales cuellos de botella de escalabilidad, y también puede mejorar en gran medida la simplicidad de la capa de ejecución, de hecho, quizás sea la única manera de hacerlo.

La idea: reemplazar el EVM con RISC-V como el lenguaje de máquina virtual en el que se escriben los contratos inteligentes.

Aclaraciones importantes:

• Los conceptos de cuentas, llamadas entre contratos, almacenamiento, etc. se mantendrían exactamente iguales. Estas abstracciones funcionan bien y los desarrolladores están acostumbrados a ellas. Opcodes como SLOAD, SSTORE, BALANCE, CALL, etc., se convertirían en llamadas al sistema RISC-V.
• En un mundo así, los contratos inteligentes podrían estar escritos en Rust, pero espero que la mayoría de los desarrolladores sigan escribiendo contratos inteligentes en Solidity (o Vyper), los cuales se adaptarían para añadir RISC-V como backend. Esto se debe a que los contratos inteligentes escritos en Rust sonrealmentebastantefeo, y Solidity y Vyper son muchomáslegible. Potencialmente, devex cambiaría muy poco y los desarrolladores apenas notarían el cambio en absoluto.
• Los contratos EVM de estilo antiguo seguirán funcionando y serán completamente interoperables en ambas direcciones con los contratos RISC-V de estilo nuevo. Hay un par de formas de hacer esto, en las que profundizaré más adelante en esta publicación.

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

¿Por qué hacer esto?

A corto plazo, los principales cuellos de botella para la escalabilidad de Ethereum L1 se abordan con próximos EIPs como listas de acceso de nivel de bloque, Ejecución retrasaday almacenamiento de historial distribuido adicional EIP-4444. En el medio plazo, abordamos más problemas con statelessnessyZK-EVMs. En el largo plazo, los principales factores limitantes en la escalabilidad de Ethereum L1 son:

1. Estabilidad de los protocolos de muestreo de disponibilidad de datos y almacenamiento de historial
2. Deseo de mantener la producción de bloques como un mercado competitivo
3. Capacidades de demostración ZK-EVM

Argumentaré que reemplazar el ZK-EVM con RISC-V resuelve un cuello de botella clave en (2) y (3).

Esta es una tabla del número de ciclos que el Succinct ZK-EVM utiliza para demostrar diferentes partes de la capa de ejecución EVM:

Hay cuatro partes que ocupan una cantidad significativa de tiempo: deserialize_inputs, initialize_witness_db, state_root_computation y block_execution.

initialize_witness_db y state_root_computation tienen que ver con el árbol de estado, y deserialize_inputs se refiere al proceso de convertir los datos del bloque y del testigo en una representación interna; por lo tanto, realísticamente más del 50% de ello es proporcional a los tamaños del testigo.

Estas partes pueden ser altamente optimizadas reemplazando el árbol de patricia Merkle de 16-arios keccak actual con un árbol binario que utiliza una función hash amigable para el probador. Si usamos Poseidon, podemos demostrar 2 millones de hashes por segundoen una computadora portátil (en comparación con ~15,000 hash/seg para keccak). También hay muchas opciones aparte de Poseidón. En resumen, hay oportunidades para reducir drásticamente estos componentes. Como bonificación, podemos deshacernos de accrue_logs_bloom, bueno,desprendiéndose del florecimiento.

Esto deja la ejecución de bloques, que representa aproximadamente la mitad de los ciclos del verificador gastados hoy. Si queremos aumentar la eficiencia total del verificador en 100 veces, no hay forma de evitar el hecho de que necesitamos al menos 50 veces la eficiencia del verificador EVM. Una cosa que podríamos hacer es intentar crear implementaciones del EVM que sean mucho más eficientes en términos de ciclos del verificador. La otra cosa que podemos hacer es notar que los verificadores ZK-EVM de hoy ya funcionan probando implementaciones del EVM compiladas a RISC-V, y dar a los desarrolladores de contratos inteligentes acceso directo a ese VM RISC-V.

Algunos números sugieren que en casos limitados, esto podría proporcionar ganancias de eficiencia de más de 100 veces:

En la práctica, espero que el tiempo restante del probador esté dominado por lo que hoy son precompilaciones. Si convertimos RISC-V en el VM principal, entonces el cronograma de gas reflejará los tiempos de prueba, y habrá presión económica para dejar de usar precompilaciones más caras; pero aún así, las ganancias no serán tan impresionantes, pero tenemos buenas razones para creer que serán muy significativas.

(Por cierto, la división aproximada de 50/50 entre “EVM” y “otras cosas” también aparece en la ejecución normal de EVM, y intuitivamente esperamos que las ganancias de eliminar EVM como "el intermediario" sean igualmente grandes)

Detalles de implementación

Hay varias formas de implementar este tipo de propuesta. La menos disruptiva es admitir dos VM y permitir que los contratos se escriban en cualquiera de ellos. Ambos tipos de contratos tendrían acceso a los mismos tipos de facilidades: almacenamiento persistente (SLOAD y SSTORE), la capacidad de mantener saldos de ETH, la capacidad de realizar y recibir llamadas, etc. Los contratos de EVM y RISC-V serían libres de llamarse entre sí; desde la perspectiva de RISC-V, llamar a un contrato de EVM parecería desde su perspectiva estar haciendo una llamada al sistema con algunos parámetros especiales; el contrato de EVM que recibe el mensaje lo interpretaría como un CALL.

Un enfoque más radical desde una perspectiva de protocolo es convertir los contratos existentes de EVM en contratos que llaman a un contrato intérprete de EVM escrito en RISC-V que ejecuta su código EVM existente. Es decir, si un contrato de EVM tiene el código C, y el intérprete de EVM vive en la dirección X, entonces el contrato se reemplaza con lógica de nivel superior que, cuando se llama desde el exterior con parámetros de llamada D, llama a X con (C, D), y luego espera el valor de retorno y lo reenvía. Si el propio intérprete de EVM llama al contrato, pidiendo ejecutar un CALL o SLOAD/SSTORE, entonces el contrato lo hace.

Una ruta intermedia es optar por la segunda opción, pero crear una característica de protocolo explícita para ello, básicamente, consagrar el concepto de un 'intérprete de máquina virtual' y requerir que su lógica esté escrita en RISC-V. El EVM sería el primero, pero podría haber otros (por ejemplo, Move podría ser un candidato).

Un beneficio clave de la segunda y tercera propuesta es que simplifican en gran medida la especificación de la capa de ejecución; de hecho, este tipo de idea puede ser la única forma práctica de hacerlo, dada la gran dificultad incluso de simplificaciones incrementales como eliminar SELFDESTRUCT. Tinygrad tiene la regla estricta de nunca superando las 10000 líneas de código; una capa base óptima de blockchain debería poder encajar bien dentro de esos márgenes e incluso ser aún más pequeña. El esfuerzo de la cadena beam promete simplificar en gran medida la capa de consenso de Ethereum. Pero para que la capa de ejecución vea ganancias similares, este tipo de cambio radical puede ser el único camino viable.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [Magos de Ethereum]. Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. El equipo de Gate Learn realiza traducciones del artículo a otros idiomas. Copiar, distribuir o plagiar los artículos traducidos está prohibido a menos que se mencione.