aragon
Analyse contract storage layout
Because of the way upgradeability works, changing the storage layout would break apps.
It is possible to analyse what the contract storage would look like for a contract, and perhaps make a diff between two versions of the same app - e.g. the storage layout for v1.0.0 of the contract and v2.0.0.
If they differ in a breaking way (i.e. a type is changed in a specific storage slot), then we should emit an error in the CLI. This error should be skippable by explicitly adding a flag to the publish command.
We could extract this to a separate module and make it mandatory to publish your contract source for source code verification. This would also allow us to display errors to the user in case the storage layout would change between versions.
Relevant link on the storage layout of Solidity contracts: https://solidity.readthedocs.io/en/v0.4.21/miscellaneous.html#layout-of-state-variables-in-storage
Sort of related to #26 as they both do contract analysis
Interesting issue to follow for this https://github.com/ethereum/solidity/pull/4017. The zeppelin team did a PR to make the compiler output information about the storage slots of a contract
Fairly sure this is no longer relevant as storage approach has changed. Moving to close unless I hear on this issue in the next week.
@Quazia This is still relevant, in case apps change their storage layout between updates. The proxying storage has changed, but it's still possible for someone to completely mess up an app's internal state after upgrading.
We would likely need to encode some metadata about the storage layout as part of each package's metadata (similar to how we storage the flattened code and compiler options) on publish.
