Do We Really Need Blockchain?
By Philip Rutovitz on ALTCOIN MAGAZINE
There is a lot of discussion about whether we really need blockchain technology and whether it is here to stay. There is also a lot of hype around cryptocurrency and whether there is any real value or long-term utility.
I am going to attempt to answer this from a business perspective. Looking more at how the technology can facilitate better solutions to existing problems or even solve problems that we could not previously. Given my background, I will focus on the financial applications, but the same discussion applies in all areas of business.
Dispelling the Myths
Blockchain is not magic, it is just some code that any decent programmer can learn. I am not the best programmer in the world, but I have learned to make blockchain applications in less than 1 year. Most people talk about smart contracts without really understanding what they are and more importantly what they mean. Some blockchains also allow for fast or almost instant payments such as Ripple (XRP), Cardano (ADA) and EOS. Ethereum (ETH) is the gold standard in smart contracts (although EOS may claim that place for its own) and Bitcoin (BTC) is digital gold.
What is important is how blockchain technology transposes into solutions for applications that can solve real-world problems. I am now going to look at what the advantages and disadvantages of traditional client-server applications as opposed to blockchain technology. I will start by looking at each of them in turn and discussing what the two technologies actually are.
Client-Server
According to Wikipedia
Client-Server is defined as follows:
The client–server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients.What this essentially means in everyday language is that you have a central, powerful computer (Server) that does the hard work including calculations and then you have smaller computers (Clients) that request and display information. This is a black and white definition and there are lots of variations in between, but fundamentally that is what it comes down to.
What it means practically is that you need to have server-side code that is written and maintained by the software provider or distributor usually with an underlying relational database such as Microsoft SQL Server, Oracle or MySQL.
Clients can be deployed as desktop clients or web clients. They act as a front-end and do not usually do any complicated calculations but rather display data, create reports and send instructions to the Server. You can create almost any type of application using this approach.
The question at hand is whether there is a better way to solve certain kinds of problems.
Distributed Applications (Dapps)
Software that is created in the blockchain is called a Distributed Application or a Dapp. According to Wikipedia
The definition of a Dapp is as follows:
A decentralized application (Dapp, dApp or DApp) is an application run by many users on a decentralized network with trustless protocols. They are designed to avoid any single point of failure. They typically have tokens to reward users for providing computing power.
Picture Source:
In this type of architecture, there is no central server doing the heavy lifting, rather each node in the network stores all data and there are miners or validators who create blocks and perform the required calculations or other actions. In its purest form, you do not need to have an underlying database nor do you need a central server for the back-end. You do need a front-end such as a Java application to access the blockchain and display/manipulate data through libraries such as web3.js for developing front-ends that are written in JavaScript (there are also libraries for Python and other front-end programming languages) and interact with the Ethereum blockchain. You can read more about web3.js here:
There are other blockchains such as Cardano, Ripple, Neo and EOS which have smart contract capabilities. That said most implementations will have a database storing data for persistence so that you can continue to access your application even when your internet connection goes down) and also for back-up in case data is lost or corrupted (which is very unlikely for any of the large blockchains but might be possible in smaller private blockchains).
Even if the back-end does not require any centralized systems, the front-end of a blockchain application does need to run on a centralized web server.
Development and Deployment in a Client-Server Environment
Development and deployment is handled centrally and controlled by the software developer. This makes it easy to manage security and user access.
Version control is much easier to manage as roll-outs are performed centrally and deployed to clients as required. Database configurations can be changed with upgrade scripts to make any necessary transformations to the data. Also, if one client is not working for whatever reason, that particular client can be updated in isolation. If there are any problems with the database, the problem can be fixed and deployed by the software developer.
Development and Deployment in a Blockchain Environment
Development in the blockchain is done centrally in one sense. Someone is doing the programming and if it is a software company, they will want to make money on the software they create. They will also be responsible for releasing versions and updates as well as bug-fixing. The big difference is that the deployment is done in a decentralized way (in most cases anyway and the scenario I am talking about here). In other words, whether or not we are considering a private or public blockchain, there are multiple nodes that will “host” the application. It is possible to deploy quite large software applications without having any infrastructure other than a moderately powerful computer. If you add a data layer with a database running on the node, then you will require more infrastructure, but it is possible to do without.
The other major difference is that blockchain programming functions in an asynchronous way whereby you do not know in which order transactions will be performed until after the blocks are mined or otherwise validated. This means that when summing data fields, such as outstanding loan balances, you have to add data to the totals incrementally (this means you get the current total, add the new data to the total and then display it in an iterative loop) rather than summing the data sequentially and then displaying it. This means some extra overhead in the front-end and requires thinking in different way.
Transfer of Value
This is the big gun of the blockchain. There is no ability to transfer value within a traditional client-server application. It can be done through the use of third-party tools such as PayPal or APIs interacting with a bank. Even then, actually transferring payments from a borrower to a lender would not be made in the lending software, rather the application reflects the status as received from an API or the upload of a payment file. The database stores data reflecting the real-world. In the case of a bank both holding funds and transferring amounts, this would come pretty close to actually transferring value but even then the amounts are transferred independent of the data that is changed and stored. Also in this case the transfer can take days as opposed to seconds or minutes in the case of fast blockchains such as Ripple, Cardano, EOS and Ethereum.
However, in a Dapp, when the software updates the “database” with a payment made by a borrower to a lender, the data entry is both a change to the underlying data and an actual transfer of value. For example, the following code both updates the database and transfers funds from a borrower to a loan using Solidity code on the Etherueum blockchain:
payLoan(address _loan, uint _amount) is launched from the borrower smart contract while receiveFunds() is launched by the borrower through payLoan but is a function belonging to the loan. This is like object-oriented programming meets relational databases.
When the funds are received by the loan, some information fields will need to be updated as well (this is handled by the function applyPayments() which is not shown here). Unless the transaction fails (in which case the entire transaction is reversed), the value is transferred at the same time as the data is updated and the lender can use the transferred funds. The funds can also stay there until a later date or be transferred/picked up by the lender or owner of the loan. The loan is a smart contract as is the borrower. This means that there is code that can be triggered on a given event.
However, there is an issue which is that the funds transferred in this case are Ethers (the cryptocurrency underlying the Ethereum blockchain). Most people do not earn money in Ethers nor do they pay bills in Ethers. This may well change over time, but for the foreseeable future there needs to be a bridge to a traditional fiat currency. This can be done via APIs or alternatively through the use of a StableCoin that is a cryptocurrency pegged one-to-one (or at least close) to a fiat currency such as the dollar or the euro.
Loosely speaking, you can equate a stored procedure in a relational database to a smart contract on the blockchain. The SQL code for the stored procedure to send/receive funds might look like this:
Where received and loanID are fields and @_payment and @_loanID are parameters. The difference is not so much in the code itself as it is in the fact that the SQL Query updates a database but there is no transfer of value. That either happens before or after the execution in separate code connected to an outside system.
Immutability and Auditing
In any blockchain, there is a concept of immutability whereby once a block has been mined or validated and entered into the chain of data blocks, it can not be changed. Some variable values can be changed in future blocks, but there is no practical way to remove previously deployed blocks. This means that audit trails are instantly visible (assuming a publicly-accessible blockchain) and an auditor can tell with certainty who did what when. The question of who has some nuance as what is visible is the wallet address but not the actually physical person or company behind it. There also are privacy coins such as Monero and Dash which programmatically hide transaction parties to observers.
In a traditional application environment, this is possible as well including bank payments, but auditing can be complicated and is not instantly available when it involves an external bank account.
Real-Time
Applications developed on the blockchain show the current state of the underlying data in real-time to any authorized observer (in the case of a public blockchain, this means anyone). Practically speaking, that means that if there is value such as loans or fund balances, the front-end will provide a real-time window into the underlying data.
In a traditional client-server application you can only have a real-time view into the database. Through an API it is possible to make the software close to real-time, but the data reflects the real-world with a lag rather than being the real-world in itself.
Summary
Here are some headline distinctions between Client-Server applications and Blockchain Dapps:
Overall, almost anything can be programmed in the traditional client-server application world, but for certain types of application blockchain offers some significant advantages. For applications which require trustless parties outside of the organization creating the application where real value is be transferred with an unchangeable audit trail, it makes more sense to develop in the blockchain world. With the increasing digitalization of documents, deeds, contracts and pledges, the blockchain can also be used to transfer actual ownership of physical assets as well.
Bottom line, I will not argue with anyone who says that a blockchain solution can be done in a client-server environment — it almost certainly can be. The question is what is the best way to deploy a particular application. For sure there are many applications where blockchain adds no obvious value such as a virus scanner or CAD drawing software, but for many applications, and arguably any system when funds are transferred, there are good reasons to consider putting it in the blockchain.
Blockchain is no longer an “if” but rather a “when”. Blockchain has arrived and is here to stay.
