Allow specifying storage locations

[pipermerriam]

Inline assembly has now made fully up upgradable contracts possible. One of the main hangups with this is that the storage locations have to stay the same across upgrades. Would it be possible to introduce support for specifying the storage locations for storage variables?

[VoR0220]

not so!

[VoR0220]

See Nick Johnson's Library on upgradeability :)

https://gist.github.com/Arachnid/4ca9da48d51e23e5cfe0f0e14dd6318f#file-upgradeable-sol

[chriseth]

Especially with contract upgrades in mind, wouldn't it be better to copy the storage layout and "disable" unused state variables by e.g. prefixing them? Otherwise I don't see how you would practically verify that the storage layout is consistent between upgrades.

[pipermerriam]

Is there documentation on how storage layout is determined?

On Wed, May 25, 2016, 1:54 AM chriseth notifications@github.com wrote:

Especially with contract upgrades in mind, wouldn't it be better to copy
the storage layout and "disable" unused state variables by e.g. prefixing
them? Otherwise I don't see how you would practically verify that the
storage layout is consistent between upgrades.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#597 (comment)

[chriseth]

http://solidity.readthedocs.io/en/latest/miscellaneous.html#layout-of-state-variables-in-storage

[pipermerriam]

Ok, so after reading up on storage layouts...

contract MyContractV1 {
    uint a;
    bytse32 b;
}

In this example, a should be stored in slot 0 and b in slot 1.

Now, consider I upgrade it to the following.

contract MyContractV2 {
    int c;
    uint a;
    bytes32 b;
}

This would end up with c stored in slot 0, a in 1, and b in 2 which would break things.

So, instead, I propose being able to do the following.

contract MyContractV2 {
    int c;
    uint a @ 0x0;
    bytes32 b @ 0x1;
}

The solidity compiler would see that a and b are designated for storage slots 0 and 1 respectively, and would then place c at the next available location, slot 2.

Does that make sense? Is this possible?

[axic]

I was looking for a complementary/similar feature: the ability to disable packing. (i.e. currently if two storage parameters are each < 256 bits and together they fit into one slot, they are packed together.)

Ultimately the compiler could optimise the packing based on the frequency of changes to one ore more variables within.

With your suggestion this is a given, each marked variable gets its own slot. I would use a different markup though:

storage(0) int a;
storage(1) bytes32 b;

[pipermerriam]

I would use a different markup though

the @ was just the first thing that came to mind. I like storage(...) better.

[chriseth]

I think the tradeoff between introducing errors and decreasing readability is much better when just adding int c at the end. If you want, you can also use inheritance (let the upgraded contract inherit from the old contract).

[VoR0220]

^ 👍 for the inheritance structure...it overall is cheaper and more cost effective to do it that way. I envision a lot of modularity around dapps in the future in regards to storage to better handle updates and save gas.

[axic]

This came up again as a discussion with @federicobond and I think a good middle ground could be to have an annotation (as proposed in #597 (comment)), but instead of marking a storage slot, it would rather have a string literal as a key, which is hashed to produce a 256-bit key for storage.

This would be more expensive (due to the fact of using 32-byte long constants and one couldn't combine multiple variables into a single slot), but might be justified for some.

When this annotation is missing, it would default to the current behaviour.

For syntax I propose:

int256 a storage_key("this_is_my_variable");
bytes32 b storage_key("and_this_too");

[pipermerriam]

@axic

1. I like the hashed key approach
2. reasoning for not allowing specific slot to be specified? foot gun?