Getting Started with Distributed Apps on Ethereum
In the past we’ve talked about how the blockchain works and some of the practical applications of the blockchain on our society. In this post I’m going to talk a little bit about distributed applications that take advantage of smart contracts on the ethereum blockchain and give a quick guide to getting started building a distributed application on the blockchain.
What are Dapps?
Distributed Applications (Dapps) are applications (typically a web application) that run in your browser and interact directly with Smart Contracts on the block chain. A traditional web application (Like a shopping cart) would have a web client that makes API requests to a backend server and persists. Data would be stored on a database wholly owned by the application and all business logic would occur in the API Layer. In a dapp, the web application reads data directly from the blockchain and writes data via transactions back to the blockchain. All business logic occurs in a smart contract that is deployed to the blockchain.
How do I use Dapps?
Because Dapps do not interact with an API but instead interact directly with Ethereum and smart contracts, you need to enable your browser to communicate directly with the ethereum network and the smart contracts that exist on it. In the future it’s very likely that your browser will come with a wallet that allows you to post transactions to various blockchains, but until then the best choice is running a browser extension called MetaMask. MetaMask is not only a wallet (it allows you to store and transfer ether), it also exposes a javascript sdk that allows you to interact with the ethereum blockchain from within your distributed app. Download and install the MetaMask extension from their website.
How do I build dapps?
The easiest, quickest way that I have found to getting started building distributed apps is using the Truffle Suite. Smart Applications require a couple different components — Smart Contracts, which are deployed and executed on the blockchain, and the client application that interacts with the smart contracts. The truffle suite gives you an all-in-one project for creating, deploying, and migrating your smart contracts alongside your client application. It also includes some other features that simplify development — Automated testing of contracts, a local version of an ethereum blockchain that allows for quickly & easily testing your distributed app locally, and some convenient ‘Truffle boxes’ that provide for a good starting point for developing applications. To get started with Truffle Suite, follow the instructions in their documentation. I found that installing an existing truffle box and modifying the contract/dapp to support some new features was the quickest way to get an understanding of how the applications work.
Important concepts
Here’s some concepts you should understand before building your first distributed application.
Smart Contracts
In a distributed application, instead of an API, your application interacts with Smart Contracts directly on the blockchain. This will handle any scenarios where you want to perform trusted business logic or data storage. These smart contracts can be written in a language known as Solidity. Take a look Here for an example Smart Contract or read the docs for Solidity here: Solidity Docs.
Transactions
A transaction is any request that requires modifying the blockchain; it costs ‘ether’ (aka gas) and requires time to be committed to the blockchain (20s or more). A transaction will not return a payload, instead just returning some information about the transaction itself (how much gas was used). See the section below about events if you’re looking to capture some data from a transaction.
Calls
A call is simply a read from the blockchain and is instantaneous and free. It returns a value in the request.
To help understand the difference between calls and transactions, I’ve created a simple contract for a key-value store with two methods — get and set. Both methods are public, but the set method (a transaction) when called from the browser will prompt you to commit the transaction and will use a small amount of ether (gas) to do that while the get method will return the value from the store in the result and will not require any payment.
Events
Since transactions do not return data, if you send a transaction and need to get some data back, your contract must define and fire an event with the appropriate information attached. While using the test network from Truffle, these events are captured and can be received in the transaction response under the key of ‘logs’. Other ethereum nodes (like Geth) run a web socket server that allows for subscribing to specific events and handling those in the code.
Debugging/Troubleshooting Smart Contracts
One of the most challenging aspects of smart contracts is attempting to troubleshoot a smart contract that is not working as expected. In a traditional language, you could simply log messages to the console while the application is running, but in the case of a distributed smart contract, we don’t have access to a console that we could write against. Truffle offers a debugger for your contracts via their CLI, but I found the information to be a bit lacking. The approach that I found to be most useful is to create and log a new Event for any messages that you are looking to track, then to fire those events from the transaction. With Truffle you will receive those messages in the response, or if you’re using a different web3 client you should be able to stream any logging events directly to the browser.
Quick start for developing a Dapp
Assuming Node.js is already installed:
Where do we go from here?
We’ve talked a lot about the blockchain in the past, but one of the most important things to understand around the blockchain is the concept of a distributed application. We’ve talked about how the blockchain reduces our need for trust in any specific organization and instead replaces it instead with a technology that allows for secure, verifiable, and distributed transactions stored on the blockchain. The same concept can be applied to our application infrastructures — In a traditional web application, we need to trust in the API that our application is communicating with, but with a distributed application our API exists as a set of smart contracts running on ethereum nodes — No middleman necessary, the applications communicate directly with the Smart Contracts.
The technology for creating dapps is still in it’s infancy — it requires some getting used to the concepts around developing distributed applications, but the development tools will become easier and the integration between the wallet and the browser will become more seamless. We’re even beginning to see more acceptance of distributed applications on the web. Over the last weekend a distributed app was released and quickly went viral — CryptoKitties. In the first few days people spent around $1.3M on electronic cats. Although the concept is a bit silly, it truly shows what is possible using distributed applications, and it may expose the market of distributed applications to a large new base of users. The same set of users that are buying and selling virtual cats on the internet may be the next set of users that are willing to use distributed versions of other apps as well.
Stay tuned for more follow-up posts while we explore the blockchain and distributed applications in more depth.
