Skip to content
Branch: master
Find file History
Type Name Latest commit message Commit time
Failed to load latest commit information.
contracts Update proxy contracts Apr 9, 2018
package-lock.json Update package-lock from inherited storage approach Mar 30, 2018
package.json Update package.json files Feb 2, 2018 Fix typo Feb 5, 2018
truffle.js Split every upgradeability approach in a project itself Jan 27, 2018

Upgradeability using Inherited Storage

The idea of this approach is to allow us to upgrade a contract's behavior, assuming that each version will follow the storage structure of the previous one.

The approach consists in having a proxy that delegates calls to specific implementations which can be upgraded, without changing the storage structure of the previous implementations, but having the chance to add new state variables. Given the proxy uses delegatecall to resolve the requested behaviors, the upgradeable contract's state will be stored in the proxy contract itself.

Since we have two really different kinds of data, one related to the upgradeability mechanism and another strictly related to the token contract domain, naming was really important here to expressed correctly what's going on. This is the proposed model:

               -------             =========================
              | Proxy |           ║  UpgradeabilityStorage  ║
               -------             =========================
                  ↑                 ↑                     ↑            
                 ---------------------              -------------
                | UpgradeabilityProxy |            | Upgradeable |
                 ---------------------              ------------- 
                                                      ↑        ↑
                                              ----------      ---------- 
                                             | Token_V0 |  ← | Token_V1 |         
                                              ----------      ---------- 

Proxy, UpgradeabilityProxy and UpgradeabilityStorage are generic contracts that can be used to implement upgradeability through proxies. In this example we use all these contracts to implement an upgradeable ERC20 token.

UpgradeabilityProxy is the contract that will delegate calls to specific implementations of the ERC20 token behavior. These behaviors are the code that can be upgraded by the token developer (e.g. Token_V0 and Token_V1).

The UpgradeabilityStorage contract holds data needed for upgradeability, which will be inherited from each token behavior though Upgradeable. Then, each token behavior defines all the necessary state variables to carry out their storage. Notice that Token_V1 inherits the same storage structure defined in Token_V0. This is a requirement of the proposed approach to ensure the proxy storage is not messed up.

You can’t perform that action at this time.