Contract storage granularity

mquandalle

Hi,

As of POC5 the key/value store associated to a given contract impose a 32 bytes value. Of course some values doesn't require these 32 bytes, for instance in the Chronos contract [0] the storage is used to keep 4 bytes timestamp. Because the blockchain space is expensive (for good reasons) I might want to merge up to 32/4=8 different timestamp values in a single storage entry to reduce the gas fee, and then play with bit operators to read or write the one I want. That's really hacky.

A pricing model in which I can (optionally?) specify how much space I want to use (in this case 4 bytes) and then pay the fee accordingly would make a lot of sense.

This more granular model would also simply the storage of "large" values (32b+). Currently we have to split a large value in chunk of 32 bytes and put these chunks in different storage locations, and then recompose the different parts to read the original value. Once again this is very hacky it would be easier to register a 64 or 128 bytes value by just specify it and without splitting it. That would also considerably simplify the compilation process of high level languages such as Serpent or Mutant which allow structures like arrays.

Thoughts?

[0]: https://github.com/mquandalle/chronos/blob/master/contract.lisp

Jasper

I think the cost should essentially represent the actual storage cost. I dont know if that means that pricing should be per-32-byte slots.

However the languages to write contracts with could probably make it easier to take apart a slot into multiple values. That may include handling strings longer than 32 bytes compile-time, i suppose. Kindah easier said than done, maybe a bit of a cop-out. Seems like it is decided that the protocol is going for bounded integers, i think that might imply not to change the block size for strings either.

If you use it as a key-value store, If you only have one value to pick from each value, afaik you may be stuck with using the entire slot for it. I suppose you could use the first 4(or 8?) bytes to store the stamp, and try to figure out a use for the rest.. At the cost of complicating the principle.(the core function of a contract is important..) For instance timestamps could have 28(24)-byte names.. Could fumble a title in there.

Another approach is to go for a completely different data structure, like a trie or a list, where things form a chunk of storage. It probably has a larger calling fee, though it does save on storage.

Note that in a sense storage isnt a key-value store, but is more seen as a sort of 'infinite storage space' that happens to be usable as such. There probably isnt going to be a way to iterate it. To be honest, not yet 100% as to why.

Wonder if memory storage is actually similar to contract storage? i.e. the memory could in principle be used as key-value aswel. Expect so.