This is part 5 of a seven parts series by Dr Ken Alabi, who has a Doctorate in Engineering from Stony Brook, a masters in Computer Aided Engineering from the University of Strathclyde, and is an IT professional, programmer, and a published researcher with over twenty publications in various fields of technology.
This is part of a series looking at issues that need to be solved in the next few months and years for digital currencies to grow to reasonable size compared to the tiny segment of the global economic system that they currently occupy.
There have been several analyses comparing digital currencies to fiat currencies. Such comparisons typically proceed on the basis of whether the digital currency can satisfy similar characteristics as fiat currency, in its ability to serve as a means of exchange, unit of accounting, and a store of value. The ideal digital currency can pass such test; easily if it includes the modifications and enhancements described in the first four parts of this series. However, it turns out that this definition itself is limiting to the potential that cryptographically secured digital currencies represents in the evolution of how value is stored and exchanged.
Evolution of the Means of Exchange
The start of the process of exchanging value was by barter, and the only requirement then was that both parties each agree on the value of what they were exchanging was worth and be able to deliver them at the same time. The next step along that roadmap was the invention and use of physical symbols of value as means of exchange. Items such as cowry shells became used as the means of exchange. Then the requirement for these items that represented value was that they needed to be scarce and thus valuable, so that value could not be arbitrarily created. They also needed to be portable, and numeric so that their value could be split and aggregated to represent the value of what they were being exchanged for. The need to have them fully divisible and usable as a means of account was the next step that proceeded from those rudimentary requirements, and brings us to the current status with the three set of requirements outlined above.
The Next Step in the Evolution of the Storage and Exchange of Value
Cryptographically secured digital currencies extends that definition to include two new requirements. The first is that ownership of the currency is cryptographically included with its storage and transfer at every stage. This removes the need to trust any entity in the process of storing it or engaging in commerce, besides the owner of the asset. The second is that since ownership of the asset is now an integral part of its formulation, it can now accommodate some programmable functionalities in ways that was not possible with assets that are not cryptographically secured. Some of these new possibilities are described below.
Code is Law and also Enforcement
I’m sure many are familiar with business, financial, or even personal scenarios where someone makes some financial promise. And then asks to shake hands on it, but is requested to “put it in writing” and sign it. Maybe even get it notarized. Well, all that presents some bit of comfort on the legal side to both parties, but still represents potential challenges on the enforcement side. For many such scenarios, the mantra in the next decade, would likely be “put it in code.” And then the code would not only serve essentially as law, witnessing the agreement between the two parties, but also as enforcement mechanism. Consider the following scenarios, most of which are already possible today.
ICOs and Investments Putting Their Promises In Code
A new business raises funds from investors or contributors, where it uses a utility token as a means of generating revenues from customers using the service. The business promises the contributors 20% of all proceeds from the sale of the utility tokens, and further writes the distribution mechanism into the contract of the token prior to any of the contributors putting their funds in. By putting the promise in the code eliminates the need to simply trust the operators of the business that they would uphold their promise to their contributors. Conditional release of the investor contributions could also be written into the contract tying the release to actual deliverables.
Living Blockchain Enabled Wills
A wealthy individual creates a contract to distribute their digital assets, which includes significant savings and title or deeds to properties on the blockchain, to their beneficiaries. The code executes within some trigger period when an Oracle or external authority certifies the condition for the invoking of the will is met. An Oracle in this context represents a digital authority that certifies an event or provides information outside of the blockchain making that information or trigger available to processes within the blockchain.
Th preceding two examples are but few out of which there are likely hundreds of other possibilities. There will likely be some disruption in the legal profession where a lot of what is put in writing and later enforced via lengthy litigation is actually put in code. There will also be significant opportunities where there are those who specialize in writing such codes for different parties, and code savvy legal experts and even lawyers would specialize in examining and proofing that what is put in code represents the agreement as understood by both parties before the contract is set on the blockchain.
Higher Level Programming Languages
So, the thrust of this segment is that the ideal digital currency needs to be programmable. Turns out that some of the popular digital currencies are indeed programmable. Bitcoins, which was the first blockchain digital currency is itself programmable through bitcoin scripts. The programable capabilities was a further major focus and development in Ethereum which introduced Turing complete programmable features within the blockchain. A few blockchains have followed since; a list of which is not necessary here but can easily be discovered via a search, or a possible future article reviewing the state of programmable blockchains. (Turing complete language simply means the programming tools includes all the full features of a programming language including mechanisms for repetition or loops, and conditional execution of parts of the code based on decision statements.)
The next step in this progression would likely see even more high level programmable features overlaid on the lower level programmable features currently available on the blockchains itself. This is the same kind of progression we see in computing and with earlier Internet technologies itself. For blockchains, this is more important when we consider that the people who would wish to utilize money in more innovative and creative ways programmatically are not likely to coincide with those with the technical programming skills to do it with lower level tools. In fact, virtually everyone would be beneficiaries of higher level programming tools available for utilizing their digital assets. Consider the following simple but highly effective examples.
Some Simple Programming Scenarios
A family wishes to program their monthly digital currency balance to allocate 20% of what is left at the end of the month into a small savings account for vacation, only if that balance exceeds some number, say $800 after all bills are paid. If that balance also exceeds $1000 they would like to further allocate an additional $200 payment to their mortgage.
A young worker wants his balance of digital currency every week to seek out digital currency investments based on some preset criteria, or to purchase some predetermined digital currency; whereby the characteristics of the choice is transient and depends on external inputs such as maybe the price of the digital currency and other performance indexes related to it.
The possibilities here again are endless and can hardly be completely imagined at this point, but some of them could only be best presented to users via more high-level programmable features. We are already seeing development environment for blockchains, for instance with Truffle. It is expected that high level programming tools will further be layered on top of blockchains. In addition, we also expect to see integration with higher level analysis and development environment, such as blockchain integrated spreadsheets (yes you heard this here first) that allow this age-old killer application to actually access blockchain accounts using the keys of the account owners. This would allow spreadsheet analysis to be made using actual digital currency balances, as well as potentially their programmable features.
At this point, I suppose a question that may not yet be clearly answered is could the ideal digital currency succeed without being highly programmable, especially if the other challenges in the earlier parts of this series are addressed. The answer would likely be yes. However, if there is a similar digital currency that has addressed all those issues as well and also gives users the power to programmatically utilize their digital assets in the new ways described here, then the programmable digital currency will likely receive greater use and is therefore the ideal one. However, as before we are still at early stages, and we can expect programmable features to be added even to some existing blockchains where they do not exist, or continuously improve where they do.
The views here are provided freely and could be freely used in whole or part, hopefully with a kind reference to the article. It is not intended as investment advice and should not be used in that capacity.