Según tengo entendido, EVM opera bloques de 256 bits. También lo uint256es el tamaño natural para los cálculos en memoria.
Pero no puedo encontrar en la documentación cómo se aplica a las transacciones y al almacenamiento.
Quiero decir, ¿hay algún beneficio de usar:
function x(uint64 a, uint64 b)
en vez de:
function x(uint a, uint b)
¿Cuánto tomará la primera transacción y los segundos? ambos usarán 512 bits para datos? o primeros 128 bits, segundos 512? ¿Quizás primero será de 256 bits, como una longitud de bloque mínima?
La misma pregunta para las estructuras utilizadas en el mapeo de valores, por ejemplo:
struct something {
uint8 x, uint64 y
}
comparado con:
struct something {
uint x, uint y
}
¿Hay alguna optimización de almacenamiento que EVM pueda usar para la primera estructura?
En el almacenamiento, las variables se empaquetan estrechamente, por lo que su estructura cabe en una palabra. Consulte esta página de documentos: http://solidity.readthedocs.io/en/latest/miscellaneous.html
Para los parámetros, el empaquetado es menos importante ya que son datos efímeros. Los argumentos de la función siempre están en la memoria: https://solidity.readthedocs.io/en/latest/frequently-asked-questions.html#what-is-the-memory-keyword-what-does-it-do
Sin embargo, otra pregunta es el formato de la transacción que se realiza por cable. Tengo problemas para encontrar la documentación del formato, pero encontré una página que dice que los argumentos se rellenan a 32 bytes en ABI: https://github.com/ethereum/wiki/wiki/Solidity-Features
En cualquier caso, definitivamente no es una gran diferencia de costos. Mirando los precios de la gasolina en el papel amarillo, almacenar una palabra es 20,000 gasolina. Cada byte distinto de cero de datos de transacción es solo 68 gas. Si cada parámetro se rellena a 256 bits, entonces tendremos un montón de cero bytes, y esos solo cuestan 4 de gas. (Dado que los ceros son más baratos, estoy tentado a pensar que están empacados, pero no estoy seguro).