Building CRUD Applications on the Blockchain - Part I

With Bitcoin and cryptofinance in the news, blockchain programming has suddenly become very important but most people - including many programmers - do not have a clear idea on how to write a program on the blockchain. This article is not about theoretical concepts like Merkle Trees and SHA256 Hash. It is about how to write an application that creates, reads, updates and deletes a data record from a 'database' on the blockchain. A CRUD application. If you are impressed by Powerpoint slides in Zoom Webinars, you may skip this article, but if you are a programmer -- professionals or hobbyist -- do read on. You will end up writing your first blockchain application without too much sweat.

I first came across Bitcoins as currency in the virtual world of Second Life and wrote about "Bitcoins - my first look at a new currency" in 2013 and then I struggled to wrap my head around this fantastic concept for almost a year until I reached a point where I could write "Bitcoins - as I understood it." While Bitcoin itself was a fascinating concept - an esoteric cocktail of mathematics, programming and economic concepts worthy of a Nobel Prize in Economics - the underlying technology of blockchain was even more fascinating. The incredible potential of this technology became evident with the advent of the Ethereum Virtual Machine and intrigued me enough to explore the concept of the CryptoCorporation, a strange, but successful automatic, manager-less organisation that could create value out of thin air and finally in 2016, I was finally able build my own cryptocoin using Smartcontracts running on the Ethereum blockchain.

Back in 2016, writing blockchain programs were not for the faint-hearted, because there were two big stumbling blocks.

• First, one had to install a whole suite of very complex software -- including wallets -- on the laptop and 
• Second, one had to buy Ether, with credit cards, and use it each time you wanted to run, or even test a program that you had written.

This was frustrating, to say the least. First, if you had to replace or change your computer, there was this great likelihood of not just losing your software stack but also your Ether wallet unless  you had the foresight and the ability  ( which very few had) to keep proper backups. The other huge challenge was the sudden decision of the RBI / Government of India, not too ban cryptocurrency, but to bar banks from allowing people to purchase cryptocurrency using normal, legitimate banking channels like credit cards. Hence while the whole world, including China, raced ahead with blockchain technology, programmers in India were left with no option but to only watch from the sidelines. Fortunately, the Supreme Court has lifted this ban  in March 2020 and blockchain programmers can start work again after losing nearly two years of sitting it out in the wilderness.

image from Forbes.com

But blockchain programming is so very different from 'normal' programming that most programmers have difficulty in wrapping their heads around the  concept. Forget about the concept of smart contracts, even basic stuff like writing, reading and updating a piece of data becomes esoteric because apparently there is no one machine where program resides or executes. It took me quite a while to understand this and once I did, the elegance and beauty of it all took my breath away. Which is why I thought of writing it down, not just for my own clarity but for other programmers who could possibly be in the same boat as well. While I have tried to keep my post as simple as possible, please note that reading beyond this point means that you have some programming experience that goes beyond Excel. An exhaustive manual would be far too long but if you are like me, a hobbyist with a penchant for coding, sit back and enjoy this ride. 

This tutorial is based on two important premises :

1. Only the bare minimum software will be installed on the local laptop, we will use hosted software as much as possible.
2. We will not spend any real money -- as in using credit cards.

Without any further ado, let us start with 

The Big Picture / Architecture

A theoretical and mathematical description of the blockchain is given in this article but for all practical purposes it consists of a network of computers (the MainNet) that run the the full Ethereum node software. All full nodes contain identical copies of two artifacts : (a) a node software application and (b) a huge database file that is called the blockchain. Both the node application and the block chain are kept in continuous sync by constant exchange of messages between nodes, all of which have a peer-to-peer relationship with each other. In addition to the MainNet, there are other private and public chains called Test Nets  with names like Ropsten, Rinkeby, Roerli etc. 

In traditional three-tier client server architecture we have three components. 

