is there any limitations to the proxy?? #2190
-
is there any limitations to the proxy for using it to change the implementation contract?? or we can change the whole implementation smart contract if we want through proxy other than appending the storage variables? because if we proxy the whole smart contract then its core features of not getting tampered will make no sense right? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 10 replies
-
Unnecessary complexity and the extent of decentralization it provides. |
Beta Was this translation helpful? Give feedback.
-
Ya lesson 16 made me question that is it any more "Decentralized" as with upgradable smart contract control remains In the hands of the admin or the owner of the smart contract as he can change the Implementation contract without the permission of the people using it. |
Beta Was this translation helpful? Give feedback.
-
There are some Glitches in this approach, but these will be only if our admin is not a governance smart contract but instead some group or single owner. The two main issues are: Storage Clashes: Function Selector Clashes: If we have the same function in both the Proxy contract and implementation contract, so when the user calls the implementation contract’s function through the proxy contract, it always calls the function of the proxy contract, not the implementation contract, and implementation contract’s function gets never called. This is called Function Selector Clashes. Three implementations of Proxy Contracts that save from the above Clashes: Transparent Proxy Pattern: In this pattern, the admin is allowed to call proxy contract functions and users are allowed to call only implementation contract functions. With this pattern, we will be saved from Function Selector Clashes. Universal Upgradable Proxies: In this pattern, the admin put all of the upgradable logic inside the implementation contract which also saves some gas because in the proxy contract we do not need to check whether someone is admin or not. And also the proxy will be smaller itself. The issue is that if we deployed the implementation contract without any upgradable functionality, we will be stuck and the solution will be again the YEET method. Diamond Pattern: This allows multiple advantages, one of the advantages is, that it allows us to implement multiple implementations of smart contracts that also save us from smart contract file size issues. We can separate the code into multiple smart contracts. It also helps us to just upgrade that small part of the separate implementation contract instead of upgrading the complete one. |
Beta Was this translation helpful? Give feedback.
@sadath-12
There are some Glitches in this approach, but these will be only if our admin is not a governance smart contract but instead some group or single owner. The two main issues are:
Storage Clashes:
Function Selector Clashes: If we have the same function in both the Proxy contract and implementation contract, so when the user calls the implementation contract’s function through the proxy contract, it always calls the function of the proxy contract, not the implementation contract, and implementation contract’s function gets never called. This is called Function Selector Clashes.
Three implementations of Proxy Contracts that save from the above Clashes:
Transparent Proxy Pattern: In…