Weekly Updates:

Did I mention I was a father again? Not a whole lot of coding this week as I’m trapped in the whirlpool of 3 hour feeding cycles. Never fear though we do explore something of value today. My book Immortality is up to #123 in the Kindle Store > Kindle eBooks > Nonfiction > Politics & Social Sciences > Philosophy > Metaphysics category on the kindle store. Watch out world. I purchased my various tickets to DevCon3. Look out Mexico, Here I come!

The Code

Today’s post isn’t very long but I think it will help answer some questions for others who have been confused by the storage system in Ethereum.

There are a number of good pieces of info out there that talk about how you should handle storage for more complicated contracts. The basic idea is that you create a storage contract to hold all of your data so that if your master contract needs to be replaced you can just deploy a new contract and point the storage to a new place. Here are a few articles on how some of this works:

https://blog.colony.io/writing-upgradeable-contracts-in-solidity-6743f0eecc88

https://ethereum.stackexchange.com/questions/13167/are-there-well-solved-and-simple-storage-patterns-for-solidity

https://ethereum.stackexchange.com/questions/15930/pushing-pulling-data-from-data-storage-contract

http://solidity.readthedocs.io/en/develop/miscellaneous.html

The colony article is really interesting and they end up setting a place for all different kinds of data. As it is difficult to predict what kinds of data you are going to have I thought it would be interesting to think about how to make this more generic. This gets especially difficult when you start doing mappings of mappings. This is going to be important for our decaying tokens as we are going to need to keep track of transaction inputs in a mapping(address => mapping(address => amount)) such that we can get data you like prefs[reciver][payer]

My little example looks at allocating ERC20 allowances and how to store those: