Blockchain has the potential to be a powerful technology. Utilized in the right places it can save costs, streamline processes, and erase human errors. However, if misused the technology can also become an efficiency killer, a useless technology that contributes nothing beyond being a gimmick. At Kepler Lab, we design practical use cases for blockchain. However, even more frequently our job is to point out why our client’s don’t need blockchain technology. I am going to list the 8 most common misunderstandings surrounding the application of blockchain technology, and then offer a glimpse into how blockchain can work in practical use cases.
When we talk about blockchain, we often hear two extreme responses, either that blockchain is everything or that blockchain is nothing (e.g. Nouriel Roubini). People draw these extreme conclusions because we fail to understand the appropriate application of the technology. Below are eight misunderstandings that commonly arise in blockchain discussions.
1. “Use of blockchain increases system security”
I don’t know the origin of this misconception, but we often hear our clients saying that they want to improve their system’s security by putting everything on blockchain. Blockchain does not equate absolute security. In fact, only some blockchains are secure, a lot of blockchains are not.
Before we discuss whether using blockchain improves system security, we need to know how blockchain secure itself and its limitations in doing so.
Blockchain secures your data in two ways: Firstly, it maintains data integrity by making sure that the data recorded on blockchain cannot be altered or removed. Secondly, it secures the ownership of your account with public / private key cryptography. This means that your account is secure as long as your private key isn’t exposed (normal password protection is much easier to crack compared to public / private key cryptography).
In the case of smart contracts, the above characteristics of blockchain makes it possible to achieve security on another level: a program deployed on blockchain cannot be altered or removed, meaning that hackers cannot change your program code or make it misbehave. But there are also limitations. For example, if the deployed code has bugs then blockchain won’t allow you to fix these bugs as the program code cannot be changed once launched. Also, the public / private key encryption adds an element of user unfriendliness to your system, since users cannot choose their private key and the keys can be long and hard to memorise.
Back to the discussion, can blockchain helps improving your system security? It depends.
- If you just want to secure the data integrity: Yes, blockchain can help. Putting your data on a public blockchain can make your data close to immutable.
- If you want to make your program secure: Usually no, sometimes yes. Yes if your program is coded flawlessly; No if your program is not flawless, and most programs are far from perfect and do contain bugs.
- If you want to hide your data from hackers: No, there are better ways to hide your data securely. Putting the data on a blockchain without lowering the usability of the data is impossible.
- If you want to give your users the ability to store their encrypted data securely, and make sure that only they can decrypt their own data: Yes, you can do this with blockchain, but make sure you really need this level of security and you are willing to make the relevant sacrifices in usability to users.
2. “Use of blockchain protects user privacy”
“We protect user privacy by using blockchain!” Well, Bitcoin can protect your privacy, and so can many other cryptocurrencies. But here is the very common misconception that startups, VCs and a lot of laymen (non-laymen as well) have been reiterating. Blockchain protects privacy because it can verify a transaction without needing your personal information. However, it does not protect your privacy by preventing other parties from misusing your information without your permission.
Below is a proposed solution that is often brought up by blockchain projects:
“To illustrate, consider the following example: a user installs an application that uses our platform for preserving her privacy. As the user signs up for the first time, a new shared (user, service) identity is generated and sent, along with the associated permissions, to the blockchain in a Taccess transaction. Data collected on the phone (e.g., sensor data such as location) is encrypted using a shared encryption key and sent to the blockchain in a Tdata transaction, which subsequently routes it to an off-blockchain key-value store, while retaining only a pointer to the data on the public ledger (the pointer is the SHA-256 hash of the data). Both the service and the user can now query the data using a Tdata transaction with the pointer (key) associated to it. The blockchain then verifies that the digital signature belongs to either the user or the service. For the service, its permissions to access the data are checked as well. Finally, the user can change the permissions granted to a service at any time by issuing a Taccess transaction with a new set of permissions, including revoking access to previously stored data. Developing a web-based (or mobile) dashboard that allows an overview of one’s data and the ability to change permissions is fairly trivial and is similar to developing centralized-wallets, such as Coinbase for Bitcoin.” — by enigma
What these projects are suggesting is that all user data is uploaded and stored on a blockchain platform, and that services (applications) can only access this information with user permission. Most importantly, you can revoke the permission anytime you like. Does this not sound like Facebook login? Applications can only access your information with your consensus and you can revoke their permission to do so at anytime. So, can these applications “steal” your information should they wish to? Yes! All they have to do is to create a copy of your information.
The most obvious failure of the above proposal is that once the application has received user permission, then it can simply make a copy of your user data. And the data you generate in the application can only be uploaded to blockchain by the application, so they can steal it in the middle of the upload, or even outright prevent it from being uploaded. The only way to make it work is through something like TouchID: your fingerprint is collected by your iPhone, applications cannot touch the data, they can only ask iPhone to check whether your fingerprint is correct. The data from the point being of being collected, to being processed and stored is in a closed loop. This is how Apple protects your privacy from everyone except from themselves.
In short, cryptocurrencies can protect privacy because they don’t need your private information to verify transactions, nor do they require authorities that own your personal information to verify transactions. Blockchain can encrypt your data and store it securely and prevent anyone from using it, but it cannot protect your data from being misused.
3. “Blockchain makes illiquid asset liquid”
While this can be true, it is in fact far from that straight forward. It is important to understand why cryptocurrency can be liquid, and why this same liquidity may not apply to other assets even if they are tokenized.
Here are two very important concepts: transaction cost and liquidity.
Transaction cost consists of a number of different individual costs:
- Search and Information cost
In short, this is the cost of matching buyers and sellers, verifying the identity of all parties, and verifying the authenticity and ownership of the goods.
- Bargaining costs
Cost of achieving consensus on price and delivery method.
- Policing and enforcement costs
Cost of making sure the all parties follow the agreement.
These costs can also be categorized as 1) cost of regulation, 2) cost of verification, 3) cost of execution and enforcement.
Liquidity depends on the divisibility, transaction cost, and most importantly, adequacy of demand and supply of the asset.
Bitcoin is highly divisible, it has low transaction cost as it has almost no cost of verification, you don’t need to check the authenticity of a Bitcoin; and as long as it is not regulated (e.g. sending 1 BTC from North Korea to USA is no different from sending 1 BTC from USA to Hong Kong) then there is no cost of verifying the identity of involved party. With enough demand and supply, Bitcoin has very good liquidity. This logic can be applied to all tokens if those tokens do not represent any real-world assets (no cost on verifying the quality, authenticity and ownership), and they are non-regulated (no cost of verifying identities and no regulatory cost).
But when it comes to tokenizing real-world assets, then we are looking at a different story. For example, security token offering — STO, is the tokenizing of company shares. Let us assume tokenization won’t affect the demand and supply: if the asset is not allowed to be offered for sale to the general public, then it will not / should not suddenly be possible to sell the same asset to the general public if we put it on a blockchain. Furthermore, it won’t make unattractive assets become attractive, bad debt is still bad debt no matter if it is on blockchain or not.
So, what we need to look at is if tokenization improves the divisibility and lowers the transaction cost of an asset compared with existing methods. As we mentioned previously, transaction cost is made up of various components, those components can be categorized as 1) cost of regulation, 2) cost of verification, 3) cost of execution and enforcement. The cost of regulation will not be lower for a security token. Crypto has low cost of regulation because it is non-regulated, but security tokens must be regulated just like other securities and hence they should have the same cost of regulation. In terms of cost of verification, Bitcoin is Bitcoin, they are homogeneous and the authenticity is self evident. This is definitely not the case of the underlying assets of security tokens. Say, if the token represents an overseas property, as an investor you still need to check the location of that property, the decorations, the actual return of investment etc. This type of information is what we call general information (see the previous article) which blockchain cannot help verifying. Also you need to verify the identity of the involved parties to make sure the transaction complies with relevant laws.
Blockchain may help in by lowering the cost of execution and enforcement, but this is only limited to the token transaction part. Security tokens don’t only involve token transactions, and there are also transactions from the underlying asset which are not happening on blockchain. For instance, in the case of the overseas property example. There is rental income and operating costs to handle. And unlike Bitcoin transactions, once the Bitcoin is transferred, it won’t default. But the tenant may be in rent arrears or even default. The management company may take away the rental income.
I will not spend too much time on the divisibility issue. Most of assets are already highly divisible, REITs for real estate, different types of funds for various investment. I agree that tokenization can improve the divisibility of an asset, but I would also argue that tokenization is not an improvement over existing solutions.
As a result, blockchain doesn’t really make illiquid asset liquid unless the tokens are non-regulated and do not represent any real-world asset. We make blockchain decentralized to allow it to operate without trusted parties; decentralization is not the goal in itself. In the case of STO, personal information and authorities must be involved. It makes no sense for us to pay the extra cost of introducing decentralization. STO is more like an internal system upgrade for existing security systems, it is not a paradigm shifting technology. So if the asset is illiquid because of regulatory requirements, insufficient demand and supply, then blockchain will not help. If the asset is illiquid because of the cost of executing the transaction is too high, private blockchain may help.
4. “Blockchain applications are decentralized applications”
Making applications decentralized can be helpful sometimes. For an example we can look at decentralized gambling applications (which contribute 40% of total blockchain transactions, Standard Kepler Research). They don’t have licenses, users don’t know who the operators are, there is no protection for gamblers. Yet, users can trust them because decentralization guarantees the immutability of the code. The agreed program code cannot be altered.
Decentralized applications put the core logic on blockchain and establishes fully automated execution. That’s why we can trust the program will deliver what has been claimed. But just putting the program code on blockchain doesn’t make it decentralized.
Program 1: A smart contract that stored 1000 coins, and it will send out 1 coin to a random address until there are no more coins left.
Program 2: A smart contract that will distribute the income from a company to token holders, every quarter the company CEO will convert the company profit to crypto and send it through the smart contract.
Obviously, we can determine whether the program 1 can deliver what they’ve promised just by checking the code while we cannot tell if program 2 will be executed. Even though the smart contract is immutable, no one can guarantee the CEO will send all the profits to the smart contract. Therefore, program 2 cannot be considered as a decentralized application as the core logic and execution is not decentralized.
If we want to build a truly meaningful application on blockchain, we have to know it’s limitations and not just keep repeating how powerful blockchain is (with most of these statements of power being incorrect). Misusing this technology contributes nothing beyond making it appear a gimmick or even a scam.
Even though blockchain is an over overhyped technology, we still believe that everyone can benefit from blockchain. In the next chapter we will discuss how can you use blockchain as a KOL / SME owner / game developer / large enterprise.