My first Dapp (Ethereum)

Thanks to the folks at Ethereum, I was able to get my very first so-called 'dapp' (decentralized application) up and running.

While the immaturity of the technology is painfully evident in the number of hoops one has to jump through to get it working, the core technology is quite sophisticated and robust, and this is where (quite rightly), the folks at Ethereum have been focusing their efforts.

It started with this post here, purporting to get you up and running with a dapp on Ethereum in under an hour. This is certainly possible, but due to the rapidly evolving and sometimes unstable nature of continuous development, builds do not work on all platforms all the time. Currently, Ubuntu 14.04 seems to be the recommended platform (with builds most likely to work at any given point in time), but other platforms are also supported.

So, what did I learn from building my very first dapp? 

The dapp in question is a general ledger application for reliably keeping track of tokens sent between participants - essentially, the functionality that most people associate with Bitcoin.

First, you must create a 'contract'. This is a document with embedded logic and state. A contract contains instructions (code) - for example, to transfer tokens between participants on the Ethereum network. Such a contract can then carry out instructions such as 'transfer 100 tokens from Alice to Bob'. The contract reliably records how many tokens Alice and Bob have respectively after the transaction has completed. Tokens are allocated according to the logic embedded in the contract. The logic in the example states that tokens can only be transferred between two participants when the sending participant has enough tokens to send, otherwise the transaction fails. 

Contracts are created with initial state - in the example above, an initial 10,000 tokens are in the account of the contract creator (e.g., Alice), who can then reliably transfer some or all of these to any other participant on the Ethereum network (e.g., Bob).

The contract is sent around the Ethereum network. Executing and validating transactions on the contract requires  a quorum of nodes on the network to do that work. Nodes cannot modify contracts, and contract state can only modified by executing pre-defined transactions on the contract.

This transaction execution and validation requires 'gas', a new concept which reflect the cost of executing transactions on Ethereum contracts, which could in some cases be expensive in terms of computation and/or storage. Gas pays for Ethereum 'miners' to execute and validate transactions. Contract execution can be priced ahead of time in terms of gas, and gas itself is priced in terms of ether (the Ethereum's unit of account). 

The example, while trivial, helps bring to life some of the key concepts behind Ethereum and similar distributed blockchain technologies.

In particular, it is important to understand the difference between the underlying 'currency' that represents Ethereum's unit of of account (the 'ether') and contracts that sit on that unit of account. The 'ether' in the end should reflect only the utility cost of providing compute and storage: the value of the contracts however could fluctuate wildly depending on the purpose of the contracts.

For example, in the simple example above, a token could be taken to represent 1 USD, and a commitment from whoever issued that token (Alice) to give you (Bob) 1 USD for each token you have. Ethereum cannot guarantee that Alice will actually give Bob 1 USD, but it can ensure that the token you have is not owned by anyone else. In other words, Alice has a maximum liability of the $10,000 she created the original contract with, and the tokens are worth $1 as long as Alice makes good on the promise to reimburse token holders with equivalent USD. And Alice can rest assured that once all 10,000 tokens have been reimbursed, that nobody else will appear claiming they have a token.

Next up: further experiments with Ethereum's platform.