Timeline for Rationale Behind Ethereum's Data Storage Scheme
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 26, 2018 at 5:00 | comment | added | ivicaa | 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(?) | |
| Feb 25, 2018 at 20:43 | comment | added | Vega4 | 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. | |
| Feb 25, 2018 at 8:44 | comment | added | ivicaa | 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. | |
| Feb 25, 2018 at 8:07 | comment | added | Vega4 | anyone could comment little broader on the "unlimited values are too hard to make a secure gas model around" point of view? | |
| Feb 24, 2018 at 21:57 | history | edited | ivicaa | CC BY-SA 3.0 |
added 146 characters in body
|
| Feb 24, 2018 at 20:46 | history | edited | ivicaa | CC BY-SA 3.0 |
added 2 characters in body
|
| Feb 24, 2018 at 20:36 | history | answered | ivicaa | CC BY-SA 3.0 |