4

1) Why does Ethereum store data in 32byte chunks? I don't suppose this to be some backward-compatibility left-over; is it? We could store data in variable length fields as well.

2)I don't think optimization is the case as we are already wasting over 32bytes (32bytes for the hash which constitutes the path + Merkle Trie node's-metadata) as an access key to each such field (the path from Data Trie root to each variable).

3) any notes on how the compiler computes the access key for each variable?

4) I'm quite new to Ethereum, is there any economic incentive to remove the previously occupied data?

Improve this question

1 Answer 1

Reset to default
5

About 1/2: from https://github.com/ethereum/wiki/wiki/Design-Rationale

32 byte word size - the alternative is 4 or 8 byte words, as in most other architectures, or unlimited, as in Bitcoin. 4 or 8 byte words are too restrictive to store addresses and big values for crypto computations, and unlimited values are too hard to make a secure gas model around. 32 bytes is ideal because it is just large enough to store 32 byte values common in many crypto implementations, as well as addresses (and provides the ability to pack address and value into a single storage index as an optimization), but not so large as to be extremely inefficient.

(has been already asked and answered. See Rationale behind 256-bit words in EVM)

About 3: there is a difference between a simple field variable, arrays and mappings. Simple fields are packed to storage starting at index 0. Mappings consist of paths which are hashed. See How do I get the storage indices/keys?

About 4: You will get gas refunded for deleting from storage or deleting (suicide) a contract. See What are the limits to gas refunds?

Improve this answer
4
  • anyone could comment little broader on the "unlimited values are too hard to make a secure gas model around" point of view?
    – Vega4
    Commented Feb 25, 2018 at 8:07
  • My interpretation is: if you keep something simple, it's easier to secure it. Hence, all reads/writes are always on 32byte words and you need to specify only two simple instructions and their corresponding gas prices. Less "if-then-elseif" -> better security/stability.
    – ivicaa
    Commented Feb 25, 2018 at 8:44
  • it could be easily implemented to keep one function for reading/writing data and specify price per each byte. Which would be perfectly simple as well, it just wouldn't be Ethereum:) Personally, I'm much toward simplicity.outputs of hash functions are the only reason I can see to keep the word size at 256bits. once the user runs out of gas throw exception and bye bye. Implementing optimization rationale too keep data aligned in 256 bit boundaries seems more bug-friendly than taking care of unlimited data-bundles at least to me. Ivicaa? thanks.
    – Vega4
    Commented Feb 25, 2018 at 20:43
  • Your argumentation sounds valid in this aspect. I guess one more aspect which has to be taken into consideration is the storage trie. I don't know all the details about it, but a wild guess would be that 256bit load/store help in reducing the update frequency on it and in keeping its size small(?)
    – ivicaa
    Commented Feb 26, 2018 at 5:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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