Upgradeability Improvement Protocol 2— Modularization 101

People don’t seem to understand the power, in the separation of powers

Introduction

In part 1 of this series, we built a simple smart contract that allows us to upgrade to a new contract by transferring each user’s data individually. Now, let’s kick into advanced mode!

Isolating the innocent data from all the violence

We think this thought would have crossed a number of solidity developers, “What if we could deploy a new contract, but keep the old data?”. And if you come to think of it, assume you have another place where you had just all of your data, you might never have to worry. And the answer to the above question would solve almost all of the UpgradeAgent limitations. Let’s consider a traditional ERC20 token contract, where everything is in one place. Now what if, the token logic(functions, events) and the data (balances[address], totalSupply, etc) remained at 2 different places that interact with each other through external calls.

UIP2. The Logical Token (ERC-1067 draft)

Before getting to the logical token, we present to you the facilitor for the logical token, the DataCentre contract!

It is a very simple, yet powerful contract that stores all of the data and has a couple of getter setter methods.

And judging by its name, the logical token will not concern itself with storage. It only has functions, and when required, forwards the menial tasks of storing and retrieving information to the DataCentre. So we can deploy a new logic part(the token), and re-reference the new address of the token whenever we want, without having to touch the data. Don’t worry if this went above your head, lets get to the implementation.

A very simplified example for how the DataCentre contract would look for tokens, just to give you an idea, can be seen below

Note: All the setter methods are onlyOwner functions and the owner of the DataCentre will always be the Token contract, except during deployment.

To accomodate the DataCentre, some changes have to be made to the token contract as well.

This is how the deployment sequence for this token architecture would look like (Feel free to check all of this on remix using complete code here)-

1. Deploy the DataCentre
2. Deploy the token with the address of the DataCentre in params
3. transferOwnership of the DataCentre to the Token contract.

This way we create a 2 way link between the Token and the DataCentre. This link between the contracts is very important and will be used in the coming approaches as well.

How does it upgrade?

I hope it looks very easy now. We need to go through 2 steps to upgrade the contract-

1. Deploy the new token contract

2. a. kill the old token contract and enter new token contract into the params.

2. b. the kill function automaticallytransfersOwnership of the DataCentre to the new token contract.

And that is as easy as it gets! Well, at least for now.

Notes-

1. The 3rd transaction carries the weight of the couple 1000 individual transactions in previous approach. Screw this, and everything is lost!
2. The ownership is transferred to the token contract. Insteadmsg.sender should be used for a better approach, because, this address will surely be a private ethereum address(unless someone gets fancy) or at least an address(maybe a multisig contract) that will surely be active. The new contract address can be checked and confirmed and then one can manually transfer the ownership of the data centre to the token. On the other hand, this also opens the door to a lot of other features, out of scope for now.

Advantages to the LogicalToken-

1. This approach completely kicks out the first 5 problems that the UpgradeAgent approach had.
2. The contract owners have complete control and can upgrade whenever they want. Major bugs in tokens that might hurt market sentiments remain undisclosed.

Limitations-

1. Increase in gas costs of about 35% due to the external calls between the logicalToken and the data centre contract.
2. The 6th limitation of UIP1still remains. The contract is deployed to a new address, and the contract owners will have to re-list everywhere. But still, a breather for the investors!
3. The DataCentre implementation brings a small limitation with it. Once deployed, you cannot add, remove, change the public variables. This can be taken care of though, if you consider all the possible cases and create a cure-all DataCentre like the following, you still cannot add more datatypes though. (https://github.com/grepruby/UIP2/blob/master/contracts/DataCentre.sol).

The storage layout is a lot more complicated here but allows to create different types of variables using mappings of mappings.

Though this method is better than UIP1, it is not perfect! And we want to tend to perfection. The next approach is something that looks like a bumped version of this method. If I may, Approach 2–2.0. Or maybe not. Lets get right to the part 3 of this series.

PS: This contract architecture has been submitted for an EIP as ERC-1067. Follow the issue on this link.