• Client software written in, say Python, Javascript, VisualBasic, or in many cases running inside an Internet Browser like Chrome, Mozilla or Edge. This provides the user interface.
•  Application software, written in say, PHP, Ruby, Python that resides within an application server or web server like Apache. This provides the business logic. 
• A persistent data store like MySQL. Obviously the application server (Apache) and the database server (MySQL) may or may not reside in the same physical machine.

Developers build applications by writing both client-side programs (in Javascript, Python) that are hosted in the client machine and server-side program (in PHP, Python etc) that are hosted in the web-server. There is also the case of client side software being stored in the server and downloaded and used inside a browser, but we shall park that aside for the time being. The database engine, MySQL ( or equivalent) is not written but purchased or downloaded and installed on an appropriate machine. If you are a programmer, all this will be very easy for you to understand.

In the blockchain architecture we have a two tier setup

• Client application written in Javascript, Python (there could be others, but I have not used other languages) or running in an Internet Browser. As in traditional client-server architecture, the client software provides the user interface which may or may not be GUI.
• 'Contracts' - a new term used only in the blockchain -- written in a language called Solidity - again a new language used on blockchains -  that holds BOTH business logic AND persistent data.

Since contracts are the new kids in the block, let us look at them a little carefully

• Think of a contract as an instance of a object from the world of Object Oriented programming. This means that the contract has both logic ( as in methods, or functions) and data. But unlike OO objects which can have multiple instances, there is only one instance of a contract. Like OO objects, contracts can inherit properties from other contracts.
• The state of a contract -- as defined by the data that it holds -- can be changed  through a transaction. A transaction can be initiated from a client application either by a human being or some automated process
• A contract is deployed into and resides in the blockchain. Hence it is available on all computers on all networks and all copies are in the same state. Each contract is identified with its own unique address that is generated when a contract is deployed in the blockchain through any node.
• A wallet is special kind of contract that holds a defined quantity of Ether. A transaction can deposit any amount of Ether into a wallet contract but to withdraw the Ether from a wallet contract, one must provide a password ( aka 'the private key') of this specific wallet. So a wallet is a contract defined by its address (similar to a bank account) and its private key (similar to specimen signature in a bank account)
• When a client application connects to any node (through a standard URL) it requests or calls a contract that is now loaded from the blockchain on the node where it resides to the Ethereum Virtual Machine running on the same node. On the EVM, the contract performs the task -- in the process, it may or may not change its state -- and then is put back in its new state back into the blockchain. 
• It is actually a misnomer to say that the state of the contract is changed. The blockchain is immutable, it can be added to but earlier data cannot be changed. When we say that the state of the contract is changed, what we really mean is that the original contract along with all transactions that were supposed to change it are ALL stored in the blockchain. Hence the current state of the contract can -- and is -- recreated. This may sound incredibly inefficient when compared to, say a relational database, but it is the only option when there is no central authority ( like the MySQL database adminstrator) who is trusted by everyone in the network. Which is why it does not make any sense to port an application from a traditional three-tier platform to the blockchain platform where there exists a clear central authority, like a statutory body and its database administrator, to own manage a central database.. Blockchain applications are meant to handle situations where there are multiple operators -- all of whom are peers, without a central hierarchy -- and there is no reason to trust any or all of them.

Finally, in addition to the client application and the Solidity contract, that a developer needs to build there is a third 'joker' that the developer needs to deal with - a payment. Since the transaction is getting executed on network node, the owner of the node needs to be incentivised or compensated for their investment in hardware and electricity. In the Bitcoin network this incentive is in the form of new coin that is mined ( that is another long story -- see here, and here ) but in the Ethereum ecosystem it is a combination of mining and an actual fee that must be paid by the client application to the node owner in the form of Ether. On the Main Net, this is real Ether that has be mined or purchased but in the other Test Nets, there is a lot 'fake' or 'toy' Ether that is freely available. Think of this as monopoly money with which we buy properties in the Monopoly game. This Ether - real or fake, depending on the network being used - must be sent along with the transaction request.

The second part of this tutorial will show you how to to build 

• a Solidity contract pmCrudCon.sol  to manage employee data ( empID, empName, empSalary)
• a Python Application to Insert, Update, Display and Delete this Data