- Ethereum is still developing, and there have emerged many controversies over how to upgrade the smart contract version.
- The method makes use of the DELEGATECALL opcode. This is the opcode provided by EVM for the assembly and works like a regular call.
- Unstructured storage is probably the most substantial upgradeability method which is available today.
Ethereum is still developing, and there have emerged many controversies over how to upgrade the smart contract version. Here are some of the best options to do so.
Registry contracts are probably the most straightforward approach to scalability, but in this approach, simplicity brings some severe flaws.
It uses the work of two smart contracts: a registry contract and a valid contract. Registry contracts only used to point users to the current version of the logical agreement.
This method can be disadvantageous because when users want to use the contract, they must first lookup the current address. Inability to do so might result in the loss of funds.
Proxy contracts are used for forwarding data and calling to the logical arrangements. With the help of a proxy contract, users can always call the same contract address and forward it to the current sensible contract.
The method makes use of the DELEGATECALL opcode. This is the opcode provided by EVM for the assembly and works like a regular call. The difference is that the code for the target address executed in the context of the calling contract.
This method avoids problems related to registry contracts. However, it also has its challenges. Like, if it not managed properly, data storage can quickly fail. If the storage layout of the new contract is different from the previous contract, then the data may be corrupted.
The implementation of this also prevents you from receiving return values from functions, limiting its use cases. It also requires your valid contract and ancillary contracts. In this case, the auxiliary deal is a permanent storage contract.
The technology of inherited storage upgradeability makes use of three different contracts, first the proxy contracts to delegate calls and serve as persistent storage, the second is the logical contracts which help process data, and the last is storage contracts.
The proxy contracts and sensible contracts inherit from storage contracts, and thus, their storage references are aligned. When a valid contract is updated, we only have to change the location pointed by the proxy agreement to use the administrator-only function.
However, this approach has its anomalies. Since the agent contract and the storage contract are eternal, if any errors or loopholes found in any of the agreements, they cannot be repaired.
Unstructured storage is probably the most substantial upgradeability method which is available today. It allows us to take advantage of the layout of state variables in storage. When using a constructor-dependent contract to set some initial state, working with a proxy is not easy.
Post creating the valid contract, the EVM will discard the constructor, so you cannot only reuse the code. A possible alternative to it is to use constructor code in regular functions. One has to make sure that this function can only run once.
It is essential to consider that necessary contracts inherited from logical arrangements. This part is particularly complicated since solidity also supports multiple inheritances.
All in all, one thing persists, which is to ensure that smart contracts are upgradeable. One also has to consider the upgrade process carefully. Everything done has to be done by using logic and discussing the pros and cons of it.