Our Approach

While designing and building Rocket Pool a complex multi-contract Dapp, there were two main design choices that were made early on.

All main contracts must be upgradable.

Have a flexible, yet simple way to store data permanently.

The first one is fairly self-explanatory, all contracts must be upgradable within the network. If we have an issue with one contract, its address needs to be editable so that we can replace the bugged contract with a new copy of it sans bugs and all other contracts in the Dapp must now communicate with the new version. Ok that sounds great! But what a lot of new developers don’t realise is that any data that bugged contract was storing on itself is now gone…

Imagine if you had a contract called Users.sol that maintains a list of all the users that sign up to your Dapp, but it turns out Users.sol has a major bug, your developer Harry rushes to replace that bugged contract with a new one and in doing so, he deploys a new fixed Users.sol and updates the address of it so that all contracts in your Dapp now talk to the fixed contract. Harry is super happy, proud he fixed it so quick and soon to be wishing he also bought a 5 pack of brown underpants.

As what Harry is soon to realise is that contract storage cannot be so easily replaced, he’s just fixed the bug in Users.sol code and all contracts in your Dapp now talk to the new fixed contract, but all records of their users in the Dapp are gone, instead stuck in the old contracts storage… oops.

The second goal is then to create a way to isolate your datastore from your contracts and make it as flexible as possible so that it is unlikely to ever warrant upgrading.