How to write a decentralized application for Ethereum - Part 1: the smart contract

The possibilities offered by the blockchain in terms of security, transparency and trust are now recognized by everyone, including the most general media. But where Ethereum brings a new dimension, it is in what it offers to integrate in the blockchain not only data (monetary transactions, document timestamps ...) but also programs, whose execution can be controlled and certified in the same way as a Bitcoin transaction.

As a developer, when I discovered Ethereum and understood the possibilities offered by smart contracts (read the article "Smart contract", where the self-executing contract), my new obsession was to understand how it worked technically , and how to create my own decentralized application.

This series of articles will be devoted to the writing of a fully decentralized application taking advantage of the possibilities of Ethereum. It is aimed more specifically at developers (especially the web, but not necessarily) who wish to discover the possibilities offered by Ethereum. I chose to base these articles on a concrete example of application, in this case a roulette game (extremely simplified) of those found in casinos.

But before starting to write our application, let's first see how a decentralized Ethereum application is organized, and how will the following organization be organized.

Constitution of a dApp

A decentralized application (also called dApp) is usually accessible from a website. Nothing very new here will you say, this is what is done in the web since its inception. What is new, however, is that this web application connects not to a centralized server (web server) but directly to the Ethereum blockchain. This connection is made by connecting via an API to an application running on the user's computer: his wallet.

In other words, on a classic (modern) web application:

the user connects to a web server that returns the interface to display in the browser (front-end part);
the interface connects to an API (back-end part) by sending data to it, which in turn sends back other data.
The application works in centralized mode, in the sense that a priori all users connect to the same web server, and therefore trust this server. A priori can not verify that the centralized web server processes the data as promised. Moreover if the server falls (hacking, closing the company ...), all data is potentially lost.

In the case of a decentralized application on the other hand:

the user connects to a web server that returns the interface to display in the browser (front-end part, so far no change);
the interface connects to the user's local wallet via an API (web3, we'll see this later) by creating a contract or calling a method of a specific contract;
the portfolio executes the contract in the blockchain, then returns the result to the front-end.
If we make the analogy with a classic web application, we can say that the role of back-end is provided by the local wallet, which connects to the blockchain. No more centralized server concept so, if not the one that serves the web interface. But this web interface can after all be integrated within a desktop application for example.

The development stages of our dApp

As this series of articles progresses, we will implement a decentralized end-to-end application:

write the contract: this will be the application base of our roulette game, which will be distributed in the blockchain;
deploy the contract in a "local blockchain", and test it through the browser console;
write a web interface to create a game of roulette on the one hand, and to play on the other hand;
Deploy the contract in the actual blockchain, and make the web application available for others to play.
Warning: An Ethereum contract may contain significant security flaws, especially since the technology is very young. This is all the more risky as we indirectly manipulate money (Ether, exchangeable for euros). The game developed in this series of articles is for purely educational purposes; in any case I do not recommend deploying in Ethereum's blockchain contract (let alone a gambling game) without having taken all the necessary precautions in terms of auditing the code by a security expert.

Development tools needed

In order to develop a dApp, no need to install a heavy tool artillery, the environment remains quite light. Two tools are to be installed at first:

Truffle: this is a small development suite created by ConsenSys including the necessary pto easily compile a contract, deploy it in the blockchain, and generate a dApp skeleton to access it; Test RPC: a small client to simulate a local wallet connected to a local blockchain also; ideal for testing 🙂Note that the installation of these tools requires the prior installation of Node.js. Once these tools are installed, it is time to move to the first step of the development of our application: the contract. Write the smart contract for Ethereum Let's get down to business with the writing of the contract; but not too fast, let's take a few minutes to specify the expected behavior of our contract in the context of our roulette application.Functional specifications of the contractTechnically, Ethereum contracts are stored in the blockchain as assembled binary code similar to the machine code executed by our computers. But of course there is a higher level language for writing contracts: Solidity. Halfway between C and JavaScript, it will not disappoint you if you are used to widespread programming languages.RouletteLicence CC-BY-2.0 (Source) Let's start by defining the expected behavior of our contract. The goal is to manage a simplified roulette game. The principle is as follows: at regular intervals, a random number is chosen between 0 and 36. Before that the players have the choice to bet: either on a number (between 0 and 36 therefore): the player wins 35 times his bet if this number falls, either on the "pair" box: the player wins twice his wager if an even and different number of 0 falls, or on the "odd" basis: the player wins twice his wager if an odd number falls. The roulette game also includes the possibility of wagering "on horseback" on two or four numbers, on lines, columns, etc. but we will stick to these three possibilities for the moment.Our contract will have to: be created with as parameter the time interval between two rounds, receive the bets of the players: each one consists of a type (simple single number , even or odd odd), the number if any, and the amount bet, when the time is up, choose a random number between 0 and 36, and pay the winning players.Nothing very complicated, but some points deserve some details. First of all the players' bets and the payment of the winners will be done directly thanks to the Ether included in the transactions. It would have been possible to use a custom cryptocurrency as it is quite easy to implement with Ethereum, but it is interesting to present the integration of Ether in a contract.Second point: it is not possible to natively program call to a method of a contract. A user or another contract must necessarily call him. This is why our contract will give everyone the opportunity to "spin" the roulette wheel and trigger payments to winners, as long as the interval between two rounds has elapsed. Thus everyone knows that his bets will not be blocked because the roulette has not been launched. Last point: it is also not possible to draw a random number in an Ethereum contract. Indeed, the very principle of the blockchain wants that the final result of the execution is the same whatever the node having carried out the execution. To simulate this draw, we will use the hash of the last block received before execution. Theoretically it is therefore possible to "manipulate" the draw, but it is difficult and expensive; and to secure more, we can always use the last 2, 3 ... n blocks. Note that some checks will be made for each bet requested: it will be necessary that the transaction includes Ether (the amount of the bet); that the bank has enough reserves to pay the players on the assumption that all will win; in other words, the address of the contract must have enough Ether to pay all the bets accumulated since the last turn if they prove to be winners. Our contract is specified, it is now time to write it .