Should we use uint64 for storing block.timestamp(instead of uint256)?

Question

Apparently using uint256 costs less gas on average(if i am not mistaken), but when it comes to storage, using smaller datasize can apparently be cheaper (or so i've heard. is this correct?).

So my question is. Should the timestamp be uint256 or uint64 or even uint40. Does it optimize for gas and make it cheaper?

struct Something {
 .....
 uintX timestamp;
}

Answer 1

I do not think either of abhinavmir examples cost more or less. I think they both cost the same.

Variable packing is when you pack several variables that can be added to use 1 memory slot. A memory slot is a word of 32 bytes. A string variable will take at least 32 bytes, (+32 bytes again if you go over one 32 bytes limit).

uint8
uint8
uint16
uint32
uint64
uint128

Would work and take only one memory slot.

However a memory slot will always be filled. So if you use a full memory slot for a uint8, the EVM will automatically fill it with empty bytes to fill up the slot. In this case using a uint256 is cheaper than using a uint8.

uint8
uint256
uint8
uint256

is more expensive than 4 uint256.

Using different ints or uints can mainly be for variable packing or limiting the numbers. (Overflow/underflow check...)

Answer 2

The EVM still has to access the slot and read the data contained within it per value being read.

As such, whilst 'tightly packed' structs can occupy less gas during deployment, when it comes to interacting with the contract, it turns out that actually more gas may be spent whilst trying to read/write/unpack that data content in the slot.

Be careful when optimising in this way, too!

Answer 3

Storage in a solidity pack 32bytes to 1 slot that 32*8=256 bit, so uint8, uint16,... uint256 is the same to use 1 slot in solidity, but when you using uint8 EVM need to downscale from 256bit -> 8bit. So uint8 take more cost than uint256

Answer 4

What you're referring to is tight variable packing.

uint256 var1;
uint256 var2;
string abc;

Is cheaper than, say -

uint256 var1;
string abc;
uint256 var2;

This is by design of EVM. uint256 does not cost "less gas on average". I'd suggest using uint256 for future proofing. Currently the Unix time stamp is around ~1649302387 - for which uint32 should suffice, but it will cause overflow in the future. Something to the effect of false Transaction mined but execution failed - thus unless important, use uint256 for block.timestamp.