consider using the etherrouter pattern instead of paratiiregistry to handle upgrades
Opened this issue · 2 comments
I looked over this code and investigated the assembly code. It's a cool idea aside from the ominous warning about using the code as it stands in a production environment. Note, however, that it actually only registers and tracks contract methods. The result is that all the methods of all the contracts look kind of like they belong to one big contract. This seems to me like it might be a bit limiting as an architecture.
There's a nice discussion on StackOverflow on different approaches to upgradable smart contracts.
Based on the responses, it seems this approach has had a lot of eyes on it and seems to implement the most agreed upon approach amongst the answers.
The idea is to inherit an Upgradable base contract that acts as a mirror to the real contract code. I think it's a bit more streamlined than the ether-router approach.
Not sure i understand the "limiting" part. There could be an ether-router instance for each of our contract classes - so it won't look like "one big contract"
What may be a problem in our solution as it stands (i.e. have a contract registry) is the "updating of storage" . The way we do things now, if we were to update, say, the userregistry contract, we'd need to either migrate all data (i.e. copy them, verrrry expensive) or continue to read the data from the old contract while using the logic of the new one (which is messy).
The dispatcher pattern you linked to sort of solves that, by keeping data and logic separate (Sort of - it will not help you if you want to change the data model and, say, at a field "surname" to the user registry)