Part Three—Solving Real-World Problems with Blockchain
By: Jim Boone
Tags: Blockchain, Ethereum, P2p Payments, Problem Solving, Fintech

In my last post, I described the characteristics of a distributed payments alias directory application that leverages blockchain’s features, wrote a simple contract to manage the directory, and showed one way to test and debug the contract.

The blog series wraps up here by deploying the contract to a private blockchain environment running the Ethereum blockchain client, Geth. Finally, I will offer a few observations of the lessons learned while creating a contract-based application that runs on top of an Ethereum blockchain.

Setting up a Private Ethereum Blockchain Network

Now that we have an alias directory contract, we need a real blockchain network to deploy it to. There are several public Ethereum development blockchain networks that we could deploy to, but I will instead set up a private network to emulate what a consortium of financial institutions would have to do to participate in the alias directory blockchain network. By doing so, we can examine some of the common components of the blockchain and how they are created.

We will create a blockchain network with four nodes as shown below:

The Admin node represents the organization that will deploy the contract and will authorize Financial Institutions (FIs) who manage user accounts to write to the directory. Two other nodes represent FIs, and the third represents a participant node that can read the directory, but cannot write to it.

To host a node and participate in an Ethereum blockchain, we will need to install an Ethereum client. There are several clients available that are written in various programming languages. I chose Geth, which is written in Google’s Go language and is available for easy installation via Homebrew on my Mac.

Genesis Block

The genesis block is the very first block in a blockchain — block 0. It is the only block that does not have a predecessor block and represents the entry point into the blockchain database. The genesis block for our network is shown below:

The genesis block isn’t all that exciting. You can read more about what each parameter represents here. You can make it very easy to mine blocks initially in a private blockchain network by lowering the difficulty (the lower the difficulty, the fewer calculations a miner must perform to validate a block). Then, eliminate the problem of running out of gas during any transaction by setting the gasLimit very high (gasLimit is the maximum amount of ether that can be consumed to solve for a block). This helps nodes earn enough ether to execute other operations that modify the database (e.g. add aliases).

Continuous Block Generation

One detail that many people don’t realize is that blockchain networks are designed to generate new blocks periodically — kind of like a heartbeat — even if there are no transactions to validate. Public Ethereum blockchain networks generate a new block every 15 seconds, on average, by design. This frequency is maintained by the network participants by periodically adjusting the difficulty parameter we saw in the genesis block. There are valid reasons for doing this (e.g., additional mined blocks results in greater security), but one of the side effects is that the chain is always growing and nodes are always exchanging information with each other. In other words, blockchain nodes are always consuming computing resources, the blockchain database is always growing, and there is always network chatter between network nodes. The Proof of Work consensus algorithm is clearly not eco-friendly in terms of computing resource consumption.

Create a Private Blockchain Network

The Geth client allows us to create our own blockchain network, or find and connect to an existing network. To do this, there are a multitude of command line arguments that must be set when the Geth command is executed. Consequently, the only practical way to repeatedly launch the client is to do so is by using a script.

For convenience, a script was created to set up and launch each node in our private network. The script logically performs the following actions which are necessary to create each node in the network described above:

Create the blockchain database

Create a user account

Start the node

Unlock the user account

When running all nodes on the same computer, we are required to give each node a unique identity, remote procedure call (RPC) server port number, database directory, and log file name. These prerequisites are reflected in the script. No such constraints are required when running a single node on a computer.

The following is a listing of the Python script used to create the blockchain network:

The following output shows the result of running the script to create and start the first node in the network. The output for all other nodes is similar.

A quick check of the process table shows that all nodes are up and running.

Now we will check to see if the nodes are connected to each other. Once again, we can use the geth client to connect to our running node via RPC. It is very easy to attach to a node and launch a JavaScript console using the geth attach http://localhost:8101 command. Unfortunately, when we query for connected nodes, we find that there are none (empty JavaScript array []). What is going on?

Blockchain Network Node Discovery

Ethereum includes a discovery algorithm that facilitates the discovery of all nodes on a public network. This algorithm, however, may not be useful for configuring a private blockchain network since the network nodes might be behind a corporate firewall and/or listening on non-standard ports. For the latter reason, automatic node discovery is disabled for our private network.

Ethereum provides a way to seed the node discovery process using what is called a bootnode file which lists all communication information necessary for each node in the network to connect with all other nodes. The following is an example of the static-nodes.json bootnode file used to find other members of the blockchain network:

This file was created by running the bash script shown below. The script must be executed while all nodes are running since we are querying the admin.nodeInfo.enode JavaScript object property to extract the enode value for each node. The enode is basically a URI used by the discovery algorithm to connect to another node.

Once the static-nodes.json file is created, it must be copied into the data directory of each node, and each node must be recycled to pick up the enode information to connect to the other network members. Now, when we query each node to find how many peers they are connected to, we see that all of them are now connected thanks to the static-nodes.json file.

It looks like the private block chain is almost ready for us to deploy our contact. The only thing left to do is to earn a bit of gas money so we can deploy the contract and execute methods on it. Fortunately for us, it is free and super easy to send our miners to work to earn enough Ether. Just for good measure, we will send the miners of each node out to solve a few math problems and earn gas money doing it. After 10 blocks each have been mined, they can rest as shown below.

