Dapp-a-day 6: Upgradeable Tokens
Each weekday leading up to devcon2, Nexus will highlight a dapp, library, or package (something with a
dappfile) as a promotion of our toolchain and as case studies for other developers. Yesterday's Post
It achieves two seemingly opposing goals:
- Keep the "interface" address fixed - don't burden consumers with your update logic (e.g. registry lookups or following an update chain).
- Allow the behavior to be changed (with the ability to lock down, of course), and make it painless.
This is done by splitting the token contract into 3: A "Frontend", a "Controller", and a "Datastore". These are all
DSAuthorized), they look up to a
DSAuthority for access control.
The frontend has
erc20 function definitions as well as
emit* event callback functions.
The controller has implementations of the
erc20 functions extended to also accept the frontend's
msg.sender as an argument (ERC20 semantics depend on msg.sender).
The datastore holds all app state and has only dumb getters and setters and makes logic updates significantly easier.
This design is partially an artifact of the days before
DELEGATECALL and usable libraries, which could arguably reduce this to a 2-contract system. But still, separating the entrypoint and logic controller makes me less nervous about accidentally butchering state.
There is a DSToken "installer" (a "smart factory") which instantiates a token that is functionally equivalent to ERC20Base. It installs a token "into" an existing
ds-token under our belt, we can explore applications that use tokens as well as applications that are tokens. Wow, coins!