Decentralized application’s development

Note:
The article was prepared in the autumn of 2017, since that time technologies may have changed.

ETH (Ether) – tokens, the main cryptocurrency is represented by ethereum, it can be transferred in transactions, and it is the payment for mining of a new block.

GAS – the payment unit for performing operations in a blockchain. Has an equivalent in eth.

DApp – a decentralized application.

This document describes experience and practices gained during the development of a decentralized platform for managing and storing solutions of organizations.

Let’s consider a usual application, such as “Notes.” A user makes notes and the application saves them in the computer’s memory on HDD. An HDD is a device, and, as anything in this world, it might wear out or break down. It means that in case if something happens or at the end of HDD useful life, we will lose all our notes, which could contain valuable information. A viable option would be a transfer to a client-server application, for example, to the web application “Notes”. Using it, we will take notes in the browser and upload them to a remote server. In this case, we shift responsibility for storing information to a third-party server, which stores information, just like our computer. But what if the server owner denies access or the server crashes?

We will lose our information again. Centralization is the main problem of these approaches. Using DApp, more specifically, using blockchain technology in the applications can solve this problem.

DApp, as well as the classic web application, has frontend and backend parts. Its distinctive feature is the usage of blockchain instead of a centralized remote server, that is, as a backend.

Decentralization is its main feature and advantage. A blockchain, by definition, is a chain of blocks with information, for example, our notes. In Ethereum blockchain, each participant of the network has a copy of the chain of blocks with information independently of each other. This means that all HDDs of all network members should be destroyed or disabled to lose the information. Ethereum blockchain network contains thousands of participants, and it is rapidly expanding, which reduces the possibility of losing information to a critical minimum.

A blockchain is a chain of blocks. A block is a structure with its hash, the hash of the previous block for communication and a list of transactions.

The blockchain user receives a unique address to identify himself in transactions and a private key to confirm his transactions. The private key is a randomly selected positive integer. The private key is converted into a public key by a hash algorithm, and the public key is converted into a unique address.

A transaction is a transfer of cryptocurrency from one address to another. For example, this transaction transfers 0.41 Ether:

Block with the given transaction:

The hashing algorithm used by Ethereum is called ethash. It hashes the metadata of the last block in the system (transactions and hash of the previous block) using a special code called nonce: a random binary number (generates the ethereum algorithm), which sets the unique value of the hash function. For each new block in the blockchain, the network sets the target hash value (it is set after the new block is filled with transactions), and all the network miners try to guess the value of nonce, which will lead to this value.

The principles of cryptography which underlie such hashing make random selection of nonce practically impossible. It means that the only way to find the right nonce is to cyclical movement through the entire range of possible solutions until the correct one is found. In this case, the solution can serve as a “proof of work”, that means the computer which has found the correct nonce value should actually perform the work, i.e., use the processing power to run the hashing algorithm.

The first block of blockсhain is zero and has no parent’s hash, while the rest of the blocks are added to the block system after the hashes are calculated by the miners.

The chain of blocks is distributed across all nodes of the network. A node is any equal participant of the network that has a fully loaded blockchain on his computer. This feature provides decentralization, since the network is not tied to one server, it lives while at least one node is present.

Hashes in blocks provide security and reliability of stored information. If an attacker in the transaction assigns to himself an extra ether, then the blockchain algorithm will figure the mismatch (as the previous transactions are known) and cancel the transaction. It is also impossible to change existing transactions, since hashes of all transactions and hashes of past blocks participated in creating the hash of the block and blockchain is synchronized to the reliable state. Otherwise, the attacker has to count the hash of the whole blockchain, that is unreal.

A smart contract is a program code that stores its logic and state in the blockchain.

Smart contracts in Ethereum are presented in the form of classes that can be implemented in different languages, including visual programming, and compiled into the byte code for the Ethereum Virtual Machine (EVM) before being sent to the blockchain. State changing of the virtual machine can be written in a full Turing scripting language, that is, comparable to most popular programming languages.

Unlike the script language in the bitcoin protocol, EVM supports cycles, so the platform uses a mechanism called “gas” to limit contracts that can take a long time to complete. That is the commission is taken from the caller for calculations in the form of gas, which is converted into ether and depends on the complexity of the call (complexity depends on the degree of change in the contract state, that is, the call while (true) {2 + 2} does not cost anything for the blockchain).

In this case, there can be created a contract that would recover costs, but such method has some disadvantages.

Let’s consider a simple contract:

