Developing our first Ethereum app (DApp)

And the trials and tribulations thereof

Background

Bitcoin grabbed our attention by providing anonymous, decentralized, and independently verifiable transactions using a currency that can’t be forged or destroyed.

As amazing as that was, the real killer app that bitcoin ushered in was the “Blockchain”. Smart folks quickly realized that an immutable, distributed, fault tolerant database that couldn’t be revised without leaving a clear audit trail opened the door to some fantastic opportunities.

Ethereum was designed to take better advantage of this powerful new database than Bitcoin had. Instead of simply recording transactions, the designers of Ethereum made a virtual machine and storage mechanism resulting in a “turing complete” machine, that was simple enough to suit fast peer to peer validation and confirmation of new transactions.

Introduction to the Project

mike ihbe

challenged our team at

Must Win

:

How can we, in just a couple weeks, build a useful app on top of Ethereum?

After considering some amazing ideas we decided on a small project to provide a way for content publishers to accept micro-payments in order to unlock access to content.

The idea is straightforward; a smart contract that accepts a small payment of ether (or it could be expanded to other considerations of value; from bitcoin, to other currencies, or even more creative exchanges), and when the payment is confirmed the contract automatically releases the funds to the seller, and access to the content to the buyer. We called it TinyPay.

Thumbnail sketch of TinyPay

The basic workflow for clients of TinyPay looks like this:

1. Sign up on our web app with the sellers domain name.
2. Ask the seller to register a DNS record with a token we provide.
3. Send an event from the contract once the domain is configured to trigger our “oracle” to perform a DNS check for the token.
4. The oracle periodically checks the DNS record, and once the domain has been verified the oracle sends a follow up transaction to the contract, confirming that the domain is legitimate.
5. Once the seller is recognized, they place our javascript code on their site and configure it to display our payment button at the appropriate time
6. Consumers of the sellers content see the prompt to make a micropayment, and if they choose to buy access to the content, then they click the payment button.
7. A secure payment window pops up (currently using browser plugin MetaMask), prompting the user to confirm a small micro transaction of ether to the contract, from their configured Ethereum wallet.
8. As soon as the payment is approved, the seller provides access to the content to the buyer. Funds are transferred quickly and irrevocably in seconds.
9. A very small transaction fee is sent to the holder of the contract, and payment is released to the seller from the contract on behalf of the buyer.

The Architecture

Contracts

Smart Contracts are the core of Ethereum DApps. They live in the blockchain as bytecode in the Ethereum Virtual Machine binary format. The bytecode is compiled down from a higher level language. The most popular one, and the one we used, is Solidity; a language that feels mostly like Javascript.

Other high level languages you can use are Serpent (similar to Python), and LLL (Lisp Like Language, but closer to assembly). Serpent compiles down to LLL and direct use of LLL seems to be deprecated. In reality Solidity is quickly becoming the de-facto standard for writing Ethereum contracts.

Oracle

In our TinyPay.co app, we want to verify ownership of the sellers domain, but that requires some DNS lookups that are not possible from the smart contract. Enter the “Oracle”, an application designed to conduit external data into the contract. We take a deeper look at Oracles and ours in particular in this follow up post.

Web app client (for third party sites)

Our web app client is defined by javascript code that sellers of content place on their site. This client code handles the display of the “buy now” button and interfaces with the Ethereum wallet on the local browser. In our case we used a browser extension built by the Ethereum foundation called MetaMask to inject the Web3JS code that interacts with the Ethereum network.

When a buyer clicks our “buy now” button the web app client triggers the transaction process.

Web app sign up

Another piece of browser based javascript code is in our Sign Up page, where sellers agree to the terms of using the TinyPay contract, and send their proof-of-ownership transaction, which verifies that they own the domain they’ll be using the web app client code on.

Ethereum node

The first aha! moment for me in developing against Ethereum was when I understood that running a blockchain node is essentially running a database replica. It keeps in sync with every other database replica across a peer to peer network (in this case thousands of nodes). Some useful and interesting features of the Ethereum “database” include immutability / append only updates, event emitting, and a form of eventual consistency based on consensus between peer nodes.

Consensus and transactions in general are a byproduct of the mining process that propagates the Ethereum blockchain. In Bitcoin, for example, the incentive for miners to expend resources on mining is that they can earn Bitcoin for each block they mine. Ethereum is similar, but there are additional incentives for miners; each transaction includes a (usually very small) fee that goes to the miners who process the transactions.

When building distributed apps, all your middleware and front end code can be written essentially as you normally would. To connect to the “database” back end, there are language bindings for most of the popular languages these days. (Go, .NET, node.js, Java, Python, Ruby, etc.) One thing to keep in mind is that Ethereum is under active development, and the client libraries are in various stages of completion.

Deployment

We used a framework called Truffle to handle the deployment of our contracts. It ensures the contracts compile, and then performs the transactions required to get the bytecode installed and propagated on the blockchain. Once the installation is successful, Truffle updates the compiled javascript libraries with the address of our contracts on the blockchain, and we can use those to distribute our web applications as we normally would.

Must Win would love to help develop your next “DApp”. If you’re looking for help understanding or utilizing block chain tech, reach out to we@mustwin.com and reference this post.

John Weldon writes back-end code for various projects and has experience in a wide range of technologies and programming languages.