What is the best way to store data/information while writing smartcontract?

Question

Smart contracts are immutable. Unless we're 100% sure that our smart-contract is fully functional without any exception we never want to push that in the main net. That's why we have public test net.

I am writing a smart-contract that stores information in an array. I am worried about something after I deploy my contract in the main net and start using and saving information in the blockchain. Over time my requirement might change(which is hypothetical) and I had to update my contract and then re-deploy in main-net. Now how can I retrieve the information that was saved in the old contract address in the main net because now that I start using the newly deployed address?

Is there any way to link that saved information from the old contract address to the new one?

What is the best way to overcome this scenario?

Answer 1

You have at least a few alternatives.

Upgradeable contracts and proxy patterns

Yes, contracts are immutable but contracts can reference other contracts in various ways. So what you can do is use a pattern called upgradeable contracts. Typically this means you have one contract which stores the state (the actual data) and which doesn't change and can't be upgraded. But you also have another contract which implements the actual logic. the storage contract simply points to the logic contract and the pointer can be changed.

Here's some more info: https://medium.com/cardstack/upgradable-contracts-in-solidity-d5af87f0f913 and actual implementation: https://docs.openzeppelin.com/upgrades/2.6/

There are also variations to this scheme, various proxy patterns and so on.

Copy contract data manually

If there is a problem in your original contract you can simply change it and copy data to the new contract. The most straightforward approach is to add this kind of support to the new contract and simply read data from the old contract and insert into new contract upon deployment with a custom script. This may not be a feasible solution if there's lots of data (due to gas costs) or if the stored data is complicated.

New contract reads data from old contract

Another option is that the new contract utilizes the old contract's data directly. So whenever someone requests for data from the new contract the new contract retrieves it from the old contract, and similarly for storing data.

This is not a very good approach as it makes the logic complex and error-prone.