As we approach 2016 there seem to be endless discussions about ‘blockchain’. It’s a term that is ever-more frequently cited in even mainstream journalism, while in the FinTech space alone there are a slew of would-be suppliers and would-be users claiming that ‘blockchain’ will revolutionize any number of applications.
This now-common usage suggests it must be something precisely defined and well understood, but this seems to be more a matter of mantra than comprehension.
The echo chambers of the Internet reverberate to many opinions, but attempts to find a precise meaning seem to find a dismaying lack of agreement. To be anything more than marketing hyperbole we really need the answers some questions.
What is it? What isn’t it? What might it be? Can it be something that will allow us to build new and enduring systems? In short, what is the essence of blockchain?
The Satoshi white paper
Almost every discussion of blockchains starts with the Satoshi white paper, but it is this very foundation that starts us on a path to confusion. Neither the terms ‘blockchain’ or ‘block chain’ appear there; there are 67 uses of ‘block’ and 27 of ‘chain’, but zero of ‘block chain’ or ‘blockchain’. This aside though, let’s see where this origin leads us.
The white paper is short; it’s just nine pages long. The first mention of ‘block’ and ‘chain’ starts at the bottom of page 2, section 3, where there is a discussion of a basic timestamp server. Prior to this the white paper describes a series of design goals associated with the bitcoin design, such as the ability to allow two parties to transact without needing to trust a third party.
The statement of the design goals are fundamentally important. They set the scene for an implementation to meet those goals in which characteristics are layered upon each other, but it is informative to look at what each new layer does.
In our quest for the nature of a blockchain we need to be careful to look for things that are its attributes, rather than characteristics of this first implementation.
Section 1 of the white paper is an introduction and it is with section 2 that we see anything really substantive. Section 2 sets a scene for a digital coin, but it is described as being a chain of transactions in which the ‘coin’ is assigned to new owners. The coin is really a metaphor for a transaction history of linked transactions.
Interestingly, section 2 also describes how a centralized system doesn’t actually need to do this.
Blocks and chains
With section 3 we see the essence of the design pattern that might best describe the basis of a blockchain. It is given as something that is constructed from a series of incremental blocks of data, each of which can be identified by a cryptographic hash over its contents. In addition, each block incorporates the cryptographic hash of its predecessor block to ensure the construction of a chain.
The block hashes are published as a form of widely witnessed evidence that demonstrate shows the existence of both the block data and the predecessor hash. Changing either the predecessor or the other data within the block would result in a different hash signature for the block that would not match the widely witnessed view.
These characteristics are all fundamental, and without them we cannot construct anything interesting. What is equally interesting though is what is not stated as necessary at this point. There are no mentions of coins, no mentions of peer-to-peer networks, no mentions of mining, etc. Instead the suggestion is that publishing hashes in any widely disseminated form would be sufficient, with the two examples being given as publication in a newspaper or publication via Usenet.
While we see some explicit characteristics these lead to a few implicit ones:
Publication of the hashes is meaningless unless those same hashes can be independently recomputed by an external observer who is given just the data from the blocks in the chain. It is this characteristic that enables the observers to not have to trust the originator of the chain of blocks; instead they are able to compare historical hashes for themselves.
Recomputing of the hashes requires that the algorithm by which the blocks is produced be deterministic and well specified. Without these our external observer cannot recompute the hashes.