Contract change registry

Question

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?)

Answer 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.