¿Es seguro y efectivo usar números enteros de 128 bits para rastrear wei en un contrato para ahorrar gasolina?

El tipo predeterminado para Wei en Solidity es el entero sin signo de 256 bits. (por ejemplo, mensaje.valor)

Sin embargo, para rastrear 1.7e38 wei (1.7e20 ether) solo necesita un número entero de 127 bits. Es un número gigantesco que probablemente no se supere en ninguna aplicación del mundo real.

Siempre que no multiplique dos valores de Wei, ¿se considera razonablemente seguro rastrear Wei en enteros de 128 bits con signo para que dos valores puedan empaquetarse en una palabra de 256 bits para ahorrar costos de almacenamiento en gas?

¿Existen costos computacionales adicionales en la aritmética de media palabra que podrían consumir significativamente los ahorros de gasolina?

Escribiría suficientes pruebas unitarias :)
Sí, pruebas unitarias para matemáticas enteras. La cobertura es difícil de acertar y, a la velocidad de cálculo, probablemente imposible.

Respuestas (2)

En mi opinión, sí uint128es seguro rastrear los valores de wei y puede ahorrar la mitad de los costos de almacenamiento uint(cuando Solidity puede optimizar). Internamente, probablemente se esté enmascarando para acceder a los 128 bits superior e inferior de la palabra de 256 bits, pero no creo que vaya a consumir mucho gas: por lo que el ahorro de gas de almacenamiento será mayor.

dado que el gas es actualmente 50Gwei, casi tiene sentido ni siquiera molestarse en rastrear a Wei, sino a Gwei. un entero de 63 bits puede rastrear 9.2e18 Gwei o 9.2e18 ether. Si logra obtener un contrato para mantener 9 mil millones de éter, tuvo un gran éxito. Quizás la unidad correcta para el seguimiento debería ser el szabo (1e12 wei) porque, si bien hay un pequeño error de redondeo, está en el mismo nivel de ruido de magnitud de orden que el costo del gas de una llamada de solidez típica.
Buen punto a considerar
Cuando termine mi sprint interminable actual, escribiré un código de prueba para mostrar diferentes costos de gasolina y consideraciones de redondeo para las diversas alternativas.
ja, la ironía es que acabo de descubrir un caso de uso para multiplicar dos valores de wei ... sin embargo, podría usar memoria en lugar de almacenamiento para eso. Hace que el código sea más complicado. Comenzar a sentirse como una biblioteca de plantillas de "matemáticas comprimidas" debe escribirse una vez que las plantillas estén disponibles en solidez. Esto me recuerda a los cachés de la CPU: actualmente es más rápido comprimir y descomprimir los datos que van a/desde la DRAM, ya que el costo de la CPU para hacerlo ahorra una tonelada de costos de pérdida de caché. El mismo principio podría aplicarse aquí. Utilice el almacenamiento más pequeño que sea práctico, amplíe a la memoria, comprima de nuevo al almacenamiento

Sí.

Actualmente existen 77 millones de ether, y cada año se crean alrededor de 18 millones. En 20 años tendremos en total alrededor de (77m + 18*20m) * 10^18 wei.

Esto encaja en 89 bits. Para estar seguro, supongamos que su aplicación necesita realizar la multiplicación de cantidades de wei tan grandes, entonces, en teoría, podría necesitar 90 bits. Redondeando hacia arriba el tamaño entero de solidez más cercano da uint96. Si es necesario almacenar muchos valores, esto ahorraría algo de tamaño sobre uint128.

Multiplica por el doble el número de bits, no aumenta luego por uno. (la suma iaumenta los bits en uno). Como mencioné a continuación, probablemente aún ahorraría gasolina para almacenar como 64 bits, pero haría cálculos con copias en la memoria de 256 bits. Pero tendré que hacer una prueba para estar seguro.
¡Voy a abusar de mi error evm para acuñar cuatrillones de éter para poder desbordar la verificación de saldo en su aplicación!
¿Es seguro y efectivo usar números enteros de 128 bits para rastrear wei en un contrato para ahorrar gasolina?
RespuestasAquíPolítica de privacidad1y, 0v