In order to fully understand the nature of the much-hyped concept of blockchain, and what it can be used for–which is very different from how it is implemented–we need to understand the area of interest. It should not come as a big surprise that blockchain does not constitute anything new Per Se, but is rather application of existing theory and well known concepts in a novel way.
Nota Bene: Novel application of well-known techniques and theory is still novel.
Blockchain offers a new solution–in addition to the existing–to a well known problem: How to ensure arbitrament in disputes regarding “contracts” where the following (and only the following) needs to be settled:
- Does a “contract” exist related to this asset?, and
- Was contract X attached to the asset before contract Y?
The definition of “before” was described by Leslie Lamport in his seminal article Time, Clocks, and the Ordering of Events in a Distributed System in 1978. From this theory we known that a single entity can always provide a unique order of events, and that if there are more then one entity, it is impossible to establish one single order of events without arbitration. We will return to this later.
Typical examples of “contracts” are
- This property belongs to Alice;
- Bob possess the right to reside at this address;
- Alice claims that public key 0x123 belongs to Alice;
- Bob owes Alice two sheep, and
- If Bob does not give two sheep to Alice before Summer, he has forfeited his right to reside at this address.
The concept of a “contract”–or statement, if you like–does not depend on the physical properties of it. A sheet of paper is but one alternative. Furthermore, it is a matter of policy how those that enters the contract is to be identified (if all all). A contract may be “Alice will pay two sheep to the holder of the (digital) document with digital hash X”.
A solution to the original problem has been known since Roman times. The classical Notarius Publicus offered a service consisting of two concepts wrapped into one:
- A ledger (for norske lesere: en protokoll). In Norway there are many such ledgers; The Land register of ownership, encumbrances and cadastre (norsk: matrikkelen vedlikeholdt av Kartverket) is a classic public ledger;
- A physical personal filling the role of Notarius Publicus. He is trusted to:
- Only add to the ledger. That is, never erase or alter anything previously written;
- Add to the ledger anything pertinent in the order they arrive, obviously governed by policy (for norske lesere: protkollére) For example: To have an entry in written into the Land Registry, a fee must be paid, and
- Truthfully answer questions regarding the content of the ledger. How, under which conditions the ledger is to be available to the public is a matter of policy. For example, one reasonable policy would be that one could get hold of one particular entry if one knew an identifier. That is, “Please give me entry number X” or “Please give me all entries related to asset (property?) Y”. The ledger, or parts of it, might be available in full, not at all, for a fee, or whatever.
Whether contracts are true or not depend only on policy. The classical Notarius Publicus had among his duties to ensure that the named parties understood the contract’s consequences. But this need not at all be the case: If the contracts says that Alice claims that the public key 0x123 belongs to her, the only thing that is actually true, is the claim itself. Whether she actually holds the key is another matter all together. If statements are true or not (in the real world) is not a property of a ledger Per Se. Furthermore, a ledger is not in any way dependent on it being available to the general public.
What, precisely, can be written into the ledger? What is a contract? The ledger holding the Land Registry, for example, will not accept entries about public keys. It seems obvious, but a blockchain is (only) able to accept any digitally representation of a contract. “Things” that can not be represented digitally, such as signatures, can not be entered without a level of indirection; for example, the contract may say “A sheet of paper with Alice’s signature has been deposited in the National Archive in Mo i Rana”.
Numbering entries is crucial: If entry N says “Alice is the owner of property X”, an later entry that says “Bob is the owner of X” is probably not legit, unless there is an intermediate entry “Alice transfers the ownership of X to Bob.”. From this simple example, it is evident that the value of the ledger as a tool depend on it’s resistance against altering of previous entries.
Notarius Publicus must be trusted on his actions. Said in other way: We trust that the Notarius Publicus has the will and ability to act honestly (according to the rules). Trusting someone on his actions means one places trust in that he will not take bribes, or have personal interests in the content of the ledger. The classical means to that end has been to ensure the Public Notarius becomes rich if being trustworthy, or making it a public service (as in Norway). One need not trust Notarius Publicus on his opinions as there is no need for him to understand or verify claims. The essence of Notarium Publicus is thus the ledger itself, and a well-defined and universally understood policy for writing into it. The policy of writing may well inhibit some parties from submitting entries; typically, children are not allowed to write into the ledger documenting debts. That a ledger is still a ledger even if not all can write to it; ledgers are not exercises in democracy.
Blockchain realises a digital ledger. A ledger and a well-defined and universally understood policy for writing into the ledger. No more, but also no less.
There will always be costs associated with maintaining a ledger. The costs of maintaining a digital ledger with global availability for the general public with no delay for read-requests might be equally high as a paper based one with a non-trivial delay. As will be evident, there is no such thing as a free lunch!
To understand blockchain we must identify the properties needed to solve the original problem:
- Where is the ledger. That is to say: How can interested parties read (parts of) the ledger;
- What is the policy of writing to the ledger, and
- How are the two crucial properties upheld: Sequential addition, and no alteration of existing entries?
Then there is the cost: It is always helpful to understand who picks up the bill.
Before we continue, a primer on cryptography is absolutely necessary. There are (only) two concepts that needs to be understood: Hashing and asymmetric-key cryptography.
A hash of a (digital) document can for all practical purposes be though of as a digital fingerprint. Hashing is a well established technique; Knuth writes is was first used in 1953.
Each and every document has an unique fingerprint, and one particular fingerprint is associated with only one document. Even the tiniest change results in a completely different fingerprint. No information what so ever about the document can be learned from a fingerprint alone. In particular: If the document is long or short can not be gleaned from the fingerprint alone. However, since digital copies are identical, two copies of a document will have the same hash.
Some interesting solutions become possible:
- Assume Bob and Alice both hold a document, and Bob wants to convince himself that Alice in fact does holds it. He asks Alice to “Add X to the end of the document and send me the new fingerprint, please”. Upon receiving the fingerprint, he himself adds X to the document, calculates the correct fingerprint, and compares them. If the two prints are equal, Alice (in some way) must have access to the document;
- There is no need to enter a full document to a ledger, the fingerprint of a document is sufficient. This way, a document can be added to a ledger without adding the document itself, and, in particular,
- A chain of documents can be created. Each document simply include the fingerprint of the “previous” document. In such a chain, no document can be altered, removed, or added without having to change all later documents in the chain.
Make sure you understood the last point! Here is an example, where [this text] is a property and not entered in the ledger itself:
- “This is the first document. It is not a contract, but only used to bootstrap the chain.”. [Fingerprint of this document is 42]
- “This is document number 2. Alice claims to have public key 0x123. The previous document has number 1 and the fingerprint is 42.” [Fingerprint of this document is 56]
- “This is ducument 3. Bob is the owner of a digital coin with the value of 1 hour of CPU time. The previous document has number 2 and the fingeprint is 56.” [The fingerprint of this document is 12]
- “This is document 4. Charlie is the owner of the right to live on property X. The previous document has number 3 and the fingerprint is 12. [The fingerprint of this document is 67]
- And so on
To remove document 2, document 3 must be changed to the effect that it says the previous document was 1. However, this change will result in a new fingerprint, which means entry 4 must be changed, which in it’s turn…… An alteration of document 2 will lead it to have a new fingerprint. This means document 3 must be changed, and so on. From this simple example it should be evident how a ledger itself can be constructed. What is needed to reconstruct the function of a Notarius Publicus is a manner to “sign” each entry in the ledger; enter digital signatures.
Every person is supposed to be able to provided signatures on paper that are (more or less) identical every time. Even though the signature itself is the same, each one is attached to a different physical paper. So it does not matter if the signatures are identical since the physical properties of paper makes them distinct. Another important aspect of a signature is that it does not identify a person. It is for this particular reason that the name is always written in majuscules (“capital letters”) below the signature. All these properties are carried over to digital signatures. The concept of digital signatures are 40 years old this year.
It is possible to construct two (different) encryption keys that have a very particular property: What is encrypted by one can only be decrypted by the other. To see how this can be useful, assume Alice constructs two such keys X and Y. She gives Y to Bob. If Bob gets hold of a message that can be decrypted with the key Y, he can be certain that the message was encrypted by the key X. And since the key X is held by Alice, the message must originate with Alice. This is the central idea of digital signatures; needless to say: A considerable amount of technical and mathematical detail have been left out. Assume that Charlie finds the key Y (on Internet, most likely) but he does not know that Alice holds the corresponding key X. If Charlie finds a message that decrypts with the key Y, he knows it must have come from the holder of the key X. But he can not identify the holder of X from the fact that a message decrypts with the key Y. However, Alice can, at her own leisure, reviel her identity by telling Charlie “I have the key X. Send me anything, and I will encrypt it for you to verify”. Of course, Alice may hide behind any form of alias such as an email address. In any case, Alice can distribute the key Y to all that are interested (the community, as it were). All receivers will be able to verify that documents they have at hand are encrypted by the key X. We say that they can verify Alice’s digital signature on the document.
Let us for a moment digress, and pounder the question of how to reach agreement in a setting without a single, trusted arbiter. The purpose of this exercise is to forego the single (trusted) Notarius Publicus. If we have someone we trust, the problem becomes moot. Assume we have two, who together decides what is right and what is not. But if we receive two different answers, which one do we trust? If we trust one over the other, we are back to the Notarius Publicus solution and nothing has been gained. Knowing how to deal with different answers is a problem named The Byzantine Generals Problem, and was solved by Lamport, Shostak, and Pease in 1982. Basically, what you need is more than four peers that offer their opinion. The more peers, the harder it will be for anyone to corrupt the decision. It is a majority voting system, with quite a few technical aspects thrown into the stew. Technically speaking, the process of reaching a decision in this manner is called consensus.
With all this theory under our belt, let us examine IBMs blockchain offering. It is based on Linux foundation Hyperledger and is named Fabric. As we know how a ledger is put together, the interesting part is how decision are made on what to write into it. Fabric is “pluggable”, but the general idea is along those described by Lamport in 1982. In practice: Select a set of nodes (people) and they will, in concert, decide what is to be written in the leder. Fabric contains tools to
- Create a (distributed) ledger;
- Appoint the group who will decide what to be written into the ledger (that is, execute the process that is needed to reach consensus), and
- All the glue needed to hold it all together (APIs, libraries, protocol stacks, Et Cetera).
Now, if your system needs a ledger, and the system doesn’t have a Notarius Publicus (that is: Noone is trusted to have the will and ability to behave according to what is required), Hyperledger Fabric is for you. If your system does not need a ledger, it is not for you. Simple. As a side note: IBM is only one of many systems built on Hyperledger. If you need a ledger and know what you are doing, surf over to Hyperledger and get what you need.
The typical application of a ledger in the digital domain is those where it is used in the paper-based world such as financial transactions, and logging. All places where it is important to record in which order things are done.
To sum up this first part: A blockchain is a digital representation of the services offered by Notarius Publicus, without the human. The trust you can place in the ledger depends solely in the trust you place in the writer(s). If you have many peers with little (or no) interest in not acting correct cooperating in reaching a (shared) decision, your confidence might be stronger.
To understand what Bitcoin is, we first need to understand money (twice as much as you ever need to know can be found in ISBN 978-0609801727). Abstract: Money is whatever the participants agree is money. If we all agree that a note with the picture of a boat has the value of a sheep, it has. There is nothing more to it. But more to the case at hand: We can all agree that an entry in a particular ledger saying “The user who can encrypt messages so that it can be decrypted with key Y, has available 0.34 bitcoin” gives Alice (remember: Alice holds the key X) the purchasing power that might be behind 0.34 bitcoin. If Bob thinks that some good, a coffee, for example, has the value of 0.34 bitcoins (or less) Alice may buy it from him. To do so, she will write into the ledger: “Alice transfers 0.34 bitcoins to Bob”. The property of a ledger (entries are only added, never deleted, and never changed) ensures that Bob now own 0.34 bitcoins. By pointing to the ledger he can demonstrate that Alice transferred them to him.
Bitcoin is a combination of
- A blockchain, and
- A clever method of finding deciding what is written to the ledger
The clever idea is a combination of
- The only way to decide what is written to the ledger is by running a program for some time. The program searches for a specific manner to pack together entries into the ledger, and
- Part of what you pack together is an entry saying that you were awarded Bitcoin for the job you did
The result is that if you find the solution, the ledger will include, together with other entries, the entry awarding you Bitcoin. At any point in time, millions of computers are running the program in order to be the one who finds the correct way to package a set of entries. And since you are awarded Bitcoin if you succeed, you are very interested in ensuring that the result is spread and used.
Anyone can use the ledger provided by Bitcoin, but the main purpose is to record Bitcoin spending. Just as property can change hands in the Land registry, Bitcoins change hands by writing entry in the ledger to that effect.
Bitcoin was designed to be electronic money for the internet age. For this money to be useful, several properties must be meintained:
In addition, if you want to have something added to the ledger, you will have to pay a fee (in Bitcoin). The fee is awarded to those running the program. At the time of writing (June 2018) the fee for writing a 255 byte entry in the ledger about 7 NOK.
Finally — if you want to understand why a Bitcoin was worth USD 1 in 2011, 13 in 2012, 100 in 2013, 500 in 2014, and 18.000 in 2017, you need to read the book on money I cited earlier.