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.
|image from Forbes.com
- Only the bare minimum software will be installed on the local laptop, we will use hosted software as much as possible.
- We will not spend any real money -- as in using credit cards.
- 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.
- '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.
- 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.