Ethereum DApp Development: How to Build a Decentralized Application
So, you decided to get yourself one of those fancy-shmancy dapps? Well, it's about time! In this paper we give you a brief guide on how to build an Ethereum-based decentralized application (DApp). Why does it have to be Ethereum?
You have at least three firm reasons:
1. You can create any app on Ethereum. The point is, Ethereum is written in Turing-complete code language which makes it capable to run any algorithm/script Moreover, Ethereum "moves" faster than other well-known platforms including Bitcoin: Ethereum can process transactions in 12 seconds!
2. Ethereum is powerful and flexible enough to be incorporated into every business.
3. Ethereum is being incorporated by financial institutions.
This time we'll cover topics such as crucial blockchain concepts, basic project structure, smart contract development, etc. Perhaps, we should start with the following overview:
- All DApps use the advantage of smart contracts. They really do! The smart contracts are deployed on the "blockchain backend" and handle the most important data processing and storage for your decentralized application.
- Smart contracts can't do without user interface (UI). True again, digital contract used on your blockchain are virtually useless without a UI. Fortunately, the user interface can be created in any language or environment Ethereum can "talk to."
- Choose your browser. A browser you need is one that can render your HTML5 UI. Unfortunately, traditional Web 2.0 browsers won’t be enough in the case of decentralized apps due the following reasons:
1. They don’t support e-wallets for digital currency, so you there's no chance for you to make transactions fast and easy.
2. They would have to rely on a central/external RPC service to interact with the actual blockchain. What a drag!
Let's consider the very basic concepts of what decentralized blockchain application really are. Actually, to develop a full-fledged DApps you need to get some further concepts that are important to understand. But first you need to digest the following things:
- Compilation: the process of compiling Solidity code into bytecode that can be stored on the blockchain for further execution.
- Call vs Transaction: calls are specific functions in your smart contract that read data from the blockchain while transactions write or update the state of the blockchain. Calls go for free; transactions cost gas.
- Gas: the cost of transactions on the blockchain which is paid with Ether.
- Migration: a transaction that creates/updates a contract to the blockchain.
- Mining: the process of verifying transactions which is rewarded with cryptocurrency (in your case, with Ether). You can use that reward to pay for gas.
That seems obvious, but you need a reliable tool capable to help you with compilation, migration and smart contract testing. That tool is the Truffle framework.
Also, to run a blockchain locally for testing, you need a relevant client. Feel free to choose [TestRPC]. It's a standard client that makes a good choice for automated testing. All you need is to Install both mentioned above tools globally to use them across various projects:
$ npm install -g truffle ethereumjs-testrpc
When it comes to the Truffle framework, it has a set of resources for developing smart contracts. As for now, you can start with creating the following files and directory structure for your precious DApp:
As you can see, we haven't created any project-specific files. The point is, the created structure, and the source code of these files are project-agnostic and can be used for almost any project of yours. Let's see what do directories and file source codes mean:
build/ is where Truffle will put our compiled contracts.
chain/ is where the data directory and all the blockchain files will live. You will need it only when using geth as the blockchain client.
scripts/ is where we later will put various utility scripts.
test/ is where we will keep our files for automated testing.
contracts/ is where the Solidity source code will live for all our contracts. The only contract so far is the required but project-agnostic Migrations.sol that Truffle is using to store the migration state for your project-specific contracts.
migrations/ is where we need to put deployment scripts for all contracts. Please, keep in mind that scripts have to be named as they are executed in numerical order and the first script in a list must be the required but project-agnostic 1_initial_migration.js which migrates Migrations.sol to the blockchain. Your project-specific deployment scripts must be named 2_example.js, 3_example.js etc. Luckily, the format of deployment script is quite easy to understand.
genesis.json contain information required to create the very first block in the blockchain known as the coinbase. This is only required when using geth as the blockchain client. The file itself contains information about the initial mining difficulty, transaction gas limits, etc.
truffle.js contain basic configuration for the Truffle framework to connect to your blockchain.
Now when you are done with the basic DApp project structure, you can proceed to the next stage and create your very first, and very own smart contract.
In Ethereum, smart contracts are written in Solidity. To get more details about that language, feel free to check out the Solidity documentation.
As for your smart contract, try to make as simple as possible. Let it perform simple actions including adding transactions, getting the address of the trustee, etc.
It's worth noting that Solidity is a strictly typed language; it's quite easy and comfy to read. Still, there are few key points you need to keep in mind:
- State variables hold the data stored on the blockchain.
- The global variable msg contains metadata about the current messages sent to the contract (e.g. sender’s address).
- The constructor is only executed once when the contract is first deployed/created on the blockchain.
- Constant functions promise to not change the state of the blockchain, which means you can call these for free without having to pay transaction gas.
- Modifiers are bits of code that are executed before the modified function. These are often used for access checks. The _; syntax is where the execution of the modified function continues.
Running smart contract tests is also important. With this in mind, please refrain from creating tests you're not going to run. Instead, feel free to perform testing in order to check your project structure and the first contracts. Run them all!
In spite of the fact that Ethereum stands for the Web 3.0 Internet, it can work (and actually works) with Web 2.0 tools and protocols where it makes sense. If so, you DApp needs an user interface.
Now, to check if everything is OK with your decentralized app, follow these steps:
- Install the Mist browser.
- Start a blockchain (don’t forget to start a miner).
- Create and migrate smart contracts to your new blockchain.
- Install all UI dependencies and start a local web server in order to host our DApp. The local web server is provided by the package defined in the repo root.
- In a new window of the Mist browser try to connect to the local blockchain.
- Enjoy your very own DApp!