0

If i have a smart contract stored on block 10, when i change the status of this contract, the altered contract will be stored on the next block or the status of the contract will be stored in block 10 (in this case, the old status will be erased?)

1

This is conceptually off. Possibly a hidden assumption is that modifying your code is an option.

I'll explain the default conditions and then touch on some edgy workarounds.

Default case

Contracts are immutable. You don't get to amend them. If you could arbitrarily change them then they wouldn't be contracts. A good deal of the trust that arises from a contract is the knowledge that no one, not even the author can change anything.

Even a minor defect can have non-trivial consequences and this implies the need for a renewed focus on quality-assurance because it may be difficult or impossible to change a line of code after a contract is published.

Work flow

It goes without saying that there is always plenty of iteration during inception and development. Mainnet isn't the place for experimentation. Tools like ganache and private chains you can set up with one node are appropriate. When you think it's ready for a public debut, you can deploy on a testnet. These are all precursors to what should be a ceremonious occasion when you publish the contract on mainnet. Generally, this closes the door on further evolution of the code. It has been described as launching a spacecraft. What's on board is beyond your reach from then on.

New contracts are new instances

You can use the same source code to deploy another version of the same contract. It gets it own address and follows the same logic. It doesn't replace or interfere with the original. In some cases, user-bases have been migrated to new instances. This usually involves reading the complete dataset in the original, writing the data to a new implementation and redirecting users to the new contract. It can be confusing and controversial.

Upgradable contracts

There are several approaches to upgradable contracts. Modular design is a good start. A contract can hold the addresses of component contracts and pass messages back and forth. Addresses are data (address myServantl) so they are potentially changeable, and that can be used to create a workflow for possible upgrade.

The eternal storage pattern separates immutable data from potentially amendable logic contracts. The ENS name service can help sort out which logic contracts are "official".

There are proxy contract patterns that use a not-upgradeable entry point that delegates all operations to interchangeable implementation contracts using DELEGATECALL.

Countless other combinations of libraries and modular design are possible.

TL;DR;

Contracts are upgradable to the extent that you design upgrade processes. The default is no upgradability exists in the append-only universe.

Meta concerns

Most upgradable patterns imply a privileged user who can decide to change the rules of the contract at will. This implies reintroduction of a non-trivial degree of centralization. Have a look at this: https://medium.com/consensys-diligence/upgradeability-is-a-bug-dba0203152ce

Trustless upgrades

The trustless upgrade pattern severely restricts the author's authority. Rather being the contract owner who (for some reason) gets to decide for everyone, the privileged user (or organization, or DAO) can only propose an upgrade. Individual users decide if they wish to accept it. In the case that the upgrade resolves a major issue or substancially improves matters, this is a solution. In the case that author wishes for everyone to switch to a new version that steals their money, the users would be expected to reject it. It allows for the case that some users want the upgrade and some don't.

As the software architect, your task is to choose among these options the best combination of properties for your project. For example, many cases should not be upgradable. Consider a value token. It is probably a defect if the rules can be changed. In other cases, it will not be sensible for users to simultaneously use different versions of logic. In some cases, trustless will provide an upgrade path for periodic iteration of the production code.

https://github.com/rob-Hitchens/TrustlessUpgrades

Proceed on the basis that nothing can every be changed and then carefully consider the justification and method, especially the authority and the limits on authority that should exist when deciding which upgradable patterns to use.

Hope it helps.

  • So from what I understand, regarding the immutability of the contract, the ideal is not to overwrite conditions or create new contracts with each change made. I asked this question because I'm developing an application where contracts will store a user's privacy preferences for a given scenario. For the chosen scenario there are two users, one sets the privacy preferences and the other user can change preferences under certain conditions. In this case, I thought about using only one contract for all features (I've added a rule so that a "super-user" can change the original user preferences) – Mutante Apr 19 at 2:01
  • In my application I chose to use CREATE2 to generate pre-defined addresses for each contract. Therefore, I do not need to use a separate smart contract to link a privacy preference contract. In my case then, whenever a privacy preference is changed (i.e. will I use true and false for each privacy preference) will the original contract be changed correct? – Mutante Apr 19 at 2:02
  • 1
    It sounds more like changing a state variable within a contract to me - rather than issuing a completely new contract every time the state is amended. function updatePref(bool _preference) ... { preference = _preference; } – Rob Hitchens Apr 19 at 2:38
  • Yes, I just need to set now the addres of the “super-user” to change the contract. Thanks again! – Mutante Apr 19 at 7:20
  • Check out the Ownable.sol standard component in the Open Zeppelin package. – Rob Hitchens Apr 19 at 7:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.