Quick Updates:

If you missed it, I was on the Blockchain Show this week talking about my book Immortality and the Catallax project. Thanks to Steven for the time and platform. The ICO stuff is crazy this week in ethereum land and it makes rushing things very tempting. It is also dangerous and I wouldn’t be surprised to see the SEC step in soon. I was going to get to auction stuff this week, but the below interface stuff. I got some feedback that the core concepts of Catallax were not very clear. I’m working on a set of posts to lay those out more clearly. Thanks to @evan_van_ness. Check out his Week In Ethereum newsletter here. Be looking for those next week. I started a sub-reddit. r/Catallax - Subscribe to follow along.

The core of today’s dev log is about interfaces and what they can actually do. All this ICO excitement is based of the implementation of ERC20 tokens. Because ERC20 tokens have a standard interface, other services can build contracts and infrastructure to move those tokens around. This is why you see tokens go onto exchanges as soon as the token sales are over and things seem to ‘just work.’

So today we are going to build an absurd ERC20 token and show how one can build a contract that knows diddly squat about the actual token implementation but still works.

Sound fun?

First some definitions:

Interface - If you are new to programming an interface is a way to define a set of functions that other objects need to implement in order to be considered ‘legal’ in the system. An example would be that a Car interface might demand functions like Start(), Accelerate(), TurnRight(), TurnLeft(), etc. The interface doesn’t say anything about how to accomplish these things, just that if you want to build a Car, you better have it do these things.

Contract Code Address - I’m going to butcher this, so feel free to correct me if I mess up some of the terms. This is an ethereum specific thing. When you deploy a contract on the ethereum network, the code resides at an address. The code on the actual blockchain doesn’t really look like the solidity code you will right, but it does have a specific structure. Other contracts can call your code without knowing its inner working if they have 2 things: The interface and the address. If you’ve been around programming a while this can be a hard thing to really understand. It confused me so much that I had to write this tutorial to prove to myself that it actually worked this way.

ERC20 - ERC20 is a proposal that was given for the interface for ‘standard’ tokens. You can read it here. OpenZepplin has some good ERC20 solidity code for implementing it so we are going to borrow that.

So here is what we are going to do:

Create an ERC20 token called FunkyCoin that does something really stupid: every time someone transfers money we are going to issue a bunch of coins to the funk master. Why? Because he is so funky. Create a generic ERC20 Wallet contract that can hold any ERC20 token. This wallet won’t know anything about FunkyCoin. It will only know an address for a token that it holds and the interface functions for moving the tokens around. We are going to change the funk master address to a random address. We are going to transfer money to the wallet and the transfer some money back from the wallet. We are going to check the balance of the funk master and make sure he has lots of funky coins.

The following code can be loaded in a gist here.

First, we have the code for the interface. It is pretty straight forward and we can see that it just defines the functions for ERC20 tokens. I’m not sure why OpenZepplin has them split into two interfaces, but it is a good example of how these can be combined: