What you get for free with blockchains
Over the past year I have come across many blockchain ‘proof of concepts’, that take existing business ideas or challenges and apply a specific technical design (blockchains) to the solution. The usual problem/solution decision process has been turned on its head:
Of course, I’m probably being a little melodramatic, but let’s explore the subtleties. I used to think “Yes, you could use a blockchain for this use case, but a normal database can do that, so why would you use a blockchain?”, particularly for internal blockchain use cases that don’t require multiple parties to participate. Recently I’ve started to understand some of the reasons:
- Experimentation: Because companies want to experiment practically with the technology so that they can become more familiar with blockchains.
- Freebies: Because current open source blockchain solutions give you things out of the box that you’d otherwise have to code yourself. But consider the hidden costs.
Let’s explore these ideas. If the following gets too heavy, please first read a gentle introduction to blockchain technology.
The easiest way to experiment with a new technology is to take a known problem and see if you can build a solution for it using the new technology. You know what the result should look like, and you also understand the constraints of the problem more-or-less. You then create the new-tech solution and then compare the pros and cons of the old-tech and new-tech solutions.
With new technologies or paradigms, it is hard to think about new use cases, because we’re set in our ways of looking for certain shapes and sizes of problems. For example, we understand what computers can automate because we’ve seen automation happen, so we know how to look for problems that can be addressed by automation. I don’t think we’re there yet for blockchains.
With blockchains, the only solutions we’ve seen so far are cryptocurrencies (bitcoin) and recently some experiments with smart contracts on Ethereum. So we look for similar problems with dematerialised assets, for example stock settlement, currency payments, and loyalty points. It takes some creativity to think about what else this technology could be used for, so for now we focus on easily understandable problems.
Blockchains are a new type of hammer that can hit new nails. We don’t fully understand what the new nails look like yet, so let’s keep hitting old nails until we understand the new hammer.
So it makes sense to apply this technology to well understood problems, even if they can be solved using existing technology.
This is where it gets a bit more interesting. There are many open source projects using blockchains and distributed ledgers that can give benefits out of the box that may not be found for free elsewhere.
Some of the freebies are because blockchains themselves give you benefits, and others are because the software that is being wrapped around the blockchains is open source, hence you can make use of free features that someone else has coded. There are also some additional benefits in some flavours of blockchain which have a layer of business logic built into the database replication process.
What do blockchains give you out of the box?
Arguably the single most important benefit of distributed ledgers is that you can create agreement about facts and processes across entities without a single entity being able to unilaterally make changes.
That is the thing that gets people excited about disintermediating 3rd parties.
For other use cases that don’t need multilateral agreement, especially those where a single entity is already trusted, there are still some technical benefits to using this type of distributed database – whether you are creating a ledger that tracks ownership of things, or just distributing a database for pictures of cats.
Let’s explore some business benefits and some technical benefits.
Business benefits “out of the box”
Timestamped events are agreed upon across multiple, possibly hostile or non-trusting entities.
Catastrophic data loss becomes a non-issue due to the constant replication between all participants.
You are able to prove that data hasn’t been unilaterally tampered. It takes some significant coordination to alter data that has already been written and replicated on a blockchain.
If digital signatures are used to initiate transactions, and if the keys are carefully managed:
- Ability to prove authenticity (who initiated this transaction?)
- Nonrepudiation (hard for participants to deny responsibility)
- Full traceability of ownership history
- Sound business logic validation that only lets you spend what you have received
- A guaranteed group-agreed resolution if the same token is transferred to two different people simultaneously
- Atomic transactions – payments with multiple legs either succeed collectively or fail collectively. There is no risk of a single leg failing (known as “Herstatt risk“). This includes single payments to multiple recipients, or asset swaps (for example I give you 5 of these for 3 of those).
Technical benefits “out of the box”
Immutability (well, three things)
- Participants to a blockchain can easily and quickly confirm the sanctity of their data by comparing one single piece of text (a recent block hash) with the records of another participant
- Attempts to change to historical data are not accepted by other nodes
- Nodes will attempt to self-heal against the network if alterations to historical data are made
More on immutability in a blockchain here.
Distributed data consistency check – essentially the double-spend prevention system. A blockchain system will automatically reject contradictory transactions simultaneously inserted into different nodes of the network, therefore preventing a data inconsistency such as a negative balance.
Sophisticated cryptographic authentication mechanisms ie the ability to orchestrate the creation, signing, and broadcasting of transactions involving multiple parties. This is extremely useful for mimicking real-life scenarios where several people or organisations are required to approve a specific process. Examples include payments requiring multiple signatories, but this can be generalised to any business process which require multiple people to participate. Digital signatures and keys representing the identity of parties (people, companies, machines, devices) are integral to these mechanisms.
Resilience through replication. Some relational databases also offer this but in a more limited way, with pre-configured hosts. In a blockchain network nodes can come and go at any time and without notice without affecting the reliability of the system.
Cloud platforms like AWS or DigitalOcean make it a lot easier to set up database replication, but you’re still limited by these infrastructures and the database instances that you have to pre-configure. Spinning up a new blockchain takes only a few minutes, with very minor pre-configuration overhead.
Master-master database setups without a controlling entity. Of course, you can take a regular database like MySQL and set a master node in one data centre and a number of read-replicas in other data centres, perhaps in a different country. However, you’re limited to writing at a single point (the master node) which somewhat defeats the purpose of a distributed system as it creates a single point of failure and control.
Some products like MongoDB make it easy to implement master-master sharding, but this is at the expense of other features like relational integrity and tabular data. You could try to mimic the behaviour of a blockchain using MongoDB, but there is nothing native to prevent two clients inserting contradictory transactions at the same time on different master nodes.
If blockchains are good at making sure data is accurately replicated across untrusted entities, smart contracts are good at making sure logic is accurately executed across untrusted entities.
As far as current ways of ensuring that exactly the same logic is followed between two entities, our best tool is automatic reconciliations of data before and after a process. With blockchains and smart contracts, the technology guarantees the process.
To replicate this using regular databases would take a lot of work, and once you’re done you’ll have something that looks like a blockchain…
The hidden costs
Proof-of-concepts are all very well, and I believe that people and companies should experiment and develop the technology. When it comes to industrialising the systems, there are additional costs to be considered, including:
- Does the new system need a new audit procedure or different types of controls?
- Are new support/exception processes needed?
- How easy is the technical expertise to find? At what cost?
- With a distributed system, who do you call when things don’t go wrong?
Aside from the last question, these are all standard for the integration of any new technology or system into an established process. The last question is the interesting one and leads me to think that with blockchains the role of the 3rd party will evolve from one of control to one of coordination, rather than ending up completely disintermediated.
Technology gives us tools to help us do what we want to do. Blockchains are just one of those tools and can be a useful solution. With any business problem, you start with your goals and see what solutions might work. Based on your needs, you may be able to achieve the same goals using centralised databases or blockchains.
There is very little overhead to running a blockchain-style distributed database. With new open source tools coming online like MultiChain and Eris, you can install and spin up a blockchain in one or two commands, and you certainly don’t need to run huge data centres to mine for tokens in a private chain.
You’ll make the decision based on the usual metrics of what is important – commonly cost, scalability, support, resilience, available expertise, technical risk etc.
The point is that blockchains and associated technologies are available to experiment with, and give you certain benefits for free. If these benefits are interesting and useful, then why not have a go? By refusing to use this technology simply because existing technology can also be used, you may be missing out on the most interesting part of the evolution of the technology, and the ability to influence its direction.