Token upgradability

[medied]

OpenZeppelin is working on upgradability (they really are: blog post, contracts in /labs repo, there's a #upgradeable-erc20 channel on their Slack too). Looks like it's still brewing at this very moment, will require some mental strength to tune myself into that conversation. Upgradability is important, seriously needed. With upgradeable smart contracts a whole lot of pressure comes off our shoulders as we could deploy a very basic V0 token and then know that we can upgrade it carefully as needed. After what I saw in #4 I think looking into this is the next logical step.

Will continue diving into this

[medied]

Key concepts:

• Eternal storage. A contract that stores all permanent data of the Dapp. Idea is to separate the storage so that if you upgrade a contract's logic, the data associated with the old contract is not lost (source: rocketpool)

• Solidity library. It's a different type of contract, that doesn’t have any storage and cannot hold ether. Their purpose is that they are deployed only once at a specific address and their code is reused using the DELEGATECALL feature of the EVM. This means that if library functions are called, their code is executed in the context of the calling contract, i.e. this points to the calling contract, and especially the storage from the calling contract can be accessed (sources: solidity docs, jorge's article)

• Proxy libraries. So builds on the idea of Solidity libraries but structured in a way so they're not immutable, that they are flexible for upgrades. (source: maraoz's article)

[medied]

Zeppelin team is exploring different approaches to upgradeability in the lab, variations of the eternal storage approach with combinations of proxy lib patterns. Need to play with all of them to understand them and know how to proceed (note they do have tests in there). Broadly:

• Upgradeability using custom Eternal Storage: The idea of this approach is to allow us to upgrade a contract's behavior, assuming that the storage structure won't change.
• Upgradeability using generic Eternal Storage: The idea of this approach is to allow us to upgrade a contract's behavior, using the same generic storage structure for any contract. This is a set of mappings for each type variable which could be accessed or modified inside the upgradeable contract.
• 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.
• Upgradeability with vtables: This idea builds on upgradeability using inherited storage, but breaks the implementation contract in multiple contracts.

[medied]

It's still such a work in progress. Tried to run different tests in there and was unable (complaining about missing SafeMath.sol, something silly but still). Point is, it is still very messy and not really near done or usable. The milestone for the v0.1.0 Kernel MVP has a due date of July 1st, gives us an idea of the timeframes they are working on. I asked in the Slack channel to confirm, let's see what they respond.

[medied]

Note Zeppelin is also thinking how to onboard (would be) 'legacy tokens' here