Researching code patterns for upgradable smart contracts

Support Upgrades
1

I am doing research into smart contracts maintenance. My first goal is to have some stats regarding how many of the deployed smart contracts are upgradable. So, i am searching for some code patterns(or maybe library imports) that would imply that a contract is upgradable. I am reading the docs but can’t find any stable common patterns. My dataset is from etherscan where i can get to analyse source codes for the last 10000 deployed smart contracts. Could you provide me any help/validity threats for that?

Thanks

1 Like
2

Hi @Geomel,

Welcome to the community :wave:

Would be great to know a bit more about your research project.

(If you haven't already) I recommend reading the following for the different upgrade mechanisms: https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/

For current OpenZeppelin proxies you could check for the storage slot (from: https://eips.ethereum.org/EIPS/eip-1967)

Storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc (obtained as bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1) ).

The proxy used in recent versions of OpenZeppelin CLI can be found on Etherscan:

The proxy used in current version of OpenZeppelin Upgrades Plugins can be found on Etherscan:

Feel free to ask all the questions that you need.

3

Hi @Geomel,

I wanted to check if you had any more questions?

4

Hi @abcoathup,

thanks for your reply!

My research questions are whether developers are maintaining sc like they do with other software, how many of the already deployed sc are upgradable and what kind of maintenance is happening there? Is it corrective, perfective maintenance? What are the community needs and what developers actually do to bypass domain specific restrictions like immutability.

So, currently the two versions of AdminUpgradeabilityProxy have been used for 702 and 42 upgradable smart contracts respectively (this has to do only with open zeppelin library users). If i wanted to include in my count the total proxy contracts i wouldn’t be able because the process of marking a contract as a proxy needs to be done manually and it is up for the developer to do it, if i got that right. So we can’t have a total here?

I also wanted to find out if there is a way to see the different implementation contracts that a proxy was pointing at since their creation. Can we see their pointing address evolution?

1 Like
5

I would check with Etherscan to see if you can access the data on what contracts have been verified and marked as proxiesContracts that are marked as proxies in Etherscan would also be worth looking at.

Otherwise you could check verified source code for use of the https://eips.ethereum.org/EIPS/eip-1967 Storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc (obtained as bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1) ).

For different types of upgradeable contracts you would need to identify them. Different upgrade types are described in:

The OpenZeppelin proxies emit an event when they are upgraded.
https://github.com/OpenZeppelin/openzeppelin-upgrades/blob/master/packages/core/contracts/proxy/UpgradeabilityProxy.sol#L62