Writing Distributed Application for Ethereum

In past article I’ve written about some basic stuff we can do with Ethereum client Parity – like transfering Ethers, creating multi-signature wallet and even writing our own contracts. Now I’ll continue with writing our very own Distributed Application ( Dapp).

What is Dapp?

In my understanding Distributed Application  is combination of contract(s) deployed in Ethereum blockchain and browser based UI that enables easy interaction with contracts. Some of application logic that is  normally hosted in server,  is in Smart Contracts in the distributed system – Ethereum – so that why they are called distributed. System is shown on following picture:
dapp-schema

So Dapp consists of two parts – browser client, written in Javasript and Smart Contract(s), written in Solidity (or other Ethereum language). Browser calls contract(s) via JSON-RPC  (interface is standardized across Ethereum browsers, so Dapp browser part can theoretically work with any client). Though we can call directly JSON-RPC methods from general JavaScript, it’s much easier to use existing library web3.js, which provides convenient objects and methods.

Our Dapp – Name Registry

For our demo Dapp we use contract from previous article, but improved slightly by adding event to notify about new name registration:

For UI part we  use Aurelia (as I have played with Aurelia framework before, so this is good opportunity to refresh  knowledge), Bootstrap 3  and web3.js for communication with Ethereum client. The resulting code is here in github.

When creating this simple Dapp following two things showed as tricky:

  • Web application packing –  as several times before correct packing of web application was problematic. Finally web3.js worked correctly with webpack bundled application generated with Aurelia CLI and using recent version (3.5) of webpack.
  • Web3.js version –  initially I started with latest beta version (1.0), but it does not seem to be ready yet, documentation is brief and I was missing some functionality or it was not working properly, so I finally used stable version 0.20.  This is a pity, because 1.0.0 has much modern interface, using Promises etc.

The core ES6 class for interaction with Registry contract is client.js:

Client must know address of the contract  (contractAddress) and its interface (contractABI).  As I do prefer to work with promises rather then callbacks, there is an utility function toPromise that converts callback to promise.

Two functions, important for user interface, are query, which queries the registry, and register, which registers new name. Of these two later is more interesting  – the interaction with blockchain is done in 3 steps:

  1. Call is evaluated locally with web3.eth.estimateGas –  it executes contract method in local EVM.  More important then knowing consumed gas is the fact that call executes without problems.  If we do not check this now, we can easily send transactions that will fail ( for instance trying to register already registered name), but even such transactions are sent out and included in blockchain. This early check prevents such problems.
  2. Send out signed transaction – this step requires cooperation of Parity wallet, were transaction has to be signed.
  3. Get notification that transaction was included in the blockchain. Method web3.eth.getTransactionReceipt can return null, if there are not enough new blocks confirming our transaction ( to be reasonably sure that transaction is not in the orphaned block), so we have to try several times until receipt is available.

Method addListener enables to listen to Register events and update application about recently registered names.

Apart of the code above rest of the application is usual Aurelia UI stuff.   Finally application looks like this:
dapp1

And here is screen for querying registry:
dapp2

Other tutorials

You can check for instance this Parity Dapp tutorial – which is focused particularly on Parity’s special libraries integrating with React. I went through it (with some issues, partly related again to web application packaging) and it’s really nice. Parity libraries provides cool reactive components – like TransactButton button, which visualizes transactions steps. Such components can significantly speed up and simplify application development.

Conclusion

We only scratched surface of distributed applications development, real applications are indeed much more complex, with numerous cooperating contracts in blockchain, dynamically created contracts etc.  But it’s first step and it’s not very difficult – web part is basically regular web app development with one additional library – web3.js and few gotchas – especially around sending transactions out.  Smarts contracts language Solidity is also relatively easy to comprehend, but as we’ve shown in previous articles it can be deceiving and one can make fatal errors, which make distributed application vulnerable. Security review of contracts based of solid understanding of Ethereum blockchain is a must for real applications.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">