This contract is written in JavaScript like language Solidity. The language is chosen because of the active support of the community and developers.

In the contract above, while calling the greet method with the parameter, a line is output. The code on Solidity does not have any radical features compared to JavaScript. The property msg.sender is really important, since it returns the address of the calling method, which in turn allows restricting access to the method. Require and assert functions in new versions of Solidity are analogous to the if throw statement.

Let’s move on to the arrangement of smart contracts in blockchain. For access to the contract from blockchain, it should be deployed. In this case, the contract deploy is a usual transaction given below, it also should be ‘mined’ in the block (to calculate the hash of this transaction and others in the block using ethash algorithm).

“To” line displays the address that executes Deploy of the contract, and ‘From’ line displays the address of the contract itself. InputData field contains the contract code in the form of a hexadecimal byte code. The contract code can be viewed by anyone, so storing secret data in the code is not the best practice.

Calling the method for changing a status of a contract is formed as a transaction in the blockchain. For example:

Everything is the same with the deploy.

The main environment for сontracts development in Solidity is Remix IDE. The application is quite elementary, below we only note the modes of working with Ethereum (Environment point).

• JavaScript VM – JavaScript is a real blockchain emulator.
• Injected Web3 – required to connect to the Web3 module on the page. Works with Metamask (addition to Chrome, allows you to access the block without downloading the block itself).
• Web3 Provider – connection to the custom blockroom.

Remix IDE has the ability to work directly with local files, which is quite convenient. To do this, you need to install Remixd:
npm install -g remixd

Then perform the following:

remixd -S <the path to the shared folder for Remix IDE>

Click the icon link, and everything should work. Installing .NET SDK 2005 might be required, during Remixd setting.

Then, select the blockchain for contracts testing. Currently, the private blockchain can be started, but this option is quite time-consuming because of setting and necessity of permanent mining, and it is also inconvenient for rapid testing. As an option, a public test blockchain can be applied, for example, Ropsten. Its difference from the main one is that ether can be got for free, although the speed of confirming transactions is not very high.

Working with contracts is possible while the whole blockchain is fully downloaded. Parity application suits well for such a case. It allows convenient synchronizing with any network and working with contracts and transactions.

In the example, Metamask is used as a wallet, node (a fully synchronized blockchain on metamask server), and Web3 provider. Metamask is just an add-on to Chrome and nothing more. This add-on provides access to remote synchronized blockchains from metamask servers (Parity downloads the blockchain to the computer containing it), it allows refusing downloading. And it also implements Web3 JavaScript module configured for the Metamask server in every page, on which the add-on is run. This allows communicating with js-applications with contracts in the blockchain and relieves from the necessity to configure the connection. Metamask is a simple wallet with a history of transactions and an account manager.

Let’s consider Metamask activity diagram:

In a classical way, you need to download the Ethereum client and synchronize the entire blockchain to the local computer, in fact, it becomes the node. This can take a significant place on the HDD and spend network resources on synchronization with the network. In addition, in DApp Web3.js should be manually plugged in and configured for the necessary node.

>Metamask can solve these problems and greatly facilitate the work with Ethereum network blockchain. Metamask is an extension for a browser, a “bridge” between the browser and Ethereum blockchain. When working with the main and test blockchain, Metamask provides access to its remote nodes, which eliminates the need to download the entire chain of blocks of the required blockchain. Another feature of Metamask is the automatic injection of Web3js object into all web pages. This object is already configured for the network and account that are selected in the extension interface.

Install Metamask in the browser from the official site and start configuration in the extension interface.

First, select the right blockchain. In addition to the main block, a test one can also be selected, or connect to any client network via IP directly.
Ropsten Test Net is necessary.

Next, we need to create an account in Ropsten network. To do this, click on the account change button and select Create Account. After that, select the created account in the list.

In the account context menu, Ethereum address can be copied and got.

But for the transaction fee, gas is needed, it is converted to ETH, and there is 0 of it on the new account. The main advantage of Ropsten is that we can get free eth. To do this, click Buy button and select service. At the opened page, request Eth and wait until the transaction is confirmed.

After performing all operations, you get a fully customized environment for working with DApp.

Truffle is a framework for working with smart contracts Ethereum. Its main features:

• contracts testing
• contracts compilation
• smart contracts deploy through migration.

To install truffle, run the following command:
npm install -g truffle

To initialize truffle run truffle init in the directory with the framework:
For further work, create .sol files with contracts in the contracts folder.

Then, compile contracts by truffle compile command. This command creates in the build folder files with the necessary information for deploying contracts.

For contracts deploying customize migration files in accordance with our contracts. Migrations in truffle represent js files, in which 4 script for contract deploying is describe of contracts in various ways. In case there are several migrations, they are executed sequentially.

Consider the simplest migration for one contract deploying:

In this case, MyContract is loaded and with the help of the deployer module it is executed in the block, the settings of which are in the file truffle.js (root).

Trigger migrations start the migration.

Unit testing of contracts is implemented in both JavaScript and Solidity. JavaScript-testing works on the basis of Mocha framework.

More details on working with Truffle.

This framework is in beta testing.

Uport can be a replacement for Metamask on a real project. At the same time, uport is conceptually different.

Uport service is completely decentralized. That is, data storage and logic are concentrated in smart contracts.

Uport operating algorithm:

1. Users should install the mobile application Uport to their smartphones and register in the system. Then they get their ID in the system and the address in blockchain.
2. If necessary, the application (smart contract) can be registered in the system. After that, you get the identifier and the application keys (they are tied only to the uport).
3. The developer uses Uport while developing the library and builds the application under a specific template:
   • When entering the application, the user should provide the qr-code for obligatory scanning. The user scans it using the uport application on the smartphone. The application, based on the recognized URI qr-code, sends its identifier to the application. The application identifies the user (gets his address).
   • Whenever you initiate a transaction on the client, a confirmation window pops up in the application. Only after confirming in the application, the transaction will be signed by the user’s key and executed.

Mist is an official Dapp web browser. It has an integrated Ethereum wallet, and this differs it from other usual browsers. It allows managing accounts and create simple transactions for sending Ethereum, to deploy contracts. In fact, Mist is a regular browser with built-in Metamask, but also Mist downloads the whole blockchain to disk, and does not use remote nodes like Metamask does.

One of the blockchain work peculiarities is the duplication of blocks with transactions, in which contracts and their state are stored on each node. This means that if there is a huge system that manipulates complex data structures, a huge amount of “gas” will be spent for performing actions on data in contracts, and storing on the PC unnecessary for the client data.

The best solution might be a regular database (MySql, Oracle, etc.), and then the only id of the necessary record can be stored in the smart contract. But what is the benefit of blockchain if there is a dependence on a centralized database? But if the database fails, the entire system would be meaningless, because one Id means nothing without a database.

IPFS is a content-addressable storage, peer-to-peer, hypermedia communication protocol.

Despite the definition above, IPFS should be considered as a kind of file system. In this file system, the files are addressed by content, not by name. In IPFS you refer to the file by its hash, which is estimated by its contents. So if the file and its hash are changed, it will be considered as a new file in IPFS file system. This property is a bit like GIT and saving file versions can be organized with the help of IPFS.

Let’s consider the decentralization of IPFS. It is similar to BitTorrent. We download a file via IPFS client, obtain its hash, and then it gets into our local cache (/UserName/.ipfs). When another user needs our file, we pass him hash, and then he makes an http request to localhost: 5001/ipfs/[hash of the required file] (if we want to work with a local client). The system is searching for this file, and the IPFS network member, from where this file can be downloaded. Since this file is only available or us and we are online, the second client can download this file and automatically upload it to its cache.

The next client can request a file from our hash and get it, for example, from the second client, and the first client for this operation no longer needs to be online.

Similar to BitTorrent, we put the file on the network, that is, “distribute” it from our computer, and other users download it and, while being an equal participant in the network, distribute it in a similar way, providing a decentralized file exchange.

Advantages of IPFS:

• decentralization
• addressing by content: we are sure that the file will not change according to the specified hash (collisions possibility is extremely small)
• no special resource required (the amount of space on the disk depends on the adjustable size of the cache)
• access speed: the client from which we download our files may be very close to us or we have a cache (the ability to work offline), whereas the
• source can be located in a place with a long network response or be offline at all
• a great solution for hosting frontend DAPP

Disadvantages of IPFS:

• immutability: files can not be deleted or changed. Any file can be lost if it is forgotten or it is not stored by anyone in the cache.
• decentralization degree depends on the number of downloaded and distributing the file at the moment. In fact, this means that if our application is not used online or it is not used for a long time, it can partially or completely lose the data that was downloaded from the source. Therefore, mass products are the main purpose of IPFS.
• the absence of a browser with IPFS support, the necessity to install a separate client.

Each user should have an IPFS client to work directly with it. The client is a console application, the first time we start it we need to initialize the cache folder with ipfs init command. After that we can work via the console or via web-gui by running the ipfs daemon command and going to http://localhost:8080/webui

The specified library, which communicates with an IPFS client via the RPC-API is used for developing frontend applications with IPFS.

An interesting feature is the addition of a whole folder. This allows laying out sites in a decentralized network in a very easy way. To do this, use ipfs add -r [path to the folder] command and get the following result:

All files in the folder will be automatically downloaded into the system, and a hash of the folder will be located in the last line. Now you can access the file in the folder with the known hash by using the following http request:
localhost:8080/ipfs//QmYHa9yW5yWRqFhkg7cq6foWcu8HN3RK5pqF2Uj5APGfnQ

setup.ini

One of the features of IPFS is IPNS system. It adds a bit of variability to IPFS. The idea is to get ipfs hash by peer id (an individual client), which can be dynamically changed. Meanwhile, users know only your IPNS identifier (a peer ID) and by accessing it they get an ipfs cache that can be dynamically changed. This feature is used for hosting dynamic websites.

Let’s highlight the most important architectural moments in the construction of DApp on the base of Ethereum blockchain:

1. There should be no centralized modules in the application. Since the work of decentralized modules fails after leaving the network, for example, a database or file hosting.
2. The application should be maximum self-contained and equal in the network. That is, when the application is running in a new network, it should recreate the necessary environment by itself. At the same time, it’s bad form to create application-administrators, on which other participants depend.

So, there are two possible architectures for building DApp based on the blockchain Ethereum:

1. Web application on public blockchain

This type of architecture is the most common at the moment, as it is easy to develop and fully suitable for public services.

The architecture can be presented as following:

DApp browser is at the beginning of the chain. At the moment, such a browser is Mist and a browser with the addition of Metamask (Chrome and FireFox). The main task of such browsers is to provide an interface for working with accounts and to implement a Web3 object that is configured for the selected network. But this functionality can be also implemented on the usual browser.

Next comes the Web application, which uses Web3js. Web3js allows using RPC to work with the blockchain node at the specified host. In most cases, such applications are located in general or test blockchain, in order to be available everywhere.

The disadvantage of this approach is the work process via general and private blockchain. In the case of a general one, we will have to pay for transactions in real currency. On the test unit there is great transaction confirmation time. Also, a disadvantage is the lack of privacy at work, as transactions are visible on the Internet.

2. A self-contained application on private blockchain

Let’s consider the architecture diagram:

This approach includes a private blockchain. That is a blockchain created only for our network. That means that we centralize it within the network of the organization. A private network has the following advantages:

• blockchain privacy: only network members can work with blockchain.
• speed of creating blocks is high due to network size
• low transaction cost

The disadvantage is weak decentralization, compared to the public blockbuster. The local network is more likely to fail than the Internet.

Then specify the client. It will represent a self-contained desktop application that will install geth and ipfs client if necessary, and will configure everything. This will save the end user from configuring the environment manually.

The application will be developed on Angular. Electron is used to wrap a web application in the desktop form (it becomes a normal window application).

For special reliability, the interaction between the client and blockchain is implemented using IPC technology. It allows communicating directly between the client process and geth (Ethereum implementation on Go), which excludes outside interference.

In this architecture, using ipfs is in doubt. Since we can afford to store the entire blockchain, because it contains the organization’s transactions only. But IPFS is necessary for storing such files as pictures, documents and so on. Then, it would be nice to make IPFS local. It’s possible. To do this, conduct a research to find out the details.

There is one problem in implementing this architecture: Web3Js developers removed API support for working with accounts in order to protect users. In their opinion, Mist and Metamask should be used for working with accounts, which is contrary to the architecture above.

Possible solutions to this problem:

1. Сustomize Web3Js library.
2. Use web3_ipc library to manage accounts jointly with Web3Js09-

Option number 2 is less time-consuming.

Within this architecture, the problem of the end user abstracting from work with addresses and private keys of blockchain was solved, as well as classical registration and login were presented. The essence of the solution is to separate the user’s accounting data and address. For example, if a user loses access to his computer with this program in it, the new computer will create a new login and when his accounting data are confirmed in the smart contract, the old address in the contract will be replaced with a new one. Thus, the new address will receive the user’s privileges and the old one will become useless and attackers will not be able to use it.

The contract, handling a problem can be like:

In addition, the application should create all the necessary contracts (if they are not available) and, if technology allows, initialize the private blockchain (if it is not found). This provides a true decentralization.