Subtleties of upgradeable contracts

General
1

OK I was able to read a little bit about the strategy using delegate call via assembly, so I suppose that answers the gas cost question, and also about getters - but I still do not know enough to understand the subtleties that come along with basically any solution - so that is the real question, what are the subtleties that come along with Upgrade?

So far I understand it uses delegate call, and that the contract iterations must be programmed so that the storage is only appended to as not to pollute the storage space of the proxy contract.

Anything else I could learn about it would be excellent.

1 Like
2

Hi @realisation

Some subtleties to consider with upgradeable contracts using the OpenZeppelin SDK:
(I split this into a new topic as I thought it was an interesting discussion on its own.)

Upgrades Pattern

Suggest reading about the upgrades pattern (if you haven't already): https://docs.openzeppelin.com/sdk/2.5/pattern

Governance

Need to consider the governance mechanisms to decide when and how to upgrade the contracts that will earn the trust of users:

Verify

Currently we can verify logic contracts on Etherscan with OpenZeppelin SDK and we can manually verify proxy contracts on Etherscan.
Etherscan doesn't currently support OpenZeppelin SDK proxy contracts.

Audits

Suggest reading the audits of the OpenZeppelin SDK contracts:

3

Great, yes this is a good start. I read the documentation on the pattern which was well done. I have more to learn there, but that would be more about the EVM than OZ itself… although help like that is always appreciated so if anyone knows good, unique resources for someone who isn’t an expert I’d love to know what they are.

Thank you for now! Maybe more to come.

1 Like
4

If I want to debug my contracts, what wrinkles does Upgrade bring into the fold?

Does it make sense to debug in the Upgrade context? Possibly not.

Seems like I should just debug my contracts before deploying them as the next logic contract in the upgrade chain.

Would love to hear your thoughts on this.

1 Like
5

Is there anything besides proper introduction of new state that I should be aware of when deploying new logic contracts to the proxy?

1 Like
6

Indeed, you can simply use the logic contract and assume the upgrade part will work fine. If you eventually need to upgrade, I would advise however then testing the specific upgrade you're planning, to make sure you didn't leave anything out. We have a testing guide to get you started with this.

No, the main things are the initialize function and the limitation around new storage variables. That said, you may need to do some custom migration when upgrading a contract, so that functionality you’ve added in the upgrade is properly initialized. For example, if you’re adding an owner variable in an upgrade, make sure you set the owner address during the upgrade process.

1 Like
7

What if I had a logic contract that had an internal function, would that pose a problem?

1 Like
8

Internal functions are fine, they are no different from the code in public functions.

1 Like