Preparing for Upgrades
- Have money management strategies in place
- Create a pause functionality
- Have paths to upgrades
- Switching addresses
- Switching Oracles
- Proxy contracts
The mentioned functionality is mandatory in order to properly maintain and do risk management on your system. The money management strategy has to do with were and how we hold the funds and the system data. The switch address is related to the proxy contract and the rest have to do with the flow paths we designed to upgrade the smart contracts .
The basic idea is using a proxy for upgrades. The first contract is a simple wrapper or "proxy" which users interact with directly and is in charge of forwarding transactions to and from the second contract, which contains the logic. The key concept to understand is that the logic contract can be replaced while the proxy, or the access point is never changed. Both contracts are still immutable in the sense that their code cannot be changed, but the logic contract can simply be swapped by another contract. The wrapper can thus point to a different logic implementation and in doing so, the software is "upgraded"
Note: This abstract proxy contract provides a fallback function that delegates all calls to another contract using the EVM
delegatecall. We refer to the second contract as the implementation behind the proxy, and it has to
be specified by overriding the virtual
_implementation function. Additionally, delegation to the implementation can be triggered manually through the
_fallback function, or to a
different contract through the
The most immediate problem that proxies need to solve is how the proxy exposes the entire interface of the logic contract without requiring a one to one mapping of the entire logic contract’s interface. That would be difficult to maintain, prone to errors, and would make the interface itself not upgradeable. Hence, a dynamic forwarding mechanism is required .