Given the uncertainty in the events in which smart contract work, can a smart contract be updated after deployment on the blockchain. For example, may real life contracts are amended by the parties during the contract execution.
-
There are upgradable smart contracts but with limitations and rules– Majd TLDec 16, 2021 at 20:13
-
Yes, you can check Open Zeppelin's libraries of upgradable contracts: github.com/OpenZeppelin/openzeppelin-upgrades and hardhat tool for it: docs.openzeppelin.com/upgrades-plugins/1.x/api-hardhat-upgrades– Julissa DCDec 16, 2021 at 20:20
-
You can find more details in this answer.– Mikko OhtamaaJan 16 at 20:45
2 Answers
The short answer is no. Smart Contracts are immutable, stateful and persistent software.
But there are some design solutions to "upgrade" them using a proxy. You can read the Proxy Upgrade Pattern at OpenZeppelin.
-
-
Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.– Community BotDec 17, 2021 at 8:30
-
"Smart Contract" is one of those catchy names that rolls up a lot of descriptive information but isn't entirely literal.
They are generally not analogous to legal contracts. Legal contracts tend to describe things that should happen and what will happen if those things don't happen. The courts are full of people using a somewhat nondeterministic process to sort out what will happen because of something that should not have happened.
"Smart Contracts" are immutable, stateful and persistent software processes that spell out what will happen. Departures are generally not possible because they are deterministic.
Building a smart contract is less like negotiating and renegotiating a legal contract and more like designing, testing and producing a piece of hardware. At the end, it does what it does and resists attempts to change what it does.
The intractability of smart contract software is a source of their trustworthiness - everyone can understand that its rules of operation will not be arbitrarily changed - not even by the author. The default condition is that changes are impossible.
This does indeed present software developers with challenges. Care must be taken to ensure quality and also to ensure relevance as future requirements that were not anticipated in advance come into view.
There are design patterns that attempt to provide authors with degrees of adaptability. These are based on modularity and delegation. The unchangeable design may include processes to delegate processes to modules, and processes to swap the modules for something more satisfactory. Invariably, this diminishes the "immutable" guarantee of a smart contract and raises the issue of who decides if the contract should be upgraded.
A comparable situation would be as follows:
You design a spaceship to go as fast as possible with present-day technology. You shoot it into space on a journey to Jupiter. Nothing will ever be onboard unless you put it there, pre-launch because you can't catch up to it.
But, you have a little foresight and anticipate that upgrades or repairs might be necessary. You can communicate with it from earth. You could put some spare parts or a 3D printer onboard and program the onboard computer to respond to commands from earth. You can make it upgradeable and repairable to the extent that you can anticipate and accommodated the things that you will need to do. All this extra stuff adds mass to the spaceship (think code complexity and governance concerns) and the various ways you have added flexibility (and risk) will be apparent to everyone to examines your spaceship design.
Hope it helps.