As discussed in Chapter one, the blockchain can be considered a tool for many uses. Purely distributed peer-to-peer systems are the basis on which blockchain seeks to establish integrity in all the use cases, that is, a whole and complete system without frauds. Many different technical details affect outcome, and all of these depend on the needed functionalities. Hence, the link between purely distributed peer-to-peer systems and the blockchain is its usage for “achieving and maintaining integrity in purely distributed peer-to-peer systems” (Drescher 2017).
The point behind blockchain that it abolishes intermediaries in a system. If we study logistics, there is large number of different intermediate systems through which data is transmitted, making mistakes, frauds, and errors more prominent. If all this can be replaced with a blockchain that is reputedly free of these ills, then there is a huge business potential. Therefore, blockchain itself does not achieve anything. It needs a business case in order to show its strengths, although there can also be non-commercial activities where blockchain can be used effectively.
On top of integrity, which relates to the technical system, one needs to also discuss trust, which is the human factor operating the system (e.g. Trautman and Molesky 2019). If there is no trust on the system, it will not be used. If the system functions without problems, then trust on the system will increase. Therefore, it is important to study blockchains’ functionality to make sure trust can generate over time.
To begin with, a peer-to-peer network has to serve for all the users in the system. These are called nodes or peers of the system. Some additional information on the peers is sometimes needed, depending on the usage of the network, but sometimes even the number of users is unknown. This is the case with e.g., Bitcoin. The less information system and its developers have on the users, the harder it is to safeguard the system in order to build trust.
When designing a blockchain, there are many different use cases to be considered. However, during the design, the different use cases can have similar characteristics which enable integrity design to succeed. On top of the designed functionalities, there can also be technical issues with the software and network that the system runs on, or problems with users that try to use the system incorrectly for their personal gain. Unknown technical failures are usually associated with the network that the system runs on. Therefore, finding ways around these issues is important in designing a blockchain. Furthermore, peers that try to use the designed system to generate frauded benefit for themselves needs to be considered. Luckily, these occurrences do not usually happen at the same time and blockchains have a very good reputation in handling them both.
Blockchains function in a peer-to-peer distributed system with a high integrity so that they are able to generate trust, including also an efficient design and handling of malfunctions. The problem solved by the blockchain however, is dependent on the specific use case. For financial transactions like Bitcoin, it is to secure all the data and make it immutable while making sure the system functions in a sound fashion in all the possible instances where peers try to use it for their unearned advantage. In logistics, the functionalities are very much the same, but now the data is not financial, rather it is about goods travelling to their destination. In tourism, these functionalities again occur but the data is about tickets, luggage and so on.
The core problem solved by a blockchain is therefore, to put it bluntly, how to store data in a public and immutable way. However, everything about this data is unknown: the number of peers, the amount of data, even the hardware that the data is stored on is unknown. The main benefit of using the blockchain in storing the data, however, is the robust way it handles different use cases. Even the most cunning hackers and malicious attacks have still not been able to take advantage of a blockchain based systems. There is one exception to this rule, called Ethereum, but we will get back to its specifics in Chapter 4 and 5.
We will next expand on the terminology because we are still in the process of negotiating what blockchain actually is. We know already enough of distributed peer-to-peer systems associated with blockchains, but there are at least the following terms that need further definitions (terminology from Drescher 2017):
The term “ledger” refers to the data stored safely and uniformly across the peers in the blockchain. All the peers should (and will, if the blockchain functions correctly) have an identical data on all the transactions occurred in the blockchain since it has been found.
“Algorithm” refers to the exact mathematical functioning of the blockchain, including how to get, store and distribute data, in which format and how to deal with missing or distorted data. As a blockchain works in a peer-to-peer distributed system, all the factors affecting the functions have to be included into the algorithm before starting the blockchain. These makes the system design a very demanding process.
The data that is stored in a blockchain is reordered into blocks. These blocks are “ordered and connected”, meaning, that there cannot be any additions in between the blocks, and that every block has the information on which block became before it.
To make the ledger, the algorithm and storing of blocks possible, the blockchain must have bulletproof “cryptographic and security technologies”. We will cover these technologies in the coming chapters, as they are very involved although almost simplistic in design. As there are more terminology to come, for now we can just imagine that these technologies are taken care of in the blockchains. In Chapter 3, we start dealing with cryptography by introducing some of the mathematics behind it.
For now, we can define blockchain as a software enabling a peer-to-peer, decentralized ledger that maintains its integrity cryptographically. The data is stored into ordered blocks utilizing different algorithms. (for related definitions, see Drescher 2017, 35 and Bashir 2018, 16).