Blockchain-related technologies are in full-hype mode these days. I had flash, a déjà-vu, of the “NoSQL” trend:
- Hundreds of projects advertised behind a single keyword,
- Dozens of companies getting into it, with speculations and buzzword-based marketing,
- Heterogeneous constraints and uses cases that make you wonder what’s the actual relations between all these projects.
The bonus this time are the questions related to currency regulation and trading.
But what’s the point of the Blockchain? What can it do? What is not possible? Why talking about it now?
When you look at the foundations of Blockchain technologies, it’s the solution to a well-known Computer Science problem:
The Consensus Problem
A fundamental problem in Distributed Systems,
- I have a set of components, maybe servers in a network, robots, etc. These components do not share any memory. All they can do is talk to each other with messages.
- I want to ask these components to make a decision. For example: elect a leader or agree on the balance of a bank account.
- How should I design my components so that they reach the same decision? So that they reach a consensus?
Like every interesting problem, there is no single BEST solution. A good solution depends on the constraints you have to deal with. Everything is a trade-off:
In a Google Datacenter, I may assume that the network is reliable. But between two continents I have to take into account latency and disconnects. For a “like” counter I can live with a margin of error. But for a bank account, I want ZERO errors on the result of an operation.
When you design a digital currency, like Bitcoin, this consensus appears as the Problem of Double Spending. Let’s say I try to pay twice with the same Bitcoin; I send two transactions to two different servers on the network.
The system must ensure that there’s no case where both transactions are processed and confirmed. We want the system to reach a consensus over every transaction.
What’s new in Blockchain-related technologies is the ability to solve a version of the problem that is much more complex:
Consensus in a Hostile Environment
This Consensus Problem is well known, a few example of systems that use or provide a consensus system in one way or another: Kafka, HBase, MongoDB, Zookeeper, etc.
All of these technologies are dealing with availability constraints (a server goes down) and partitioning (the network goes down). BUT they assume that each participant is friendly: In my company’s Datacenter, the servers are not hostile; they won’t attempt to corrupt the result of a consensus willingly. And the admins have nothing to win in maintaining a hostile machine.
That is why the solutions we use in production today cannot work within a fully open system. There’s alway an organization, a Google or a bank that takes the responsibility of the Data and the Servers.
Even Wikipedia has a CEO
That’s why Blockchain-related technologies are disruptive. It’s a solution to available and crash-resilient consensus WHILE being able to deal with hostile participants. With the ability to work in an open community.
You can clone the main Bitcoin client now, alter its source code and start emitting fraudulent transactions on the network. The laws of Bitcoin are safe (up to a certain number of hostile machines).
And that’s it!
I’ve heard a lot of other things: immutability of the logs, anonymous transactions, permanent data storage, etc. These are technical details, consequences or necessities of the consensus.
Fundamentally, the Blockchain is an apparatus that generates consensus in a potentially hostile environment.
Note that the current instances of Blockchain, like Ethereum or Bitcoin, works with an elegant approach, in my opinion:
The consensus relies on a Currency, so the participants with the more power on the network are also the ones that have the more to lose by cheating. Making the Bitcoin lie, it’s taking the risk of having its value drop to zero.
These are questions of Game Theory; we’ll look into in another article.
Three links to go further on consensus: