My pleasure mate, glad it’s helping you out. The good thing about this technique, is that it can be used on almost data structure by breaking them down into their simple data types (int, string etc). An example of how we’ve used this to store a struct, is here…
Hey Frodo! Excellent points mate, let me see if I can address them from our perspective. One key point between allowing an owner direct access to storage and allowing an owner to upgrade a contract is having an auditable trail and verifiable contract code.
Hey Fro Do! We currently use a contract called Rocket Upgrade that does exactly this. It will upgrade a contracts address in storage and also does a few checks on the contract being upgraded (does it have tokens? does it have ether?). You can see that here https://github.com/rocket-pool/rocketpool/blob/master/contracts/RocketUpgrade.sol
Hey Jim! Thanks for the comments and feedback mate. The main goal of the UI at the moment it to be big, simple and as easy to use as possible. It’s the first iteration of the UI and will be built for the beta version, so I definitely expect it to evolve as we do and also as we receive feedback over time.
Hey Héctor! It is totally possible to use the public ENS resolver for changing the contract addresses used in your dapp. You would then be relying on a 3rd party service though which is something I generally try to avoid and it also wouldn’t solve your storage issue when changing the address on a bugged contract.
Hey Jørgen, appreciate the comments mate. It would be possible to do what you’re saying, but it really depends on how your app is structured. In that simple scenario, it would be possible, but if you had 1000’s of users, it wouldn’t be practical and would cost your some $ making all those transactions to port the users across to the new contract.
The best aspect about the key/value pair storage in a contract is that new state variables can be stored in the contract without needing to modify the contract at all. This contract also acts as a hub for other contract -> contract communication, so if it’s upgraded and the address of the contract is changed…
Hey Carter! Yes you can disable owners access to storage that way in a contract. We currently do it upon deployment using truffles migrations and web3js. You can see right here — https://github.com/darcius/rocketpool/blob/ee7b7da68dc5fee8e6bad6f19290da1d185c289c/migrations/2_deploy_contracts.js#L182
Hey Rahul! Your right that you won’t be able to access the data on the previous contract, which is why you should store any data that you want kept across any contract upgrades in the main Storage contract that I’ve shown above. This contract is kept simple, so it should never need upgrading and as such, any data stored on it will always be available to any contracts in your Dapp that need to read from it.
Great questions mate. RPL is the main protocol token of the Rocket Pool network and serves several purposes that are outlined in the white paper. In the future after Rocket Pool has been running successfully for a while, we’d like to give users and businesses the opportunity to supply their own nodes to operate as…