¿No sería más eficiente una EVM basada en 64 bits en el ecosistema Ethereum?

Como dice el diseño de Ethereum Rationale :

Tamaño de palabra de 32 bytes: la alternativa son palabras de 4 u 8 bytes, como en la mayoría de las otras arquitecturas, o ilimitadas, como en Bitcoin. Las palabras de 4 u 8 bytes son demasiado restrictivas para almacenar direcciones y valores grandes para cálculos criptográficos, y los valores ilimitados son demasiado difíciles para crear un modelo de gas seguro. 32 bytes es ideal porque es lo suficientemente grande como para almacenar valores de 32 bytes comunes en muchas implementaciones criptográficas, así como direcciones (y brinda la capacidad de empaquetar direcciones y valores en un solo índice de almacenamiento como una optimización), pero no tan grande como para ser extremadamente ineficiente.

Pero la cosa es:

  • Una implementación de EVM de 256 bits ayuda a trabajar con direcciones, y eso es cierto. Pero como Ethereum no se define como un sistema de criptomonedas, la parte más importante de los datos no serían las direcciones, sino los datos utilizados en los contratos inteligentes .
  • Si la mayoría de las CPU en el mercado en realidad están hechas con una arquitectura de 64 bits , y un alto porcentaje de los datos con los que trabajamos en Ethereum Ecosystem es aproximadamente el mismo (64 bits, 32 bits, 16 bits, 8 bits. .). ¿Crees que una EVM basada en una arquitectura de 64 bits o algo así no mejoraría el rendimiento de todo el sistema?

Piénselo, si tiene que iterar una matriz de datos de 32 o 64 bits y los bloques de memoria EVM son de 256 bits, es un trabajo adicional para la CPU hacer los cálculos y se pierde mucho tiempo.

Si cree que esto sería una posible mejora, ¿hay alguna iniciativa o EIP abierta? no he visto nada

Gracias.

Respuestas (2)

Tendrás varios problemas

  • Si mantiene su almacenamiento en 256 bits, será más complejo acceder. Necesita palabras de 4 x 64 bits para dirigirse a una ranura de almacenamiento. Todas las operaciones tendrán que convertir 256 bits a 64 bits. Su EVM será bastante complejo de implementar y auditar.

  • Si cambia el almacenamiento para usar 64 bits, entonces su EVM será más simple, pero el almacenamiento es mucho más pequeño y las colisiones son mucho más probables.

  • No puede representar direcciones de forma nativa. Las direcciones son de 20 bytes y necesitará registros de 3 x 64 bits.

  • Necesita compatibilidad con versiones anteriores de contratos antiguos y tendrá que implementar algún tipo de traductor.

La CPU no es el cuello de botella. Claro que hay mejores máquinas virtuales (y hay investigaciones sobre cómo reemplazarlas con WASM), pero la implementación actual hace su trabajo correctamente.

El tema más importante es IO, cada transacción tiene un par de modificaciones del estado de Ethereum World. Y un bloque tiene alrededor de cien transacciones, y se genera un bloque cada 15 segundos.

Pasar a 64 bits es una actualización extremadamente importante de Ethereum, y el uso de una máquina de 256 bits fue un error. Ismael, ¿cuánto código máquina has escrito? La forma en que hablas de los registros me hace pensar que no entiendes el código máquina. El uso de una máquina de 32 bits no afectaría la seguridad y reduciría las tarifas de gasolina debido al espacio desperdiciado, incluso más que una máquina de 64 bits porque estaríamos almacenando menos 0. El hecho de que el booltipo desperdicie 255 bits me vuelve loco.
@rook No ataques a la persona, sino al argumento. Con la información disponible hoy y las necesidades del proyecto, optaría por una máquina virtual de 64 bits, pero hace 7 años la experiencia no era la misma. Si te sientes capaz escribe el EVM de 64 bits y propone el cambio al EF. Si es bueno, será aceptado, obtendrá cualquier trabajo que desee y se le pagará en consecuencia. Es fácil hablar, escribir algo que funcione es mucho más difícil.
-Mis disculpas. No importa cuántos registros ocupe una variable porque estas máquinas deben tener un código de operación que pueda hacer comparaciones de múltiples registros. Al hacer que todas las variables sean de 256 bits, termina almacenando más ceros que datos reales, y eso es lo que estamos viendo. Con mucho gusto escribiría esta VM, esto no es difícil porque no es nada nuevo. El primer EVM fue completamente nuevo, y eso fue difícil de hacer, y tengo compasión por eso. Pero ahora que podemos ver que EVM almacena más espacio vacío que datos reales, tenemos un problema real.
De hecho, si necesitan ingenieros en este proyecto, tengo un excelente currículum. Entonces, para este caso, x86 tiene 8 registros de propósito general, lo que significa que en un sistema de 64 bits se pueden cargar dos claves completas de 256 bits, y luego una comparación es una sola operación. El EVM debe seguir este patrón, ¿con quién debo hablar?
@rook La Fundación Ethereum y otras organizaciones tienen programas de subvenciones que cualquiera puede solicitar, ethereum.org/en/community/grants . Antes de aplicar, sugiero participar en algunos de los foros y buscar otros intereses de investigación como ethresear.ch .
@ishmael gracias, eres un gran activo para esta comunidad y una persona amable.

Por supuesto, es difícil decirlo con seguridad, pero mi intuición es que el cuello de botella no es el tamaño de las palabras. El cuello de botella es la imposición deliberada del tiempo de bloque de 14 segundos. El tiempo de bloque es un parámetro que los diseñadores originales eligieron para obligar a los mineros a gastar energía en forma de electricidad. Incluso si optimizaste en otra parte del sistema, esos 14 segundos no desaparecerían, por lo que la optimización no se manifestaría.

Sí, pero con la transición a PoS y otras metodologías de consenso, no es tan importante el tiempo de bloqueo fijo y cosas más importantes como esta implementación de EVM. Por eso pedí eso.
Entonces, una vez que migremos a PoS, ¿hay mucho más espacio para mejorar la arquitectura de EVM?
¿No sería más eficiente una EVM basada en 64 bits en el ecosistema Ethereum?
RespuestasAquíPolítica de privacidad1y, 0v