Deploy the Payment Directory Contract

We will once again leverage the Truffle framework to help us deploy our contract. If you read my previous blog post, you might recall that we used Truffle to deploy the contract to the testrpc network during testing. Truffle makes it easy to deploy contracts to any blockchain network, but you need to configure it to connect to the network, and what account you want to use to deploy it with.

Since the account belonging to Node 0 represents our administrator, he will have to pick up the deployment gas tab. The following networks addition is made to the truffle.js configuration file where our network-specific values are added.

Truffle is now used to deploy the contract. For the deployment to be successful, you must first ensure that miners are running on a few nodes since the deployment represents a state change to the blockchain database. We all know that deployment will create a transaction that must be mined before it is committed to the blockchain.

The output below shows a successful deployment of the contract to the blockchain. Be sure to record the address of the contract because it may be required by each node to connect to it.

Connect to Contract

There are many ways to connect to an Ethereum contract and execute contract functions — custom DApp, Geth console, Ethereum/Mist Wallet, etc. I will use the Ethereum Wallet application to connect to a blockchain node and execute contract commands. By default, the application will connect to the public Ethereum network and/or public test network. You can, however, connect to a private Ethereum node by targeting the RPC interface of the node. One way to do this on a Mac is to use the Automator application to specify command line arguments for launching the Ethereum Wallet (see below), or simply launch the Wallet application from a command line prompt with the –rpc flag.

Once the application launches, the Ethereum Wallet main user interface is displayed. The interface shows statistics for our blockchain such as the number of blocks in the chain (65), number of peer nodes connected (3), and ether balance for the main account (etherbase).

We can select the “Contracts” link, the select the “Watch Contract” link to view the contract within the wallet application. However, before we can watch the contract, we must connect to it. We will need to know the address of the contract as well as the JSON representation of the Application Binary Interface (ABI) to connect to it. The contract deplorer output listing will have this information. Each participant will need to connect to the contract using the address. The following dialog is displayed that lets you enter the contract name, address, and JSON ABI:

Once connected, the contract is displayed in the contact tab of the wallet.

Click on the contract link and the Ethereum/Mist wallet will display the functions that read from the contract (function calls) and write to the contract (transaction calls) using the ABI-RPC information provided while connecting to the contract (see figure below).

Executing read-only functions do not cost any gas, but executing any function that writes to the contract charges gas money. The client will require the user to confirm their password, then creates a transaction to submit the request to the blockchain. For example, prior to adding the alias fred.smith@yahoo.com to the directory, the dialog below shows an approximation of the amount of gas it will cost me to do so.

Once the transaction has been mined, we can execute the Get Alias read function in the Ethereum wallet to view the details of fred.smith@yahoo.com alias (results shown below).

The Ethereum/Mist Wallet also allows us to watch events that are generated by the contract. From the screenshot below, you can see that two authorized banks and three aliases have been added to the alias directory.

The Ethereum Wallet is a simple way to connect to the blockchain node and view information about the blockchain and contracts deployed to it. A custom web application could also be developed, but the wallet application is sufficient to illustrate the type of information and operations that are available from the RPC interface.

Final Thoughts

As I progressed through this blog series, I started to think that perhaps I didn’t choose the right tool for the job. Blockchains were created to solve the problem of decentralized consensus, and yet I have introduced an administrator node to deploy the contract and authorize only certain nodes to update the directory. Doesn’t that defeat a primary benefit of a blockchain which is no central authority? In this use case, we needed a mediator to ensure that only certain organizations could write to the directory. Also, new blocks are created and work is performed continuously, even if there is no reason to so. CPU cycles and disk space are consumed unceasingly. This is equivalent to leaving your car idling perpetually when you are not driving it. Why should we implement our distributed directory on technology that is inherently inefficient?

Finally, I couldn’t help but think about practical limitations to the Ethereum blockchain implementation, such as relatively slow database commit rates (i.e. mining rate), difficulty modifying contracts, limitations of the Solidity language and EVM, etc. I began to think that perhaps a blockchain is not the best technology to build our distributed payments alias directory on. There are plenty of web and database technologies that could be used to implement an alias directory and do so in a much more efficient and scalable manner.

My time working with Ethereum has demystified blockchain technology, but it has also provided me with some insights that I will reflect upon to close out this blog series. I must caveat my thoughts by admitting that I never thought social media sites like Twitter had any practical value — after all, who cares about what your friend had for lunch or what is on a celebrity’s mind? I clearly underestimated the vicarious nature of people. But I do know that companies ultimately have different motives than individuals. They will not adopt blockchain technology unless there is a competitive advantage to doing so. In fact, investors are pouring billions of dollars into blockchain startups whose objectives are to discover these advantages.

Perhaps blockchain is simply a clever mathematical solution that is looking for the right problems to solve (other than virtual currencies). Given my observation of human ingenuity, I believe that someone will find what those problems are (or tweak the technology until it fits one). Until then, the race is on to find the perfect applications for blockchain technology, or its derivatives, and be the first to introduce them to the marketplace.