4

The default type for Wei in Solidity is the 256 bit unsigned integer. (e.g. msg.value)

However, to track 1.7e38 wei (1.7e20 ether) you only need a 127 bit integer. That's a gigantic number not likely to be exceeded in any real world application.

As long as you are not multiplying two Wei values together, is it considered reasonably safe to track Wei in signed 128 bit integers so that two values can be packed into one 256 bit word in order save storage costs on gas?

Are there additional computational costs on half word arithmetic that might significantly eat up the gas savings?

|improve this question
  • Would write sufficient unit tests :) – nessence Feb 12 '16 at 4:46
  • Yeah, unit tests for integer math. Coverage is hard to get right, and at the speed of calculation, probably impossible. – Paul S Feb 12 '16 at 19:54
3

In my opinion, yes uint128 is safe to track wei values, and can save half of the storage costs of uint (when Solidity is able to optimize). Internally, there is probably masking being done to access the upper and lower 128bits from the 256bit word, but I don't think it's going to consume much gas: so the storage gas savings will be more.

|improve this answer
  • 2
    given that gas is currently 50Gwei, it almost makes sense to not even bother tracking Wei, but Gwei. a 63 bit integer can track 9.2e18 Gwei or 9.2e18 ether. If you can manage to get a contract to hold 9 billion ether you were wildly successfull. Perhaps the correct unit for tracking should be the szabo (1e12 wei) because while there's some small rounding error it's in the same order magnitude noise floor as the gas cost of a typical solidity call – Paul S Feb 11 '16 at 20:20
  • Good point to consider – eth♦ Feb 11 '16 at 20:23
  • When my current endless sprint is over I'm going to write some test code to show different gas costs and rounding considerations for the various alternatives – Paul S Feb 11 '16 at 21:09
  • ha the irony is I just discovered a use case for multiplying two wei values together... however could use memory instead of storage for that. Makes the code more complicated. Starting to feel like a "compressed math" template library should be written once templates are available in solidity. This reminds me of CPU caches - it's currently faster to compress and decompress data going to/from DRAM, as the CPU cost to do so saves a ton of cache miss costs. Same principle could apply here. Use as small storage as practical, expand to memory, compress back to storage – Paul S Feb 11 '16 at 22:32
1

Yes.

There is currently 77 million ether in existence, and around 18m is created every year. In 20 years we'll have in total around (77m + 18*20m) * 10^18 wei.

This fits into 89 bits. To be on the safe side, let's assume your app needs to perform multiplication of such large wei amounts, then you could in theory need 90 bits. Rounding up the nearest solidity integer size gives uint96. If many values need to be stored this would save some size over uint128.

|improve this answer
  • Multiplies double the number of bits, not increase then by one. (addition iincreases the bits by one). As I mentioned below it would probably still save gas to store as 64 bits but do math with copies in memory of 256 bits. But I'll have to run a test to be sure. – Paul S Feb 12 '16 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.