Instadapp/infinite-proxy
1
0
Fork 0
mirror of https://github.com/Instadapp/infinite-proxy.git synced 2024-07-29 21:47:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Samyak Jain 2022-04-15 20:08:02 +05:30 committed by GitHub
parent 546c6b3b2a
commit 91327d8ef1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -15,10 +15,10 @@ So whats the solution? Normal proxies have the implementation address stored (in
- In fallback it fetches the msg.sig, fetches the implementation from it and runs the code logic on that.
## How to use it?
- Proxies and implementations are deployed separately, then multiple(infinite) implementations can be added to the proxy. One thing to make sure is the storage variables of all implementations should be at the same storage slot so things don't get messed up.
- Proxies and implementations are deployed separately, then multiple(infinite) implementations can be added to the proxy. One thing to make sure is the storage variables of all implementations should be at the same storage slot so storage don't get messed up (similar to what we do in upgradable proxy).
- This repo contains an example of using infinite proxies. Checkout the example contracts. Different implementations have been separated out into different modules, but they use the same variables contract.
- Deployment of infinite-proxies is also a little different from normal proxies, the repo also contains an example deployment script.
## Dummy Implementation
One issue with infinite proxies is that etherscan isn't able to detect that the contract is a proxy and hence isn't able to link it to the implementations. This makes it non-directly usable via etherscan, also users can't see the list of all the read/write functions they can call.
An innovative solution for the problem is using a dummy implemenatation. A dummy implementation is nothing but a contract containing all external functions which are callable by the users. The dummy implementation doesn't contain any logics of the functions (analogous to contract interfaces). The dummy implementation's address is stored at the implementation slot which etherscan detects in order to link proxies to their implementations, hence all the external functions can then be seen/called directly via etherscan. Through dummy impelementations, etherscan gets the functions sigs, generates the calldata, but the actual call is delegated to the respective implementation.
One issue with infinite proxies is that etherscan isn't able to detect that the contract is a proxy and hence isn't able to link it to the implementations. This makes it not usable via etherscan, also users can't see the list of all the read/write functions they can call.
An innovative solution for the problem is using a dummy implemenatation. A dummy implementation is nothing but a contract containing all external functions which are callable by the users. The dummy implementation doesn't contain any logics of the functions (analogous to contract interfaces). The dummy implementation's address is stored at the implementation slot which etherscan detects in order to link proxies to their implementations, hence all the external functions can then be seen/called directly via etherscan. Through dummy impelementations, etherscan gets the functions sigs, generates the calldata, but the actual call is delegated to the respective implementation.