Upgradable contracts - OZ (Upgradeability using Inherited Storage)

#1

Hello, I’m wondering about one thing.
Let’s say I have contract Contract1.
Let’s say I have applied to my Contract1 Upgradeability using Inherited Storage pattern. So now it’s the time to update some logic inside my Contract1.
1st case:
I’m willing to change logic inside 1 method, but keep input/output same, so the change doesn’t affect contract ABI. Can I change it inside current implementation, and just redeploy it, and then update Registry with new implementation and set new version etc. OR I have to create new contract, for instance Contract1v2 and inherit Contract1 and then, in Contract1v2 implement (override) the method I want to apply logic change?

Thanks in advance!

#2

Hello @madjarevicn! Maybe @frangioxan help you out!

We’re at ETHDenver right now so apologies if he takes a moment to get back to you.

#3

Thanks @IvanTheGreatDev, please feel free to ping me after ETHDenver. :slight_smile:

#4

Both approaches should be valid: inheriting has the nice side effect of preserving the original ABI, but you may encounter a scenario where it is not enough (or convenient) to do the change you want to do, e.g. if you need to change a private function.

I believe @spalladino has experimented more with this sort of thing, maybe he has additional input?

#5

@nventuro no more comments, as you say, it’s exactly the same. The compiled bytecode would be (pretty much) the same whether you create a V2 extending from V1 and override the desired method, or you just modify your source code.