jakiro
Fuente: Vitalik Buterin, Ethereum Magicians; Compilación: Tao Zhu, Bittain Vision
Este artículo presenta una idea agresiva para el futuro de la capa de ejecución de Ethereum, que es tan ambiciosa como los esfuerzos de la cadena de haz hacia 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 escala y también mejorar en gran medida la simplicidad de la capa de ejecución; de hecho, esta es quizás la única forma.
Idea: use RISC-V como lenguaje de máquina virtual para escribir contratos inteligentes EVM.
Aclaración importante:
-
Los conceptos de cuentas, llamadas de contrato cruzado, almacenamiento, etc. seguirán siendo exactamente los mismos. Estas abstracciones funcionan bien y los desarrolladores se acostumbran a ellas. Sload, Sstore, Balance, Call y otros códigos de operación se convertirán en llamadas al sistema RISC-V.
-
En un mundo como este, los contratos inteligentes se pueden escribir en Rust, pero espero que la mayoría de los desarrolladores continúen escribiendo contratos inteligentes en solidez (o Vyper), lo que se adaptará a agregar RISC-V como un backend. Esto se debe a que los contratos inteligentes escritos en Rust en realidad son bastante feas, mientras que la solidez y Vyper son mucho más legibles. Quizás el cambio en Devex es pequeño, y los desarrolladores difícilmente pueden notar este cambio.
-
Los contratos EVM de estilo antiguo continuarán siendo válidos y serán totalmente interoperables bidireccionales con los nuevos contratos RISC-V. Hay varias formas de hacer esto, que cubriré más adelante en este artículo.
Un precedente es el Nervos CKB VM, que es básicamente RISC-V.
¿Por qué hacer esto?
En el corto plazo, los principales cuellos de botella en la escalabilidad Ethereum L1 se abordarán con los próximos EIP, como listas de acceso a nivel de bloque, ejecución de latencia y almacenamiento histórico distribuido, y EIP-4444. En el mediano plazo, abordaremos más cuestiones de apatridia y ZK-EVM. A la larga, los principales factores limitantes para la expansión de Ethereum Layer1 son:
-
Muestreo de disponibilidad de datos y estabilidad de los protocolos de almacenamiento histórico
-
Espero mantener competitivo el mercado de la 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).
Este es el número de bucles utilizados por ZK-EVM sucinto para probar diferentes partes de la capa de ejecución EVM:
Hay cuatro partes que toman mucho tiempo: deserialize_inputs, inicialize_witness_db, state_root_computation y block_execution.
inicialize_witness_db y state_root_computation están relacionados con los árboles de estado, y deserialize_inputs se refiere al proceso de convertir bloques y datos de testigos en representaciones internas; Por lo tanto, de hecho, más del 50% es proporcional a la escala de testigos.
Estas piezas pueden optimizarse fuertemente reemplazando el actual árbol de Merkle Patricia Keccak de 16 miembros con un árbol binario que utiliza funciones hash amigables con Prover. Si usamos Poseidón, podemos probar 2 millones de hashes por segundo en nuestra computadora portátil (y Keccak Hashes alrededor de 15,000 hash por segundo). Hay muchas otras opciones además de Poseidón. En general, tenemos la oportunidad de reducir drásticamente estos componentes. Como beneficio adicional, podemos deshacernos de acrue_logs_bloom deshaciéndose de Bloom.
El resto es block_execution, que representa aproximadamente la mitad del ciclo de prueba que se gasta hoy. Si queremos aumentar la eficiencia general de la prover en 100 veces, no podemos evitar el hecho de que necesitamos aumentar la eficiencia de prover de EVM en al menos 50 veces. Una cosa que podemos hacer es intentar crear implementaciones EVM que sean más eficientes en los ciclos de prueba. Otra cosa que podemos hacer es tener en cuenta que el ZK-EVM Prover ha funcionado hoy al demostrar que la implementación EVM compilada en RISC-V y ofrece a los desarrolladores de contratos inteligentes acceso directo a esa VM RISC-V.
Algunos datos sugieren que esto puede aumentar la eficiencia en más de 100 veces en casos limitados:
De hecho, espero que el tiempo de prueba restante esté dominado por la precompilación de hoy. Si usamos RISC-V como la máquina virtual principal, el plan de gas reflejará el tiempo de prueba, por lo que habrá presión económica para dejar de usar precompiladores más caros; Pero aun así, los beneficios no serán tan impresionantes, pero tenemos buenas razones para creer que los beneficios serán muy significativos.
(Por cierto, la división de aproximadamente 50/50 entre «EVM» y «otras cosas» también aparece en la ejecución regular de EVM, e intuitivamente esperamos que los beneficios de eliminar de EVM como «Middleman» deberían ser igualmente grandes)
Detalles de implementación
Hay varias formas de implementar tales sugerencias. El enfoque menos disruptivo es admitir dos máquinas virtuales y permitir que se escriban contratos en cualquier máquina virtual. Ambos tipos de contratos pueden usar el mismo tipo de instalaciones: almacenamiento persistente (Sload y Sstore), la capacidad de mantener los saldos ETH, la capacidad de hacer y recibir llamadas, etc. Los contratos EVM y RISC-V son libres de llamarse entre sí; Desde el punto de vista RISC-V, llamar al contrato EVM parece estar haciendo una llamada del sistema con algunos parámetros especiales; El contrato EVM que recibe el mensaje lo interpreta como una llamada.
Desde una perspectiva del protocolo, un enfoque más radical es convertir un contrato EVM existente a un contrato que llame a un contrato de intérprete EVM escrito en RISC-V, que ejecuta su código EVM existente. Es decir, si el contrato EVM tiene el Código C y el intérprete EVM está en la dirección X, el contrato se reemplazará con la lógica de nivel superior, cuando se llama desde el exterior usando el parámetro de llamada D, X se llama con (C, D), y luego espere el valor de retorno y reenvíelo. Si el intérprete de EVM llama al contrato y requiere ejecutar llamadas o lanar/sstore, el contrato lo hace.
La ruta intermedia es tomar la segunda opción, pero crear una función de protocolo clara para ella, básicamente, el concepto de «intérprete de máquina virtual» se toma como una guía y se requiere que su lógica se escriba en RISC -V. EVM será el primero, pero puede haber otros (por ejemplo, el movimiento puede ser un candidato).
Uno de los principales beneficios de la segunda y tercera propuestas es que simplifican enormemente las especificaciones de la capa de ejecución; de hecho, esta idea puede ser el único enfoque viable, ya que incluso una simplificación progresiva como eliminar la autodestrucción es muy difícil. Tinygrad tiene una regla estricta de que el volumen del código nunca excede las 10,000 líneas; La mejor capa de base blockchain debería poder adaptarse bien a estos límites, incluso más pequeños. Los esfuerzos de la cadena de haz tienen una gran esperanza para simplificar en gran medida la capa de consenso de Ethereum. Pero para la capa de ejecución, este cambio radical puede ser la única forma viable de obtener beneficios similares.
