Today I talked with Christian Reitwießner, the creator of solidity, about the possibility of future versions of the solidity compiler changing how variables are laid out in Ethereum contract storage.

A full description of how variables are laid out can be found here: Layout of State Variables in Storage

This is an important subject because contracts that use delegatecall, such as upgradeable contracts, rely on the current storage layout of solidity. If this changed in a non-backward compatible way then future versions of the solidity compiler could not be used with existing deployed upgradeable contracts.

I asked Christian about it because I recently released a proposed standard for upgradeable, transparent contracts that relies on delegatecall and so therefore relies on solidity’s storage layout.

Here’s what Christian said:

Hi Nick! I thought it to be self-evident that changing the storage layout is a very hard breaking change due to the fact that libraries rely on it. If we ever do this, we will announce it very much in advance and might even provide a switch to retain the old behavior. Added a note to the documentation. I cannot promise that it will never change in the future, since there were even EIPs that proposed to change the nature of storage from a 32->32 byte mapping to a 32 -> arbitrary byte mapping.

Here is the note that Christian added to the solidity documentation today. This is for the section Layout of State Variables in Storage:

The layout of state variables in storage is considered to be part of the binary API due to the fact that storage pointers can be passed to libraries. This means that any change to the rules outlined in this section is considered a breaking change of the language and due to its critical nature should be considered very carefully before being executed.