This article is about the basics of blockchain Technology!
It’s not about investment tips, but an attempt to understand what is different in blockchain technology and why it can be very useful in some areas. Since this is a quite big topic, I’ll write several articles about it.
Let’s start at the very beginning: Blockchain is a decentralized or distributed technology. Even if that last sentence sounds very easy to understand it’s worth to think about examples of centralised, decentralised and distributed systems.
Centralised, decentralised and distributed systems.
In order to better understand a decentralized, distributed system, we first have to classify it.
A central system has a central office. This center determines how the individual actors operate within the system. The classic example of a central system is an army. There is “someone” who gives orders based on certain information from the staff. These commands are executed by the lower ranks. The chains of command and the hierarchies are clearly defined.
Such a central system has the advantage that commands are executed quickly and largely without any queries. This allows quick action. Central systems are vulnerable in their headquarters. If the commander-in-chief fails, no one else gives orders and the system comes to a standstill.
An illustrative example from the beginning of communication over the telephone is a problem of central systems well.
In 1887, a tower was built in Stockholm to be able to put a line from the head office to each of the 4,832 connections.
Another example is currencies. You and I believe that one Swiss Franc, one Euro and one US Dollar offer a certain amount of purchasing power and are accepted as a means of payment by our counterparts. The guarantee is provided by the issuer of the currency, the respective central bank. It sets the many parameters as a central point in order to keep the currency stable in terms of price and monetary value. The decision of a central bank “generates” and “destroys” money. If a central bank announces or decides something, it will be implemented immediately in the market. Whether it succeeds or not is another question, as in the army.
A decentralized system has no headquarters and consists of more or less independent elements within a network. The Internet itself and, perhaps more clear, e-mail traffic are examples of decentralized systems. In order to know what to do, instructions, the protocols, are defined for each part of the system general. Before the first email was sent, one agreed on the rules of the email shipping. The “Simple Mail Transport Protocol” (SMTP) describes how an email should theoretically be sent. Besides the email protocol, there are dozens of other protocols that describe every conceivable step. If a step has been forgotten or incorrectly described, it must be re-discussed and the protocol adjusted.
Neither the “inventing” nor the implementation of the protocol in software is bindingly regulated. Anyone who has the desire and time, can write a building block of the system, for example, an email client, offer it for free download or sell it, of course. The quality of the software can be measured by the most complete implementation of the protocol. Of course, the user-friendliness plays a role too, but basically the software has “to work” first. The software will be considered functional if it correctly implements the protocol.
The advantage of a decentralized system is the independence of its components. If there are fewer email “components” (servers), emails will still be sent, it will only take longer for them to be forwarded and finally arrive.
Probably the best known decentralized system beside of email is Bitcoin, a decentralized payment system. In 2009, the Bitcoin protocol was described, which is gradually being implemented by different actors. Who wrote this protocol, in principle does not matter as long as it is consistent and does what it should. Whether Bitcoin is a currency or not, whether it is good for people or bad, will become apparent in the course of implementation (Bitcoin: A Peer-to-Peer Electronic Cash System PDF 184 Kb)
A distributed system is something in between. Distributed systems try to process tasks in parallel to speed them up. So, one person shovelling sand. A distributed system would use more persons, let’s say 1000 shovelling sand. Sometimes it’s possible to speed up the work by adding 999 persons, sometimes not. Such systems have always a certain administrative burden, since the 1000 persons each need a shovel and must also be coordinated. This administrative burden is a mixture of centralised and decentralised elements.
The decentralised internet
Last month I described the web as a medium for everyone. It is worth taking a quick look at the development stages of the World Wide Web.
Web 1.0 looks in the early beginning at the first view like a “traditional” centralized system. The concept of a website consists of two parts, the browser (client) that displays the page and the server that delivers it to the client on request.
In the simplest configuration, the client is the one who makes a request to do a task (“send me the website’s data!”), and the server is the one who does it (“send data!”). Over time more and more of these servers and clients existed, so the system became more and more decentralized based on protocols (like our email example).
Web 2.0 is more about communicating among clients (people). In Web 2.0 clients want to communicate with each other. The communication can involve texts (articles, comments), photos, videos, sounds, favorites und likes. In this stage clients still need a server “in the middle” that handles their requests. When the messenger app on your smartphone sends a message to another smartphone, this message is first sent to a server in the middle. This server notifies the recipient app. If the recipient looks at the message, the app sends a confirmation via the server to the sending app. This principle is also widely used in social networks like Twitter, Facebook, Instagram, WhatsApp and others. Web 1.0 and 2.0 are working well. However, the servers involved are beyond the control of the clients (Facebook, WhatsApp, Google, hosted websites, etc). Behind a server name can be a good or a bad company. It could be the mafia, an NGO or the government. The client can not distinguish and must rely on domain names and certificates to build trust with a server.
Web 3.0 is now trying to fix this “trust error”. Web 3.0 refers to peer-to-peer networking, that is, client-to-client communication without a server in between. The BitTorent Protocol has impressively proven that communication works in peer-to-peer networking. The client and the server became an entity that is both client and server. But from this fact arises immediately a new problem. How do I build trust with the other peer? Here, too, could be “everyone”!
At this point the blockchain technology begins and at this point it is about challenges such as Byzantine generals and the CAP theorem!
According to a legend, Byzantine generals had a communication problem in 1453 during the siege of Constantinople. Due to the strength of Constantinople, it was necessary to attack the city from several places simultaneously. The generals could communicate by messengers. But it was suspected that some of the generals were traitors and worked with the sultan in Constantinople. A joint agreement on the exact time of the attack was therefore difficult because the traitors could spread false information about the messenger. But if not attacked simultaneously, Constantinople can not be conquered. The problem is actually difficult to solve.
There is a mathematical solution that works unless more than a third of the generals are traitors. A better solution that works regardless of the amount of traitors is Blockchain technology.
Suppose, the attack is on Wednesday at 5 pm. Any general can be the traitor. The messenger transports the message in an envelope, but does not know the content written in it.
General 1 sends his messenger with a message to General 2. General 2 reads and confirms the message (ok, we attack Monday at 5 pm) and sends him on to General 3. General 3 is the traitor. He writes a new note with a different time without the messenger seeing it (ok, we attack Monday at 7 pm). All other generals receive the wrong time. The attack will fail!
Now rules are set (think of protocols).
- Each general has 10 minutes of preparation for his confirmation to be valid
- Each general must add the confirmations received to his confirmation (history)
If under these conditions the messenger is sent by general 1, general 2 will work on his confirmation for exactly 10 minutes and add it to the first message. In the envelope of the messenger are now two papers that relate to each other (“chained”). If the third general now writes another time on his confirmation, it will take 10 minutes. It would take another 10 minutes to fake the other message. However, the messenger would note that it was said that an answer would take about 10 minutes. And above all, the first general would notice if the messenger came back later than expected.
This second strategy ensures that no one is cheating in the chain!
Such a message chain is similar to a chain of information blocks (blockchain).
The CAP theorem
The abbreviation CAP stands for Consistency, Availability and Partition tolerance. The CAP theorem states that it is impossible in a distributed system to simultaneously guarantee the three properties of consistency, availability and failure tolerance. Sounds complicated at first, but is easy to understand.
Let’s say I sell used cars.
The cars are on my premises and I have a list of all vehicles. When I sell a car, I strike it though on the list. My business is going well and I open another used car shop in the neighboring town. My friend Holger manages it and has a list of cars too. We agree to write all the cars we have on the list. When one of us sells a car, he calls the other one to tell that the car is no longer available. We also have only one phone number, which is forwarded to both phones. Everything is going great!
- Consistent: We are consistent because we always keep our sales lists updated.
- Available: We are available because we can be reached under one phone number. Either Holger or I takes the call.
- Partition tolerance: We are partition tolerant because the system works even if one of us gets sick.
Something happens one day and Holger is mad at me (I do not remember exactly what it was). He closes the shop and goes home, but he does not tell me that he sold two cars that day. Like coincidence, someone turns up in my office and buys one of the cars, Holger already sold. He pays in my office in advance and wants to pick up the car from Holger’s place … the disaster takes its course!
The CAP Theorem now states that it is not possible to guarantee all three properties at the same time. Here are another few examples:
Available and Failure Tolerant (AP)
Facebook and Twitter are always available (A) and partition tolerant (P). But they are not consistent (C). The news, comments. photos and likes are not immediately available to all users, but gradually spread throughout the system.
Cloud Computing and the Domain Name System on the Internet also fall into this category.
Consistent and Available (CA)
A relational database system should be consistent in the first place and, if possible, always available.
Consistent and Partitian tolerant (CP)
A bank that operates ATMs must ensure that the amount fetched from the vending machine is reliably debited from the account. The availability is not so important in this case.
Since it is impossible to guarantee concurrency of requirements in distributed systems one must find a consensus on the “state of affairs”. The Byzantine generals could be provided with simple rules, a true message to distinguish from a fake message. This was achieved through the compulsion to do something for 10 minutes. Consensus plays a very important role in blockchain technology. There are different approaches. The two most well-known approaches are the proof of a work done (proof of work – as with the generals) and proof of participation (proof of stake).
At this point it’s becoming quite technically, so we take a break.
In the next part we’ll have a deeper look at the way these proofs are carried out.