What's in a Basic Token Smart Contract, and Why Create Ethereum Tokens?

December 04, 2017

Image by: Blockgeeks

If you’ve followed along with my writings, you might have stumbled on my previous post on the difference between ETH Currency and Ethereum Tokens. This reply is an evolution of an question I received from a reader.

But perhaps you still have the question, where are the tokens stored? How are they related to the ETH I transact in? What’s in a smart contract?

As a quick review, recall that at a high level, smart contracts function to programmatically control assets in the decentralized world. A contract is really just an code-able interface to manipulating the blockchain ledger which when combined together create

“applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interface” - Ethereum Project

But in terms of how these assets are accounted for, let’s take a look at a modified Standard Token smart contract courtesy of Consensys.

contract StandardToken {

    mapping (address => uint256) balances;

    // Transfer a value of tokens from one ethereum address' token balance to another
    function transfer(address _to, uint256 _value) public returns (bool success) {}

    // Get the token balance of an address
    function balanceOf(address _owner) public returns (uint256 balance) {}

    // Add a token balance equal to the value of ether sent to the balances mapping under the user's address
    function buyTokens() payable {
        balances[msg.sender] = msg.value;
    }
    // More functions left out..
}

At a base level, a Token contract maintains a “list” of token balances associated with Ethereum addresses. These addresses represent accounts or persons who have sent the Token contract ETH in exchange for tokens.

This “list” of tokens is known as a mapping in the contract language Solidity.

If you’re more technical, you can consider a mapping similar to a HashMap data structure in other languages. For example, consider in Java a HashMap<String, int>, but in this case the String refers to a hexadecimal Ethereum Address which maps to an int value that represents our token balance.

INSIDE CONTRACT:
mapping:
[Ethereum Address]→ 20 tokens
[Ethereum Address 2] → 15 tokens
[Ethereum Address 3] → 22 tokens
— — — — — — — — — — — — — — — 

These tokens are used for different functions or processes in the context of what the contracts purpose is. For something like the Golem Project, the Token acts as an internal mechanism of accounting to be able to create a system of renting and buying CPU time.

Golem Project

Fig. How you “rent” CPU time with GNT

Solidity Café - We Take Fiat $!

But all this talk of tokens, renting CPU time, and internal accounting is a bit complex. Let’s consider a simple example of managing tokens instead called “The Solidity Café” a gaming café.

At Solidity Café, we sell gaming time at a computer for a rate of $5 per 30 minutes to patrons who stop by. But because we serve so many patrons, every time a new patron stops by we’re going to add their name to our ledger of accounts along with the remaining gaming time balance they’ve paid for.

INSIDE GAMING CAFÉ
[Moss Doerksen] → 20 minutes
[Robert Simoes] → 15 minutes
[John Flammington] → 22 minutes
— — — — — — — — — — — — — — — 

If you’re keenly perceptive, you might have noticed this looks vaguely familiar to what we did in the Token contract. In fact, when patrons exchange their currency they’re really buying tokens of time in our Solidity Café. Comparing the two they don’t look all too different.

The Solidity Café

Fig. Contract comparison for Solidity Café vs. Simple Token balance

Why Bother With Tokens At All?

While it’s nice and all that we can codify tokens it still fails to explain the reason for using tokens in the concept of a smart contract. For example, why use Golem Network Tokens (GNT) at all in Golem project instead of time like we did in Solidity Café? The reason for using tokens really depends on the application one is building with the contracts.

Good Protocols and Projects build utility into their token. For example use as an internal transaction medium or gamification mechanism to provide a service or a task by the application itself.

The power of tokens comes from:

  1. The ability to programmatically create scarcity (cap the amount of tokens in circulation)
  2. The ability to define the rules by which the token is used in the system.

Let’s consider our Soidity Café example again. What would happen if we wanted to let people trade time, and perhaps start accepting time for different services?

We probably could, but the time concept has own vocabulary, uses and role in our Café. When we start adding different benefits such as trade-ability of time for refreshments or other service, things get a bit cumbersome.

Instead, we create a new entity (i.e. a token) which we can define the means by which it is used and accounted for in our system. I personally like to think of the token as encapsulating the role of accounting unit instead of overloading the time concept as a means of utility and accounting.

Back To Golem

Golem Ecosystem

Fig. Service providers and developers can build ontop of the GNT construct to produce and transact their own services

Let’s go back to the context of the Golem project.

The real power of creating GNT is a common language by which developers or other persons can trade, sell or build on top of the initial concept of renting CPU time. This allows developers to hook into the ecosystem and start providing other services or products in a common language of exchange, which is very powerful.