How to handle maintaining state when upgrading adapters?

[jtrein]

This issue's purpose is to begin a discussion about the exploration making adapter upgrades more robust by maintaining state between upgrades. The secondary purpose is to see what we can create, even if it doesn't work - at least we could attempt it. 😎

Getting historical data for adapters should be handled at the contract level, and avoid pushing the task to dapps, if possible.

Description

Tribute can currently can swap out an adapter in the DaoRegistry. One reason for changing an adapter is for contract version upgrades (e.g. security fixes, added feature). Once an adapter is changed, the state within the adapter(s) which has been replaced (possibly multiple times v1->v2->v3) must be manually fetched (i.e. using the correct ABI version and contract address). There are ways to maintain adapter state between contract upgrades using upgrade patterns in Solidity, but @fforbeck and @adridadou have mentioned this will not be especially simple to do.

A note on upgradeability patterns from @fforbeck:

yeah, that would be the idea, we would need to change the adapters to support the proxy pattern, and then the storage would be maintained always in the 1st deployed contract. The issue with that is that every new adapter that will "replace" the old adapter needs to contain the exact same storage variables - even the order of the variables, if we change that, it will break the state and lead to serious issues (we wont be able to restore the previous state because the storage is overwritten). I saw there are some strategies to handle that, but the level of complexity added to the smart contract gets overwhelming. I agree that we should explore that, just not sure if the proxy pattern will be the best solution for us.

Thoughts to consider, if we decide to explore solutions:

• Overall, is this a win for Tribute users & developers (i.e. is it a needed feature, and would it help make Tribute more awesome)?
• If not the proxy pattern, which pattern(s) could work?
• Should we bounty this?
• Can we get the community to begin helping on this?

[fforbeck]

More details on the storage layout limitations of an upgradable contract:

Due to technical limitations, when you upgrade a contract to a new version you cannot change the storage layout of that contract.

This means that, if you have already declared a state variable in your contract, you cannot remove it, change its type, or declare another variable before it. In our Box example, it means that we can only add new state variables after value.

Fortunately, this limitation only affects state variables. You can change the contract’s functions and events as you wish.
If you accidentally mess up with your contract’s storage layout, the Upgrades Plugins will warn you when you try to upgrade.

https://docs.openzeppelin.com/learn/upgrading-smart-contracts#upgrading

https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies#storage-collisions-between-implementation-versions

https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies#the-constructor-caveat

https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable#modifying-your-contracts