People are resorting to blockchain for all kinds of reasons these days. Ever since I started doing smart contract security audits in mid-2017, I’ve seen it all. A special category of cases is ‘blockchain use’ that seems logical and beneficial, but actually contains a problem that then spreads from one startup to another. I am going to give some examples of such problems and ineffective solutions so that you (developer/customer/investor) know what to do when somebody offers you to use blockchain this way.
- The described use cases and problems occur at the initial stage. I am not saying these problems are impossible to solve. However, it is important to understand which solutions system creators offer for particular problems.
- Even though the term ‘blockchain use’ looks strange and I am not sure that blockchain can be used for anything other than money (Bitcoin), I am going to use it without quotes.
Let’s say you ordered some goods, and a carrier guarantees to maintain certain transportation conditions, such as keeping your goods cold. A proposed solution is to install a sensor in a truck that will monitor fridge temperature and regularly transmit the data to the blockchain. This way, you can make sure that the promised conditions are met along the entire route.
The problem here is not blockchain, but rather sensor, related. Being part of the physical world, the sensor is easy to fool. For example, a malicious carrier might only cool down a small fridge inside the truck in which they put the sensor, while leaving the goods in the non-refrigerated section of the truck to save costs.
I would describe this problem as:
Blockchain is not Internet of Things (IOT).
We will return to this statement a few more times. Even though blockchain does not allow for modification of data, it cannot ensure such data is correct. The only exception is on-chain transactions, when the system does not need the real world, with all necessary information already being within the blockchain, thus allowing the system to verify data (e.g. that an address has enough funds to proceed with a transaction).
Applications that submit information to a blockchain from the outside are called “oracles” (see article ‘Oracles, or Why Smart Contracts Haven’t Changed the World Yet?’ by Alexander Drygin. Until a solution to the problem with oracles is found, any attempt at blockchain-based supply chain management, like the case above, is as pointless as trying to design a plane without first developing a reliable engine.
I borrowed the fridge case from the article ‘Do you Need Blockchain’ by Karl Wüst and Arthur Gervais. I highly recommend reading this article and paying particular attention to the following diagram:
Even though this case is similar to the previous one, I would like to single it out as it is presented in a different wrapper.
Say we make unique and expensive goods, such as watches, wines, or cars. We want our customers to be absolutely sure they are buying something made by us, so we link our wine bottle to a token supported by blockchain and put a QR code on it. Now, every step of the way (from manufacturer, to carrier, to store, to customer) is confirmed by a separate blockchain transaction and the customer can track their bottle online.
However, this system is vulnerable to a very simple threat: a dishonest seller can make a copy of a real bottle with a token, fill it with wine of lower quality, and either steal your expensive wine or sell it to someone who does not care about tokens. Why is it so easy? That’s right! Because…
Blockchain is not IoT!
A bottle is a physical object, and as such can be faked, unlike a digital signature.
Let’s take university diploma authenticity as an example. In this case, we need to verify the genuineness of the statement (“Peter graduated from the university”), rather than a physical object. To make sure the diploma is authentic and the date of issue is accurate, we need to check a digital signature and a time stamp.
Digital signatures are great, some even call the asymmetric cryptography they are based on ‘the greatest invention of the 20th century’. But let’s not confuse it with blockchain. Indeed, digital signatures existed and served us well before blockchain was around. Be careful! Today, digital signatures are often sold as blockchain. Perhaps a digital signature is all you really need and blockchain does not really suit your requirements.
Timestamping is closer to blockchain. In fact, blockchain itself is the most reliable timestamping method. You don’t need to invent anything: just put a hash of your data into Bitcoin blockchain.
Is it a good idea to put a hash of student diploma digitally signed by several professors on Bitcoin blockchain? Yes. However, it is important not to screw this system up by using centralized verification through a website or an app, which will be a single point of failure.
When it comes to using blockchain for voting, we need to be clear about what problem we want to solve.
Forgery of vote/voter authentication: To tackle this problem, we need digital signature rather than blockchain. The main issue here is a private key: where to get it from and how to store it. I won’t explain why any system in which a key is generated anywhere other than on the end user’s device is broken by design. However, on top of this, it is also important to have open source and properly audited key generating software, third-party hardware (smartphone being the simplest option), and a user who can handle a private key.
While a system developer can address the first two issues, the third is much more difficult. Bitcoin may actually help us learn how to deal with keys. Indeed, losing a password to your social media account or your vote is one thing, but losing a key to your own money is another story.
Yet again, it is oracle that links a public key to a particular person if we need it for the voting process.
Publicly visible vote counting: It would be safe to assume that, say, Ethereum smart contracts are perfect for this issue, as they allow everybody to see how many votes any particular candidate received. However, in this case the level of openness may be too much, as we can see how each and every person votes, and thus can influence them. Although the system may be built in such a way that every vote is only visible to the person who cast it, there is another more complicated challenge: as long as voters are technically able to bring evidence of their voting choice, they could still be put under pressure.
UPD: Colleagues assure me that there is a solution: incoercible encryption.
And here, once again, we need oracles to check whether there have been any extra votes from nonexistent voters.
Let’s say Artist A wants to use blockchain to register that a certain painting is his. He takes a photo of it, puts the photo hash in blockchain, and then uploads the photo to a blog. Now, if Artist B claims that the painting belongs to him, Artist A can easily prove his authorship by showing the photo and hash.
There are two potential issues in this case:
- First, Artist B can say he did not know about blockchain and thus could not use it to register his authorship. Therefore, this procedure can only work if it becomes common practice.
- Second, Artist B could break into Artist A’s studio, take a photo of the painting, and place the hash in blockchain before Artist A.
The reason is that…
Blockchain is not IoT!
Yet, in general, this use case makes sense. However, it does not require anything other than Bitcoin’s blockchain.
Note: I am talking about proof of authorship only, as the concept of intellectual property is nonsense in my opinion: ‘Against Intellectual Property’ by Stephan Kinsella.
Another proposed case is linking blockchain-based tokens to land ownership. There are at least two issues with this.
Enforcer actions: While a bottle/watch/car can be handed over peer-to-peer (P2P), land ownership and transfer must be registered by a regulatory authority, which can always physically visit your land and enforce its will. What will happen to a blockchain record if the regulatory authority insists that you should transfer your land? The first option: blockchain record still specifies you as a land owner, which is not true anymore; the second option: the regulatory authority can make its own record and thus rewrite yours, which means that blockchain doesn’t work. This is a critical point since blockchain is also promoted as a tool protecting you against the fraudulent activities of both the regulatory authorities and any individual officials.
Centralized development and support: Now, who is going to develop such a system and support nodes? If the regulatory authority itself or its counterparty is to do the job, then such a system won’t be decentralized. A decentralized protocol plus centralized development equals a centralized protocol.
Besides, each time somebody offers you blockchain, ask yourself:
Can we use a distributed database instead?
If the answer is ‘Yes’, why go for blockchain at all? Indeed, blockchain is slower and more resource-intensive. Plus, specialists in database development and integration are much less expensive and easier to find, their work product is easier to check, and system support is simpler too.
Given all these challenges, I believe a distributed database to be a much better choice for land registry today, even though it definitely needs to become more reliable and open (see ‘Blockchain as a Trigger’ section).
Indeed, it looks like this particular use case has already become a reality. Bitfury recently announced the launch of a blockchain land registry system built on the Exonum framework and is set to do the same in Ukraine and Moldova. Strangely enough, I could not find any technical details of this case, meaning that for some reason Bitfury is in no rush to boast of it.
This case is a good one according to the scheme from ‘Do you need blockchain?’ It involves a number of parties that do not trust each other, without any trusted third party being engaged. Although Bitcoin can be used here, banks are unlikely to make their mutual payments publicly visible. Therefore, we would offer a private blockchain where only banks themselves can input data, support nodes, and verify the transactions of all other parties.
In terms of functionality, does this system differ from a distributed database with access control? Yes, it does, but only when it comes to a disagreement between the parties. Here, the question is: will banks agree to a consensus offered by the system or will they appeal to a court? If banks can choose the second option (i.e. they have never signed an agreement to unconditionally accept all decisions offered by the system) then this system makes no sense.
Plus, this entire case will be nonsensical if regulatory bodies prohibit or restrict the use of such systems or instruct the courts to refuse system data.
Yes, that’s right! I’m actually writing about ICO in the year 2019. To prove its continued relevance, let me just point out that on January 28, BitTorrent had a successful ICO.
What I mean by ‘Token for token’s sake’ is that some startups issue tokens and say they entitle you to a share in their companies/ profits/ split-fee options. The problem is:
Blockchain is not IoT!
Unlike venture capital investors or regulatory bodies, blockchain won’t hold a startup accountable or responsible to their investors. A promise in the form of a token alone does not oblige a company’s founders to do anything — something we saw many times during the ICO boom (remember Lambos?). In this respect, an ICO is more similar to crowd funding than an IPO.
Although pro decentralized institutions and against regulatory control, I must admit there are almost no such systems in this field yet, which means you must either go for existing tools or trust company founders.
Now, let me describe some promising use cases.
Oddly enough, even non-working cases may be useful. Say a corporation uses a long-outdated process/system. Instead of opting for a normal and obvious solution, management decides to invest in hype (blockchain/big data/AI/IoT) to gain a lead.
That’s when a savvy yet responsible intrapreneur can offer a proper system design, marketing it as blockchain. Depending on the situation, blockchain can either give certain advantages or be not the case at all living on slick presentation slides only.
Hint: If you are offered the chance to use blockchain, make sure it is actually blockchain. However, even if it is not, it could still be a sensible offer.
Blockchain is perfect for handling money, primarily because it was created exactly for this purpose. Blockchain records and verifies statements like ‘Party A owned X amount; Party A transferred X amount to Party B; Party B owns X amount’ as all previous similar statements were recorded within the same blockchain.
In the second part of the series of his posts on BitTorrent Lessons for Crypto titled ‘If You’re Not Breaking Rules You’re Doing It Wrong’, Simon Morris says that the original objective of decentralization is to break the rules, as those who observe those rules will try to stop you.
Bitcoin meets this requirement perfectly, as it breaks the old rule according to which only the government issues money, defines issuing procedures, and decides which transaction is valid and which is not.
More importantly, I think Bitcoin performs a specific role: the transfer of value that existed long before the technology in an easy to understand manner (see ‘Shelling Out: The Origins of Money’ by Nick Szabo). At the same time, the majority of blockchain startups have to explain from the very beginning which task they solve and why — something which is nonsensical even for traditional startups that usually look for customers, test hypotheses, and try to stay in sync with the market, i.e. solve existing problems, rather than invent new ones.
At any rate, Bitcoin is the only working blockchain application so far. That is why, at the beginning of my article, I questioned the relevance of the term ‘blockchain use’.
Note: I do not include cases in which blockchain is not used by end users, but rather by another blockchain that is, in turn, used by decentralized exchanges where tokens of the third blockchain are listed. Who knows, the industry may actually manage to pull itself out of the swamp this way.
Let’s be honest: nobody really knows what smart contracts are and what they are for, as this concept is still in its infancy. Ethereum is truly ahead of the curve. By the time decentralized Bitcoin came into play, people already knew and were used to e-money; by the time we got decentralized smart contracts running on Ethereum, we were still struggling to handle hard-copy contracts, while centralized smart contracts are simply non-existent yet. We can try and jump two steps at once, but to do so we need time and a viable concept.
Personally, I believe that smart contracts will find their niche. That’s why I am working in the field already. However, this is my personal belief, which has not been neither confirmed nor refuted yet.
I presented the ideas described above in my speech at ETHDenver conference. By the way, ETHDenver was great!
The examples above are only the ones I could remember and summarize. I might have forgotten or simply haven’t heard of some cases. So, I will be grateful if you give more examples in the comments below. Maybe I will continue this article.
This article was created by SmartDec, a security team specialized in static code analysis, decompilation and secure development.
Feel free to use SmartCheck, our smart contract security tool for Solidity language, and follow us on Medium. We are also available for smart contract development and auditing work.