Hi,
I learned about the SELFDESTRUCT opcode. So smart contracts once deployed on Ethereum cannot be changed or upgraded. However, there is the possibility to delete the smart contract by programming this functionality into the smart contract and calling SELFDESTRUCT.
What I don’t understand … if it is possible to delete a smart contract by coding that into it upfront, why can’t I upgrade it by having an equivalent code foreseeing upgrades?
Thanks!
Mhh I’m not sure I understood the questions, mind clarifying? Upgrading and selfdestructing are actions that correspond to different needs.
So what I was thinking… if there is the possibility to pre-code the self-destruction of a contract once you call it, should there not be a way to also pre-code the possibility to upgrade/update the contract somehow? If you can foresee the possibility of deleting the contract, meaning that it will not stay immutable on the blockchain … you could also have a function there that implements some kind of upgrade, like software updates? Why should this not be possible for smart contracts? I am just challenging the view whether smart contracts are really that rigid and fixed, if you can determine something beforehand, such as the contract completely deleting itself, you could determine the possibility of it changing, which is a lesser evil… do you see what I mean?
I do, but I’m a bit confused: on one hand it appears that you’re not aware of the OpenZeppelin Upgrades Plugins, but at the same time you’re using the upgrade keyword which implies you’re somewhat aware of it being a thing.
Hi @martriay
In fact I was not aware of that plugin. In Antonopoulos&Wood’s Mastering Ethereum it says: "One of the big challenges facing developers in Ethereum is the inherent contradiction between deploying code to an immutable system and a development platform that is still evolving. You can’t simply “upgrade” your smart contracts. You must be prepared to deploy new ones, migrate users, apps, and funds, and start over.“
Probably at the time of writing, the possibility to upgrade, such as that OpenZeppelin Upgrade plugin, did not exist?
Mhhh I believe at the time of writing it was already a thing, but definitely a new one. Near that time we released ZeppelinOS, eventually renamed OpenZeppelin CLI which was superseded by the plugins.
I believe this section talks about upgrades.
Thanks!
I found a blog post, where Gupta talks about " If we deploy a contract then it is out there with turning back no longer an option. However, if we use proper techniques, we can deploy a new contract at a different address and render the old contract useless. " (2018)
In the Openzeppelin Doc it says: “A smart contract upgrade is an action that can arbitrarily change the code executed in an address while preserving storage and balance.” (2020)
Does this mean, that since then it has now actually become possible to preserve the same address for the update? Without the need to deploy a new smart contract in a new address as a reference for the upgrade?
Hi @codingbibi,
Yes. We interact with an upgradeable contract using the address of the proxy, whilst we can deploy new implementation contracts that the proxy points to.
I suggest trying it out: