I am attempting to create a permission system that will be used to give access to user resources off-chain where permissions cannot be manipulated by the deployer (me) where the user is the owner of the proxy contract but the logical contract can only be updated by the developer.
The reason being, if a proxy contract owner can update their implementation this will undermine the integrity of the app
These contracts will be deployed on a private gas free network so cost is not an issue
New user "proxy contracts" will be create pragmatically with JS
I would like to deploy a new proxy contract for each new user (and if possible have 1 logical contract they all delegate calls to although this is not essential is i'm using gas free network this)
Over the past few days i have read a mountain of resources (thanks for the hard work OpenZeppelin team) and although they have been helpful, ingesting so much information has left me a little confused.
From what i have read it seems to me OpenZeppelins approach is as follows (please correct me if i'm wrong)
Does this mean by default that only I (the developer/admin) can upgrade contracts (ie set the implementation address on the proxy contract) or is the proxy contract owner also able to also?
is there a scalability issue with my approach. say i had 1000 users (proxy contracts / logical contracts) how would one go about upgrading them all
Is there a possibility of some sort of minimal & upgradeable proxy pattern? like so (again not a big issue as network is gas free, so if the answer is to long feel free to skip)
i cam across an article about contract factories is this implementation my silver bullet? (taking into consideration my questions above) Contract factories
Thanks so much for your time any sort of help would be appricated
Each user has a contract that only they can modify state via access control.
You (as the developer) want to be able to upgrade the logic in these contracts without requiring permission from the user.
Inheriting from ProxyFactory could potentially meet your needs to deploy proxies pointing to a single logic contract. Though there a couple of caveats using Transparent proxy pattern upgrades in your specific solution:
An upgrade can be used to change state, so users would need to trust that the upgrade process didn’t change the state of their contract. Transparency and governance around how and when upgrades could occur would be very important.
For upgrades, each users proxy would need to be called to point to a new logic contract. For a large amount of contracts this could take time and involve a large amount of transactions, depending on the scalability of the chain that you are using.
Please ask all the questions that you need.
It would be great to learn a bit more about you and what you are building. If you have a chance it would be great if you could introduce yourself.
you are correct the idea is “Each user has a contract that only they can modify state via access control”
yes that is correct i am working under the assumption that 99% of my user base haven’t even heard of blockchain technology, have no knowlage of blockchains and do not care a blockchain is being used. so asking for permission to do application logic upgrades may be confusing to the end user (although it would be good for organisations to have to agree on logical contract updates)
damn i didn’t think about the fact the upgrade could change proxy state. this kind of defeats the purpose of what i’m proposing. thanks for the input, i’ll go away and think about my solution a bit more, based on your advice.
I assume that coming away from the CLI and using “upgrades” package to achieve what i want will mean there are some caveats that are handeld by the CLI that will no longer be handled for me. i will re-read resources and make sure i’m aware of what i now need to handle, but i was wondering if you know off the top of your head or have a list, could you let me know.
At some point today i will glady introduce myself and explain what i am build. when i have done so maybe ill leave a link here to give some more context to my question?
Also once i have completed my project i will post showing my solution / processes / findings etc to show the community what i have achieved and hopefully even help someone else
The governance on how and when upgrades can be performed will be important here.
There may also be other ways to structure your solution including other upgrade mechanisms to solve this. (None that come to mind unfortunately). To separate the permissions from the users contract (perhaps having permissions as tokens)
When upgrading you cannot change the order in which the contract state variables are declared, nor their type, this includes state variables in inherited contracts.
(See: Modifying Your Contracts)
You can test your upgrade of contracts locally (without using your factory) using the CLI so that you can leverage CLI checks.
You should also create tests to test the upgrade process.
