Blockchain — the big challenge
This weekend, the city of Groningen, the Netherlands, will be the stage for the Odyssey Hackathon. Last year it was the biggest blockchain hackathon in the world, and this year’s edition is even fifty percent bigger. Participants come from all over the world, and partners include KLM and Vattenfall, and even the Dutch central bank DNB and AFM, the Dutch equivalent of the SEC. All this in a time when all pundits seem to agree that blockchain is useless; a “solution in search of a problem”. In reality, we are starting to get a pretty good understanding about the specific uses cases for which blockchain is a proper fit.
Blockchain is a technology to reach agreement on the trustworthiness of certain data, between parties that do not trust or even know each other. Blockchain facilitates economic interaction between strangers, just like money (cash) does. In the case of ‘proper’ blockchain solutions, we are looking at automation across supply chains, or networks. We are talking about reaching consensus between parties that do not trust each other automatically. Those are definitely not the easiest use cases. Yes, there is a common interest, but there are also opposing interests and mistrust. In other words, there are hardly any low hanging fruits to pick.
In the rush to build something (anything!), and to prove the technology works, a lot of projects have been realised in which a single, dominant party in the chain acted as commissioning party. Probably the most well-known project is the logistics solution TradeLens, built by IBM for shipping company Maersk. But a lot of the pilots that were held within Dutch Government agencies also fall in this category. These are, on the whole, systems that could just as well (or even better) have been realised without blockchain. And it proves, in general, to be very difficult to onboard supply chain partners to a system that they do not co-own, and did not co-design.
Nevertheless, it is completely understandable why these projects were the first to be initiated. Projects that have a single owner are simply much easier to define, execute and deliver. This first generation of blockchain projects has not only brought us unused software and scathing articles in the media, but a couple of very interesting insights as well. The three that stand out the most are:
- Blockchain is very much suitable to automate settlement of transactions, but far less suitable as a platform for those transactions. The theory is appealing: a decentralized system in which users pay each other in a special cryptocoin. No platform monopolist that takes a cut, no advertising and no surveillance capitalism. But in practice, these ‘ecosystems’ become sub-optimal, non-communicating sub-economies. It’s like having to buy fish-money, vegetables-money and bread-money before going to the local market to buy your groceries.
- Blockchain is a very well-suited mechanism for the verification of the provenance and trustworthiness of data, but it is hardly usable as a database. All participants need to have a complete copy of the database and all mutations are simultaneously processed everywhere. This is highly inefficient en creates a whole host of problems with regards to security, privacy and confidentiality.
- The difference between an open (public, permissionless) blockchain and a closed (private, permissioned) blockchain is less principled than one might assume at first glance. The above could read as a plea in favor of what we call permissioned blockchains, distributed ledgers or closed blockchains. No built-in coin, no platform, no anonymous users, but a layer that you can superpose on existing systems that validates provenance and integrity of data and automates the settlement of transactions. The funny thing is, in order to make these closed blockchains actually work, they need to be designed and built as if they were open. Remember, any system that is owned by one or only a few of the parties in a value chain, will hardly be used by the rest of the parties. An ideal blockchain is designed and maintained by, or in name of, the entire chain. And because you can never know up-front which parties will be part of the chain in the future, you must facilitate exit and entry of parties, both procedurally and with respect to safety and confidentiality. In other words: because you don’t know who will join your blockchain, you have to build it as if anyone can join it — very much the definition of an open system.
The image of a ‘proper blockchain’ that arises from these three learnings, is the image of blockchain as digital infrastructure, partially also public infrastructure. That image is reflected in the challenges of the Odyssey Hackathon. Teams are working on a cargo insurance protocol for the world. And a government-backed protocol for digital permissions, and a solution for co-creating and sharing validated data during a disaster. Those are indeed the kinds of challenges in which blockchain technology can add value. The big pitfall obviously is that these challenges are in essence not really technological challenges, but rather political and governance challenges. They are more about how we want to organise things, than about what we can build.
If the teams manage to avoid that particular pitfall, beautiful results could emerge. If not, we’ll be provided with another slew of unused software and scathing articles in a few months time.
(Translated from Dutch. Original can be found here.)