Enable cost differences between SSTORE8-248

[VoR0220]

Currently in solidity, there is this very unintuitive way of declaring variables. You would think that taking up less storage with a uint8 would end up costing less in gas than a uint256, but in actuality you end up being charged more in gas for a uint8 than a uint256. This proposal is for a set of EVM opcodes to mimic SSTORE but with specific sizes and ascending gas costs from 8-248. I will add to this more, but this is an initial posting to get this out there. Let me know your initial thoughts and concerns.

[janx]

I think the cause is in solidity instead of EVM, as SSTORE gas cost is not related to value size.

Ref:

• https://github.com/ethereum/pyethereum/blob/develop/ethereum/vm.py#L422
• http://solidity.readthedocs.org/en/latest/miscellaneous.html#layout-of-state-variables-in-storage

[VoR0220]

@janx shouldn't it be though? You're storing a value, should it not be cheaper if the size capability of the value is smaller?

[chriseth]

The main cost for sstore is not created from the size of the stored value (at least not for sizes up to 32 bytes), but from the actual insertion, so I don't think it is reasonable to reduce the costs for smaller values.

The gas savings for smaller values in solidity does not arise from taking up less space but from being able to combine multiple variable assignments into a single sstore.

[janx]

@VoR0220 it would be cool. My point is adding SSTORE8-248 alone may not work, since variable assignment in solidity will be compiled to opcodes more than SSTORE.

And as @chriseth pointed out, right now the main cost is from actual insertion, that should be taken into consideration too.

Also related:

• EIP 104 (Serenity): Unlimited storage key or value size #36
• Proposed initial abstraction changes for Metropolis #86 (6. SSTOREBYTES)

[VoR0220]

@janx @chriseth thanks for the input. Let me stew on this for a bit.

[vbuterin]

The bulk of the actual underlying computational effort is in updating the merkle branch, which doesn't depend too much on the size of storage especially for values under 32 bytes; hence, Chris is entirely correct in that the larger gains come in batching multiple storage update operations (something that SSTOREBYTES in #86 is intended to make much more widely applicable as an optimization strategy).

[VoR0220]

closing