Los desarrolladores refutan a Vitalik: las suposiciones son erróneas y RISC-V no es la mejor opción

Este artículo es de: Compilación del desarrollador de Ethereum levochka.eth

|Odaily Planet Daily (@OdailyChina); @azuma_eth Nota del editor

:

Ayer, el cofundador de Ethereum, Vitalik, publicó un artículo radical sobre la actualización de la capa de ejecución de Ethereum (ver "El nuevo artículo radical de Vitalik: el escalado de la capa de ejecución "no se rompe, no se mantiene", EVM debe iterarse en el futuro), mencionando que espera reemplazarlo con RISC-V EVM como lenguaje de máquina virtual para contratos inteligentes.

Tan pronto como se publicó este artículo, inmediatamente causó un alboroto en la comunidad de desarrolladores de Ethereum, y muchos peces gordos técnicos expresaron diferentes puntos de vista sobre el plan. Poco después de que se publicara el artículo, el desarrollador de Ethereum de nivel 1, levochka.eth, escribió un extenso artículo debajo del artículo original refutando el argumento de Vitalik de que Vitalik había hecho suposiciones equivocadas sobre el sistema de prueba y su rendimiento, y que RISC-V podría no ser la mejor opción porque no podía equilibrar la "escalabilidad" y la "mantenibilidad".

El siguiente es el artículo original sobre levochka.eth, compilado por el diario Odaily.

Por favor, no hagas esto.

Este plan no tiene sentido, porque está haciendo suposiciones equivocadas sobre la prueba del sistema y su rendimiento.

Hipótesis de validación

Según tengo entendido, los principales argumentos para este esquema son la "escalabilidad" y la "mantenibilidad".

En primer lugar, quiero hablar de la mantenibilidad.

De hecho, todas las RISC-V ZK-VM requieren "precompilaciones" para manejar operaciones de proceso intensivo. La lista precompilada de SP 1 se puede encontrar en la documentación de Succinct, y encontrará que cubre casi todos los códigos de operación "computacionales" importantes en la EVM.

Como resultado, todas las modificaciones de las primitivas criptográficas de la capa base requieren que se escriban y auditen nuevos "circuitos" para estas precompilaciones, lo cual es una limitación seria.

De hecho, si el rendimiento es lo suficientemente bueno, puede ser relativamente fácil realizar la capacidad de servicio de la parte "no EVM" del cliente. No estoy seguro de si es lo suficientemente bueno, pero tengo menos confianza en esta parte por las siguientes razones: el

• "cálculo del árbol de estados" se puede acelerar enormemente con una precompilación amigable como Poseidón.

• Sin embargo, no está claro si la "deserialización" puede manejarse de una manera elegante y fácil de mantener.
  

• Además, hay algunos detalles complicados (como la medición de gas y varias comprobaciones) que pueden incluirse en el "tiempo de evaluación del bloque", pero que en realidad deberían clasificarse como partes "no EVM", que tienden a ser más vulnerables a la presión de mantenimiento.

En segundo lugar, la parte de la escalabilidad.

Debo reiterar que es imposible que RISC-V maneje las cargas de EVM sin usar la precompilación, absolutamente no.

Por lo tanto, la afirmación en el texto original de que "el tiempo de prueba final estará dominado por la operación de precompilación actual" es técnicamente correcta, pero es demasiado optimista: asume que no habrá precompilación en el futuro, cuando de hecho (en este escenario futuro) la precompilación seguirá existiendo, y es exactamente lo mismo que los códigos de operación computacionalmente intensivos en la EVM (como firmas, hashes y posiblemente análogos grandes).

Es difícil juzgar el ejemplo de Fibonacci sin entrar en los detalles más sutiles, pero las ventajas vienen al menos en parte:

• la diferencia entre la interpretación y la sobrecarga de ejecución;

• Desenrollado cíclico (reduciendo el "flujo de control" de RISC-V, no se sabe con certeza si se puede implementar Solidity, pero incluso un solo código de operación puede generar un gran número de accesos de flujo de control/memoria debido a la sobrecarga de interpretación);

• utilizar tipos de datos más pequeños;

A este respecto, me gustaría señalar que, para obtener los beneficios de los puntos 1 y 2, hay que eliminar la "sobrecarga de interpretación". Esto está en línea con la filosofía de RISC-V, pero este no es el RISC-V que estamos discutiendo actualmente, sino más bien un "RISC-V" similar: requiere ciertas capacidades adicionales, como el soporte para conceptos de contrato.

Aquí viene el problema

, entonces, hay algunos problemas aquí.

• Para mejorar la capacidad de mantenimiento, necesita un RISC-V (con precompilación) que compile la EVM, eso es todo.

• Para mejorar la escalabilidad, se necesita algo completamente diferente: una nueva arquitectura que pueda ser similar a RISC-V que comprenda el concepto de "contratos", sea compatible con las limitaciones de tiempo de ejecución de Ethereum y pueda ejecutar el código del contrato directamente (sin la "sobrecarga de interpretación").

Ahora asumo que te refieres al segundo caso (ya que el resto del artículo parece implicar eso). Necesito llamar su atención sobre el hecho de que todo el código fuera de este entorno todavía se escribirá en el lenguaje zkVM RISC-V actual, lo que tiene un impacto significativo en el mantenimiento.

Como alternativa,

podemos compilar el código de bytes a partir del código de operación EVM de alto nivel. El compilador es responsable de garantizar que el compilador permanezca invariable, por ejemplo, no experimente un "desbordamiento de pila". Me gustaría ver esto mostrado en una EVM normal. Los SNARK compilados correctamente se pueden proporcionar con instrucciones de implementación del contrato.

También podemos construir una "prueba formal" que demuestre que algunos invariantes se conservan. Hasta donde yo sé, este enfoque (no "virtualización") se ha utilizado en algunos contextos de navegadores. Al generar SNARK de esta prueba formal, puede lograr resultados similares. 

Por supuesto, la opción más fácil es morder la bala y hacer ......

Construir una MMU "encadenada" mínima

, que puede expresar implícitamente en el artículo, pero permítame advertir que si desea eliminar la sobrecarga de virtualización, debe ejecutar el código compilado directamente, lo que significa que debe evitar de alguna manera que el contrato (ahora ejecutable) escriba en la memoria del kernel (no una implementación de EVM).

Por lo tanto, necesitamos algún tipo de "unidad de gestión de memoria" (MMU). El mecanismo de paginación de las computadoras tradicionales puede no ser necesario porque el espacio de memoria "físico" es casi infinito. Esta MMU debe ser lo más ajustada posible (porque está en el mismo nivel de abstracción que la propia arquitectura), pero algunas características como la atomicidad de las transacciones se pueden mover a esta capa.

En este punto, la EVM demostrable se convierte en el programa del kernel que se ejecuta en esta arquitectura.

Curiosamente, en todas estas condiciones, la mejor "arquitectura de conjunto de instrucciones" (ISA) para esta tarea puede no ser RISC-V, sino algo similar a EOF-EVM por las siguientes razones:

• Los códigos de operación "pequeños" en realidad dan como resultado una gran cantidad de acceso a la memoria, lo cual es difícil para que los métodos de atestación existentes manejen de manera eficiente.

• Para reducir la sobrecarga de ramificación, mostramos cómo probar el código de "saltos estáticos" (EOF) con rendimiento a nivel de precompilación en nuestro artículo reciente, Morgana.

Mi sugerencia es construir una nueva arquitectura amigable con pruebas con una MMU mínima que permita que el contrato se ejecute como un ejecutable separado. No creo que se suponga que sea RISC-V, sino más bien un nuevo ISA optimizado para las limitaciones del protocolo SNARK, e incluso un ISA que herede parcialmente un subconjunto de códigos de operación EVM podría ser mejor: como sabemos, la precompilación está aquí para quedarse, nos guste o no, por lo que RISC-V no aporta ninguna simplificación aquí.